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)
