From: david.brown@hesbynett.no   
      
   On 30/11/2025 18:55, bart wrote:   
   > On 30/11/2025 17:17, Janis Papanagnou wrote:   
   >> On 2025-11-30 13:51:22, bart wrote:   
      
      
      
   >   
   > I've said many times that it's a poorly designed feature.   
      
   You have said continuously that you think everything about C, along with   
   everything you believe to be related to C (however tenuous the   
   connection may be in reality) is poorly designed.  It seems that   
   absolutely everything that you did not design personally, is poorly   
   designed in your eyes.  I'm not even sure you think your own languages   
   are well designed, given the number of times you've found new features   
   or limitations that you didn't know they had.   
      
   Perhaps you just have a different scale of what is "poor design" and   
   "good design".  Or maybe you don't understand that things don't have to   
   be perfect to be good enough in practice.  You certainly don't seem to   
   understand that when there is more than one person involved - and for C,   
   there are millions involved - compromises are inevitable, and elegance   
   of design must bow to compatibility requirements.   
      
   > Read the   
   > thread, as I'm not going to repeat things.   
   >   
      
   Is that a promise?   
      
      
      
   >   
   >>> Yet over the past decades nobody has been screaming because they   
   >>> couldn't have a 31-bit or 65-bit numeric type. But now suddenly   
   >>> EVERYONE wants to be able to do that, and on huge numbers!   
      
   For the most part, programmers use the tools they have, and switch to   
   more suitable tools as they become available.  Programmers that are not   
   toddlers are usually aware that screaming about things does not help.   
      
   A relatively small proportion of those who work with C have any   
   influence over features.  Many /could/ have influence if they choose to   
   - anyone can take part in standards discussions, make new proposals, get   
   involved in compiler development, and so on.  Most just get on with   
   their tasks of programming in the languages others have created and   
   implemented.   
      
   When a new feature is added to the language, it is natural to consider   
   it and discuss what uses people could have for it.  That's what we have   
   been trying to do here.  For most programmers, the reasons behind the   
   feature are only of minor interest - _BitInt exists in the latest C   
   standard, and is to some extent supported in existing compilers.  The   
   question for C users is not whether it should have been different - it's   
   too late for that (anyone could have followed and got involved in the   
   standards discussions earlier).  And pretty much every C user is aware   
   that they are each one voice in million - features are based on   
   compromises that work for many people, not what happens to be perfect   
   for their particular needs.  No, the question for C users is whether it   
   is a feature that will be useful for them in their own programming,   
   using the feature as it is defined in the standards.  Can we use it to   
   make code more efficient, more elegant, safer, or less effort?   
      
   The answer, it seems, is that many people do think they can use _BitInt   
   to make their code better in some way.  It doesn't matter if one person   
   thinks _BitInt(128) will be useful, while another thinks _BitInt(12) is   
   something they'd use.  It doesn't matter if they will use them for FPGA   
   programming, small-systems embedded programming, cryptography, neater   
   bitfield structs, or whatever.  And most importantly, it does not matter   
   in the slightest if someone does /not/ want to use a particular size of   
   _BitInt.   
      
   I don't think there is much that could be done with _BitInt's that could   
   not be done before in C.  People could use clang's extension (_ExtInt, I   
   think it was called).  They can use struct bitfields, or different sizes   
   of standard integer types, or arrays of uintNN_t types.  They could make   
   manual maskings, macros, functions, C++ classes (for those that want to   
   branch out from C) or other methods to get the effect of any _BitInt   
   uses.  But _BitInt's can be used to make some code better - clearer,   
   more efficient, simpler, etc.   
      
   Contrary to your beliefs, I haven't seen anyone clamouring for huge   
   _BitInts, especially not of "odd" sizes.  It's just that no one has been   
   advocating for some specific arbitrary limit on sizes or on how "odd"   
   the size can be.  Putting in such limits in the standard would be silly,   
   since there is no limit value that would make sense.  It is far better   
   to leave implementations to pick a limit according to what is practical   
   for them.   
      
   (I am not entirely sure, but I think it is standards-conforming for an   
   implementation to haev BITINT_MAXWIDTH set to 64 and support all   
   _BitInts up size 64, and then also support _BitInts of multiples of 64   
   thereafter.  Use of _BitInt greater than BITINT_MAXWIDTH is UB in the   
   standard - so an implementation can choose to give that a defined   
   behaviour for specific sizes.)   
      
      
   >>   
   >> You are again talking nonsense and exposing your non-sincere moves   
   >> to stupidly exaggerate ("screaming") and unreasonable generalize   
   >> ("EVERYONE"). - Yet, you prove again that you are not willing to   
   >> be a serious discussion partner.   
   >   
   > Yet what I said is pretty much true. Nobody care about BitInt until they   
   > became aware of, and now it's must-have.   
   >   
     Of course people cared about _BitInt before it existed - otherwise no   
   one would have implemented its prototype in clang, or written the   
   proposals for standardising it, and then putting it into the standards,   
   and then implementing it in compilers.   
      
   And I don't see anyone calling it a "must-have".  But it is hardly   
   surprising that the people involved in a discussion thread entitled   
   "_BitInt(N)" with the question "Is anyone using or planning to use this   
   new C23 feature?" are people that are interested in using it!   
      
   In this thread, there are people who are interested in using the   
   feature.  There are people who are just interested in C in general, and   
   want to understand it even if they probably won't use it themselves.   
   Perhaps there are some people who have chimed in to say they are not   
   interested in it at all - I haven't noticed any, but it's a big thread   
   and I might have missed some posts.  That too would be a reasonable and   
   valid opinion to express.   
      
   And then there is one person who just wants to moan and whine about   
   everything in C, and invents problems, misrepresents people's opinions   
   and posts, and exaggerates to an absurd extent in order to "justify" his   
   over-inflated ego and self-image of being the sole source of "good   
   language and tool design".   
      
   I am struggling to understand your motivations, and to give you the   
   benefit of the doubt - to put your posts down to ignorance or   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)