return types of sort() and concatenate()

[gavinking]

The return types of the toplevel functions sort() and concatenate() don't preserve nonemptiness.

Unfortunately, fixing this requires a break to binary- and source- compatibility.

[lucaswerkmeister]

Why does it break source compatibility? The current return type is Element[], the new return type would be a subtype of that, wouldn’t it?

[gavinking]

I would have to add an additional type parameter.

[gavinking]

Done.

[lucaswerkmeister]

Apparently this is a breaking change in another way as well – a pattern similar to the following in ceylon.ast no longer compiles:

[String+] strings = ["Hello", "World"];
[Integer+] integers = [1];
[<String|Integer>*] objects = concatenate([strings.first], *zipPairs(integers, strings.rest));

error: spread argument must be assignable to variadic parameter 'iterables' of 'concatenate': '[Integer, String][]' is not assignable to '{String+}[]'

Is this change intentional? From the change to the signature, it’s not immediately clear to me why this would no longer work.

[gavinking]

Wait, so it's not correctly inferring Element from the second argument?

[lucaswerkmeister]

Yeah, I think so. If the second (spread) argument is made nonempty as well.

[gavinking]

You mean unless it is made nonempty, right?

[lucaswerkmeister]

Huh, not sure what happened with my comment :D I think I meant it works if the second argument is made nonempty as well.

[gavinking]

Fixed, it was a bug in type argument inference. Actually we should report it in a different issue.