[Proposal] Optional explicit type parameters

[gregsn]

We want the user to be able to specify explicit type parameters on type definitions.
This is necessary to solve Issue B mentioned here: #38

In the Name field
you shall be able to write MyClass<MyT1, MyT2>.

By that, you tell the system

• there are exactly two type parameters in this generic type
• these are their names - inside my type definition we can refer to those types inside of type annotations
• and this is the order. If a user of our type has some type annotation MyClass<Float32, Boolean> somewhere, it is clear which type parameter is replaced by which type argument.

This proposal tries to not reinvent everything:

• This way of expression is optional. Generic type definitions without explicit type parameters are still valid.
• However, type annotations referring to generic types shall only be valid if
  • the type definition has explicit type parameters or
  • the type definition ended up with only one type parameter

This proposal is not about optional explicit type parameters on

• instance operation definitions
• static operation definitions

For now, we want to tackle the problems on type definitions. Let's see if we then still need those other forms of expression.

[gregsn]

Regarding the details:

What shall happen when you annotate a pin with type parameter A and it is connected to a node that feeds or accepts e.g. a Boolean.

• Shall that type parameter vanish and be substituted by Boolean?
• Do you want an error or warning? When is that in the way? or
• Do you want a constrained type parameter? Note: this is not always possible (think value types and type parameters on sinks that are not expressable in the C# target code)

Argue!

[gregsn]

Shall that type parameter vanish and be substituted by Boolean?

Option A) Replace every occurrence with the concrete type
If this type parameter vanished from the body of the patch (it got replaced everywhere, so no type annotation left with that type parameter)

• we now managed to be left with a type parameter in the signature of the type, which no longer is used
• feeding any type from outside should work out (it's not used anyway)
• we have a contradiction, because if that type parameter was actually used inside the body of the patch it should now be equal to the type it got substituted with, it's not a type variable anymore
• Longterm we could have such a type variable which only gets used inside of a patch, helping out while patching, but currently we only have type parameters, which are part of the signature of a type or operation. This notion of a type variable is not a free type variable, but a type parameter, which when used gets substituted by the type argument.

Option B) No. Always keep the parameter. Never substitute
The type unification has to collect all the constraints for the type parameter. In the end, it should check if these are valid type parameter constraints. If yes these are kept, otherwise we report an error.

[azeno]

I wanted to add that this proposal might give us a way out regarding another issue: calling operations on This in generic patches is currently completely broken. We could say that self-referential generic patches will only work with explicit parameters.

[gregsn]

Works for me

[gregsn]

This got implemented for 2021.4.
It's like specified here, but also comes with explicit type parameters for static operations. Layer operations still don't have that ability. Oh, and it's of course Option B): never substitute an explicit type parameter.