On 11/21/2013 03:26 PM, John Colvin wrote:
On Thursday, 21 November 2013 at 14:19:22 UTC, Wyatt wrote:
On Thursday, 21 November 2013 at 13:04:21 UTC, John Colvin wrote:
3) properties decay to normal functions when they have their address
taken
Is there some reason why we _need_ to be able to take the address of
properties? I've yet to see a good argument in favour of it, and I've
seen several against. I think that whole idea is a misfeature that
won't be missed.
-Wyatt
Are there any arguments against it within the context of the proposal
i'm making?
There is always this:
ref int foo(){ return b?x:y; }
&foo
(i.e. return values can have addresses as well.)
http://wiki.dlang.org/DIP24
See 'basic design' for my take on it.
&__traits(propertyAccessors, foo) would get the address of the
underlying function. IMO one could just encourage usage of ()ref=>foo,
(int x)=>foo=x and allow/require the compiler to perform η-reduction though.
At the very least the obvious problems disappear.
If the consensus was that the address of a property was an unnecessary
concept then it could be disallowed and point 3) of my list disregarded.
The rest stands separate from this issue.
It is not unnecessary, but making unary '&' get a function pointer to
the accessor is not really behaviour consistent with the point of the
@property annotation.
