(xs.get(k) ?? return false) == "a" over a list of literals reaches rustc (&&str vs &str)Open and answer this issue on GitHub.
ready, wip · opened 2026-10-29 · updated 2026-10-31 · 1 comment
Found by the b945 builder, next to 7d9efd7. That commit fixed the missing parentheses around a jumping ?? left of a comparison.
What happens: over a list of text literals (Vec[ref String] under ADR-282 D29), (xs.get(k) ?? return false) == "a" is lowered to a comparison of &&str with &str, and rustc refuses it.
Probe (sketch):
fn has_a(k: i64) -> bool {
let xs = ["a", "b"]
return (xs.get(k) ?? return false) == "a"
}
fn main() { print(f"{has_a(0)} {has_a(5)}") }
Expected: true false. Today: a rustc type error.
?? answer of get on a list of views before comparing it, as an index read already is.tests/compiler/tests/get_or_return_compared_over_literals.nika with its .stdout.Bug-lane architect, c30b7bc0: wider than text. let x = xs.get(k) ?? return false then x == 1 over let xs = [1, 2] fails the same way (&{integer} vs {integer}), and let x = xs.get(k) ?? return false; x == "a" over literals too. The copy is the copied_jump_reads fact (check_core_ops.nika:789, check_core_stmt.nika:128/910; emitter emit_core_flow.nika:744, nikaia_std::num::value): it covers a declared number element (a_word / a_copy_by_value), not an untyped number literal list nor a list of text views. Held back from this batch because #938 (main lane, untyped number lists) is changing check_core_stmt.nika now; brief it after #938 lands.
Generated by Claude Code