render/forms: normalizeLocaleNumber matches the minus sign as a literal byte, so a U+2212 locale cannot round-trip

[Yaraslaut]

Split out of #574, which listed it as one of two "smaller fixes while there" and whose PR (#581) deliberately did not take it: it is an API change to both control edges and all their call sites, and unlike the group-separator defect it does not produce a wrong value — it rejects a valid entry. Filing it so closing #574 does not lose it.

Verification status: reproduced

Revision: fix-574-quantity-provenance-locale @ 3a1effd0 (PR #581), i.e. after the group-separator fix. The sign behaviour is unchanged by that PR.

morph::render::normalizeLocaleNumber(text, decimalSeparator, groupSeparator) takes both separators as std::string_view precisely because a real locale's separator is not always one byte (fr-FR groups with U+202F). The sign got no such treatment: it is matched as the literal byte '-', in include/morph/render/locale_format.hpp:

char const chr = text[i];
if (chr == '-') {

So a locale whose minus sign is U+2212 MINUS SIGN (−, 3 UTF-8 bytes) cannot round-trip:

normalize("−5", dec=".", grp="")  = NULLOPT

— the first byte of U+2212 is not a digit, not '-', and matches neither separator, so the entry is reported malformed. formatCanonicalNumber, the display-direction inverse, has the mirror-image problem: it emits a literal '-' whatever the locale.

The same is true of the QML mirror in src/qt/forms/qml/DynamicForm.qml, which compares ch === "-".

Why it matters, and why it is smaller than #574 was

This one rejects, it does not silently mis-convert. A user who types −5 is told the entry is malformed, which is wrong but visible and recoverable — the opposite of "1.5" → 15, which was the whole reason #574 was a defect. So the cost is a usability failure in a locale that uses the typographic minus, not a wrong number on the wire.

Qt's QLocale::negativeSign() returns U+2212 for several locales, and DynamicForm.qml reads the rest of its separators straight off Qt.locale(), so a renderer that passed qtLocale.negativeSign through would be handing this function something it cannot accept today.

Suggested shape

A fourth parameter, std::string_view negativeSign = "-", matched as a whole string the way the separators already are, and the same on formatCanonicalNumber so the pair stays inverse. Both edges must change together — docs/spec/forms/forms.md, "Locale data formatting", records that a divergence between the C++ function and its QML mirror is a divergence in what the product accepts.

Not verified

• Which locales Qt actually reports U+2212 for on each platform, and whether any application in this repository configures one. The claim above is about QLocale's documented behaviour, not a measurement.
• Whether a positiveSign parameter is wanted for symmetry. Neither edge accepts a leading + today at all, in any locale, which is a separate question.

What would change the verdict

Close this if the control edge is deliberately restricted to ASCII - on entry, with the renderer expected to normalise the sign before calling — but nothing says that today, and the separators set the opposite precedent in the same function.

[Yaraslaut]

Reproduced output, for the record (clang 22.1.8, branch `fix-574-quantity-provenance-locale` @ `3a1effd0`):

normalize(U+2212 "5", dec=".", grp="") = NULLOPT
normalize("-5",       dec=".", grp="") = "-5"
formatCanonicalNumber("-5", ",", ".")  = -5

The second and third lines are the controls: ASCII - parses, and the display direction emits ASCII - whatever the locale, so the pair is not inverse for a locale whose sign is anything else.

[Yaraslaut]

Triage: valid — premise reproduced, and the "not verified" clause is now measured

Re-verified on current master (70792bee), i.e. after #581 landed.

The premise reproduces, in both directions

A standalone -fsyntax-only-clean program against include/morph/render/locale_format.hpp:

== entry direction ==
normalize("-5",     dec=".", grp="")   ASCII  -> "-5"
normalize("−5",     dec=".", grp="")   U+2212 -> NULLOPT
normalize("−1.050,25", dec=",", grp=".") de-DE -> NULLOPT

== display direction ==
format("-1050.25", dec=",", grp=".")          -> "-1.050,25"
  (no way to ask for U+2212: the sign is a hardcoded '-')

So the report is accurate as written: the sign is matched as the literal byte
'-' at include/morph/render/locale_format.hpp:190, and emitted as one at
:249, while both separators are matched as whole string_views.

What the issue listed as not verified, now measured

"Which locales Qt actually reports U+2212 for on each platform... The claim above is about QLocale's documented behaviour, not a measurement."

Enumerated over every locale Qt knows, Qt 6.11.2, QLocale::matchingLocales(AnyLanguage, AnyScript, AnyCountry):

negativeSign values across 711 Qt 6.11.2 locales:

  U+002D                  634 locales   e.g. C
  U+061C U+002D            24 locales   e.g. ar_EG
  U+200E U+002D             9 locales   e.g. ar_DZ
  U+200E U+002D U+200E     17 locales   e.g. az_IR
  U+200E U+2212             2 locales   e.g. fa_IR
  U+200F U+002D             2 locales   e.g. ckb_IQ
  U+2212                   23 locales   e.g. eu_ES

77 of 711 locales — not one hypothetical locale. Bare U+2212 is real (23
locales, e.g. eu_ES), so the headline claim stands. But the issue understates
the case: 54 further locales carry a bidi-control-prefixed sign
(U+061C ARABIC LETTER MARK, U+200E LTR MARK, U+200F RTL MARK) that is 2–3 UTF-16
units, including two that combine both (U+200E U+2212, e.g. fa_IR).

Every one of those forms is rejected today:

eu_ES  normalize("−5")     [bare U+2212]      -> NULLOPT
fa_IR  normalize("‎−5")    [bidi + U+2212]    -> NULLOPT
ar_DZ  normalize("‎-5")    [bidi + ASCII '-'] -> NULLOPT
control: normalize("-5")                      -> "-5"

Note ar_DZ: the sign is prefixed ASCII '-', so a locale can fail this even
when its minus sign is the ordinary hyphen.

Why the proposed fix survives that correction

The suggested shape — a fourth std::string_view negativeSign = "-" matched as a
whole string, on both normalizeLocaleNumber and formatCanonicalNumber — is
exactly right for all 77, because whole-string matching is what handles the
multi-unit bidi forms too. The count changes; the fix does not. Hence valid
rather than rescope.

The motivation is live, not hypothetical

src/qt/forms/qml/DynamicForm.qml:118 defines property var qtLocale: Qt.locale(displayLocale),
and the renderer already passes that locale's data straight through at three call
sites (:1048, :1724, :1729):

normalizeLocaleNumber(text, qtLocale.decimalPoint, qtLocale.groupSeparator)

negativeSign is the one piece of the same QLocale object that is hardcoded
instead of passed. displayLocale is a settable property, so this is reachable
by configuration, not by a future refactor.

Invariants checked

• Invariant 3 (the value type reports the fact; the layer decides the policy)
  is satisfied by the proposed shape: the function keeps reporting
  std::nullopt and the control edge keeps owning what that means. A defaulted
  fourth parameter is additive — no existing call site changes behaviour.
• Invariant 5 (spec/code disagreement is itself the finding) does not
  apply: docs/spec/forms/forms.md "Locale data formatting" justifies
  string_view separators by multi-byte locale data but says nothing about the
  sign. It is a gap, not a contradiction — so the fix must add to that section.
• The spec's "Both edges, or neither" rule binds: DynamicForm.qml:857
  (ch === "-") and :889 ((neg ? "-" : "")) carry the identical defect and
  must change in the same PR. The QML mirror compares one UTF-16 code unit,
  so it needs whole-string comparison for the 2–3 unit forms specifically.

Filed separately, not folded in

ar_EG renders -5 as U+061C U+002D U+0665 — U+0665 is ARABIC-INDIC DIGIT
FIVE, not ASCII '5', and the digit scan chr >= '0' && chr <= '9' rejects it:

ar_EG  normalize("؜-٥")  [sign + native digit] -> NULLOPT
       normalize("٥")    [native digit alone]  -> NULLOPT

So for those 24 locales, fixing the sign alone still will not make entry work.
That is a different fix site (the digit scan, not the sign match) and a
larger decision, so it is filed as its own issue rather than folded in here.

What would change the verdict

Close this if the control edge is deliberately restricted to ASCII -, with the
renderer expected to normalise the sign before calling — but that would now have
to be written down, and it would have to explain why the separators three lines
away take the opposite approach.

Not verified here

• Whether positiveSign is wanted for symmetry. Neither edge accepts a leading
  + at all today, in any locale; unchanged from the original report.
• These counts are Qt 6.11.2 on Linux. Qt's locale data is CLDR-derived and
  versioned, so another Qt release may shift the counts — not the conclusion.
• Measured QLocale::matchingLocales only; not tested against a running Qt GUI.