First Draft: opUnwrapIfTrue
Dejan Lekic
dejan.lekic at gmail.com
Mon Sep 21 19:37:00 UTC 2026
On Monday, 21 September 2026 at 19:13:33 UTC, Richard (Rikki)
Andrew Cattermole wrote:
> It would appear that we have opposite concerns.
>
> I don't care about the error case, with the error case you can
> always have an empty or even a poison value to say hey you did
> something wrong.
>
> I care about the success case, specifically because to get the
> value, you must have passed successfully the check, these two
> operations must be as one. There is no 'empty' or valid value
> you can provide if you do a get without the check on a result
> that is in an error state.
>
> I know I am not alone with this set of concerns, since other
> languages support it!
>
> false < true
> true needs more proving than false.
Then nothing will help you unless you do all possible checks
after every function call since you obviously do not trust the
result. :) Right?
I trust that author of foo() function knows what kind of error it
can produce better than I do (he/she is usually domain experts).
More information about the dip.development
mailing list