Seven operators hand-wrote the same count check and the same message.
Move it to Operators, next to evalArgs, whose result it always checks.
Messages are unchanged, so no fixture moves.
Co-authored-by: Cursor <cursoragent@cursor.com>
* Compare strings by UTF-16 code unit in the rules engine
A JS string is a sequence of UTF-16 code units and every string operation
works on those units. Swift's String compares canonical equivalence over
Unicode scalars, so <, <=, >, >=, ==, ===, in and rc.entries key ordering
all had cases where a predicate evaluated one way on iOS and the other in
JS and Kotlin.
Co-authored-by: Cursor <cursoragent@cursor.com>
* Keep the new fixture descriptions platform-neutral
The fixture files are byte-identical across the iOS and Android engines, so
a description that explains the contract in terms of one host language's
string comparison does not read correctly in the other repository.
Co-authored-by: Cursor <cursoragent@cursor.com>
* Name the characters under test in the UTF-16 fixture descriptions
The predicates spell these strings as \uXXXX escapes so the exact code
units are unambiguous, which leaves a reader unable to tell which
character a fixture is about. Each description now shows the glyph and
its code point, and spells out the surrogate pair where one is the
point of the case.
Co-authored-by: Cursor <cursoragent@cursor.com>
* Route rc.sortBy string keys through jsStringPrecedes
The operator open-coded the UTF-16 comparison because the shared helper
did not exist yet when it landed. It does now, and the rationale lives
in the helper's doc, so the operator no longer repeats it.
Co-authored-by: Cursor <cursoragent@cursor.com>
---------
Co-authored-by: Cursor <cursoragent@cursor.com>
* Add rc.sortBy custom operator
Orders an array by a key computed per item, ascending, with ties keeping
their input order. Keys must be all strings or all numbers so the two
engines never have to invent a cross-type ordering.
Co-authored-by: Cursor <cursoragent@cursor.com>
* Reject non-finite rc.sortBy keys
A NaN key compares false in both directions, so every pair tied and the
input came back unsorted with no error. Negating a string key to attempt
a descending sort produced exactly that.
Co-authored-by: Cursor <cursoragent@cursor.com>
* Note ascending order in the rc.sortBy summary
Co-authored-by: Cursor <cursoragent@cursor.com>
* Trim the rc.sortBy doc comment
Co-authored-by: Cursor <cursoragent@cursor.com>
* Trim the rc.sortBy stability comment
Co-authored-by: Cursor <cursoragent@cursor.com>
* Order rc.sortBy string keys by UTF-16 code unit
Swift's < orders by Unicode scalar and treats canonically equivalent
strings as equal, while JS and Kotlin order by UTF-16 code unit. The two
disagree once a scalar above the surrogate range meets an astral one, so
the same rule would sort differently on iOS and Android.
Co-authored-by: Cursor <cursoragent@cursor.com>
* Keep the rc.sortBy ordering fixtures platform-neutral
The fixture files are byte-identical across the iOS and Android engines, so
a description that explains the contract in terms of one host language's
string comparison does not read correctly in the other repository.
Co-authored-by: Cursor <cursoragent@cursor.com>
---------
Co-authored-by: Cursor <cursoragent@cursor.com>
