Numeric conversion rules wording is inconsistent

[zoddicus]

This originates from writing CTS tests for u32 & i32, and finding them failing for Dawn/Tint, issue.

There is some subtly inconsistancies in the language used for numeric conversions, which causes unexpected behaviours.

Specifically f16(e: T), i32(e: T), and u32(e: T) say 'T is a scalar type', where as f32(e: T) says 'T is a concrete scalar type'.

So for f32, AbstractInt and AbstractFloat go through conversion to a concrete type before being converted to the destination type, where as the others go directly. u32 and i32 have explicit language about how to handle AbstractInt, so this doesn't appear to be a simple typo.

Where this gets weird is when passing an out of range abstract floating point value into u32(). Conversion rules means that it will be rounded towards 0 to the nearest u32 (either 0 or max) instead of erroring, which multiple people have mentioned is unexpected.

[dneto0]

Related to #4569

[kdashg]

WGSL 2024-04-30 Minutes

• KG: f32’s specification is different from the other ones. Is this on purpose?
• DN: This is kind of the same as the next issue. The difference is floating-point to integer-conversions versus integer-to-integer conversions. We introduced a distinction between these two because we wanted to introduce clamping on the floating-point side.
• KG: let’s discuss the next two points.
• In light of u32(abstractint) errors on out of bounds value, u32(abstractfloat) and u32(f32) clamps out of bounds value #4569 being closed:
• DN: Let’s think about this one a bit more.

[dneto0]

Where this gets weird is when passing an out of range abstract floating point value into u32(). Conversion rules means that it will be rounded towards 0 to the nearest u32 (either 0 or max) instead of erroring, which multiple people have mentioned is unexpected.

The resolution to #4569 confirmed that truncate-to-zero-then-clamp is the intentional behaviour for u32(x) where x is out of bounds for u32.

The same set of rules apply to i32(x).

And completing the thought:

• f16(x)
  • The finite range of f16 is roughly +/- 65K, so the same overflow cases occur when x is AbstractInt or i32.
  • Similarly, the same overflow cases occur for x in AbstractFloat or f32.

So no spec change is required. Closing.

[dneto0]

Reopen to make f16 and f32 wording consistent. My preference is to separate the f16 cases into abstract and concrete cases.

[kdashg]

WGSL 2024-05-14 Minutes

• DN: Alan and I verified the key issue is overflow behavior for u32(x) and i32(x), and that was resolved in #4569 in the last meeting. Also I verified that the f16(x) cases do the correct thing across all scalar argument types. I closed the issue as no-change-to-spec.
• JB: Mozilla’s main concern now after 4569 was that f32 was different from f16, as the most surprising thing here
• DN: We’re happy to resolve to clarify (though they are behaviorally the same) that f16 behaves the same as f32.