From: bc@freeuk.com   
      
   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.)   
      
   >   
   > (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.   
      
   You forgot about the type-punning part, which I guess needs yet another   
   inlined function,   
      
   >> Rather more fiddly and error prone, and it needs an auxiliary   
   >> statement that makes it awkward to embed into an expression. (I also   
   >> had to think twice about that format code.)   
   >>   
   >> BTW here is how my C transpiler translated it, so it /can/ be done   
   >> without explicit temporaries:   
   >>   
   >>      mminc$m_print_u64(msysc$m_getdotslice((i64)msysc$m_tp_r64toi64((x   
   >> + y)),(i64)52,(i64)62),NULL);   
   >>   
   >   
   > Avoiding explicit temporaries is not a goal to aspire to - unless you   
   > are trying to squeeze performance from a poorly optimising compiler.   
      
   The memory temp involved a declaration which needs to exist outside of   
   the expression in standard C. While type-punning in C either means   
   writing to a union, or using & and applying a cast.   
      
   (My type-punning works on rvalues and will work on values in registers.)   
      
   > No, what was shown was how _BitInt(12) could let people write clearer C   
   > code than C without _BitInt.  There was no comparison to other languages   
   > or other features.   
      
   But when it came my example, it could trivially be done with inline   
   functions, just like this could.   
      
      
      
   >>   
   >>>> But as a systems language, it is much more enticing than C.   
   >>>   
   >>> And that is presumably why it is so much more popular than C.   
   >>   
   >> If it was generally available then I think quite a few would prefer it.   
   >   
   > Sure.  Keep telling yourself that.   
      
   Well, it would be a minority. Grown-up languages with decent syntax   
   exist such as Ada and Fortran; those are not that popular. People prefer   
   brace-based languages such as C, Java, Go, Zig, Rust.   
      
   Anything without braces isn't taken as seriously, eg. scripting languages.   
      
   >   
   >> As it is I enjoy the benefits myself.   
   >>   
   >   
   > That I /do/ believe - and I genuinely think it is great that you enjoy it.   
   >   
      
   I've had several opportunities to retire my language and switch to C.   
   Each time, I rejected that and chose to perservere with mine, despite   
   the extra problems of working with a language used by only one person on   
   the planet.   
      
   Then, because I genuinely considered it better, and now because I enjoy   
   working at it and with it. Using C feels like driving a model T.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)