@property Incorrectly Implemented?
Ethan Watson via Digitalmars-d
digitalmars-d at puremagic.com
Mon Sep 12 00:38:37 PDT 2016
On Sunday, 11 September 2016 at 23:31:54 UTC, Timon Gehr wrote:
> His property returns by ref.
Irrelevant for the implementation details of properties. Ref in
that context specifies a function property that makes the
property function return by ref (wrap your head around that one).
That entire post went in to detail about why treating properties
as the functions they are is correct.
> You do realize that typeof(property) is the type of the return
> value, right? Also, it's easy. Add __traits(isVariable,...) or
> __traits(isProperty,...), or just use .tupleof. Furthermore you
> can even get the property accessor function overload set using
> (a hypothetical) __traits(getPropertyAccessors,...).
You are correct. typeof( __traits( getMember, Type, PropertyName
) ) is the type of the return type of the function, since
getMember forms a complete expression which evaluates down to the
Note that all of the __traits( is<X>Function ) return true
correctly on these things though. This is one of the checks I
have to make when parsing over a class to correctly determine
what is and isn't actually a variable. I've even wrapped it all
up in a trait called IsVariable. The std library has traits for
checking types but nothing that straight up tells you if
something is a variable or not.
As such, who needs __traits( getPropertyAccessors ) when
__traits( getOverloads ) already works?
> [Commentary on example]
Actually, I take back what I said. Mostly because of typeof( t.x
). The thing that needs fixing is the property evaluation order
so that ambiguities like all of this don't exist.
More information about the Digitalmars-d