Follow-up to #68. That issue scoped equality (= / <>) for text and explicitly deferred ordering operators:
Ordering operators (<, <=, >, >=) on strings are a separate question and can be left as-is for now (numbers only) unless we want lexicographic ordering.
This is the separate question.
Current behavior
"a"<"b" returns #VALUE! — the ordering arm in crates/cell-sheet-core/src/formula/eval.rs still coerces both sides to f64 via cell_value_to_number, which errors on text.
Excel / Google Sheets behavior
Both treat the ordering operators as lexicographic on text:
"a"<"b" → TRUE"banana"<"apple" → FALSE"Foo"<"foo" → ? — this is where it gets interesting
Excel's text ordering is case-insensitive for < / > (matching its case-insensitive =). Google Sheets is the same. So "Foo"<"foo" is FALSE in both because they compare equal under case folding.
Open design questions
- Case sensitivity. Should ordering follow
= and be case-insensitive? Strong yes for Excel parity. Implementation: lowercase both sides before comparing.
- Mixed-type ordering. What does
1<\"a\" mean? Excel sorts numbers before text before booleans, so 1<\"a\" is TRUE. We'll need a type-rank helper. Alternative: keep mixed-type ordering as #VALUE! and only support same-type ordering. Worth deciding explicitly.
- Bool ordering. Excel sorts booleans after text (
\"z\"<TRUE → TRUE). Niche; consider whether to bother.
- Locale. Pure byte / Unicode-codepoint ordering, or locale-aware collation? Codepoint ordering is simplest and predictable; locale-aware needs ICU. Codepoint is probably fine for v1.
Acceptance criteria
Follow-up to #68. That issue scoped equality (
=/<>) for text and explicitly deferred ordering operators:This is the separate question.
Current behavior
"a"<"b"returns#VALUE!— the ordering arm incrates/cell-sheet-core/src/formula/eval.rsstill coerces both sides tof64viacell_value_to_number, which errors on text.Excel / Google Sheets behavior
Both treat the ordering operators as lexicographic on text:
"a"<"b"→TRUE"banana"<"apple"→FALSE"Foo"<"foo"→ ? — this is where it gets interestingExcel's text ordering is case-insensitive for
</>(matching its case-insensitive=). Google Sheets is the same. So"Foo"<"foo"isFALSEin both because they compare equal under case folding.Open design questions
=and be case-insensitive? Strong yes for Excel parity. Implementation: lowercase both sides before comparing.1<\"a\"mean? Excel sorts numbers before text before booleans, so1<\"a\"isTRUE. We'll need a type-rank helper. Alternative: keep mixed-type ordering as#VALUE!and only support same-type ordering. Worth deciding explicitly.\"z\"<TRUE→TRUE). Niche; consider whether to bother.Acceptance criteria
\"a\"<\"b\"and similar return aBoolrather than#VALUE!.help/entries.rs(extend the=/<>entry, or add a new one).cell-sheet-corecover same-type text ordering, case behavior, and the mixed-type decision.eval_ordering_on_text_still_errorsregression test ineval.rs(currently locks in the deferred behavior).