The spec doesn't take a position on the stringification for most types. But in practice, the Java and Go implementations agree that positive infinity gets turned into "+inf" rather than "inf". This causes issues for Bazel's current textproto serialization, where "+inf" is not valid but "inf" is.
The obvious fix is to handle this specially in the textproto serialization logic. But the question came up of whether we should instead change the general convention for Starlark floats.
Argument: "+inf" is not consistent with Python, which uses "inf". But then again, our NaN behavior is completely different from Python, so maybe we're less bound by precedent here.
Argument: "+inf" is nicely symmetric to "-inf". But then again, we don't stringify positive float zero to "+0.0".
Argument: Go distinguishes positive infinity with a plus. But it uses "+Inf" rather than lower "+inf". And Go's precedent matters less than Python's.
The spec doesn't take a position on the stringification for most types. But in practice, the Java and Go implementations agree that positive infinity gets turned into
"+inf"rather than"inf". This causes issues for Bazel's current textproto serialization, where"+inf"is not valid but"inf"is.The obvious fix is to handle this specially in the textproto serialization logic. But the question came up of whether we should instead change the general convention for Starlark floats.
Argument:
"+inf"is not consistent with Python, which uses"inf". But then again, our NaN behavior is completely different from Python, so maybe we're less bound by precedent here.Argument:
"+inf"is nicely symmetric to"-inf". But then again, we don't stringify positive float zero to"+0.0".Argument: Go distinguishes positive infinity with a plus. But it uses
"+Inf"rather than lower"+inf". And Go's precedent matters less than Python's.