User-defined "opIs"

via Digitalmars-d digitalmars-d at puremagic.com
Sun Sep 28 03:44:47 PDT 2014


On Saturday, 27 September 2014 at 11:38:51 UTC, Marco Leise wrote:
> I'm against overloading identity checking, too. Instead I
> would propose to change its definition to make Proxy structs
> work. The rules are currently:
>
>   For class objects, identity is defined as the object
>   references are for the same object. Null class objects can
>   be compared with is.
>
>   For struct objects, identity is defined as the bits in the
>   struct being identical.
>
>   For static and dynamic arrays, identity is defined as
>   referring to the same array elements and the same number of
>   elements.
>
>   For other operand types, identity is defined as being the
>   same as equality.
>
> If we changed that to:
>
>   A byte for byte comparison of both operands is performed.
>   For reference types this is the reference itself.

Maybe allow this only for types that somehow implicitly convert 
to each other, i.e. via alias this?

>
> Breakage is limited to current uses of "is" that clone the
> behavior of "==", which a deprecation warning could catch.
> And to comparisons of slices with static arrays. (You'd have
> to write `dynamicArr is staticArr[]` then.)
> This is all comprehensible since you need to be educated about
> the difference between value types and reference types anyways.
> What it breaks it makes good for by allowing these to compare
> equal:
>
> struct CrcProxy { ubyte[4] value; }
>
> CrcProxy crc32a;
> ubyte[4] crc32b;
>
> assert (crc32a is crc32b); // Yes, it is byte identical.
>
> If empowering structs to fully emulate built-in types is still
> on the agenda it might be the way of least resistance.



More information about the Digitalmars-d mailing list