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