Path: csiph.com!news.swapon.de!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: C23 thoughts and opinions - why so conservative? Date: Thu, 23 May 2024 18:35:58 -0700 Organization: A noiseless patient Spider Lines: 39 Message-ID: <86ikz4htz5.fsf@linuxsc.com> References: <20240523171911.00002f5a@yahoo.com> <20240524003424.0000590a@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Fri, 24 May 2024 03:36:00 +0200 (CEST) Injection-Info: dont-email.me; posting-host="4e2ccf3374e48a9f13e87ba250cb95a8"; logging-data="2244816"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18CpNDuJkG+8HaQU47ENq6ycOlbZl3LPa0=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:bim1u6E/rlTKoKsfVFLBMn+bokg= sha1:XCB8K/wc0FdA/iIKIYa+VnFp4ZE= Xref: csiph.com comp.lang.c:384952 Michael S writes: [what new language features would you like?] > Ability to break from nested loops. Ability to"continue" outer > loops would be nice too, but less important. [...] > > 1. global objects, declared in header files and included > several times. Where defined? [...] I wnat it to "just work" > everywhere. [...] Both of these features seem like frills. Neither one is either necessary or common; they would make the language bigger but especially any better. Adding them would be the proverbial tail wagging the dog. > 2. Reversing defaults for visibility of objects and functions > at file scope. > Something like: > #pragma export_by_default(off). Not sure taking a half-and-half approach on this is a good idea, but if so I think it's better to have the choice be a per-TU compilation option rather than a #pragma. > When this pragma is in effect, we need a way to make objects and > functions globally visible. I think that it's done best with new > storage class. Just use extern. No new storage class needed. > With regard to constexpr, mentioned above by James Kuyper, my > feeling about it is that it belongs to metaprogramming so I > would not consider it a real storage class. Having 'constexpr' be classified as a storage class illustrates how poorly thought out it is.