AbstractFloat should not be convertible to infinity or NaN in concrete float type

[dneto0]

1e100 is a valid AbstractFloat value, but outside the finite range of f32.

When converting a value from one float type to another, values outside the finite range of the target (modulo possible truncation of mantissa bits) are converted to an infinity of the target type.

So f32(1e100) should be the infinity of f32.

This is a bit weird:

• you can't write a float literal with 'f' suffix that does the same thing. So f32(...) is not equivalent to the .....f form.
• also, WGSL doesn't have reliable support for infinity (or NaN) because that reflects underlying implementation limitations. There is no isinf, isnan equivalent that can be reliably implemented.

So, we're proposing a change to the float conversion rules: When a float to float conversion would produce an infinity, but the source type is AbstractFloat (and hence a creation-time constant value), then that produces a shader creation error.

Credit @ben-clayton for finding this issue and proposing the solution.

[dneto0]

Also, this rule mirrors the rule that an AbstractInt value outside the range of a concrete integer type is not convertible to that type. It also produces a shader creation error. See https://gpuweb.github.io/gpuweb/wgsl/#ref-for-abstractint%E2%91%A1

[ben-clayton]

Should we also prevent hex floats from constructing a NaN?

[dneto0]

Yes.

For hex float literals, the spec says:

The value of the literal is the value of the mantissa multiplied by 2 to the power of the exponent. When no exponent is specified, an exponent of 0 is assumed.

A NaN occurs when the mantissa is nonzero and the biased exponent is the all 1's value for that field, or the maximum representable exponent. So putting a NaN bit representation through the ideal value calculation (quoted), the result value is outside the finite range of the concrete float type.

So the spec update is basically: It's a shader creation error if an AbstractFloat value is being converted to a concrete float type, but the value is outside the finite range of the target type.

[kdashg]

WGSL meeting minutes 2022-05-31

• DN: PR now posted: AbstractFloat to out-of-finite-range is shader creation error #2984
• DN: When abstract numeric is too big for concrete type should be shader creation error. More in line with big float with f being shader creation error. Just makes it consistent.
• KG: Is this normal for a language or a new thing?
• DN: Normal thing I think.
• KG: Often warning or error?
• DN: Literal it’s an error. Looked at c++14, says if converting from double -> float (narrowing the type) if the value doesn’t fit in the finite range then it’s undefined behaviour. Don’t want implementation to do the check as it’s a hazard, so lets avoid.
• KG: Works for me. Let’s take it.