"Walter" <walter@digitalmars.com> escreveu na mensagem news:bk5l19$p7k$1@digitaldaemon.com...
>
> "Mike Wynn" <mike@l8night.co.uk> wrote in message news:bk5k38$m5t$1@digitaldaemon.com...
> > Walter wrote:
> > > A number of bugs fixed.
> > >
> > > http://www.digitalmars.com/d/changelog.html
> > >
> >
> > while I like having the ability to pass a Derived[] as a Base[]
> > simply disallowing inout does not solve the problems of ending up with
> > an instance of Base in your array (or worse).
> > cast(X[])ar should check all elements of ar;
> > I've not used two threads but is I had then its easy to see a sitation
> > where one thread sees an array as a B[] (or worse Object[]) the other
> > sees the same range as D[], and chaos may follow shortly after
>
> I know about that gaping hole in type safety, but I don't see a fix for
it.
> It happens in C++ as well.

IME this is a Bad Thing. Usually we have three kinds of subtyping:

1. common covariant subtyping: used for values (e.g. integer is a subtype of
real);
2. contravariant subtyping: used for functions, where (using "->" to denote
function type, "int -> bool" is a function that take an "int" and returns a
"bool", and "<:" to denote subtype of) it holds "A' <: A", "B' <: B" and
"(A -> B') <: (A' -> B)". That in the subtype the parameter can be
generalized and the return type can be constrained. A example would be the
the type "real -> int" that is a subtype of "int -> real". A example in D:


class Real {...}
class Integer : Real {...}

Integer i = new Integer(42);
Real r = null;
Real function(Integer) f;
Integer function(Real) g = Integer function(Real r)  { return
r.truncate(); };

f = g;    // contravariant rule say it's ok.
r = f(i); // g expects any Real, so it's ok to pass an Integer.
          // g returns a Integer, so it's ok to treat it as a Real.


3. invariant subtyping: used for mutable arrays. In this situation there's no subtyping possibility, because of possible undesirable assignments:


class A {}
class B : A {}
class C : A {}

void bind(A[] as, A a) {
    as[0] = a;  // ok
}
int main() {
    static B[] bs = [new B(), new B()];
    bind(bs, new C());   // ops, if covariance was ok this would break
type-safety.
}


Java has this hole in their type-system, but they use a runtime check to verify that nobody calls "bind" passing a value that the array rejects. As we have templates in D, which are capable of F-bounded polymorphism (impressive, huh? ;), someone can rewrite bind as:


template TBind(T : A) {
    void bind(T[] ts, T t) {
        ts[0] = t;
    }
}


And the template instatiation would point the error at compile time. IMO it's completely unnecessary to allow array subtyping in a system that has the correct mechanism to write generic array operations. Java doesn't have (1.5 is in the future) generics so they had to allow such holes in their type-system, or else people would have to write the same array libraries for every possible type. It doesn't kill people to write templates (using them may kill some ;) specially when they lead to correct code. If the template syntax starts to get in the way it's a sign that the syntax should be changed.

    Best regards,
    Daniel Yokomiso.

"Enlightenment does not divide you, just as the moon does not break the
water. The depth of the drop is the height of the moon."
 - Dogen


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.518 / Virus Database: 316 - Release Date: 11/9/2003

> small changes and it works like adding ":" ~ val and ":..." only seems to be an issue with 4 char values ...

hmm weird.


"Mike Wynn" <mike@l8night.co.uk> wrote in message news:bk7cv4$2ce$1@digitaldaemon.com...
> Charles Sanders wrote:
> > That code works here using 0.72 , windows 2000 advanced, dmc8.36
> >
>
> sorry forgot the version/os - linux(RH9 gcc 3.2.2) dmd 0.71 and 0.72
>
> small changes and it works like adding ":" ~ val and ":..." only seems to be an issue with 4 char values ...
> >
> >>switch to name
> >
> >
> > Charles
> >
> > "Mike Wynn" <mike@l8night.co.uk> wrote in message news:bk5t54$1njn$1@digitaldaemon.com...
> >
> >>Walter wrote:
> >>
> >>>A number of bugs fixed.
> >>>
> >>>http://www.digitalmars.com/d/changelog.html
> >>>
> >>>
> >>>
> >>
> >>there seems to be a problem with wchar switchs I have some code that reads from a file (bytes) and casts to wchar ... though that was the problem, has taken me a while to get a 10 line prog to repro this ... but here it is with internal strings.
> >>
> >>----------------------------------
> >>
> >>import c.stdio;
> >>
> >>wchar[] getName() {
> >>return "name";
> >>}
> >>
> >>int main(char[][] args ) {
> >>wchar[] tmp = getName();
> >>switch( tmp ) {
> >>case "name":
> >>printf("switch to name\n");
> >>break;
> >>case "afoo": printf("switch to afoo\n"); break;
> >>default:
> >>printf("switch to default(not afoo or name)\n");
> >>printf("tmp[0..%d]:\n", tmp.length);
> >>for( int i = 0; i < tmp.length; i++ ) {
> >>printf("tmp[%d] = '%c'(%d)\n", i, cast(char)tmp[i], cast(int)tmp[i] );
> >>}
> >>break;
> >>}
> >>return 0;
> >>}
> >>---------------------------
> >>switch to default(not afoo or name)
> >>tmp[0..4]:
> >>tmp[0] = 'n'(110)
> >>tmp[1] = 'a'(97)
> >>tmp[2] = 'm'(109)
> >>tmp[3] = 'e'(101)
> >>
> >
> >
> >
>

"Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message news:bk88jp$gi$1@digitaldaemon.com...
> And the template instatiation would point the error at compile time. IMO it's completely unnecessary to allow array subtyping in a system that has the correct mechanism to write generic array operations. Java doesn't have (1.5 is in the future) generics so they had to allow such holes in their type-system, or else people would have to write the same array libraries
for
> every possible type. It doesn't kill people to write templates (using them may kill some ;) specially when they lead to correct code. If the template syntax starts to get in the way it's a sign that the syntax should be changed.

I think you're right. I'll change it back :-(