On Mon, 04 Feb 2013 06:47:26 -0500, Andrei Alexandrescu
<[email protected]> 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
