www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3981] New: More useful and more clean 'is'

reply d-bugmail puremagic.com writes:
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


--- Comment #0 from bearophile_hugs eml.cc 2010-03-17 07:29:20 PDT ---
(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
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3981



--- Comment #1 from bearophile_hugs eml.cc 2010-03-17 07:38:16 PDT ---
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3981



--- Comment #2 from bearophile_hugs eml.cc 2010-03-24 07:49:17 PDT ---
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3981



--- Comment #3 from bearophile_hugs eml.cc 2011-07-09 11:14:03 PDT ---
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3981


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yebblies gmail.com


--- Comment #4 from yebblies <yebblies gmail.com> 2011-07-16 19:39:29 EST ---
(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? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3981



--- Comment #5 from bearophile_hugs eml.cc 2011-07-16 18:00:39 PDT ---
(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? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 16 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3981


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME


--- Comment #6 from yebblies <yebblies gmail.com> 2012-02-15 16:47:44 EST ---
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