Dee Girl <deegirl noreply.com> writes:

One good argument for a cast keyword is that persons can grep for it. But I
just compiled this program:

void main() {
    int a = 4;
    float b = mixin("ca" ~ "st(float)(a)");
}

It seems like string mixin makes it possible for bad persons to avoid being
exposed by a grep. Just a thought, Dee Girl ^_^

janderson <askme me.com> writes:

Dee Girl wrote:
 One good argument for a cast keyword is that persons can grep for it. But I
just compiled this program:
 
 void main() {
     int a = 4;
     float b = mixin("ca" ~ "st(float)(a)");
 }
 
 It seems like string mixin makes it possible for bad persons to avoid being
exposed by a grep. Just a thought, Dee Girl ^_^

I guess your not being serious but in case you are, you want to make bad 
coding difficult to do and good coding easy.  People area not likely to 
go to that much effort to circumvent cast.  There are a couple of other 
ways to get around cast:

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


Unions are another one.
You could also hide your cast in a lib file.

Dee Girl <deegirl noreply.com> writes:

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

Robert Fraser <fraserofthenight gmail.com> writes:

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

Java learned its lesson in 1.5... List<B> can't be cast to a List<A> 
implicitly, only to a List<? extends A>.

janderson <askme me.com> writes:

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.  I think the 
reason for allowing A[] a = b; is polymorphism.  The problem comes when 
you append a new A.  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[].

Dee Girl <deegirl noreply.com> writes:

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

torhu <no spam.invalid> writes:

janderson wrote:
 I guess your not being serious but in case you are, you want to make bad 
 coding difficult to do and good coding easy.  People area not likely to 
 go to that much effort to circumvent cast.  There are a couple of other 
 ways to get around cast:
 
 //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.
 

But array b has no element at index 1, it's length is still 1.

This gets the desired effect:

  	B[] b;
  	b ~= new B;
  	b ~= new B;
  	A[] a = b[0..1];
  	a ~= new A;

Now, the second element of b will be an A.  On the other hand, appending 
to slices could easily be considered bad style.

Dee Girl <deegirl noreply.com> writes:

torhu Wrote:

 janderson wrote:
 I guess your not being serious but in case you are, you want to make bad 
 coding difficult to do and good coding easy.  People area not likely to 
 go to that much effort to circumvent cast.  There are a couple of other 
 ways to get around cast:
 
 //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.
 

 
 But array b has no element at index 1, it's length is still 1.
 
 This gets the desired effect:
 
   	B[] b;
   	b ~= new B;
   	b ~= new B;
   	A[] a = b[0..1];
   	a ~= new A;
 
 Now, the second element of b will be an A.  On the other hand, appending 
 to slices could easily be considered bad style.

I do not understand D arrays yet to know why appending to slices is bad style.
But there is no need for slices. The following program compiles and runs. D
makes a textbook mistake by making arrays covariant. Why nobody gets arrays
right?

import std.stdio;

class A {}
class B : A {}

void main()
{
    B[] b = new B[2];
    A[] a = b;
    a[0] = new A;
    a[1] = new B;
    writeln(b[0]);
}

It is correct to allow B[] to be a subclass of const(A[]), but B[] can not be a
subclass of A[] because elements of A[] can be written to and end up in the B[]
array. Could D2 repair this bug? Dee Girl

"Janice Caron" <caron800 googlemail.com> writes:

On 10/05/2008, Dee Girl <deegirl noreply.com> wrote:
 Could D2 repair this bug? Dee Girl

Yes. That's why it's exciting to be involved in an evolving language.

You need a bugzilla account to report bugs. Just sign up over at
http://d.puremagic.com/issues/

Report it, and wait. It might not get fixed immediately, but it will
be in the queue.

terranium <spam here.lot> writes:

Dee Girl Wrote:

 Your example compiles but it was so good if it did not. Modifiable arrays
should never be covariant!

Compiles and works? There is no problem with covariance, it just needs runtime
typechecks for assignment.

terranium <spam here.lot> writes:

terranium Wrote:

 Dee Girl Wrote:
 
 Your example compiles but it was so good if it did not. Modifiable arrays
should never be covariant!

 
 Compiles and works? There is no problem with covariance, it just needs runtime
typechecks for assignment.

The problem is array (unlike java and .Net) is a primitive type, so it doesn't
have TypeInfo and doesn't know what it's supposed to contain, so it can't do
typechecks.

Dee Girl <deegirl noreply.com> writes:

terranium Wrote:

 terranium Wrote:
 
 Dee Girl Wrote:
 
 Your example compiles but it was so good if it did not. Modifiable arrays
should never be covariant!

 
 Compiles and works? There is no problem with covariance, it just needs runtime
typechecks for assignment.

 
 The problem is array (unlike java and .Net) is a primitive type, so it doesn't
have TypeInfo and doesn't know what it's supposed to contain, so it can't do
typechecks.

Maybe check insertion could be arranged by the compiler. Java does that. But it
is generally better to detect type errors earlier. D has const so not much
expressive is lost. Dee Girl

terranium <spam here.lot> writes:

Dee Girl Wrote:

 Maybe check insertion could be arranged by the compiler. Java does that. But
it is generally better to detect type errors earlier. D has const so not much
expressive is lost. Dee Girl

Typecheck can't be arranged out of nothing. Java and CLR can do a typecheck
because array is an object there, a complex object, arrays in D are just slices
- pairs of pointer and length. There is no way to do a typecheck, because there
is no type to check against.

Dee Girl <deegirl noreply.com> writes:

terranium Wrote:

 Dee Girl Wrote:
 
 Maybe check insertion could be arranged by the compiler. Java does that. But
it is generally better to detect type errors earlier. D has const so not much
expressive is lost. Dee Girl

 
 Typecheck can't be arranged out of nothing. Java and CLR can do a typecheck
because array is an object there, a complex object, arrays in D are just slices
- pairs of pointer and length. There is no way to do a typecheck, because there
is no type to check against.

I finally understood, thank you. Your explanation is another good argument:
that covariance of modifiable arrays should be statically disallowed. Dee Girl

terranium <spam here.lot> writes:

Janice Caron Wrote:

 Report it, and wait. It might not get fixed immediately, but it will
 be in the queue.

I've filed it
http://d.puremagic.com/issues/show_bug.cgi?id=2095