If I had my way

[Jonathan M Davis]

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