Is it safe to use 'is' to compare types?

[Steven Schveighoffer via Digitalmars-d-learn]

On 3/4/16 4:30 PM, Yuxuan Shui wrote:
> On Friday, 4 March 2016 at 15:18:55 UTC, Steven Schveighoffer wrote:
>> On 3/3/16 6:58 PM, Yuxuan Shui wrote:
>>> On Thursday, 3 March 2016 at 23:51:16 UTC, Adam D. Ruppe wrote:
>>>> On Thursday, 3 March 2016 at 23:46:50 UTC, Yuxuan Shui wrote:
>>>>> Will typeid(a) is typeid(b) yield different results than typeid(a) ==
>>>>> typeid(b)?
>>>>
>>>> No. Indeed, opEquals on TypeInfo just calls is itself.
>>>
>>> But opEquals also has extra comparison:
>>>
>>>          auto ti = cast(const TypeInfo)o;
>>>          return ti && this.toString() == ti.toString();
>>>
>>> This makes me feel they are not the same.
>>
>> In some cases, for instance using DLLs, the TypeInfo for an object
>> allocated in one way may be identical, but be a different instance
>> from the TypeInfo allocated in another way. This is why the string
>> comparison occurs.
>>
>> Note that comparing ANY object will first check if they are the same
>> instance before calling any functions (this is in object.opEquals)
>>
>
> Thanks for answering. But I still don't understand why TypeInfo would
> need to be allocated. Aren't typeid() just returning references to the
> __DxxTypeInfo_xxxx__initZ symbol?

You misunderstood, I meant the typeinfo *for* an allocated object, not 
that the typeinfo was allocated.

In some cases, 2 different objects allocated from different libraries 
(usually DLL-land) may reference TypeInfo from different segments, even 
though the TypeInfo is identical.

-Steve