Bug 2095 – covariance w/o typechecks = bugs

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

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

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

solution was proposed in bug 2412 comment 3

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

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.

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

isn't this bug 2093?

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.

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

*** Issue 3977 has been marked as a duplicate of this issue. ***

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

(In reply to comment #11) > I think in this case runtime tests in nonrelease builds are better than > nothing. In what case? And what would these runtime tests do?

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.

(In reply to comment #11) > 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.

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

(In reply to comment #14) > 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.

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.

(In reply to comment #17) > 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.

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 came across the code sample in bug #2544, but before I read Stewart's proposal (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.

(In reply to comment #19) > 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. A solution based on the type system (plus a bit of syntax) as in C#/Java seems better. But it's probably better to implement it after the current group of features is implemented.

(In reply to comment #20) > (In reply to comment #19) > > > 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. > > A solution based on the type system (plus a bit of syntax) as in C#/Java seems > 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)

> Yes, like I mentioned, Steven's solution has some limitations. I meant Stewart (Gordon), not Steven.

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

(In reply to comment #23) > > <? 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.

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.

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[])?

(In reply to comment #26) > 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.

(In reply to comment #27) > (In reply to comment #26) > > 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.

Doesn't the following make x an lvalue? const(base)[] x = derived_array;

(In reply to comment #29) > 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.

Terrific!