tink-crypto
Genericized PrimitiveSet
What sort of feature would you like to see?
With Go Generic now in mainstream use, I'd suggest that the PrimitiveSet is made generic so that the Entry are of a single type (eg. tink.AEAD).
This could simplify some cases, such as in https://github.com/tink-crypto/tink-go/blob/bb5b5fe001759c7908c1fab2008f6839f1f73d6d/aead/aead_factory.go#L101 where an entry in PrimitiveSet needs to be typecased. In https://github.com/tink-crypto/tink-go/blob/bb5b5fe001759c7908c1fab2008f6839f1f73d6d/aead/aead_factory.go#L47-L57 both checks that the PrimitiveSet is of uniform type can be removed.
The signature of https://github.com/tink-crypto/tink-go/blob/bb5b5fe001759c7908c1fab2008f6839f1f73d6d/core/primitiveset/primitiveset.go#L102 could be made to type check the primitive to be the same as the PrimitiveSet.
I understand that this is a breaking change, but perhaps this feature request would bring this to maintainer's attention in case of future improvements.
Have you considered any alternative solutions?
I've made internal fork in my company where PrimitiveSet is genericized and interfaced (to allow lazy key loading) and is used in production for over a year. From that experience I found that using generic made the project more typesafe to use, but in some cases the lack of runtime generic make the code unusable. For example, when a PrimitiveSet is loaded using an ORM wrapper one would need to create the receiver variable beforehand, but the key type is not yet known. Unlike Java, PrimitiveSet[any] is not usable in PrimitiveSet[tink.AEAD] and there's no cast between the two.
I'd be open to contribute such fork to the project, but I assume that since it significantly change PrimitiveSet and Entry it might not be exactly well received by the project.
