To me, this indicates that there’s probably no middle ground that would allow as to be used for both numeric and bitwise casts in all cases, so two separate facilities are needed: one for numeric casts, and one for bitwise casts.
If we’re going to use the existing as for one and methods for the other, I think using it for numerical casts is the only consistent approach. All of the arguments that applied to arithmetic seem to apply equally to conversion.
It seems that the vast majority of cases want or can use strict behavior. Looking at your survey of rustc:
2 & 4: You say these want strict.
1: You say this wants width-oriented to catch dropped bits, but since both values are unsigned, strict works just as well.
3: Doesn’t matter
6: Assuming x is unsigned, (x >> 16 | 0xFF) as u8 would work just fine, even with strict, and makes the intent clearer, in my opinion.
Which leaves only 5 to use the bitwise methods, and explicitly saying “we’re dealing with this value as bits” in this instance does not seem undesirable.
In my own code, the vast majority of as usages want strict, and the rest are byte selection from unsigned values, where strict works just fine with a mask.
Perhaps we could also have some kind of conversion trait that also allowed as to be used on wrapping types with bitwise behavior.
