On Tuesday, December 13, 2011 16:35:08 Michel Fortin wrote: > Say you have a array-member property called "front" defined in > std.range (not hard to imagine) and an identical property called > "front" in another module and you import both modules: "array.front" > becomes ambiguous. With the function call syntax you can write > std.range.front(array) and other.module.front(array) as a substitute to > the property syntax to disambiguate, but if the property syntax is > enforced should calling the property as a function still be allowed for > array-member functions? Or should we invent a syntax such as > array.(other.module.front)?
Hmmm. Obviously, we either end up with a function that can't be called due to an ambiguity, or we need to find a way to resolve the ambiguity. And to resolve the ambiguity, we'd either have to allow for the property function to be called as a normal function or introduce a new syntax. Bleh. The simplest solution would be to simply have the function callable as a non- property function when there's such an ambiguity, but that does go against the whole "require a property function to be used as a property" thing. Your suggested syntax is pretty good, but it's not exactly a desirable solution either. I don't know. Given the simplicity of it and the fact that there's no way that you're going to change the property function to a member variable (since it's not like you can add it to arrays), allowing for it to be called as normal function seems like the better solution, albeit not exactly ideal. Free functions definitely complicate the whole property thing. - Jonathan M Davis
