On Monday, 4 February 2013 at 05:32:39 UTC, Andrei Alexandrescu
wrote:
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.
[SNIP]
Andrei
It was my understanding that once a function is declared a
property, it is meant to emulate a field. In such circumstance,
there were talks about plain and simply not allowing taking the
address of an @property function.
2 questions:
1. Was this proposal rejected, or have we just forgotten about it?
2. What are the actual use cases for taking the address of a
property function?
Unless I'm mistaken, the "entire mess" of &a.b would be solved if
we simply recognized it as "but you aren't allowed to take the
address of the function b, so why have a syntax to support it
anyways"? In such circumstance, "&a.b" == "&(a.b)" == "the
address of the thing obtaining by running a.b"
