On Thursday, 27 September 2018 at 14:23:48 UTC, Steven Schveighoffer wrote:
> On 9/27/18 10:20 AM, Steven Schveighoffer wrote:
>> typeid sometimes gives you a more derived type than TypeInfo. Including for classes and structs.
>> 
>> In the past, .classinfo gave you a different thing than typeid(obj), but now it is the same thing:
>> 
>> 
>>      auto obj = new Object;
>>      // classinfo and typeid are the same object
>>      assert(obj.classinfo is typeid(obj));
>>      // and the same type
>>      static assert(is(typeof(obj.classinfo) == typeof(typeid(obj))));
>> 
>> I wouldn't use classinfo any more, I generally use typeid.
>
> I should add that typeid does give you the derived TypeInfo_Class, not the concrete one.
>
> that is:
>
> Object obj; // = null
>
> //typeid(obj); // segfault, can't dereference null pointer
>
> class C {}
>
> obj = new C;
>
> static assert(is(typeof(obj) == Object));
>
> writeln(typeid(obj)); // C, not Object
>
> So it really is a drop-in replacement for classinfo. I think classinfo is still there to avoid breaking existing code that uses it.
>
> -Steve

Interesting!  That's yet another thing I hadn't realized had changed.  Good to know.

On Thursday, 27 September 2018 at 13:23:15 UTC, Adam D. Ruppe wrote:
> On Thursday, 27 September 2018 at 05:04:09 UTC, Chad Joan wrote:
>> As above, I think this might be a very clean and effective solution for a different class of use-cases :)  I'll keep it in mind though.
>
> Yeah. And I did make one mistake: the tupleof assignment trick wouldn't work well for references, so lol it isn't much of a deep copy. You'd want to deep copy any arrays too probably.
>
> But sounds like you are already doing that, yay.

You're right though, if I end up adding boilerplate anyways, I may as well have a good shallow copy to begin with.

On Thursday, 27 September 2018 at 09:58:25 UTC, Jonathan M Davis wrote:
>
> For two types to be compared, they must be the the same type - or they must be implicitly convertible to the same type, in which case, they're converted to that type and then compared. So, as far as D's design of comparison goes, there is no need worry about comparing differing types. At most, you need to worry about what implicit type conversions exist, and D isn't big on implicit type conversions, because they tend to cause subtle bugs. So, while they definitely affect comparison, they don't affect anywhere near as much as they would in a language like C++. In general, you're not going to get very far if you're trying to make it possible to compare a user-defined type against other types in D without explicitly converting it first.
>
> - Jonathan M Davis

That makes sense, but requiring types to be explicitly converted before comparisons kinda throws sand on the cake when I'm ostensibly trying to make things that interact seamlessly with existing types.

"alias this" is still awesome, so it's usually fine regardless :)

Thanks for the explanation.