digitalmars.D.bugs - [Issue 3981] New: More useful and more clean 'is'
- d-bugmail puremagic.com (75/75) Mar 17 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3981
- d-bugmail puremagic.com (8/8) Mar 17 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3981
- d-bugmail puremagic.com (9/9) Mar 24 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3981
- d-bugmail puremagic.com (8/8) Jul 09 2011 http://d.puremagic.com/issues/show_bug.cgi?id=3981
- d-bugmail puremagic.com (12/16) Jul 16 2011 http://d.puremagic.com/issues/show_bug.cgi?id=3981
- d-bugmail puremagic.com (8/10) Jul 16 2011 http://d.puremagic.com/issues/show_bug.cgi?id=3981
- d-bugmail puremagic.com (12/12) Feb 14 2012 http://d.puremagic.com/issues/show_bug.cgi?id=3981
http://d.puremagic.com/issues/show_bug.cgi?id=3981 Summary: More useful and more clean 'is' Product: D Version: future Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: bearophile_hugs eml.cc (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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 17 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3981 So this assert should never fail (from a comment by grauzone): T x; assert(x is T.init); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 17 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3981 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 24 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3981 Bug 3632 implements this for floating point values (it's not truly bitwise when they are NaN). "some_struct is some_struct" seems useful. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 09 2011
http://d.puremagic.com/issues/show_bug.cgi?id=3981 yebblies <yebblies gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |yebblies gmail.comBug 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? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 16 2011
http://d.puremagic.com/issues/show_bug.cgi?id=3981struct 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? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 16 2011
http://d.puremagic.com/issues/show_bug.cgi?id=3981 yebblies <yebblies gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME I think everything in the original report is either working or covered by other bug reports (eg issue 3632, meta namespace proposal) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 14 2012