From: david.brown@hesbynett.no   
      
   On 26/11/2025 23:19, bart wrote:   
   > On 26/11/2025 20:43, David Brown wrote:   
   >> On 26/11/2025 19:42, bart wrote:   
   >>> On 26/11/2025 16:37, David Brown wrote:   
   >>>> On 26/11/2025 16:44, bart wrote:   
   >>>   
   >>>> The "other people" I referred to are the folks behind the C   
   >>>> language, not me.   
   >>>   
   >>> OK. The people who chose to make 'break' do two jobs, unfortunately   
   >>> in parts of the language that can overlap in use; those people! (I   
   >>> guess you mean the more recent lot.)   
   >>>   
   >>>>> In C, the solution for my example might look like this:   
   >>>>>   
   >>>>>      double temp = x+y;   
   >>>>>      printf("%llu", ((*(uint64_t*)&temp)>>52) & 2047);   
   >>>>>   
   >>>>   
   >>>> No, that's not how a C solution would work.  People who know C would   
   >>>> know that.  As a challenge for you, see if you can spot your mistake.   
   >>>   
   >>> This was my point. (Although I can't see the problem, making it even   
   >>> more pertinent.)   
   >>>   
   >>   
   >> So you can claim to have a "better" solution than C, without knowing   
   >> how to write it correctly in C?   
   >   
   >>   
   >>>>   
   >>>> (And of course if anyone wanted to do this stuff in real code,   
   >>>> they'd wrap things in a static inline "bit_range_extract" function.)   
   >>>   
   >>> Also my point: everyone will invent their own incompatible solutions   
   >>> for this fundamental stuff.   
   >>   
   >> It is not remotely fundamental.  Extracting groups of bits from the   
   >> representation of a type, especially a floating point type, is a niche   
   >> operation.   
   >   
   > A bit like that BitInt(12) example then?   
      
   Yes, using BitInt(12) is quite niche.   
      
   But when the people behind _BitInt() started thinking about what sizes   
   people might want, it quickly became clear that it would be vastly more   
   effort to try to define which sizes were useful.  It was much simpler   
   and clearer just to support any size (up to an implementation-defined   
   limit).  Most particular sizes, other than 8, 16, 32, 64, and perhaps   
   128, are going to be niche.  But if one clear feature enables a large   
   number of niche uses, that's a good thing.   
      
   No one has suggested that _BitInt(12) is in any way a /necessary/   
   feature.  And I certainly don't think a stand-alone proposal to add   
   12-bit types to C would have been accepted.  But since it exists, it   
   will let me write slightly neater code in some cases - thus I will use   
   it when appropriate.   
      
   What I don't like about your bit extraction operations is that you have   
   an operator syntax for a fairly obscure and rarely used operation.  A   
   "bit_range_extract" standard library function would make more sense to   
   me, though I think shifting and masking works well enough for the few   
   situations where you need it.  A syntax that looks very much like array   
   access is not going to be helpful to people looking at the code - for   
   general-purpose languages, most programmers will never see or use bit   
   ranges.   
      
   >   
   > This is about a lower-level systems language working with primitive   
   > machine types, and having access to the underlying bits of those types.   
   >   
   > How much more fundamental can you get?   
      
   It is not fundamental for a low-level systems language.  And this is a C   
   group - C is a language covering general application programming as well   
   as systems programming.  I can agree that it can be a /useful/ operation   
   at times - useful enough to make it worth having a standard library   
   function (or macro - or, in your case, a keyword or built-in function).   
   But not "fundamental" or useful enough to make it operator based like that.   
      
   >   
   > C provides only basic bitwise operators, and you have to do some   
   > bit-fiddling, while trying to avoid UB, in order to extract or inject   
   > individual bits or bitfields.   
      
   You make it sound difficult.  It's not.   
      
   >   
   > I provide direct indexing ops to get or set any bit or bitfield, which   
   > is actually a great core feature to have, but for some reason you want   
   > to downplay it.   
   >   
   > You might just admit for once that it is quite neat.   
   >   
      
   I am sure it is very nice on the few occasions when it is useful.   
      
   >   
   >>   (It can be an important operation - such as for software floating   
   >> point routines.   
   >   
   > That particular task can be important for lots of reasons.   
   >   
   >>   But the people who write those are few, and they know what they are   
   >> doing.)   
   >   
   > And I don't? I used to write FP emulation routines...   
   >   
      
   The thing you always seem to forget, is that your languages are written   
   for /you/ - no one else.  It doesn't make a difference whether something   
   is added /to/ the language or written in code /for/ the language.  You   
   think other languages are missing critical features simply because there   
   is a thing that /you/ want to do that you added to your own language.   
   And you think other languages are overly complex or bloated because they   
   have features that you don't want to use.   
      
   That attitude is fine for your own personal specific language.  If   
   that's how you like to do things, that's fine.  But that's your own   
   little isolated world that does not compare to the wider world of other   
   people, other programmers, other languages, other tools.   
      
   Imagine asking the regulars in this group what features or changes they   
   would like C to have in order to make C "perfect" for their uses,   
   regardless of everyone else, all existing code, all existing tools.  We   
   could all fill pages with ideas.  And if those were all added to C, the   
   result would be a language that made C++ look as easy as Logo, while   
   being riddled with inconsistencies and contradictions.   
      
   >   
   >> "Type punning" refers to using a union to access or reinterpret the   
   >> underlying bit representation.  Using references and a cast to do so   
   >> is UB,   
   >   
   > In C maybe, using your favoured compilers.   
      
   In C, yes.  This is comp.lang.c.   
      
   > In my implementations of C,   
   > and in my languages, it is well defined, especially as it is   
   > type-punning a 64-bit quantity to another 64-bit quantity.   
   >   
      
   OK.  But not in C.   
      
   > (This is a great thing about creating your own implementations: you get   
   > to say what is UB, which will be for genuine, not artificial ones   
   > maintained so that C compilers can be one-up on each other.   
      
   Ah, so the many C compilers I have used over the decades were not   
   "genuine", and the many different processors I have used were all   
   "artificial".  Okay, that clears things up.   
      
   >   
   > As it is, somebody using C as an intermediate language can have a   
   > situation where something is well-defined in their source language,   
   > known to be well-defined on their platforms of interest, but inbetween,   
   > C says otherwise.)   
      
   You've never really understood how languages are defined, have you?   
   With your own languages and tools, you don't have to - there is no need   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)