Bug 3981 – More useful and more clean 'is'

(Most of this was not an idea of mine.) The semantics of the 'is' operator can be improved, to remove special cases and make this operator more useful: 'is' can always perform a bytewise comparison. So: - "class_reference is class_reference" compares the values of the two references (as now). - "integral_value is integral_value" or "bool_value is bool_value" performs the normal == among them. - "floating_point is floating_point" or "complex_number is complex_number" (and the same with imaginary values) perform the bitwise comparison of the two floating point values, so "floating_point is nan" and "floating_point is float.nan" are allowed and "-0.0 is 0.0" is false. - "some_struct is some_struct" performs the lexicographic comparison of the bytes of the struct. It never calls the opEquals (if the struct contains a float it's compared bitwise, so this is not so commonly useful). (So the "some_struct == some_struct" can call opEquals, or when it's missing it can ignore the alignment holes in the struct). - "some_char is some_char" performs the bitwise comparison, like for integral values. (So the "some_char == some_char" can perform a smarter comparison, among chars of differenze length too). - "associative_array is associative_array" compares just the reference to the AA. - "array is array" compares just the struct that contains the pointer and length. - "something is void" can be disallowed. - "some_delegate is some_delegate" compares just the struct. - "some_function_pointer is some_function_pointer" compares just the pointer. Optionally: - If possible "some_type == some_type" can be equivalent to "is(some_type == some_type)", so the second syntax can be removed/deprecated. (If this is too much complex to implement then ignore this). The "is" operator can't be overloaded. -------------------- The is expression can be simplified, it's unreadable and it does too many different things. Some of its usages can be removed and replaced by __traits or with functions in the std.traits module with a better name, each one specialized for just a purpose: http://www.digitalmars.com/d/2.0/expression.html#IsExpression Case 2: The is(Type : TypeSpecialization) can be done with a function in the std.traits module. Case 3: is(Type == TypeSpecialization) is better written as Type==TypeSpecialization, but I think this can be a little hard for the compiler, so this case can be kept. Case 4: is(Type Identifier) can be removed, the same thing can be done with an is(Type) inside a static if followed by an alias. static if (is(bar T)) { ... } else { ... } ==> static if (is(bar)) { alias bar T; ... } else { ... } The case 7 is so complex (and probably not so common) that can be better to move this purpose elsewhere.

So this assert should never fail (from a comment by grauzone): T x; assert(x is T.init);

Don reminds us that there are many different NaNs, so "is nan" is not good. "x is double.init" can be OK to detect uninitialized variables. Eventually, "x == nan" can perform the smart comparison, testing if x is any of the many possible nan values.

Bug 3632 implements this for floating point values (it's not truly bitwise when they are NaN). "some_struct is some_struct" seems useful.

(In reply to comment #3) > Bug 3632 implements this for floating point values (it's not truly bitwise when > they are NaN). > > "some_struct is some_struct" seems useful. struct is struct already does a bitwise comparison. Is that what you were asking for?

(In reply to comment #4) > struct is struct already does a bitwise comparison. Is that what you were > asking for? Right, I didn't know this, thank you. So what's missing from my original list?

I think everything in the original report is either working or covered by other bug reports (eg issue 3632, meta namespace proposal)