hasDataMember and mixin inconsistency

[Olivier Grant]

On Sunday, 27 January 2013 at 09:49:33 UTC, Philippe Sigaud wrote:
> Hi,
>
> If think in your code, your testing whether or a not a 
> mixin("...")
> statement is valid D. Which it is.

But what I'm surprised by is that the behavior of hasDataMember
with my implementation works fine for all test cases except
hasDataMember!(Test, "init"). If it was only testing whether the
mixin statement was well formed or not, shouldn't my
implementation of hasDataMember always return true ? What's more
confusing is that it seems to work properly for all test cases
except a built-in property of a structure :

assert(!hasDataMember!(long, "init")); // This succeeds.
assert(!hasDataMember!(Test, "init")); // This fails.

> I'd put the mixin externally:
>
> template hasDataMember( T, string M )
> {
>    mixin("
>    enum hasDataMember = __traits(
>       compiles,
>       ( ref T x, ref T y ){ x." ~ M ~ " = y." ~ M ~ "; }
>    );");
> }

I've just tried that and it unfortunately does not work, the same
test case still fails.

> Also, I suppose the Test inner struct is not visible from the
> hasDataMember template. The template is instantiated where it's
> declared, not where it's called. You could use a mixin 
> template, I
> guess.

I'm not sure at all what you mean by that. I thought all symbols
within a source file were visible irrespective of their order or
scope? Also, the test failure is on the Test structure directly,
not its inner structure A.

> I'd use a string mixin, but then I was converted to string 
> mixins a
> few years ago :)
>
> string hasDataMember( T )(string M )
> {
>     return " __traits(compiles, {
>         Test t;
>         auto _ = t.D; // reading t.M
>         t." ~ M ~ " = t." ~ M ~ "; // assign to t.M
>     })";
> }
>
> using is a bit more noisy than your solution: 
> mixin(hadDataMember!(Test)("M"))

I've tried that as well and it still fails on the same test case
again.

>> And it works pretty well, but it gets the wrong result for the 
>> following
>> test case which is commented out. Originally, I thought maybe 
>> you were
>> allowed to write to the .init member of structures, but 
>> writing the same
>> code directly without relying on a mixin actually yields the 
>> right result
>> (all the asserts pass)
>
> You cannot write to .init, it's not a member. It's a built-in
> property, like .sizeof or .offsetof.

Makes sense.

>> 2) Is there a better way to check for the existence of a data 
>> member ?
>
> If by data member, you mean some symbol that can be read and 
> written
> to, then I'd test just that. See the string mixin before: it 
> tests for
> existence, reading and writing.

Could this be a compiler bug by any chance? It seems really weird
that the template would work for intrinsic types but not for
structure, especially when the exact same template without the
use of mixin works fine.

Thanks again for your help.