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

Enhancement: Support user-provided annotations for generated types and functions #1078

Open
Lukasa opened this issue Oct 5, 2020 · 2 comments

Comments

@Lukasa
Copy link
Contributor

Lukasa commented Oct 5, 2020

It is possible that users may want to define types that need to be annotated in some way, such as with @frozen or @available. This can be useful in cases where a library is built in unusual modes.

There are a few ways we can do this: we can extend the proto file option syntax, with things like option swift_annotate = "@frozen". Or we can pass flags to the protoc compiler. For some cases it's possible that a tree of structs will all need to be serialized and have these annotations applied, and passing a flag addresses that issue.

I would be interested in adding a "sledgehammer" flag to the protoc compiler to simply whack an attribute everywhere. This doesn't address the full suite of problems long term, but does give us an out for some basic cases now.

Does anyone have thoughts on whether this is a good idea?

@thomasvl
Copy link
Collaborator

thomasvl commented Oct 5, 2020

Don't both flags imply some contracts around ABI/API stability? i.e. - we'd have to ensure we never change anything about how we generate these files at any given time, i.e. - we could change the logic around us of the backing Storage. We couldn't reorder properties to try and get better packing. So far we've said the runtime support also doesn't support API evolution, so it seems like we'd be signing up for lots of things to do this, no?

@Lukasa
Copy link
Contributor Author

Lukasa commented Oct 5, 2020

Yes, the examples do, though there are many attributes floating around, not all of which do. Regardless, we can always consider whether giving a space to apply attributes implies that we support all arbitrary attributes, or whether they are caveat user.

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

2 participants