DIP23 draft: Fixing properties redux

[David Nadlinger]

On Monday, 4 February 2013 at 03:15:51 UTC, David Nadlinger wrote:
> On Monday, 4 February 2013 at 03:11:25 UTC, Andrei Alexandrescu 
> wrote:
>> I really think you are wrong about this. Parenthesizing has 
>> nothing to do with this. &a.b is punctuation that creates an 
>> indivizible unit.
>
> a.b already is an indivisible unit, the result of the function 
> call.

Actually, let me illustrate this point a bit further, sorry for 
the hasty reply.

The problem I see is that usually, one can insert grouping pairs 
of parentheses into an expression according to the operator 
precedence/associativity rules at will without changing the 
result. This isn't merely a theoretical exercise, but the way 
(well, in the form of trees) I tend to reason about source code 
intuitively.

Now, grouping the expression »&a.b« according to the precedence 
rules yields »&(a.b)« – but in your proposal, they mean 
completely different things.

You could argue that &<expression>.<identifier> is a special 
construct different from the normal address-of operator. But 
where do you mentally draw the line? What about &a.b.c <-> 
&(a.b).c <-> &((a.b).c)? &(a + b).c <-> &((a + b).c)?

Again, from an user's perspective the change in behavior seems to 
be completely at odds with the usual rule in C-family languages 
that grouping parens can be added without changing the meaning of 
an expression. Thus, this part of the proposed syntax strikes me 
as being extremely misleading, which is especially bad because 
the situation with the two possible meanings is confusing enough 
to start out with already.

And how often do you think you'll find yourself in the situation 
of needing to get a delegate from a property anyway? Can't we 
just make »@property getter expressions are always equivalent to 
their return value« a hard (simple!) rule and add something like 
__traits(propertyGetter, ...) for the rare cases where you really 
need to get hold of the underlying function?

David