Type-safe way to force caller to check Ok/Err Result values

Hi, In the static languages that inspire this package, the default way of accessing values is only allowed once you’ve checked a Result is Ok:

return actuallyAnErr.value # type error!

However, in this package, because Ok and Err both share .value, this is by default allowed, and the user is not forced to check that a result is ok.

return actuallyAnError.value # fine, but will confuse the hell out of the caller because we just swallowed an error!

Could you consider “blessing” an accessor for value that only exists on Ok, to allow this usage? (Or rename .value on Err to .value_err or something, but that would be another big breaking change…)

Thanks for all your work on this package, I use it in a bunch of places.

[francium]

Okay, so the proposal here and to be implemented in #99 is,

• Deprecate value, deprecation warning for 1 or more releases, then raise exception on usage, then total removal
• Add value and err_value properties that exist only on Ok and Err respectively

Any objections to this? Any better ideas?

[felixhammerl]

I’ve taken the discussions here, because I’ve had the same annoyance with type checkers complaining about Ok being of type str | None instead of str, and created a fork that is breaking compatibility with the upstream repo in many ways.

https://github.com/felixhammerl/resultify

Since Python does not have the pattern matching capability of Rust, Python’s intepretation of Optional is not compatible with Rust’s and it does not quite make sense in my opinion to treat them equally.