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.