Void as a member or wrapper element passes validation and generates `void x{};` / `std::optional<void>`

[matt-edmondson]

What happens

ValidateParameter refuses a top-level Void parameter, but nothing refuses Void as a member type or inside a wrapper. ValidateType's WrapperType arm simply recurses, and its default: arm swallows both Void and None:

// Schema/Models/Schema.Validation.cs:723-729
// Every wrapper resolves to whatever it wraps, so a class named inside a Span,
// Handle, Result or Optional is checked exactly as one named directly is.
case WrapperType wrapper:
    ValidateType(issues, wrapper.ElementType, path, element);
    break;

default:
    break;

Member-level checks (Schema.Validation.cs:102-112) warn only on member.Type is None — Void is not mentioned. CppTypeMapper then maps it unconditionally (Schema.Cpp/CppTypeMapper.cs:48): SchemaTypes.Void => new TypeReference("void").

Failure scenario

member type	schema.Validate()	generated C++
Void	clean	void x{};
Optional<Void>	clean	std::optional<void> x{};
Span<Void>	clean	std::span<void> x{};
Optional<None>	clean	CppGenerationException

All four C++ outputs are ill-formed — std::optional<void> and std::span<void> are explicitly not instantiable.

Why it matters

CLAUDE.md states the invariant as:

Schema.Validation.cs enforces the corollaries — no Array, Result or Void parameters, no None anywhere generatable.

Neither half holds below the top level.

Optional<None> at least fails loudly at generation time. Void fails silently, and the broken header only surfaces at the consumer's compiler — pointing at generated code rather than at the schema that produced it.

A Void member is also a plausible editing state rather than a contrived one: the type picker offers Void for return types, and the same picker serves members.

Suggested fix

Report Void at any position other than a function return type (and Result's element), and report None wherever ValidateType descends rather than only at the top of a member or parameter.

The WrapperType arm is the single place both can be caught on the way down, so the fix is one check rather than one per call site.

[matt-edmondson]

Triage

Priority: High Effort: Small

What needs to be done: Void is only refused as a top-level parameter type; as a member type or nested inside a wrapper (Optional<Void>, Span<Void>) it passes validation cleanly because ValidateType's WrapperType arm recurses without checking, and member-level checks only test for None, not Void. The C++ generator maps Void unconditionally, so all of these validate cleanly and then emit ill-formed C++ (void x{};, std::optional<void>, std::span<void> — none of which are legal). Worse, the editor's type picker offers Void for members via the same picker used for return types, so this is a reachable editing state, not a contrived one.

Suggested next steps / acceptance criteria:

• Report Void at any position other than a function return type (and Result's element type), and report None wherever ValidateType descends (not just at the top of a member/parameter) — the WrapperType arm is the single place both can be caught on the way down per the issue's analysis.
• Add validation tests for Void and Optional<None>/Span<Void> etc. as member types, asserting they're now rejected.
• Add/confirm a C++ generation test that a rejected schema never reaches CppTypeMapper (i.e. validation is the actual gate, not generation-time luck).

Blockers / dependencies: None identified. One shared choke point (WrapperType arm) fixes all the reported cases.

---

Generated by Claude Code