[antiguru]

#39061 made the blanket LazyBinaryFunc impl evaluate both arguments into an array of results. That made case_literal/if_chain/* 11-13% slower, which nightly cargo-bench flags. A named iterator that evaluates each argument on demand restores most of the previous speed and keeps #39061's code-size reduction (cargo llvm-lines -p mz-expr --lib: 1,933,557 lines vs. 1,934,453 on main).

Local A/B against ae3cc46, #39061's parent (median of 3, pinned core): if_chain/64_arms/last 4741 ns before #39061, 5319 ns on main, 4816 ns with this PR. Most of the family lands within 2.3% of the parent. 4_arms/last is the exception (306 / 340 / 333 ns), and it reproduced in two runs.

Every binary function's input is a 2-tuple whose try_from_iter pulls both arguments before it checks for errors and NULLs, so evaluation semantics are unchanged. A new case in error_semantics.slt pins that an eval error wins over a NULL in either argument position.

Closes: CPU-315

🤖 Generated with Claude Code

[bosconi]

Replaces #39061's [Result<Datum, EvalError>; 2] with a named iterator that evaluates each argument when try_from_iter asks for it, keeping one instantiation per input type and Eval implementor. Semantics are unchanged: every binary function's Input is a 2-tuple generated by #[sqlfunc], and the tuple try_from_iter pulls every argument before it checks for errors and NULLs. So both arguments are still evaluated, and an eval error still wins over a NULL. Looks good.

Reviewed at a765877.

Suggestion

• With the array, both arguments were evaluated whatever try_from_iter did. Now that rests on the tuple impl consuming everything before it decides, which is easy to "optimize" into a short-circuit later, and I found no test that pins the resulting priority for binary functions. A column-based case in test/sqllogictest/error_semantics.slt would: a table (a int, b int) holding (NULL, 0) and SELECT a + 1/b, expecting the division-by-zero error. Columns keep the optimizer from folding the NULL away.

Nits

• nit: the description says this restores the previous speed but gives no numbers. The A/B figures from CPU-315 (if_chain/4_arms/last 300-313 ns before #39061, 344-351 ns after) plus this PR's number would make that checkable.

[antiguru]

I adjusted the PR based on the feedback. PR body now includes measurements, and there's an SLT to assert the error semantics. Thanks for the review!