Ah my bad for suggesting it then.

Though I think the reasoning was that if the result is unused, it could get optimized out.

That is what inspired the value.assert(x -> x != 0) idea

Assertions don't normally return anything, and since they throw, I also wouldn't expect the return value to be a boolean.
Returning its input when succesful sounded somewhat logical to me

In the BigQuery example they avoid the optimizer by either using the function in the WHERE clause with an IF condition, or by using it in a CASE statement. I think that is fine as a work-around - it just seems more readable to me.

value.assert(x -> x != 0)

The issue with this syntax is that it is very geared towards this one case (checking for 0 on a single variable) - it would not work in general if you have more complex conditions you want to check. I also think the ERROR function has potential other purposes as a debug function because it can be used to e.g. test correct error handling in clients.

Thanks for the review @Mytherin, I updated the description of the current PR and code in the same branch, if you need me, to close this PR and send a new one please let me know.

I overall agree with the concerns. I think, we made the problem a bit complicated.

@Tishj thanks for the help and thinking together in the discussion, no worries, the purpose was to get familiar with the code, and the assert was a good start.

Thanks for the fixes! LGTM