A proper WAT moment

[Paul Backus]

On Tuesday, 15 October 2019 at 09:34:41 UTC, Simen Kjærås wrote:
> void fun() {
>     pragma(msg, __LINE__, " ", 
> __traits(compiles,__traits(getMember, S, "e")));
> }

__traits(compiles) is lying to you again. If you replace it with

__traits(getMember, S, "e")

...you'll get an error.


> Interestingly, the code does of course actually compile:
>
> struct S3 {
>     void fun() {
>         alias a = __traits(getMember, S, "e");
>     }
> }

I think this is the key. It compiles if you put it on the 
right-hand side of an alias declaration, but *not* if you write 
it as a bare expression:

struct S3 {
     void fun() {
         __traits(getMember, S, "e"); // Error
     }
}

The difference is that in an alias declaration, 
__traits(getMember) isn't evaluated as a function call, whereas 
in a naked expression, it is. So the question becomes, why is 
__traits(getMember) evaluating @property functions differently in 
different contexts?

I suspect the answer has to do with the difference between the 
two error messages. In the context of a free function, it's "need 
`this` for `e`"--i.e., you're calling a member function without a 
receiver--so the compiler can infer that you didn't mean to call 
the function at all. In the context of a member function, 
however, it's "`this` needs to be type `S`, not `S2`"--i.e., 
you're (implicitly) calling a member function on the wrong type 
of receiver--so the compiler treats it the same as any other 
function call with incorrect arguments, and assumes you actually 
meant it.

Of course, this is speculation; it would take looking at the 
compiler source to be sure.