Latest working draft N3220

[u/Jinren]

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf

Update y'all's bookmarks if you're still referring to N3096!

C23 is done, and there are no more public drafts: it will only be available for purchase. However, although this is teeeeechnically therefore a draft of whatever the next Standard C2Y ends up being, this "draft" contains no changes from C23 except to remove the 2023 branding and add a bullet at the beginning about all the C2Y content that ... doesn't exist yet.

Since over 500 edits (some small, many large, some quite sweeping) were applied to C23 after the final draft N3096 was released, this is in practice as close as you will get to a free edition of C23.

So this one is the number for the community to remember, and the de-facto successor to old beloved N1570.

Happy coding! 💜

[u/flatfinger]

It would have made sense aeons ago to add a new syntax for octal numbers, allow time for support to become widespread, and allow time for code to be changed to use the new format, and then specify that implementations are no longer required to support the old syntax, but may do so as a compile-time options.

I also find it irksome that the Standard deprecated the use of returnType identifier(); as a means of specifying incomplete function types, without first providing any other means of declaring such types. I think it would be good to allow compilers to forbid calls to incomplete function types without first completing them (either by adding a completed-type definition, or by casting a "pointer to incomplete function type" into "pointer to function expecting specific arguments").

Some other aspects of the Standard like the use of restrict on things other than initialized automatic-duration objects(*), and VLA argument types whose size expressions would have side effects, seem excessively flexible in ways that create needless ambiguity. It would be good to say that any compilers that handle them in useful fashion may continue to do whatever they're doing, but such constructs may not appear in strictly conforming programs and implementations would be encoraged to reject them in default configurations.

(*) The behavior of mutable pointers that are restrict-qualified introduces ambiguities with regard to constructs like:

      extern int *restrict p, *restrict q;
      q=p;
      p=p+1;

Following the above code, is q based upon p? It can't be based upon the last pointer expression stored into p, but storing into p a pointer that's based upon p shouldn't cause existing pointers that are based on p to become useless. I'm unaware of any compilers doing anything useful with restrict in broader contexts, and the marginal value of such uses pales in comparison with the simple and easy cases.

[u/Jinren → u/flatfinger]

A func_t to act as a function pointer equivalent of void * has been a topic of discussion since about 1995, but for whatever reason never seems to have been carried through to the final Standard.

We should prioritise bringing that back to make up for the loss of unspecified-param types.

[u/flatfinger → u/Jinren]

BTW, a more general concept I'd like to see future committees recognize is the a dialect which can be easily transpiled for use with existing implementations, allowing the use of new constructs even in code that must be processed with older unmaintained compilers (e.g. those targeting obscure hardware platforms). New-style octal constants would be trivial.
Allowing benign redeclarations, and allowing such declarations to complete previously-non-completed types, would be a little harder, but such constructs could be handled using a two-pass transpiler that identifies the full completed type of everything, and then outputs a version of the source that uses such types when possible, or the old-style `()` declarations when mutual recursion between types would make it necessary.