DIP23 draft: Fixing properties redux

[Jonathan M Davis]

On Sunday, February 03, 2013 03:16:08 Andrei Alexandrescu wrote:
> Destroy.

Overall, it looks good. It sounds like it's basically arguing for fully 
implementing @property as intended save for the fact that parenless function 
calls on normal functions are allowed. And that's pretty much what I've been 
arguing for during all of this latest @property debate.

However, one issue that I'm concerned about with regards to properties which 
hasn't really been discussed much and which doesn't have a whole lot to do 
with how they're declared (but rather the syntax of how they're used) is how 
to handle symbol clashes. For instance, if you have the free function

auto prop(int[] arr) {...}

in module a.b.c, and you have

auto prop(int[] arr) {...}

in module a.d.e, how do you deal with code that does

import a.b.c;
import a.d.e;
auto var = arr.prop;

Syntactically, there's no way to indicate which of the two functions you mean. 
It's a problem that only occurs with free functions and UFCS (since with 
member functions, the member function wins in any conflict with a free 
function, and member functions on the same type can't be in different modules), 
but it's definitely something that can happen. And we really should come up 
with a fix for it. The best that I can think of at the moment is something like

auto var = arr.a.b.c.prop;

where you're trying to use a.b.c.prop, but I don't know if that's a good 
syntax or not. It could certainly cause problems if arr were a user-defined 
type with a property called arr, so maybe adding parens would help

auto var = arr.(a.b.c).prop;

but that's still a bit ugly. I don't know if there's a good way that _isn't_ 
ugly though. I suppose that we could get away with arguing that symbol 
renaming would be required

alias a.b.c.prop myprop;
auto var = arr.myprop;

but I don't know that that's a great solution either. AFAIK though, it's the 
only way that we have to deal with the problem right now.

- Jonathan M Davis