The "is" operator is defined for built-in references and for slices. However, user-defined smart references and slices want to define it as well to integrate properly with built-in slices.
The definition of opIs should follow that of opIn.
Comment #1 by smjg — 2008-09-09T16:56:54Z
I think that having opIs is philosophically wrong. The whole point of is is to override any type-defined equality operator by forcing a byte-for-byte comparison. There are probably plenty of template libraries and the like that rely on this.
What are these "user-defined smart references", anyway?
Comment #2 by 2korden — 2008-09-10T04:25:39Z
An example of "user-defined smart references" would be a ScopePtr!(T) that destroys an object when it goes out of the scope. Some reference-counted smart pointer also behaves just like an ordinary point and one would like to be able to compare SmartPtr against null using "is null" syntax:
auto ptr = SmartPtr!(MyClass)(new MyClass());
assert(ptr !is null);
Comment #3 by smjg — 2008-09-10T05:23:58Z
(In reply to comment #2)
> auto ptr = SmartPtr!(MyClass)(new MyClass());
> assert(ptr !is null);
Hang on ... is this a smart _pointer_ or a smart _reference_?
If a pointer, it makes no sense to use is to compare them as pointing to the same object. And even if it's a reference, what practical use is there in being able to use is for this? ISTM it would break more generic programming cases than it would open up.
Comment #4 by dlang-bugzilla — 2017-07-19T05:02:36Z
(In reply to Stewart Gordon from comment #1)
> I think that having opIs is philosophically wrong. The whole point of is is
> to override any type-defined equality operator by forcing a byte-for-byte
> comparison. There are probably plenty of template libraries and the like
> that rely on this.
Agreed. Currently `is` provides a guarantee that it compares bits and will never invoke any other user-defined comparison mechanisms. This applies to user-defined types (structs, classes) as well as floating-point types (where x==x may not always be true due to NaNs). An opIs operator would break that guarantee.
User-defined smart references and slices could instead expose identity comparison via a ".ptr" property, which could then be compared using `==` or `is`.
Also, I understand that such language additions would need to be done via a DIP today.
@Andrei: I'll close this (also because this issue is close to a decade old), but please reopen if you disagree.