forms: two Choice fields of different types collapse into one $defs entry, and the renderer draws the wrong control

[Yaraslaut]

Part of the sweep tracked in #518. Finding F25.

Summary

choice.hpp:162 and widget_hints.hpp:138 give every instantiation the same schema name:

static constexpr std::string_view name = "Choice";   // for EVERY instantiation
static constexpr std::string_view name = "Ranged";   // for EVERY Min/Max/Step

glaze keys $defs by name_v<T> and populates a definition only once (glaze/json/schema.hpp:1069-1072: auto& def = defs[name_v<val_t>]; if (!def.type) { … }). The second distinct instantiation is silently skipped and $refs the first one's definition.

Verification status

Reproduced. Revision: master @ 4017228d. Compiled against the repo's pinned glaze.

For struct BoolFirst { Choice<bool,"YesNo"> flag; Choice<std::int64_t,"ListSamples"> sampleId; }:

"sampleId":{"$ref":"#/$defs/Choice", ...}
"$defs":{"Choice":{"type":["boolean","null"]}}

An int64 picklist described as a boolean. Also verified:

• Choice<std::string,"ListCodes"> next to Choice<std::int64_t,…> → the string field gets {"type":["integer","null"],"minimum":-9223372036854775808,…}.
• Ranged<0.0,1.0,0.1> next to Ranged<0,100> → {"type":["integer","null"],"minimum":-2147483648,…} while the property correctly carries "x-step":0.1. Every legal value of the double slider fails the type it was served under.

Not verified: I did not drive the QML renderer end-to-end to observe the wrong control on screen; the control-selection path is traced by reading (below).

Why this is not benign

docs/spec/forms/choice.md:150-161 and widget_hints.md:128-138 call this benign — "renderers that submit the raw nullable value observe no problem". That is false for morph's own shipped renderer:

• src/qt/forms/qml/DynamicForm.qml:229 (resolveRef) merges the $def over the property.
• :460 sets isBoolean: types.indexOf("boolean") !== -1.
• :1069 draws a checkbox.

It is also false for any generic validating client: the document emits additionalProperties: false and a standard required array, i.e. it is presented as validatable.

This is the same failure mode that the glaze_enum_t static_assert at forms.hpp:2064 was added to prevent (morph#392), re-entering through a different door.

Suggested fix

Make name unique per instantiation, exactly as Quantity already does (util/quantity.hpp:1209 composes from UnitTraits<…>::meta(U).id):

• Choice — compose from the FixedString NTTPs, e.g. "Choice_" + OptionsAction + "_" + ValueField.
• Ranged — compose from a constexpr rendering of Min/Max/Step.

Both are compile-time deterministic and compiler-independent (important: they must not derive from glz::name_v, for the reason payload_schema.hpp:66-70 gives).

This changes $defs keys, so it is a wire-shape version bump — but the current behaviour is a wrong schema, not a compatible one.

If the name cannot change, the minimum fix is a static_assert rejecting two Choice/Ranged instantiations with different payload types in one action.

What would change the verdict

• Close it if the renderer contract is changed so that $def type is never consulted — but DynamicForm.qml:460 consults it today.
• Regression test: generate a schema for an action with two differently-typed Choice members and assert both $defs entries exist with the right types. A single-Choice action passes with or without the fix.

[Yaraslaut]

Re-measured before implementing: already fixed, and the ticket is stale

Dispatched to me as rescope, so I re-measured the premise before building
anything. The premise no longer holds on master.

What the code says now

choice.hpp:170 no longer spells name = "Choice":

static constexpr std::string_view name =
    morph::forms::detail::choiceSchemaName<OptionsAction, ValueField, LabelField, DependsOn...>;

and widget_hints.hpp:149:

static constexpr std::string_view name = morph::forms::detail::rangedSchemaName<decltype(Min)>;

Both were introduced by 2c312f19 ("Fix two forms-layer safety gaps found by
the #518 review sweep", PR #562, 2026-09-18), along with
include/morph/forms/detail/schema_name.hpp. That PR's title names the sweep
rather than the issue numbers, which is presumably why #543 and #544 both
stayed open.

Reproduced, on this issue's own fixture

master @ c6f6d953, clang 22.1.8, -std=c++23, glaze v7.4.0 (pinned). This
issue's BoolFirst, extended with the std::string case it also names:

struct BoolFirst {
    morph::forms::Choice<bool,         "YesNo">       flag;
    morph::forms::Choice<std::int64_t, "ListSamples"> sampleId;
    morph::forms::Choice<std::string,  "ListCodes">   code;
};
struct MixedRanged {
    morph::forms::Ranged<0, 100>        coarse;
    morph::forms::Ranged<0.0, 1.0, 0.1> ratio;
};

morph::forms::schemaJson<...>() output, properties and $defs keys:

== BoolFirst
  code     -> ['string', 'null']
  flag     -> ['boolean', 'null']
  sampleId -> #/$defs/Choice_ListSamples_id_name
  $defs: Choice_ListSamples_id_name -> ['integer', 'null']
== MixedRanged
  coarse -> #/$defs/Ranged_i32
  ratio  -> #/$defs/Ranged_f64
  $defs: Ranged_f64 -> ['number', 'null']
         Ranged_i32 -> ['integer', 'null']

Every field is described under its own payload type. The int64 picklist is no
longer a boolean; the double slider is no longer an int. flag and code are
inlined rather than $ref'd because each is used exactly once, which is glaze's
ordinary deduplication and not a symptom.

The regression tests this issue asked for also exist

Regression test: generate a schema for an action with two differently-typed
Choice members and assert both $defs entries exist with the right types. A
single-Choice action passes with or without the fix.

That is in the tree, with the "single-Choice action passes either way"
argument written into the fixture's own comment:

$ ./build/clang-debug/tests/morph_tests \
    "*DifferentlyTypedChoiceFields*,*ChoiceFieldsOfOneInstantiation*,*DifferentlyTypedRangedFields*"
All tests passed (18 assertions in 3 test cases)

• tests/test_quantity_forms.cpp — Forms::SchemaJson::DifferentlyTypedChoiceFieldsKeepTheirOwnTypes
  (three Choice fields, bool/int64_t/std::string) and
  …::ChoiceFieldsOfOneInstantiationShareOneDefinition (the other direction:
  two fields of the same instantiation still share one entry, so the split is
  per instantiation and not per field).
• tests/test_widget_hints.cpp — Forms::SchemaJson::DifferentlyTypedRangedFieldsKeepTheirOwnTypes.

The docs were updated too: docs/spec/forms/choice.md:171 now reads "That was
morph#543", and docs/spec/forms/widget_hints.md:156 cites it as the same
defect — so the "benign" claim this issue was filed against is gone from both
specs.

Verification status

Reproduced — the fix, not the defect. Measured on master @ c6f6d953 with
the command and output above, plus the three in-tree cases. I did not verify
the defect against the revision this issue names (4017228d); the reporter did,
and nothing here depends on re-doing it.

Not verified: that DynamicForm.qml now draws the right control on screen —
the same thing the original report lists under "Not verified". The schema is
correct, and DynamicForm.qml:460's isBoolean reads the type it is now served,
so the control-selection path is right by construction; that is a reading, not a
screenshot.

What would change the verdict

Re-open if a Choice or Ranged payload type ever collapses into a shared
$defs entry again — the three tests above are the check, and the
$defs key names (Choice_<OptionsAction>_<ValueField>_<LabelField>,
Ranged_<payload>) are the thing to watch.

Closing as already fixed. No commit from this lane.