On Tue, Apr 29, 2014 at 12:13 PM, Oliver Woodford <[email protected]
> wrote:
> Quick question, folks:
>
> Does f(x::Array{Union(Int8,Int16)}) mean that x must be all Int8 or all
> Int16 (homogenous), or each element can be either Int8 or Int16
> (heterogeneous)?
>
> If the latter, then would I need to
> use f(x::Union(Array{Int8},Array{Int16})) to achieve the former?
>
Yes and yes.
> If so, then what I am suggesting is having two array types, Array and
> Cell, and have f(x::Array{Union(Int8,Int16)}) be equivalent to the
> current f(x::Union(Array{Int8},Array{Int16})), and have
> f(x::Cell{Union(Int8,Int16)}) be equivalent to the current
> f(x::Array{Union(Int8,Int16)}).
>
This is not a minor change. What you're asking for is having both invariant
and covariant parametric types in the language – Array would be covariant
and Cell would be invariant. If you're going to have invariant and
covariant type parameters, you'll want contravariant type parameters too.
At that point, you need to have a way of annotating the variance of a
type's parameters – and worse still, you have to explain all this to
everyone. At that point, you have Scala and all the
complications<http://blogs.atlassian.com/2013/01/covariance-and-contravariance-in-scala/>and
questions<http://stackoverflow.com/questions/4531455/whats-the-difference-between-ab-and-b-in-scala>that
come with that. I don't think that's the right path for a language
that's meant to be used by people who are scientists rather than
professional programmers (honestly, I don't really think it's a good idea
for professional programmers either). Making all parametric types covariant
is a more reasonable possibility, but as I pointed out, it has its own
significant issues.
