-
Notifications
You must be signed in to change notification settings - Fork 575
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
Exhaustive checks in oneof
fields
#2749
Comments
We never had sealed classes for that, and currently have no plan to. boxed oneofs will provide a |
@oldergod thanks for your reply! It wouldn't have to be a sealed class necessarily, but I think exhaustive checks that are verified at compile-time are a very strong feature, and worth some consideration. Because if someone adds a new option to a |
@oldergod If sealed classes aren't palatable, what would you think declaring an enum where the value corresponds to which one of the
Then in addition to the when (obj.my_field_case) {
MyFieldCase.MESSAGE_ONE -> handle(obj.message_one!!)
MyFieldCase.MESSAGE_TWO -> handle(obj.message_two!!)
} Which is an exhaustive check, so that we can handle new |
We have no plan to add that at the moment. |
I am also struggling with this, not only for exhaustiveness in message handling but also for making it clear for devs which ones are oneOf fields and enforcing a single oneOf value is set during message construction. For reference, all other alternative protoc compilers for Kotlin that I know do use sealed interfaces for oneOfs (ProtoKt, KrotoDC and PBAndK) |
Generating enums for |
Is there a way to configure Wire to generate either an Enum / Sealed Class for
oneof
fields, to provide Kotlin developers with an exhaustive API for selecting theoneof
field? It would be very helpful for detecting new cases at compile-time, rather then as errors at run-time. 🙏I see that the sealed classes approach used to exist, but was removed, and several developers have asked for similar "exhaustive check" support in this issue: #998. I have never contributed to this project before, but I would be willing to invest some time into this feature if it will be well-received.
The text was updated successfully, but these errors were encountered: