From: Keith.S.Thompson+u@gmail.com   
      
   bart  writes:   
   > On 24/11/2025 20:26, David Brown wrote:   
   [...]   
   >> And this huge leap also lets you have 128-bit, 256-bit, 512-bit,   
   >> etc.,   
   >   
   > And 821 bits. This is what I don't get. Why is THAT so important?   
   >   
   > Why couldn't 128/256/etc have been added first, and then those funny   
   > ones if the demand was still there?   
      
   Because a more general definition, allowing all widths up to some   
   maximum, is *simpler* than a definition with arbitrary restrictions.   
   And since it's already been implemented, what the heck are you   
   complaining about?   
      
   > If the proposal had instead been simply to extend the 'u8 u16 u32 u64'   
   > set of types by a few more entries on the right, say 'u128 u256 u512',   
   > would anyone have been clamouring for types like 'u1187'? I doubt it.   
      
   You do know that u8, u16, et al are not C types, right?  (Yes, I know   
   what you mean by those names.)   
      
   > For sub-64-bit types on conventional hardware, I simply can't see the   
   > point, not if they are rounded up anyway. Either have a full   
   > range-based types like Ada, or not at all.   
      
   Great, so don't use them.   
      
   If the ISO C committee withdrew the current official 2023 standard   
   document and replaced it with one that imposes restrictions on _BitInt   
   types, and gcc and clang withdrew their implementations, would that   
   satisfy you?   
      
   --   
   Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com   
   void Void(void) { Void(); } /* The recursive call of the void */   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)