Without generics (this is java 1, remember) it seems like a reasonable tradeoff. Otherwise[1] you can't have array-modifying polymorphic code at all - how would you write a "reverse this array" function, for instance? You'd need one for every kind of array you want to reverse. Or a "copy" function - even if you're given a properly-sized-and-typed array to put the values in, you can't make a function that'd work on anything except a single type.

You could force every array-function-caller to cast their args to e.g. `Object[]`, but that seems like it'd require more work for even less safety. Though I'd love a read-only concept in Java, for read purposes :|

[1]: I think. If I'm wrong, someone please correct me!

You could define what an array accepts vs returns separately (input vs output). Admittedly, you're pretty much into generics (good ones, not what Java has) at that point.

Edit: Could use a better word for "good" that sounds less dismissive, but I couldn't think of one. Java's generics are lacking in certain areas, unfortunately.

Generics in Java are pretty complicated already, so much so that very few developers fully understand them. I'm not sure the gain in complexity would be worth the added safety.

I'd like to see examples in languages where this is possible, if there are any?

It is both.

Passing collections of subtypes where a read-only collection of supertypes is expected by the receiving code is fine, because the receiving code can't do anything that would break type safety.

But Java decided to only have a single array type, as a matter of expediency. But they also wanted covariance, because, as you point out, sometimes it's just convenient - more expediency. And so the trade-off was to enforce safety at runtime.

It's still a defect in a sense that the design itself could be made sound, if there were a read-only array reference type in Java.

Read-only is too strict. Can't reverse the array, or sort it.

Sure you can - you just need to copy it.

And I didn't mean to imply that array references should always be read-only. What I meant is that there should be a way to say "the referenced array cannot be mutated through this reference", like const* in C. 90% of the time, when you pass or return arrays, this is exactly what you want.

The existence of arrays at all is a trade off. The language would be more type safe and more consistent with OO best practices without arrays and using dynamic random access lists instead. But that would be too slow for some applications.

I think it is a fundamental.

Just because D isa B it does not mean list(D) isa list(B).

What we need is

  listContaining(Dog) isa listContaining(Animal)
  listAccepting(Animal) isa listAccepting(Dog)

Which is precisely the idea of covariant getters / contravariant setters in some sounder languages.

IIRC, Scala has covariant/contravariant generics

(apologies for the bad terminology, I'm not too familiar with the details)

support for "<? extends X>" and "<? super X>" is supporting covariant / contravariant. invariant would be "<x>".

basically. the same concept applies in a number of areas, with varying support (e.g. Java doesn't support contravariance in its method overloading: http://stackoverflow.com/a/2501513/16295 )

> Is this a defect or a tradeoff?

I'm curious what line of thinking could prompt this question. Not all trade-offs are good choices just because they're trade-offs! Maybe it has something to do with the recent spate of language design choices justified with "it was a trade-off", as if the words "trade-off" is an incantation that puts a technical decision above criticism.

> Not all trade-offs are good choices just because they're trade-offs.

Indeed. But they're not automatically bad choices either. Are you saying this one is a bad trade-off?

Both defect and trade-off. I can definitely see value in being able to pass an array of Dogs and treat it as an array of Animals, but it means that the array of Animals is not really an array of animals (because certain properties of a real array of Animals actually cause the code to break) and as a result the language is a little dirtier for it. Like, that's pretty horrible to be honest.

What you really want in that instance is to be able to easily and explicitly cast the Dog[] to Animal[] before calling the method. A better language would make this easy instead. I think Java's Vector type can do it, so it surprises me that they allow that sort of type weirdness with arrays..

I think you're wrong about Vector