Non-empty qualifier missing on array literal type calculation

[peterhuene]

In the type calculation for literal arrays, we should be adding a non-empty specifier to the array type when there is at least one element in the literal expression.

[a-frantz]

I'm worried this could lead to a confusing diagnostic. As stated in Slack, I avoid using the non-empty qualifier. If I write an array literal and downstream I see a diagnostic with the + sign, I could see myself being thrown for a loop. I guess it depends how this gets implemented? Just something to consider I guess

[peterhuene]

Array[X]+ can coerce to Array[X], but not the inverse. If we do not include the qualifier on the array literal type calculus, you would not be able to call select_first([a, b, c]) (where a, b, and c are T?).

[peterhuene]

Erm, not sure how I deleted that comment:

I have a fix incoming for this same function where the element type calculation for both Array and Map such that the first element type might coerce to the second element type, but not the inverse.

For example, if you have [a, b] where a is T and b is T?. As T coerces to T?, but not the inverse, the type of this expression should actually be Array[T?]+ and not Array[T]+, but currently we treat it as an error as the type of b does not coerce to the type of a.

[peterhuene]

So instead of always qualifying a non-empty literal array type with Array[T]+, we need to basically treat it as coercible to either Array[T] or Array[T]+ to support an expression like if (x) then [1, 2, 3] else [], which should have a type of Array[Int]; if we treated the first literal array expression as non-empty, we wouldn't be able to coerce it to Array[Int].

We don't want [] to be Array[Union]+ either, otherwise this would be legal: Array[String]+ foo = [], which the type system should catch.

I have a fix that basically ignores the non-empty qualifier for coercions when involving non-empty literal arrays.