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

[monarch_dodra]

On Monday, 4 February 2013 at 10:09:09 UTC, timotheecour wrote:
> There's current disagreement regarding the syntax &a.fun, as it 
> makes &a.fun be different from &(a.fun):
> &a.fun   : address of member function
> &(a.fun) : address of return value of a.fun
>
> This breaks the usual rules of scoping and makes the expression 
> &a.fun special. More complex cases can arise, eg: &a.b.c, 
> &(a+b).c, etc as pointed out by others, plus who knows what 
> else might come up in practice.
>
> Here's a very simple proposal:
>
> for anything INSIDE &() operator, optional parenthesis are NOT 
> allowed:
>
> &(fun) : address of function fun
> &(a.fun) : address of member function fun (different from DIP23)
> &(a.fun()) : address of element returned by a.fun()
> &fun : same as &(fun)
>
> Now when fun is a @property: I would propose to break one rule 
> to make everything else more consistent: treat properties as 
> normal functions inside the &() operator, so that we can 
> distinguish as above the address of property vs adress of 
> return type. This is the only time a property can be called 
> with parens: eg
> &(a.fun) : address of property fun
> &(a.fun()) : address of return type of property fun
>
>
> The last point of this proposal is what to do with the 
> expression without parens:
> &a.fun : current behavior in DIP23: address of member function 
> fun
> proposed behavior: there are 3 options, please chime in:
>
> A1) disallow this with compile time error, forcing user to 
> disambiguate as:
>  - (&a).fun
>  - &(a.fun)
>  - &(a.fun())
>
> A2) interpret it as : (&a).fun, which would make the rule for 
> "&" consistent with the rule for template "!" operator: 
> B!double.x <=> (B!(double)).x)
> ----
> template B(T){	T x; }
> void main(){assert(is(typeof(B!double.x) == double)); //same as 
> (B!(double)).x) }
> ----
>
> A3) decide whether to interpret it as address of function or of 
> return type, but again, the user  can disambiguate with the 
> preferred &() syntax.

As I asked in the other thread: What is the point of even 
allowing taking the address of a property function? If a property 
is designed as something that can encapsulate and emulate a 
field, then it makes to sense to get the address of the getter 
(As far as I can tell).

If we already have optional parenthesis, then why even bother 
having property getters? They would end up being exactly the same 
thing as a normal function...

I say that if "b" is a property, then "a.b" should mean "the 
thing returned by b", *regardless of context*. Simple as that:
"&a.b"   => address of what is gotten with "a.b"
"&(a.b)" => address of what is gotten with "a.b"

Simple, no?

As for "how do I take the address of the function b": "You can't".