Enhancement: Support user-provided annotations for generated types and functions #1078
Comments
|
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? |
|
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
It is possible that users may want to define types that need to be annotated in some way, such as with
@frozenor@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?
The text was updated successfully, but these errors were encountered: