Using standard way for specifying proto field options

[bwplotka]

Hi,

Is there a way to use this awesome tool but std using field options. The problem is when we have many other options if every plugin has a different way of specifying this, it just gets confusing 🤔

What I mean:

• https://developers.google.com/protocol-buffers/docs/proto3#options

[favadi]

Is there a way to use this awesome tool but std using field options.

Not for now, although I would be happy to accept a PR.

[bwplotka]

Thanks 👍🏽

Help wanted, otherwise might take a look at some point 🤗

[lrstanley]

Looking at the options/extensions functionality in proto3, I'm not sure if it would be a good fit for this kind of logic (actually I do think it is, but more details below... 😄).

custom options docs

The deprecated field is a built-in field. Seeing how it's defined can help paint how extensions are done, It looks as though maps and oneof can't be used within extensions (e.g. map features). When trying even use just a string, it looks like it (protoc-gen-go) may only be putting the value of the custom field option into the wire-format byte array that is generated in the .pb.go file(s), which I don't see being better/easier to deal with.

E.g:

[...]
import "google/protobuf/descriptor.proto";

extend google.protobuf.FieldOptions {
  string gotags = 50001;
}

message IP {
  string Address = 1 [(gotags) = "this is a test"]; // "this is a test" doesn't show up in test.pb.go, other than maybe the byte array of the wire-formatted description.
}

(see also: this must be a non-popular feature that is used, since Github and VSCode's syntax highlighting hates this, but it's valid and compiles!)

The main problem with where it's stored, is that we'd have to figure out how to map the raw data from the wire format doc, and map it on top of what protoc-gen-go is generating. This would get messy and very complex since it's not as easy as just iterating over the AST. You can't easily import the generated .pb.go file to use the helper protoreflect methods to iterate over the data either.

The ideal location of this logic is within protoc-gen-go, creating a .proto extension that could optionally be imported by anyone, and adds the necessary gotag extension, when it is actually generating code. Unfortunately, this is probably never going to happen, and thus why this library exists today.

Skimming through the rest of the spec, I don't see anything that could be used (or abused) for this functionality, other than comments like this tool is currently doing.

Any other thoughts? Could I be missing something?