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".
