On 11/08/2013 02:31 PM, Wyatt wrote:
[3] http://wiki.dlang.org/DIP23 No, I won't ever give up. This is
important. :<
Please do. Excerpts:
struct S
{
@property Type foo(); // formal getter
@property void bar(Type); // formal setter
@property ref Type baz(); // ref return getter == auxiliary setter
}
// Taking the address reveals the delegate
static assert(is(typeof(&s.foo) == ref Type delegate()));
// Changing precedence with parens reveals the returned type
static assert(is(typeof(&(s.foo)) == Type*));
// ---
struct S
{
Type foo(); // 0-arg function
void bar(Type n); // 1-arg function
ref Type baz(); // 0-arg ref return function
}
// Getting address of delegate
static assert(is(typeof(&s.baz) == ref Type delegate()));
// Getting address of return
static assert(is(typeof(&(s.baz)) == Type*));
It completely beats me how anyone can consider this a good idea.
Seriously, this is broken. Furthermore, the DIP is too informal and
fails to handle all relevant cases. I'd rather get rid of @property
completely than to approve of DIP23.
See http://wiki.dlang.org/DIP24 (TLDR: The full proposal makes
@properties behave like ordinary variables except that their address
cannot be taken and there could be more postblit/destructor invocations
in a given expression. There is a __traits to get the underlying
getter/setter function symbols for properties.)
