Protobuf: Provide support for type aliases

[mitar]

So that we could define maybe something like:

type dataset_uri = string;

message StartTrain {
  dataset_uri from = 1;
  dataset_uri to = 2;
}

This would allow much more readable proto files.

[liujisi]

The main concern would be increase of complexity. Also I doubt it will increase readability, as users now would have to look up the definition of the types to figure out the real type for the generated API - you cannot distinguish between an aliased type vs a message type. I guess the benefit doesn't outweigh the cost, and comments would probably be better here for documentation purposes.

[david-aimsun]

The complexity can be handle by tools. For example a plugin for Visual Code can show extra info: original type and documentation. IMHO, will make the code more readable. I prefer types (I´m a C++ guy) than strings everywhere (or, in our case, uint64 representing milliseconds since epoch).

[YamiOdymel]

I'd love to see this got implemented. The type alias tells more information rather than a simple uint64 or string type.

And finally, the developer can use type alias to describe how the _real_ API is. With the Protobuf built-in types, it will never be enough and that's what really confuses us.

---

Also, like _david-aimsun_ says, it can be handle by tools like this.

[ramosbugs]

It's also potentially useful to be able to associate field options (including custom ones) with a type alias to avoid having to duplicate them in many places.

[micheal-hill]

I know this is an old issue, but this would be handy for me too. I have a definition that contains a URI field, generated token and a user-provided text field; right now I can only type these each as string. This is being used for an API between teams though; so I need to document elsewhere that each of these fields must conform to some extra constraints.

[awkr]

I'd like to have this feature, cause it'll improve the abstract and more object-oriented, and more efficient at least. Such as there is a CURD API with most fields are repeated string, with this feature, I can only type strings or strs, somehow elegant.

[cbentzel]

I was about to file a similar issue. Right now if there is a repeated use of a scalar type across messages (say, a uint32 to represent an identifier) there are two ways to help ensure consistency:

• Nested messages, but this comes with run-time overhead.
• Commenting and careful review to ensure that the types are the same.

If one ever needs to increase the size of the scalar - say from uint32 to uint64 - there is no way to do this without manually scrubbing the files. Using a typedef/alias would allow substitution in one place.

This could also be done by having protobuf users write custom pre-processors which does the type alias substitution before sending to protoc, but seems like something that would be useful in the proto syntax and protoc itself.

[Fleshgrinder]

That's actually how I would implement it in Protobuf. Have a pre-process phase that replaces all type aliases with their actual definitions and add an option to them that there was a type alias. Afterwards send it to the actual code generators. The overall impact on the Protobuf ecosystem would be minimal because all code generators that are currently in existence would continue to work since they already have to support custom options anyways. Code generators that are interested in the type aliases (e.g. typealias Uuid = string is mapped to java.util.UUID in the generated code) can do so by inspecting the custom e.g. google.protobuf.typealias option‘s value.

[mattdornfeld]

Thrift does support this in the form of typedefs. The use case of this is clearer communication of what the type should be used for and better type safety in the code that imports the generated protobuf code.

[mjfryc]

I'm using protodot to generate structure graph in .dot format and protoc-gen-doc for documentation. It will be very useful to visualize alias types dependencies at the graph and alias-type-links inside md/html/pdf documentation.

Currently the only hack is to create wrapper type:

message my_entity_id_type {
    string id = 1;
}

I would like any typealias my_entity_id_type = string; instead