DIP23 draft: Fixing properties redux

[Steven Schveighoffer]

On Mon, 04 Feb 2013 06:47:26 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 2/4/13 2:10 AM, monarch_dodra wrote:
>> It was my understanding that once a function is declared a property, it
>> is meant to emulate a field. In such circumstance, there were talks
>> about plain and simply not allowing taking the address of an @property
>> function.
>>
>> 2 questions:
>>
>> 1. Was this proposal rejected, or have we just forgotten about it?
>
> Well I at least haven't forgotten. Generally in D we don't want to 100%  
> disallow doing something sensible.
>
>> 2. What are the actual use cases for taking the address of a property
>> function?

Basically any time you have a use case for creating a delegate that  
returns a field or a property value.  Instead of creating a wrapping  
delegate to call a function, it would make more sense to access the  
delegate directly.  In other words, the use case isn't important, what we  
are doing here is creating an optimization.

If the compiler could do that automatically, I think that would be fine  
too.

>>
>> Unless I'm mistaken, the "entire mess" of &a.b would be solved if we
>> simply recognized it as "but you aren't allowed to take the address of
>> the function b, so why have a syntax to support it anyways"? In such
>> circumstance, "&a.b" == "&(a.b)" == "the address of the thing obtaining
>> by running a.b"
>
> Yes, if we disallowed address taking things would get a bit simpler.

Elsewhere you shot down my idea of __traits(getDelegate) generically  
because we already have this possibility:

void foo(int) {}
void foo(string) {}

void delegate(string) dg = &foo; // select string overload

What if we use the same exception for properties?

@property int foo();

auto x = &foo; // error
int delegate() x = &foo; // ok

-Steve