grep

[Dee Girl]

janderson Wrote:

> Dee Girl wrote:
> > janderson Wrote:
> > 
> >> //ie
> >> class A
> >> {
> >>
> >> };
> >>
> >> class B : A
> >> {
> >>
> >> };
> >>
> >> 	B[] b;
> >> 	b ~= new B;
> >> 	A[] a = b;
> >> 	a ~= new A;
> >> //b[1] Is not an A type (not a B type), but is essentially a reinterpret 
> >> A -> B.
> > 
> > Your example compiles but it was so good if it did not. Modifiable arrays should never be covariant! Why did D make the same mistake that Java and Eiffel did? Newer languages should learn from the mistakes of the old languages. This is more than a bit disappointing. Dee Girl
> 
> 
> I agree its not particularly good.  Then again, if your using casting 
> for anything you should think twice about what your doing.

The codes fails without any casts.

>  I think the 
> reason for allowing A[] a = b; is polymorphism.  The problem comes when 
> you append a new A.

It comes when you modify the array in anyway. As shown in http://www.pmg.csail.mit.edu/papers/popl97/node19.html (I am taking class now so it is very fresh in my mind ^_^)

>  I think the solution would be to make A[] invariant 
> or const and enforce it by the compiler.   That way you can't add 
> anything to B[] indirectly but can still pass it into functions that 
> take invariant A[].

I think B[] to invariant(A[]) can not work. These work:

B[] -> const(A[])
const(B[]) -> const(A[])
invariant(B[]) -> invariant(A[])

There are more that work but they can be deduced from the transitivity rule. For example invariant(B[]) -> const(A[]). Dee Girl