[carom]

I strongly disagree with this ifs take. I want to validate data where it is used. I do not trust the caller (myself) to go read some comment about the assumptions on input data a function expects. I also don't want to duplicate that check in every caller.

[azaslavsky]

Couldn't you just take the advice in [0] of parsing into types rather than validating? Then you get the best of both worlds: your inputs are necessarily checked every time the function is called (they would have to be to create the type in the first place), but you don't need to validate them at every nested layer. You also get the benefit of more descriptive function signatures to describe your interfaces.

[0] https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

[Zambyte]

One option is to use asserts that are only included in debug builds. That way any incorrect call of the function will crash the program in debug builds, but will have the performance benefits of the lifted conditional checks in release builds.

You'll end up duplicating the condition, but that seems like a reasonable price to pay for correct and performant software.

[zellyn]

At least in the first example, the optionality is directly encoded in the types, so no assumptions have been lost.