• Daniel N (7/7) May 17 https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2763.pdf
• user1234 (6/22) May 18 There was a slightly related blog post posted on [YN yesterday].

Daniel N <no public.email> writes:

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2763.pdf

"There is one crucial exception to the C rules for integer 
promotion: _BitInt types are excepted from the integer 
promotions."

I find this really interesting, finally there's a way to opt-out 
from integer promotions in C. You could even create new aliases 
for 16- and 32-bit types that then avoids the legacy rules.

user1234 <user1234 12.de> writes:

On Sunday, 17 May 2026 at 14:52:06 UTC, Daniel N wrote:
 https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2763.pdf

 "There is one crucial exception to the C rules for integer 
 promotion: _BitInt types are excepted from the integer 
 promotions."

 I find this really interesting, finally there's a way to 
 opt-out from integer promotions in C. You could even create new 
 aliases for 16- and 32-bit types that then avoids the legacy 
 rules.

There was a slightly related blog post posted on [YN yesterday]. 
No promotion means better expressivity when it's about vector 
libraries, less casts...

 Integer promotion still breaks everything. int8_t + int8_t 
 produces int32_t in C++. This is one of the oldest pain points 
 for SIMD programmers working with image data, where 8-bit and 
 16-bit arithmetic dominates. std::simd inherits this problem 
 because it’s a library on top of the language, not a fix to the 
 language. Writing a pixel blending operation with 
 std::simd<uint8_t> means fighting integer promotion at every 
 step.

[YN yesterday]: 
https://lucisqr.substack.com/p/c26-shipped-a-simd-library-nobody