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
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.
The text was updated successfully, but these errors were encountered:
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
tink-go/aead/aead_factory.go
Line 101 in bb5b5fe
tink-go/aead/aead_factory.go
Lines 47 to 57 in bb5b5fe
The signature of
tink-go/core/primitiveset/primitiveset.go
Line 102 in bb5b5fe
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 inPrimitiveSet[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.
The text was updated successfully, but these errors were encountered: