DIP23 draft: Fixing properties redux

[monarch_dodra]

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"