hasDataMember and mixin inconsistency

[Olivier Grant]

On Monday, 28 January 2013 at 20:21:19 UTC, Philippe Sigaud wrote:
>>> Just testing whether t.M can be assigned to something (ie, is 
>>> it a value?)
>>> I use '_' as a variable name to indicate I don't care for 
>>> it's precise
>>> name/value. It's just a placeholder.
>>
>>
>> Ok, I must be missing something, why "t.D" or is this just a 
>> typo?
>
> Ark, typo, sorry about that.
>
>
>> And secondly wouldn't "x.M = y.M" take care of checking that 
>> the member can be
>> read and written to ?
>
> t.M = t.M? Yes, you're right.
>
>> Also, doesn't your solution require T to be default 
>> constructible ?
>
> Yes, but if a type is not default-constructible, I don't know 
> how to test it.
> Maybe testing on typeof(T.M)?

My solution to that was to try and compile the definition of a 
delegate :

__traits(
    compiles,
    "( ref T x ){ x." ~ M ~ " = x." ~ M ~ "; }"
);

I had originally provided two arguments to the delegate (using "( 
ref T x, ref T y){ x.M = y.M; }") to avoid self assignment but 
It's not necessary. This seems to work as it returns the right 
result and does not require T to be default constructible.

Just thought of the fact that I didn't try this with a class (I 
don't know if you're allowed to write "ref T x" if T == class), 
but you can always specialize hasDataMember with constraints or 
use static if.

>>> Using 2.061 here.
>>
>>
>> Well that was the problem! I was still using 2.060 which seems 
>> to have the
>> bug. Now that I've moved to 2.061 everything works as expected 
>> (your
>> implementation and mine).
>
> Great!

Many thanks for your help on this again.