-
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
Unexpected behaviour of implicit_some #367
Comments
Also since we're talking documentation, my impression from the extensions page was that let y1: std::result::Result<Option<i64>, _> = ron::from_str(
"#![enable(implicit_some)]\n1"
);
println!("{:?}", &y1);
// gives Ok(Some(1)) And this impression comes from the phrase "if the deserialized struct requires it" |
@d86leader Thank you very much for reporting this issue! Since this behaviour was not documented and fixing it did not break any tests, I feel like allowing users to still explicitly write |
I also clarified the docs a bit and added some unit tests to ensure this will now be the expected behaviour. |
The description of this extension is kind of casual, so I went to test it:
Gives
I expected
None
andSome
to work the same way, but it seems that having this implicit_some turned on disallows you to writeSome
altogether. This means that you can't express{f2: Some(None)}
with this extension.Now actually I'm writing an implementation of RON in another language, and it seems to me now that with this extension some things just become unexpressible. This is fine, but I just need to be certain that this current behaviour is what's expected and not a bug in the implementation. If it is, can you please document it?
The text was updated successfully, but these errors were encountered: