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
