@property (again)

[Timon Gehr]

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.