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

Optional oneof #235

Merged
merged 3 commits into from
Jan 29, 2024
Merged

Optional oneof #235

merged 3 commits into from
Jan 29, 2024

Conversation

Lupus
Copy link
Contributor

@Lupus Lupus commented Jan 17, 2024

This PR introduces necessary changes to encode OneOf fields as options in OCaml types, following the discussion in #227.

Yes, the main thing with this is that this change would prompt another major release. Why not, I suppose, but it'd be nice to have at least one transition release where this is opt-in instead of opt-out (or no opt-out at all).

@c-cube are you sure it's worth it? Changes in this PR are quite spread across the codebase, and dragging additional parameter across all call stacks to make this behavior opt-in sounds like a bit too much of effort.

@c-cube
Copy link
Collaborator

c-cube commented Jan 19, 2024

So, this would prompt a ocaml-protoc 4.0 release? :)

Maybe we should create a branch 4.0 for that then, and merge this into it.

@@ -411,21 +411,6 @@ let compile_message ~(unsigned_tag : bool) (file_options : Pb_option.set)
}
in
[ type_ ]
| Tt.Message_oneof_field f :: [] ->
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this mean we don't have a way to represent "just a sum type" anymore? That would make the OCaml code quite a lot heavier I think. We could perhaps keep this as a sum type definition, and return a _ option of it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, that branch was special-casing a message which only include a oneof field. Normally ocaml-protoc emits two types - one for the variant and one for the message itself, including a field for that variant. With special-casing, there was no record type for the message itself, but only the one for the variant, which had the name for the whole message. With ordinary flow there is still a type for the variant, it's just named with _oneof suffix.

Your point is that when messages are organized into oneof only to be referenced from other messages, we'll have additional record wrapping and you want to remove it and have message type be option of sum type?

To my taste I find this special-casing confusing, I was unable to find my message record and it took me some time to figure out that it only had single one-of and the variant itself is what I need. Protobuf is about extending messages, and the odds are high that message with only one oneof field will get additional fields along the way, type errors will be quire confusing in this case (for the record case, if we don't care for exact field set and bind rest of fields to _, adding a field to message might require no changes to the program to still compile).

@Lupus
Copy link
Contributor Author

Lupus commented Jan 20, 2024

So, this would prompt a ocaml-protoc 4.0 release? :)

That's what I'm saying, yeah :)

Maybe we should create a branch 4.0 for that then, and merge this into it.

Sounds good! Maybe something else would creep in with breaking changes.

@c-cube c-cube changed the base branch from master to br-4.0 January 29, 2024 15:19
@c-cube c-cube merged commit 29a8921 into mransan:br-4.0 Jan 29, 2024
2 checks passed
@c-cube
Copy link
Collaborator

c-cube commented Jan 29, 2024

Alright, this is merged into the new br-4.0 branch :-). Thank you! Hopefully we get closer to being compliant, while not losing (much) perf.

@Lupus
Copy link
Contributor Author

Lupus commented Jan 29, 2024

Thanks for looking into this!

@Lupus Lupus deleted the optional-oneof branch February 26, 2024 05:46
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

Successfully merging this pull request may close these issues.

2 participants