I agree this would be very useful and make code safer.

Turning an empty string into 0.0 is a strong assumption that may not at all be what the user wants and can lead to surprising bugs.

Agreed! I just looked into this issue now, but I concur that having additional functions such as as_opt_bool could be a good idea. Its also good for backwards compatibility, so that it doesn't break or change existing logic.

In any case, I would welcome a PR to achieve these changes, else I can take a look into it when I have some time.

Sounds great @rnag

I've recommended serde-this-or-that in this SO answer: https://stackoverflow.com/a/75684771/7483211

Would be neat if it also covered the safer Option use case. Unfortunately I've got a lot on my plate at the moment. I'd be happy to review the feature, however, if you make progress!

@saikrishna1-bidgely @corneliusroemer I've checked in code to a WIP branch and created a PR (#5) to incorporate the changes, please take a look and let me know any thoughts or feedback.

The main points to note here:

• I basically copied de_impl.rs as a separate file, and mostly just wrapped all the return values into Some(value). For code de-duplication purposes, I'd be curious if I can wire together a macro for this purpose, i.e. to duplicate the Visitor class but wrap all return values so that it returns an Option instead.
• I removed all cases where we return error, so E::invalid_value is never used, instead we return a None in this scenario.
• In cases were parsing fails, for instance into u64 or f64, we just silently return a None value.
• Updated logic for Visitor class - please confirm if this is acceptable:
  • as_opt_bool, string values that are neither "truthy" nor "falsy" de-serialize into None

TODOs:

• Update docs for the new optional functions, and also update main docs in readme