implicit defaults for variant type parameters

[CeylonMigrationBot]

[@gavinking] By default:

• If a type parameter is covariant, and its upper bounds don't involve any type parameters, why don't we just say that its default argument is the intersection of its upper bounds?
• If a type parameter is contravariant, why don't we just say that its default argument is Nothing?

That would let us write—in type expressions—List to mean List<Anything> and Iterable to mean Iterable<Anything,Null>, without the need to explicitly specify any default type args.

That way you would only need to explicitly specify a default type argument in the very rare case where it is invariant or different to the default defined above. I suspect that this boils down to never.

WDYT?

[Migrated from ceylon/ceylon-spec#1291]

[CeylonMigrationBot]

[@gavinking] Oh, of course, and:

• If a type parameter is invariant, why don't we just say that its default argument is in Nothing?

Hah!

[CeylonMigrationBot]

[@FroMage]

shared alias Variant => Nothing;

And make the default in Variant.

[CeylonMigrationBot]

[@gavinking] @FroMage hah!

[CeylonMigrationBot]

[@gavinking] I have implemented this. Along the way I found yet another reason to deprecate the use of Category and make you write Category<> instead, as proposed in #3897, stuff like:

{"helllo", "world"}.map(Singleton)

In this, String should be inferred, not Anything.

[CeylonMigrationBot]

[@gavinking] This is done, but I need to update the spec.

[CeylonMigrationBot]

[@gavinking] I'm going to roll back this work. I believe this introduced undecidability, or near-undecidability.

We can revisit it when we have #3641.

[CeylonMigrationBot]

[@gavinking] Reassigning to 1.5, alongside #3641.

We need #3641, since the default type arg for a covariant type must always be exactly Anything. Making it the intersection of the supertypes is, I suspect, undecidable.