www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2095] New: covariance w/o typechecks = bugs

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

           Summary: covariance w/o typechecks = bugs
           Product: D
           Version: 2.012
          Platform: PC
               URL: http://www.digitalmars.com/webnews/newsgroups.php?art_gr
                    oup=digitalmars.D&article_id=71480
        OS/Version: Windows
            Status: NEW
          Keywords: spec
          Severity: normal
          Priority: P2
         Component: www.digitalmars.com
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: terranium yandex.ru


class A{}
class B:A{}

B[] ba=[new B];
A[] aa=ba;
aa[0]=new A;
ba[0].methodB(); //ba[0] is expected to be B, but is A


-- 
May 11 2008
next sibling parent reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095


terranium yandex.ru changed:

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





*** Bug 2412 has been marked as a duplicate of this bug. ***


-- 
Oct 10 2008
parent bradpiit <bradpiit12 gmail.com> writes:
There is nothing called a free lunch is this world. If things needed
to be resolved then initiative needs a support to be sorted out.

<a href=http://mls.fastrealestate.net>mls</a>
May 27 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095


maxmo pochta.ru changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lat7h virginia.edu





*** Bug 2544 has been marked as a duplicate of this bug. ***


-- 
Feb 18 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095


maxmo pochta.ru changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |2573
              nThis|                            |





solution was proposed in bug 2412 comment 3


-- 
Feb 18 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095


smjg iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg iname.com





This and bug 2412 are about covariance of classes.  Bug 2544 describes
covariance of array constancy, which is basically the same but we need to
remember that the solution needs applying to both.

See also
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=81566


-- 
Feb 18 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095






As I remember, it was pointed out that rules for implicit conversions of arrays
are formulated uniformly for complex and primitive types, and this report is
exactly about those rules, and solution for classes works for primitive types.


-- 
Feb 18 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095


jason.james.house gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason.james.house gmail.com





I don't know if it's wise to mark bug 2544 as a duplicate of this bug.  For
example, the proposed solution (comment 3) shows a lack of understanding of
this related issue.

Specifically, I believe the proposed solution in bug 2412 comment 3 says the
following would be ok:
class base{}
class derived:base{}

derived[] x = new derived[2];
const(base)[] safe = x;

That really isn't true.  Take the following code that should resize the arrays
in place:
derived[] x = new derived[2];
derived.length = 1;
const(base)[] safe = x;
x ~= new derived(); // x[1] is now valid derived instance
safe ~= new base(); // just overwrote x[1] with a non-derived instance


-- 
Feb 18 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095






isn't this bug 2093?


-- 
Feb 19 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095






int[] x=[1,2];
x.length=1;
int[] y=x;
x~=3; // x=[1,3]
y~=4; // x=[1,4]
bug 2093 has little to do with covariance. Added as dependency.


-- 
Feb 19 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095






This turned out to be well-known. Bug 926.
In NG: http://www.digitalmars.com/d/archives/17039.html


-- 
Feb 24 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095


Steven Schveighoffer <schveiguy yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla digitalmars.com



14:23:01 PDT ---
*** Issue 3977 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 16 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095


bearophile_hugs eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs eml.cc



I think in this case runtime tests in nonrelease builds are better than
nothing.

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





 I think in this case runtime tests in nonrelease builds are better than
 nothing.
In what case? And what would these runtime tests do? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 29 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095




Something about this topic:

http://blogs.msdn.com/b/ericlippert/archive/2007/10/17/covariance-and-contravariance-in-c-part-two-array-covariance.aspx

This is is an important problem, that needs to receive more votes and more
attention.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 16 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095




21:55:25 PST ---

 I think in this case runtime tests in nonrelease builds are better than
 nothing.
I'm afraid, there's nothing to test at runtime, and I thought the solution was already chosen to disallow mutable covariance at compile time. I remember there was an attempt to implement the solution, but Steven says the code still compiles. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 16 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095




12:24:40 PST ---
For the record, the same problem also occurs with pointer types:

    B* ba=[new B()].ptr;
    A* aa=ba;
    *aa=new A;
    (*ba).methodB(); // (*ba) is expected to be B, but is A

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 17 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095






 I'm afraid, there's nothing to test at runtime,
Some runtime data info may be added, then. There is already some of it for classes and modules.
 and I thought the solution was
 already chosen to disallow mutable covariance at compile time.
I didn't know this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 17 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095


Jonathan M Davis <jmdavisProg gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg gmx.com



PST ---
It really should be stopped at compile time. There's not really a good reason
to allow it. As much as it first looks like mixing A[] and B[] when B : A
should work, it's a _really_ bad idea. Just because a container holds a type
which is the base type of another type does not mean that a container which
holds the derived type should be assignable/castable/convertable to one which
holds the base type.

Really, the only question is whether you can get away with it with some form of
const, and I believe that the consensus on it in the newsgroup last time that
this was discussed was that you couldn't. I'd have to go digging through the
archives though to find the exact thread.

This can and should be disallowed at compile time. It's a definite bug. It just
hasn't been fixed yet.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 17 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095





 Really, the only question is whether you can get away with it with 
 some form of const, and I believe that the consensus on it in the 
 newsgroup last time that this was discussed was that you couldn't.  
 I'd have to go digging through the archives though to find the 
 exact thread.
