Re: C23 thoughts and opinions - why so conservative?

On Thu, 23 May 2024 22:10:22 +0200
David Brown <david.brown@hesbynett.no> wrote:

On 23/05/2024 16:19, Michael S wrote:

On Wed, 22 May 2024 18:55:36 +0200
David Brown <david.brown@hesbynett.no> wrote:
 

In an attempt to bring some topicality to the group, has anyone
started using, or considering, C23 ?  There's quite a lot of change
in it, especially compared to the minor changes in C17.
 

 
Why C Standard Committee, while being recently quite liberal in
field of introducing new keywords (too liberal for my liking, many
new things do not really deserve keywords not prefixed by __) is so
conservative in introduction of program control constructs? I don't
remember any new program control introduced under Committee regime.
And I want at least one.
 

 
What program control construct would you like?
 

Ability to break from nested loops. Ability to"continue" outer loops
would be nice too, but less important.
I am not sure what syntax I want for this feature, never considered
myself a competent language designer.

 

 
Another area that was mostly unchanged since 1st edition of K&R is
storage classes. Even such obvious thing as removal of 'auto' class
took too long. If I am not mistaken, totally obsolete 'register'
class is still allowed. 

 
"register" is still in C23.  (Some compilers pay attention to it.
gcc with optimisation disabled puts local variables on the stack,
except for those marked "register" that get put in registers.)  It
got dropped from C++ when "auto" was re-purposed in C++11, but with
the keyword "register" kept for future use.  I would not have
objected to the same thing happening in C23.
 

And I don't remember any additions. 

 
_Thread_local was added in C11, with the alias thread_local in C23.
 

_Thread_local is a special-purpose thing, probably not applicable at
all for programming of small embedded systems, which nowadays is the
only type of programming in C that I do for money rather than as hobby.
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.

What would you like to see here?
 

Instead of solutions, let's talk about problems that I want to solve:

1. global objects, declared in header files and included several times.
Where defined?
For some linkers, mostly unixy linkers, in case of none-initialized
objects (implicitly initialized to zero) it somehow works.
For linkers used on embedded systems it requires additional effort.
I think, for initialized globals it takes additional effort even with
unixy linkers.
I wnat it to "just work" everywhere. I think that the best way to get
it without breaking existing semantics is a new storage class.

2. Reversing defaults for visibility of objects and functions at file
scope.
Something like:
#pragma export_by_default(off).
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.

Personally I can think about at least two useful backward-compatible
additions in that area.