proposal to disambiguate &a.fun: disable optional parenthesis INSIDE &() expression

[FG]

On 2013-02-04 15:42, Timon Gehr wrote:
> On 02/04/2013 02:37 PM, FG wrote:
>> ...
>> The change in behavior of &(expr) makes sense in the light that "expr"
>> should behave the same in every context, not just in &(...), i.e. call foo().
>> ...
>
> The entire optional parens/@property thing is about (limited) context-dependent
> behaviour! This line of reasoning is simply wrong.
>
> There is no difference whatsoever between &expr and &(expr).

Indeed, currently there isn't and, considering the use of optional parentheses
for delimiting and grouping, it also makes sense to treat &expr as &(expr).
Oh, wait, no -- this leads straight to the OP's idea, which is:
Rule of optional parentheses omission doesn't work in the context of '&'.

Properties on the other hand need a different kind of treatment here.
Forcing properties to also use parentheses here is a bad idea:

     &obj.prop;   // a delegate?
     &obj.prop(); // address of the returned referenced data?

Bad! This would make some typical code awkward:

     void* p1 = &someRange.retro.front;
         // suddenly it's a function pointer, not pointer to the element :(

     void* p2 = &someRange.retro.front();
         // but having to add () just feels wrong.


Therefore it's better for &prop to become the address of return data
and to use some __traits or special member (like prop.__delegate)
for taking address of the property:

     auto a = &someRange.retro.front;           // address of element, yay
     auto b = someRange.retro.front.__delegate; // a delegate of front

Simple enough?
To specify exactly which prop we want it could even become:

     prop.__delegate(RetType, FirstArgType, SecondArgType)