State the strict-floor rule once, and pin it

[matt-edmondson]

Fixes #218

What #218 found, and what is left of it

The issue reported that the two readers of dimensions.json tested physicalConstraints by different rules — the C# generator on the value (MinExclusive == "0"), the C++ projection on the presence of the object — so the first constraint declared that wasn't minExclusive: "0" would have given one declared quantity two domains depending on which language it was generated into.

The behavioural half of that has already landed. The Semantics.Vocabulary extraction moved the decision into QuantityVocabulary.BoundOf, and both projections now feed it the same value-based flag. Semantics.Cpp/QuantityVocabulary.cs:155, the line the issue quotes, no longer exists. So there is no live divergence to fix, and no generated output changes here.

What was left is the part the issue called "better still", and its third acceptance bullet:

• the rule was still two copies of overload.PhysicalConstraints?.MinExclusive == "0", one per reader — which is exactly the "one metadata file read by two generators with no shared decision logic" the issue objects to, and how the two came to hold different rules in the first place;
• nothing tested the case that separates the two rules. The three constraint sites the metadata declares today (Wavelength, Period, HalfLife) are all { "minExclusive": "0" }, where both rules agree. The divergence was invisible to the whole suite.

The change

One implementation. OverloadDeclaration.IsStrictFloor(string?) in Semantics.Vocabulary, which both MetadataProjection (C++) and VocabularyProjection (C#) now ask rather than restate. Semantics.Vocabulary is already compiled into both, so this costs no new reference. Behaviour is identical — the two comments that carried the rule in prose now point at the function that holds it.

The cases that separate the rules. Semantics.Cpp.Test/StrictFloorTests.cs, driven by a metadata document written for the purpose rather than the real one, because the distinguishing constraint is one the real file does not declare yet — the point is to fail on the day it does:

declared	guard emitted
{ "minExclusive": "0" }	assert(value.count() > 0
{ }	assert(value.count() >= 0
{ "minExclusive": "1" }	assert(value.count() >= 0
(none)	assert(value.count() >= 0

plus a table over IsStrictFloor itself, which is now the single point both projections answer from.

Verification

Temporarily restoring the pre-fix presence-based rule in MetadataProjection fails exactly the two new cases the old rule got wrong, and nothing else in the suite:

failed DoesNotGuardEmptyConstraintsStrictly
  Assert.Contains("assert(value.count() >= 0", Output.Files["EmptyConstraints.hpp"])
failed DoesNotGuardANonZeroFloorStrictly
  Assert.Contains("assert(value.count() >= 0", Output.Files["OtherFloor.hpp"])
  failed: 2

With the rule in place:

• Semantics.Cpp.Test — 43/43 pass
• Semantics.Test — 1273 pass, 8 skipped (Windows-only)
• dotnet build Semantics.sln -warnaserror — succeeds, no new warnings
• git status clean of generated-source churn, as expected for a behaviour-preserving change

net9.0 was compiled but not executed locally — the container has only the .NET 10 runtime. CI covers it.

Not in scope

The issue's sibling, #216, asks for the dimensional-exponent check to be ported into the .NET generator. That is a separate diagnostic and is left alone here.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WJpXUy8JcVGpjDmK1MMHKb

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud