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

[timotheecour]

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.