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.
