-
Notifications
You must be signed in to change notification settings - Fork 123
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
Custom Implicit Enums #542
Comments
Thank you for the question! While it would be nice to extend the functionality that implicit The more likely avenue here would be to split the enum into two parts. The first would be an untagged enum that contains the implicit variant and another newtype variant that wraps the second (externally tagged) enum, which would contain all non-implicit variants. This would have some quirks, however, as untagged enums have fun interactions in I hope this helps! If you do come up with a nice idea for how to mark a single newtype variant as implicit, I'd be happy to review a PR that would add an extension to properly support it. |
One feature that would be extremely nice to have is the ability to define custom enums to automatically unwrap as newtypes on a specific variant unless otherwise specified. By this, I mean sometime similar to how the
#![enable(implicit_some)]
works, but with my own enum.Something like:
So in the Ron file, both of these fields would be valid.
I am requesting this feature as a way to reduce some of the verbosity of types that frequently use a specific enum variant. This is actually something I've encountered in one of my own projects. I am using a Ron file to design a config file, but almost all of the fields in the file have a wrapper that lets the value either be defined directly or load the value from a parent file at a specific path.
If this feature isn't practical to implement, is there an easy way I can write my own extension for Ron to support this?
The text was updated successfully, but these errors were encountered: