Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Genericized PrimitiveSet #21

Open
whs opened this issue Jul 19, 2024 · 0 comments
Open

Genericized PrimitiveSet #21

whs opened this issue Jul 19, 2024 · 0 comments

Comments

@whs
Copy link

whs commented Jul 19, 2024

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

p, ok := (primary.Primitive).(tink.AEAD)
where an entry in PrimitiveSet needs to be typecased. In
if _, ok := (ps.Primary.Primitive).(tink.AEAD); !ok {
return nil, fmt.Errorf("aead_factory: not an AEAD primitive")
}
for _, primitives := range ps.Entries {
for _, p := range primitives {
if _, ok := (p.Primitive).(tink.AEAD); !ok {
return nil, fmt.Errorf("aead_factory: not an AEAD primitive")
}
}
}
both checks that the PrimitiveSet is of uniform type can be removed.

The signature of

func (ps *PrimitiveSet) Add(primitive any, key *tinkpb.Keyset_Key) (*Entry, error) {
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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant