@property Incorrectly Implemented?

[Ethan Watson via Digitalmars-d]

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 
return type.

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.