You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.