digitalmars.D.bugs - [Issue 10971] New: assigning derived class to base should not trigger promotion of result
- d-bugmail puremagic.com (56/56) Sep 05 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10971
- d-bugmail puremagic.com (14/14) Sep 05 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10971
- d-bugmail puremagic.com (14/19) Sep 05 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10971
- d-bugmail puremagic.com (8/25) Sep 05 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10971
- d-bugmail puremagic.com (10/12) Sep 05 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10971
- d-bugmail puremagic.com (25/25) Sep 05 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10971
- d-bugmail puremagic.com (7/8) Sep 05 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10971
- d-bugmail puremagic.com (14/17) Sep 05 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10971
http://d.puremagic.com/issues/show_bug.cgi?id=10971 Summary: assigning derived class to base should not trigger promotion of result Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: monarchdodra gmail.com EG: //---- class A { A next; } class B : A {} void main() { B first = new B; B last = first; //foreach(_ ; 0 .. 10) last = (last.next = new B); [1] } //---- [1]: Error: cannot implicitly convert expression (last.next = new B) of type main.A to main.B When the call the compiler should be able to type the result of "last.next = new B" as a "B" (the type of "new B"), and not an "A" (the type of "last.next"). Other usecase: //---- class A { A next; } class B : A {} void foo(B){} void main() { A a; foo(a = new B); } //---- Error: function main.foo (B _param_0) is not callable using argument types (A) The workaround is trivial of course, but I'd have expect the compiler could handle it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 05 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10971 Maxim Fomin <maxim maxim-fomin.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |maxim maxim-fomin.ru --- I doubt it will ever be implemented because it breaks static typing of D. In second example type of a is "A" and not "B" and your request would require compiler to accept/reject sometimes arguments depending on context. For example, initializer for a can be not new B, but Object foo() and in such context compiler cannot know whether returned value is trully B or not. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 05 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10971I doubt it will ever be implemented because it breaks static typing of D. In second example type of a is "A" and not "B" and your request would require compiler to accept/reject sometimes arguments depending on context. For example, initializer for a can be not new B, but Object foo() and in such context compiler cannot know whether returned value is trully B or not.Depends on how you see it I guess. I could that I see it that the initializer is "new B", yet *because of context* (assign to "a" while we are at it), it doesn't compile. But I don't think this has anything to do with context. Just that "a = b" is an operation, and like all operations, it has a return type. I think we could improve what that type is. We could make it "The type A, but implicitly cast-able to B" That would be "nice to have". -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 05 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10971 ---In C in assignment chaining type of expression is defined to be the type of leftmost operand. I don't think you EH is a good reason to break it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------I doubt it will ever be implemented because it breaks static typing of D. In second example type of a is "A" and not "B" and your request would require compiler to accept/reject sometimes arguments depending on context. For example, initializer for a can be not new B, but Object foo() and in such context compiler cannot know whether returned value is trully B or not.Depends on how you see it I guess. I could that I see it that the initializer is "new B", yet *because of context* (assign to "a" while we are at it), it doesn't compile. But I don't think this has anything to do with context. Just that "a = b" is an operation, and like all operations, it has a return type. I think we could improve what that type is. We could make it "The type A, but implicitly cast-able to B" That would be "nice to have".
Sep 05 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10971In C in assignment chaining type of expression is defined to be the type of leftmost operand. I don't think you EH is a good reason to break it.C doesn't have inheritance. And I don't want to change that behavior. I want the compiler to know that making an implicit downcast would be legal in this situation. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 05 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10971 Andrej Mitrovic <andrej.mitrovich gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrej.mitrovich gmail.com 10:51:22 PDT --- Counterpoint: ----- class A { A next(A newA) { return new A; } // does not return B! } class B : A {} void main() { B first = new B; B last = first; last = (last.next = new B); } ----- If someone changes a field into a property, your code would break. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 05 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10971 10:52:03 PDT ---If someone changes a field into a property, your code would break.Although I missed using property there, but it's the same thing. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 05 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10971 monarchdodra gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALIDCounterpoint: If someone changes a field into a property, your code would break.I guess that's good enough of an example to conclude that my proposal is not worth following. TY for taking the time to rebuke. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 05 2013