ComboBox: reverse-lookup current-value writes into current-index

[tilladam]

Summary

Stacked on #12790 and #12791 (array.find-index / array.index-of) — this branch contains both commits plus one new one on top. Please review commit-by-commit via the "Commits" tab, or wait for the first two to merge and this will show a clean single-commit diff against master.

Implements Option A from #11970: a host write to current-value now means "select the row with this value" — the widget finds it in the model via array.index-of and moves current-index to match. A value that isn't in the model resolves to no selection (current-index -1, current-value ""), the same as setting current-index out of range — and, unlike the successful case, logs a debug() message naming the value, so a developer debugging an unexpectedly-cleared selection has something to go on. A successful reverse lookup stays silent.

Uses index-of rather than find-index: ComboBox is the first built-in widget with any dependency on the array-predicates machinery, and index-of is the stable half of it (#12791) — so this carries no dependency on the still-experimental find-index/any/all gate (#12777), unlike an inline find-index((value) => value == current-value) predicate would.

This supersedes the non-reverting interim behavior from 7dfcfdf93, which deliberately left an unmatched host write in place (with only a debug() warning) to avoid disturbing existing <=> two-way bindings while the real fix was blocked on iteration support. That blocker is gone for this narrow case: index-of needs no general loop, only a single-pass reverse lookup, so we no longer need the non-reverting compromise. <=> bindings that round-trip an arbitrary, not-in-model string through current-value will now see it replaced (with "" or the first match) instead of preserved — this is intentional, matching the issue's Option A design, not a regression.

RadioGroup is intentionally left untouched: its public API (declared in builtins.slint) exposes current-value as out only and never exposes current-index at all, so the only host-writable selection path is checked on an individual RadioButton child, which already correctly stays in sync with current-index/current-value (see RadioButtonImplBase's changed checked handler) — there's no writable-but-unreliable surface left for a reverse lookup to fix.

Known limitation, documented in combobox-base.slint and combobox.mdx: the reverse lookup runs from changed current-value, which only fires on an actual value transition. A write that doesn't change the property — writing the value it already holds, or a value equal to a later duplicate in model while an earlier duplicate should now be selected per the "first match" contract — is a no-op. Slint has no .slint-level hook for "run on every write regardless of value equality" (the Rust-internal equivalent, BindingCallable::intercept_set, isn't usable from widget source), so this can't be closed without new core machinery; it equally affected the debug()-only interim mitigation this replaces. Covered by two regression-documenting assertions in tests/cases/widgets/combobox.slint so the behavior stays intentional and visible rather than silently drifting.

Closes #11970 (for ComboBox — the issue also covered RadioGroup, addressed separately as described above).

Part 3 of 3:

1. Add experimental array.find-index predicate #12790 — array.find-index, the experimental predicate.
2. Add stable array.index-of, desugaring to find-index #12791 — array.index-of, the stable value-based sibling.
3. This PR — wires ComboBox to index-of, closing ComboBox and RadioGroup: writes to current-value are silently overridden #11970.

Test plan

• SLINT_TEST_FILTER=combobox cargo test --manifest-path tests/Cargo.toml -p test-driver-{interpreter,rust,cpp} — all 5 widget styles pass.

[LeonMatthes]

The approach seems good. 👍

We should take this opportunity to make sure setting current-value is consistent everywhere. Currently it behaves differently if set in the element instantiation instead of imperatively.

[LeonMatthes]

We should add this check to init as well, as current-value could be set at init time already, which currently behaves differently.

So currently this:

box := ComboBox {
     model: ["1", "2", "3"];
     current-value: "5";
}

Will actually show 5, which is inconsistent with box.current-value = "5", which would instead clear the ComboBox selection.

We should clear the selection at init time as well IMO. A ComboBox should only ever show a valid value, or an invalid index.

Make sure to run this check only if current-value != root.model[root.current-index] to prevent calling index-of on every init.

[tilladam]

I did implement this — added init => { root.reverse-lookup-current-value(); } so a declarative mismatch gets resolved the same way a host write does.

However, I could not verify it's actually reliable, so I've reverted it (1830689) rather than leave it in a state I can't stand behind. What happened: CI's Windows job ran the widget test suite twice in the same run — once normally (passed) and once with --features slint/live-preview (failed), on assert_eq!(get_init_value_found_index(), 1). I dug into the generated Rust to understand why: the literal current-value: "5" write does land in init() before user_init() runs the init => handler (I confirmed this empirically, so it's not a fundamentally broken approach), but I couldn't reproduce the failure locally after 30+ runs, including with the exact --features slint/live-preview flag CI uses. So there's a real platform- or feature-dependent difference here I don't understand yet, and I'd rather not ship an init-time fix I can't explain or verify.

Given that, I've pulled the init handler and the init-time test instances out of this PR. If you'd like this fixed here rather than as a follow-up, I'm happy to keep digging, but wanted to flag the CI finding rather than quietly resubmit something with an unexplained flake.

[LeonMatthes]

Please add a test first that set_current_value("dup") actually selects the first of the duplicate indices.

[tilladam]

Added — see the "A fresh write to a duplicate value" test right before the pre-existing known-limitation test: it writes a real transition ("" → "dup") and asserts index-of picks the first occurrence (index 1, not the later index 2).

[LeonMatthes]

Follow-up questions: what happens if I write current-index and current-value right after each other? 🤔
Does the last set win, or does current-index win over current-value?

Maybe we should add this to the test.

[tilladam]

Added a test for this — the "Consecutive writes to current-index and current-value" block. What it shows: each write's changed handler resolves the other property before the next statement runs, so with set_current_index(1); set_current_value("Ccc"); the value's resolution sticks (it was written last), and reversed, the index's resolution sticks instead. So today: last write wins, no built-in priority either way.

I want to flag that this is what I observed from the current changed-handler implementation, not something I verified is a robust, documented guarantee — while chasing the init-time issue above I found ordering-dependent behavior in this widget has more edge cases than I expected, so I'd rather not assert this as an intentional contract without your input. Do you want "last write wins" codified as the actual guarantee, or would you prefer e.g. current-index to always take priority over current-value regardless of write order? Happy to implement whichever you'd rather have.