Constants: clarify type

[thorehusfeldt]

The current 2025-09 says, under constants:

A constant value is either a scalar (integer, float, or string), or a map with a required value key (integer, float, or string) and optional variant keys providing alternative representations.

This does not specify the type of a “variant” key.

I think it should be string. To be precise, I suggest this schema:

	constants?: [=~"^[a-zA-Z_][a-zA-Z0-9_]*$"]: int | float | string | {
		value!:               int | float | string
		[string & !="value"]: string
	}

If not, we don’t know that this means:

constants:
  k:
    value: 5000000
    tex: 5,000,000
    mystery: 5.000
    scientific: 5 \cdot 10^6

We would need to rely on the YAML parser or editor to tell us what k.mystery is (here: the float 5.0). The spec says “a representation”, which can mean many things to many people, including __repr__(). Had I written mystery: 5.000,000 I would need to understand how YAML (a notoriously ill-specified standard) interprets that value (here: the string "5.000,000".)

[niemela]

I think you are saying that "all constants should be treated as opaque strings"? If so, I very much agree, but explained why much better!

[RagnarGrootKoerkamp]

Just restating the same in my own words after some discussion:
So the constant (value) itself can be int, float, or string, and will be rendered the usual way.
This is nice because value: "5" is a bit silly.

But specifically all variants (alternative representations) will be different representations of the same value. But when written without quotes (ie as string/float), there is a high risk that the yaml-parser interprets those different representations as a different value instead.

Eg 5,000 or 5.000 might be parsed as just the integer 5 rather than 5000, completely defeating the purpose.
So to safeguard the user from mistakes, it's best to only allow strings for the alternative representations.

[niemela]

So, should it be a warning or an error to have a alternate representation that is not a string?

[RagnarGrootKoerkamp]

In the spec it's an error, but tooling can make it a warning instead.

[niemela]

In the spec it's an error, but tooling can make it a warning instead.

That doesn't make sense. If we want to allow tools to make it only a warning, it should not be an error. What am I missing?

[RagnarGrootKoerkamp]

From the perspective of the spec, something is either valid or not, so error it is.

But tools can still continue to work but give a warning/error that it should be fixed. (And still give non-zero exit code.)