From: janis_papanagnou+ng@hotmail.com   
      
   On 27.10.2025 18:44, bart wrote:   
   > On 27/10/2025 16:35, David Brown wrote:   
   >> On 27/10/2025 12:22, bart wrote:   
   >   
   >   
   > /My syntax/ (as in my proposal) is bizarre,   
      
   What was your proposal? - Anyway, it shouldn't be "bizarre"; it's   
   under your design-control!   
      
   > but actual C type syntax isn't?!   
      
   There were reasons for that choice. And the authors have explained   
   them. - This doesn't make their choice any better, though, IMO.   
      
   >   
   > The latter is possibly the worst-designed feature of any programming   
   > language ever, certainly of any mainstream language. This is the syntax   
   > for a pointer to an unbounded array of function pointers that return a   
   > pointer to int:   
   >   
   >     int *(*(*)[])()   
   >   
   > This, is not bizarre?!   
      
   You need to know the concept behind it. IOW, learn the language and   
   you will get used to it. (As with other features or "monstrosities".)   
      
   > Even somebody reading has to figure out which *   
   > corresponds to which 'pointer to', and where the name might go if using   
   > it to declare a variable.   
   >   
   > In the LTR syntax I suggested, it would be:   
   >   
   >    ref[]ref func()ref int   
   >   
   > The variable name goes on the right. For declaring three such variables,   
   > it would be:   
   >   
   >    ref[]ref func()ref int a, b, c   
   >   
   > Meanwhile, in C as it is, it would need to be something like this:   
   >   
   >     int *(*(*a)[])(), *(*(*b)[])(), *(*(*c)[])()   
   >   
   > Or you have to use a workaround and create a named alias for the type   
   > (what would you call it?):   
   >   
   >     typedef int *(*(*T)[])();   
   >   
   >     T a, b, c;   
   >   
   > It's a fucking joke.   
      
   Actually, this is a way to (somewhat) control the declaration "mess"   
   so that it doesn't propagate into the rest of the source code and   
   muddy each occurrence. It's also a good design principle (also when   
   programming in other language) to use names for [complex] types.   
      
   I take that option 'typedef' as a sensible solution of this specific   
   problem with C's underlying declaration decisions.   
      
   > And yes, I needed to use a tool to get that first   
   > 'int *(*(*)[])()', otherwise I can spend forever in a trial and error   
   > process of figuring where all those brackets and asterisks go.   
   >   
   > THIS IS WHY such tools are necessary, because the language syntax as it   
   > is is not fit for purpose.   
      
   I never used 'cdecl' (as far as I recall). (I recall I was thinking   
   sometimes that such a tool could be useful.) Myself it was sufficient   
   to use a 'typedef' for complex cases. Constructing such expressions   
   is often easier than reading them.   
      
   > [...]   
   >   
   >> Yes, my ideal would be different from the output of cdecl.  No, the   
   >> author is not doing something "wrong".  I live in a world where   
   >> programming languages are used by more than one person, and those   
   >> people can have different opinions.   
   >   
   > Find me one person who doesn't think that syntax like  int *(*(*)[])()   
   > is a complete joke.   
      
   Maybe the authors (and all the enthusiastic adherents) of "C"?   
      
   Janis   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)