Whole-number double literals are emitted as integers: 1.0/2.0 becomes integer division (0) in C/C++/Go and fails to compile in Rust

[matt-edmondson]

What's wrong

LanguageGeneratorBase writes a LiteralExpression<double> as doubleLit.Value.ToString(CultureInfo.InvariantCulture) (Coder/Languages/LanguageGeneratorBase.cs:~132-134). As a result, 2.0 is written as 2. The C# generator overrides this and adds a d suffix. The C, C++, Go, Rust, Python and JavaScript generators use the base behaviour.

Failure scenarios

Input: VariableDeclaration("x", "double", Binary(Literal.DecimalValue(1.0), Divide, Literal.DecimalValue(2.0)))

• C / C++: emits double x = (1 / 2);. This is integer division, so x is 0, not 0.5.
• Go: emits var x float64 = (1 / 2). This is constant integer division, so x is 0.
• Rust: emits let mut x: f64 = (1 / 2);, which rustc rejects with E0308 (mismatched types).
• Inferred locals: 2.0 becomes k := 2, auto k = 2; or let mut k = 2;, which types the variable as an integer. A later k = k * 0.5 then fails to compile in Go.

Non-finite values have their own problems:

• double.PositiveInfinity is emitted as the bare text Infinity in every target (Infinityd in C#).
• After a YAML round trip it gets worse. The serializer writes .inf, and YamlDeserializer (~line 1264) cannot parse that, so the declaration silently loses its initializer and becomes double inf;.

Suggested fix

• Format with "R" (round-trip) and append .0 when the text contains none of ., E or e.
• Spell infinity and NaN for each language: INFINITY/NAN (C/C++), f64::INFINITY (Rust), math.Inf(1) (Go), float('inf') (Python), Infinity (JS), double.PositiveInfinity (C#).
• Accept .inf, -.inf and .nan in the YAML deserializer.
• Add per-language tests that 1.0 / 2.0 emits a floating-point expression.

[matt-edmondson]

Triage

• Category: Bug
• Priority: High. In C, C++ and Go the generated code compiles but gives wrong results (1.0/2.0 evaluates to 0). Rust fails to compile. A YAML round trip also silently drops non-finite initializers. It affects every non-C# target that goes through LanguageGeneratorBase.
• Area / suggested owner: LanguageGeneratorBase literal formatting, plus per-language non-finite spellings and YamlDeserializer
• Duplicates / in progress: None found. No open PR references this issue.
• Notes: The core fix is small: format with "R" and add .0 when needed. The infinity/NaN spellings and the YAML .inf handling could ship as a follow-up if that keeps the first PR tight.

---

Generated by Claude Code

[matt-edmondson]

#90 fixes the core bug: whole-number doubles now get .0, so 1.0 / 2.0 stays a floating-point division in C, C++, Go, Rust, Python and JS.

This issue should stay open after #90 merges. Two parts are left:

• Per-language spellings of infinity and NaN. The C/C++ and Go spellings need an include or import added.
• Parsing .inf, -.inf and .nan in YamlDeserializer.

---

Generated by Claude Code

[matt-edmondson]

Triage

#90 and #95 have merged. They fixed the whole-number .0 bug and the YAML .inf/.nan parsing. One part is still open: spelling infinity and NaN in each language.

This is blocked on a design decision, not on implementation:

• C, C++ and Go have no way to write these values without an import. C needs INFINITY/NAN from <math.h>, C++ needs std::numeric_limits from <limits>, and Go needs math.Inf(1)/math.NaN() from "math".
• Generators never add imports themselves. SourceFile.Imports is the only source of #include and import lines, and PythonGenerator says outright that emitting one would change how generators work.
• Workarounds don't hold up. Writing 1.0/0.0 instead is ill-formed in a C++ constant expression, and Go rejects it as a constant division by zero.

The options, for the maintainer to choose:

1. Let generators add the import a literal needs. This is a new mechanism in SourceFile generation.
2. Write the import-free spelling where one exists (Python float('inf'), JS Infinity/NaN, Rust f64::INFINITY, C# double.PositiveInfinity). For C, C++ and Go, document that the caller must add the import to SourceFile.Imports.
3. Reject non-finite literals in those three targets with a clear error.

I've unassigned this issue so a later run picks it up once there's a decision. Unrelated to this, #83 (float and long literals and quoted strings) is fixed in #108.

---

Generated by Claude Code

[matt-edmondson]

Decision (maintainer, 2026-09-28)

• Option 1, "Let generators add the import a literal needs", is chosen. Generators add the required #include/import for non-finite literals: <math.h> for C NAN/INFINITY, <limits> for C++ std::numeric_limits, and "math" for Go math.NaN()/math.Inf(±1). That is a new mechanism in SourceFile generation, merged with SourceFile.Imports without duplicates.
• Options 2 (caller adds the import) and 3 (reject non-finite literals) are not taken.
• The remaining per-language spellings are the same work as NaN and ±Infinity double literals are emitted as undefined identifiers (NaNd, Infinity, -Infinity) in every language except JavaScript #96, which has the full spelling table. Do it once, covering both issues.

Next reader: add the "required imports" mechanism to generation, then implement per-language NaN/±∞ spellings with the data-driven test from #96. Close this issue and #96 together when that lands. Whole-number .0 and YAML .inf/.nan are already done in #90/#95.

---

Generated by Claude Code