www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 10971] New: assigning derived class to base should not trigger promotion of result

reply d-bugmail puremagic.com writes:
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
next sibling parent d-bugmail puremagic.com writes:
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10971






 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".

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 05 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10971




---




 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".


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: -------
Sep 05 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
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.


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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10971


monarchdodra gmail.com changed:

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





 Counterpoint:
 
 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