Open jack-pappas opened 5 years ago
I've seen some non trivial code that still uses Choice, for instance Suave.
Question is how much of your own effort you want to spend (to support backwards compatibility)?
I think that perhaps @vasily-kirichenko has the most experience using a dual Result<,>
Choice<,>
ExtCore. Though I remember that there was a lot of code (in that PR) in order to support that solution. For f#+ @gusty opted to start out with changing Choice<,>
to Result<,>
and then re-add Choice<,>
based error handling with new name to support interop with libraries that still use Choice<,>
.
Perhaps a compatibility method Result.OfChoice
and a smaller set of combined builders could be used to limit the need for support?
@wallymathieu yes, I just pulled your PR, built a nuget package and have used it (Choice and Result are both there) on production with zero problems. So, I'm for just merge that PR.
For ExtCore v1.0 -- should we support both the
Result<_,_>
andChoice<_,_>
type for error-handling, or should we dropChoice<_,_>
and use onlyResult<_,_>
?Pros/cons of supporting
Result<_,_>
only:Result<_,_>
is a struct, so doing a blanket replacement throughout code may hurt performance in cases where aResult
is created wrapping a large struct and thereby induces expensive struct copies.Choice<_,_>
breaks backwards-compatibility with code written against current/past versions of ExtCore. Users of the library will have to to make non-trivial changes to their code in order to upgrade to ExtCore v1.0.Pros/cons of supporting
Result<_,_>
andChoice<_,_>
:Result<_,_>
andChoice<_,_>
and use whatever best fits their needs.Result
, once forChoice
). This is transitive as well -- any functions that call these functions also need to be implemented twice, etc.cc @vasily-kirichenko @7sharp9 @wallymathieu @dsyme @tihan