Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.lang.c    |    Meh, in C you gotta define EVERYTHING    |    243,242 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 241,484 of 243,242    |
|    bart to David Brown    |
|    Re: New and improved version of cdecl    |
|    26 Oct 25 15:12:42    |
      From: bc@freeuk.com              On 25/10/2025 16:18, David Brown wrote:       > On 25/10/2025 14:51, bart wrote:       >       >> This is another matter. The CDECL docs talk about C and C++ type       >> declarations being 'gibberish'.       >>       >> What do you feel about that, and the *need* for such a substantial       >> tool to help understand or write such declarations?       >>       >> I would rather have put some effort into fixing the syntax so that       >> such tools are not necessary!              > And I'd love to hear your plan for "fixing" the syntax of C - noting       > that changing the syntax of C means getting the C standards committee to       > accept your suggestions, getting at least all major C compilers to       > support them, and getting the millions of C programmers to use them.              I have posted such proposals in the past (probably before 2010).              I can't remember the exact details, but I think it is possible to       superimpose LTR type syntax on top of the existing language.              It's clear however that nobody would be interested in actually doing       that. I might have done it as a proof of concept, but with little       appetite (it only fixes a fraction of what I'd like to change).              If creating such a proposal today, I think it would require two new       keywords, for example:               ref replaces '*' for pointer modifiers        func marks functions otherwise there is too much ambiguity and        confusion              The above two could be type-spec starter symbols. In addition, a '['       could also start a type-spec (we don't want a third 'array' keyword).              So, in the new scheme, either of these symbols can start a new typespec:               ref        [              A type starting with T (built-in or user-defined type) is a regular       type-spec.              'func', is normally used inside the the type for function pointer: 'ref       func'. At the start, I suppose it could be used to declare regular       non-pointer functions.              Examples:               ref int p, q, r; // int *p, *q, *r;        [N]int a, b, c; // int a[N], b[N], c[N];        ref []int p; // int (*p)[]; I think        [N]ref int q; // int *q[N];        ref func(int, int)float F // float (*F)(int,int);        ref ref[M][N]double x // pointer to pointer to array ...              If you wanted to make it CDECL-clear, then make these tweaks:              - use 'pointer to' as an alias to 'ref'              - Require 'array' before [ in my examples              - Require 'returning' after ')'              (In this scheme, parentheses only occur around parameter lists.)              Old and new can be mixed, but they need to be distinct sequences:               ref func(int*, ref int)float F               int* G(ref func()void);              So, anywhere where a type could start in the current syntax, that can be       old or new.              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca