[stoeckley]

Same. I've written probably more C++ than any other language, and I have a lot of respect for the language overall, but I recently had to use only C for something, and I found it rather refreshing. My use case didn't hit a lot of the pain points of C, but it did feel refreshing as there are fewer ways of doing things, fewer options, compared to C++, and my code ended up feeling more straightforward and readable as a result.

[pjmlp]

C23 says hello.

C is becoming into everything C++ has, minus OOP and the additional type safety.

[jstimpfle]

Examples? Because the list of accepted proposals seems conservative. https://en.wikipedia.org/wiki/C2x https://thephd.dev/c23-is-coming-here-is-what-is-on-the-menu

[pjmlp]

You have to look forward to what in the plate post C23 like lambdas, improved constexpr, more _Generic support, and so forth.

https://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_lo...

[jstimpfle]

Lambdas and some other complicated looking extensions have been on the plate for quite some time, and it seems like none of them made it into C23. Lambdas in particular have been promoted for the most part by a single person AFAICT. "C is becoming into everything C++ has" is a drastic misrepresentation.

[throwaway17_17]

I think I take the middle position between you and GP, C is slowly working it’s way towards unnecessary complexity. Most of the ‘X language is a C replacement’ posts and threads here on HN seem to disregard C’s development (particularly from 2017 onward) through committee standards releases. Everyone keeps arguing about Rust, Zig, Odin, etc and claiming one or the other is clearly more C like and the others are too complicated/expansive/growth-prone. But no one ever stops and claims that the simple C in there heads is not C in 2022, but C in 1990.

C is not yet at the point where added features, idioms, or concepts have totally removed the ability to return to or regularly restrict yourself to some ‘simple’ subset of the language. However, the push to add more and more to the standard does not inspire hope that this situation will remain.

So while I don’t think it’s there yet, it certainly looks like complexity via continual expansion is the path forward. I may not like it, but it does seem to be a reasonable supposition by GP.

[jstimpfle]

I agree, there is some proposals in there that I doubt they fit well with the culture. However what has actually been accepted that makes you think C in the heads is not C in 2022? In my head, the biggest practical change from 1990 C is declare-anywhere (including declare-in-for-loop) which in my estimation has afforded a lot of added ergonomics at practically zero semantic cost. The next most relevant one is standardization of memory models, which is a good one AFAICT (but I used it only a little, so far). One unfortunate addition from 1999, VLAs, has even been demoted in the following revision.

In 2022 I can jump into basically any C codebase and be immediately productive. Which can't be said of some other languages.

[pjmlp]

I did not assert that C23 was it, rather that is how it looks like going forward.

What did not land in C23, will land in C26, C29, ....

[hgs3]

It is conservative, except for nullptr which duplicates NULL. This violates C's own charter of "provide only one way to do an operation."

[ohgodplsno]

Because NULL is dogshit. It's a #define 0. That's not one way to do an operation, that's one way to do an operation, horribly badly. That int on your stack ? Sure it can equal NULL. Hope that wasn't the result of (2 - 2).

[hgs3]

In C the NULL macro can be defined as either (void*)0 or 0. It's only mandated as 0 in C++.

The nullptr concept was introduced into C to fix a type ambiguity when NULL is used with generic selection or varargs functions. The ambiguity could have been solved by mandating that NULL be defined as (void*)0. My issue with nullptr is its an overkill solution that unnecessarily duplicates the concept of NULL in the language.

[jstimpfle]

I agree, it should have been (void*)0. I doubt that nullptr_t will see much use (as much as _Generic is a fringe addition), but we'll find out.

[loup-vaillant]

Well, since 0 is guaranteed to compare equal to the null pointer, my current code compare my pointers to it directly:

  if (ptr != 0) { foo(*ptr); }

The type mismatch is ugly, but that saves me an include (this particular code minimises its dependencies to maximise portability).