Bug 11858 – Comparison of unconnected classes using `is` must be disallowed

Status
NEW
Severity
major
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2014-01-02T07:49:31Z
Last change time
2024-12-13T18:15:33Z
Keywords
spec
Assigned to
No Owner
Creator
Denis Shelomovskii
Moved to GitHub: dmd#18746 →

Comments

Comment #0 by verylonglogin.reg — 2014-01-02T07:49:31Z
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.
Comment #1 by andrej.mitrovich — 2014-01-02T13:10:49Z
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 } -----
Comment #2 by smjg — 2014-01-03T05:53:13Z
This isn't accepts-invalid, because there's no rule against it. It's an enhancement request.
Comment #3 by verylonglogin.reg — 2014-01-05T07:20:19Z
(In reply to comment #2) > 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.
Comment #4 by smjg — 2014-01-05T15:22:40Z
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.
Comment #5 by robert.schadek — 2024-12-13T18:15:33Z
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/18746 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB