DIP23 draft: Fixing properties redux

[Andrei Alexandrescu]

On 2/3/13 11:00 PM, David Nadlinger wrote:
> 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.

Well this is going to sound bad, but you either use reason or intuition. 
I don't see how one can reason intuitively.

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

I agree they mean different things. I'm unclear that's a problem. All 
your examples stop here, there's no propagation of the issue. To take 
the address of a property, one writes &obj.prop. To take the address of 
a property's result, one writes &(obj.prop). And that's that. It all 
works with typeof.

> 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)?

That argument is easily destroyed. In a.b.c, a.b is the expression and c 
is the property name.

> 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.

I think we avoid much more bizarre things that way, such that expr and 
&expr meaning sometimes the same exact thing. Or that we have 
expressions without a type. And nobody blinks an eye. I just think we're 
better off.

> 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?

I don't see where the trouble is. If I thought the trait is necessary, 
I'd make it part of the proposal. Currently I don't see it as necessary, 
but I definitely can be convinced.


Andrei