julia> Try.and_then(Ok(1)) do x
Ok(x + 1)
end
Try.Ok: 2This example requires the user to wrap the value in Ok manually. An alternative API would automatically re-wrap the value in Ok, making it easier to retain the disjoint sum-type Ok{T} | Err{E} style that I often want.
Undisciplined use of and_then allows creating T | Err{E}
julia> Try.and_then(Ok(1)) do x
x + 1
end
2which might be better avoided.
Is this and_then worth the risk of misuse? There are other functions that could be provided, like these in Rust.
The only situation I can think of where this would be needed is in an exotic sum type like
where there is more than one success branch. But I'd usually represent this concept with the isomorphic
Ok(true) | Ok(false) | Err(Unknown)
which doesn't require the re-wrapping. And even with the multi-success type, users could always do manual pattern matching themselves.
Am I wrong about this? If not, what do you think about either removing and_then or documenting a requirement that the function argument return a wrapper type?
This example requires the user to wrap the value in
Okmanually. An alternative API would automatically re-wrap the value inOk, making it easier to retain the disjoint sum-typeOk{T} | Err{E}style that I often want.Undisciplined use of
and_thenallows creatingT | Err{E}which might be better avoided.
Is this
and_thenworth the risk of misuse? There are other functions that could be provided, like these in Rust.The only situation I can think of where this would be needed is in an exotic sum type like
where there is more than one success branch. But I'd usually represent this concept with the isomorphic
which doesn't require the re-wrapping. And even with the multi-success type, users could always do manual pattern matching themselves.
Am I wrong about this? If not, what do you think about either removing
and_thenor documenting a requirement that the function argument return a wrapper type?