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
