www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 11858] New: Comparison of unconnected classes using `is` must be disallowed

reply d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11858

           Summary: Comparison of unconnected classes using `is` must be
                    disallowed
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: accepts-invalid
          Severity: major
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: verylonglogin.reg gmail.com



19:49:31 MSK ---
Comparison of unconnected classes using `is` is definitely a mistake. If one
want to do such raw things for some reason, he has to cast to e.g. `Object` or
`void*` first. Currently such construction is allowed even in ` safe` code.

This code should compile:
---
class A { }
class B { }

void main()
{
    A a;
    B b;
    static assert(!__traits(compiles, a is b)); // fails
}
---

As a result of the issue it's to easy to make a mistake like `a.prop1 is b`
instead of `a.prop1.owner is b`. Also a refactoring of class hierarchy by
segregating subclasses becomes a nightmare as you get no errors from type
system in situations when you e.g. forget to change `find` predicate.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 02 2014
next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11858


Andrej Mitrovic <andrej.mitrovich gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich gmail.com



13:10:49 PST ---
I think this would definitely catch some bugs. I wonder what kind of impact it
would have on code breakage though (perhaps we would go through a warning phase
first). 

There is definitely a precedent:

-----
void main()
{
    int* a;
    float* b;
    static assert(!__traits(compiles, a is b)); // ok, not allowed
}
-----

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 02 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11858


Stewart Gordon <smjg iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|accepts-invalid             |
                 CC|                            |smjg iname.com
           Severity|major                       |enhancement



This isn't accepts-invalid, because there's no rule against it.  It's an
enhancement request.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 03 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11858


Denis Shelomovskij <verylonglogin.reg gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|enhancement                 |major



19:20:19 MSK ---


 This isn't accepts-invalid, because there's no rule against it.  It's an
 enhancement request.


It's still a bug as current dmd behaviour is inconsistent as if both types are
qualified the compiler rejects such comparison.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 05 2014
prev sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11858


Stewart Gordon <smjg iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |spec



Hmm.  There's a concept of a reinterpret cast with pointers, so an int* and a
float* can feasibly be pointing to the same memory address.  Since it's far
less likely that this will be done with object references, I see now that it
would need to be at least as strict to make sense.

Looking at

http://dlang.org/expression.html#IdentityExpression

there isn't a clear statement of what combinations of types are allowed.  There
should be.  As such, this is a spec issue as much as a compiler issue.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 05 2014