I've no idea what discussion you're thinking of either. But I've studied it - see comment 4. But to summarise, the following implicit conversions should be allowed: B[] to const(A)[] const(B)[] to const(A)[] immutable(B)[] to immutable(A)[] immutable(B)[] to const(A)[]
 This can and should be disallowed at compile time.  It's a definite 
 bug.  It just hasn't been fixed yet.
Yes, in the spec. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 17 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095




11:10:49 PST ---
I've looked at Stewart Gordon's proposal, and I agree that they are safe and
sound (although it may need to be more detailed or cleaned-up a bit). I
actually had prepared a post over a month ago detailing what is basically the
same proposal and underlying conclusions as Stewart's proposal. I did it when I

(which I read only recently). I didn't actually post the text I prepared yet,
since I was waiting to clear up my backlog of D newsgroups message. :S
In any case, the conclusions are the same, especially to the point of realizing
the connection to Java's wildcard generics (which, BTW, are the only way to
express this use case safely, but without further loss of type system
functionality).

As a simple solution, I recommend we adopt Stewart's proposal, which is good
enough I think.
The very best solution would be to have a concept like Java's wildcard's, but
that is too complex in implementation to consider any time soon.

 bearophile:
"Some runtime data info may be added, then. There is already some of it for
classes and modules."

Are you out of your mind? Classes are not like arrays and pointers. These are
supposed to be lightweight data types, it's out of place for D to have that
extra runtime data in these lightweight data types (arrays and pointers). It
worries me that you suggested this change without even considering an approach
based on fixing/improving the (static) type system.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 18 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095






 Classes are not like arrays and pointers. These are
 supposed to be lightweight data types, it's out of place for D to have that
 extra runtime data in these lightweight data types (arrays and pointers). It
 worries me that you suggested this change without even considering an approach
 based on fixing/improving the (static) type system.
better. But it's probably better to implement it after the current group of features is implemented. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 18 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095




15:29:24 PST ---


 
 Classes are not like arrays and pointers. These are
 supposed to be lightweight data types, it's out of place for D to have that
 extra runtime data in these lightweight data types (arrays and pointers). It
 worries me that you suggested this change without even considering an approach
 based on fixing/improving the (static) type system.
better. But it's probably better to implement it after the current group of features is implemented.
Yes, like I mentioned, Steven's solution has some limitations. For example, if you have B[] the best you have is being allowed to cast it to const(A)[]. But that means you wont be able to call mutable methods on the elements of that array, whereas with a wildcard type such as: <? extends A>[] you would be able to call mutable methods of A. So this solution is not perfect, but it works with existing concepts in D (it only needs const), whereas we are far away from the point where can add such disrupting and complex features such as wildcard type. (D's type system seems to be struggling already as it is) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 19 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095




15:31:03 PST ---
 Yes, like I mentioned, Steven's solution has some limitations. 
I meant Stewart (Gordon), not Steven. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 19 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095




14:30:34 PST ---
   <? extends A>[]
Interesting. This type implies array is mutable, so you can put objects into it. Java will check at runtime for array type, but in D arrays don't have rtti. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 20 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095





   <? extends A>[]
Interesting. This type implies array is mutable, so you can put objects into it.
No, because you don't know which subclass of A the particular array is of. Java does exactly this with its generics - prevents you at compile-time from putting objects into the data structure for this reason. All Java generics do is compile-time type checking - at run-time, a List is a List. But arrays are different. But each element of the array is mutable.
 Java will check at runtime for array type, but in D arrays don't have rtti.
Yes, because Java arrays don't use generics. Probably for backward compatibility, since they were invented long before generics were. They're just convertible to arrays of any class higher up the hierarchy. This has been claimed as one of the main weaknesses of Java's design. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 21 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095


Andrei Alexandrescu <andrei metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |andrei metalanguage.com
         AssignedTo|nobody puremagic.com        |bugzilla digitalmars.com



05:58:02 PST ---
Elevating importance of this as it's a big hole in the type system. Please vote
up.

Solution: Derived[] can be implicitly converted to const(Base)[] in all
situation where pointer adjustment is not needed for converting Derived to
Base. Conversion from Derived[] to Base[] must be rejected statically.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 27 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095




06:24:58 PST ---
If derived[] is implicitly converted to const(base)[], what happens when I
append another bade object to the array? Should it implicitly convert to
const(base[])?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 27 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095




06:32:03 PST ---

 If derived[] is implicitly converted to const(base)[], what happens when I
 append another bade object to the array? Should it implicitly convert to
 const(base[])?
You can't append a bad object to a const array. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 27 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095




10:10:58 PST ---


 If derived[] is implicitly converted to const(base)[], what happens when I
 append another bade object to the array? Should it implicitly convert to
 const(base[])?
You can't append a bad object to a const array.
Ah, you mean "base" not "bad". Sorry! Conversion Derived[] -> const(Base)[] is fine because the resulting array is not an lvalue. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 27 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095




12:08:04 PST ---
Doesn't the following make x an lvalue?

const(base)[] x = derived_array;

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 27 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095





 Doesn't the following make x an lvalue?
 
 const(base)[] x = derived_array;
It does ... but appending to x won't alter derived_array. There was, however, previously a hole here that was issue 2093. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 27 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095


yebblies <yebblies gmail.com> changed:

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



https://github.com/D-Programming-Language/dmd/pull/110

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 11 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED



10:14:30 PST ---
https://github.com/D-Programming-Language/dmd/commit/7adef956a0ca6352034b34e65f76798af51d6aab

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 24 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2095




10:25:14 PST ---
Terrific!

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 24 2011