Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
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: <v2l828$18v7f$1@dont-email.me> <20240523171911.00002f5a@yahoo.com> <v2o7re$1tlge$1@dont-email.me> <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=
Bytes: 2448

Michael S <already5chosen@yahoo.com> 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.