Nullptr, constexpr, embedd, safer enums, type inference approved for C23 | Hacker News Reader

Nullptr, constexpr, embedd, safer enums, type inference approved for C23

twitter.com

36 pointspjmlp9 comments

Where can I read more about what these changes mean?

If we assume that nullptr and auto mean the same as in C++ then what problem does nullptr fix in C? In C++ i can understand the need to use nullptr to distinguish between overloaded functions. Is the only use of nullptr in C to know what the type of an auto variable will be (which would be funny because if you care about what type it is you wouldn't use auto) or why would you need it?

Basically it fixes not having to use C++ for accessing such features.

Not something I agree with, but so it is with some circles where C is the only true path.

Lambdas were also part of the initial proposals, but it seems they were dropped.

You can read more about it about the original proposals at WG14.

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

Presumably an available nullptr typed literal will allow linters and other static analysis tools to be more aggressive?

> If we assume that nullptr and auto mean the same as in C++ then what problem does nullptr fix in C?

For starters, it fixes the same problems it fixed on C++. I'm talking about stuff like automatic type conversion to ints and consequently being forced to babysit when your compiler called foo(int) instead of food(bar *) just because you passed NULL.

Also, keep in mind that these features are low-hanging fruits to any compiler writer, especially those who already maintain compilers that support C and C++. Thus the argument you should be making is not "why should C have these features" but "why should C be deprived from these features".

As addendum to that, in C++ there was a period before nullptr came to be, that best practice for null pointers was to use 0 directly instead of NULL exactly because of that.

https://stackoverflow.com/questions/54098794/is-null-guarant...

> when your compiler called foo(int) instead of food(bar *) just because you passed NULL

That's what I meant that we don't have to worry about in C since you can't even have two different functions with the same name (assuming you meant foo instead of food).

> Thus the argument you should be making is not "why should C have these features" but "why should C be deprived from these features".

That's not an argument; that's a question. I wanted to know whether there was any reason to start using nullptr, like if there is a risk of making a bug if I use NULL. I did later find a page about nullptr in C [1] that talks about some risks of using NULL with varargs.

[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3039.htm

> That's what I meant that we don't have to worry about in C since you can't even have two different functions with the same name

But you can have a macro foo which expands to a generic selection: <https://docs.microsoft.com/en-us/cpp/c-language/generic-sele...>

The committee should have standardized on defining NULL as (void*)0 which would have allowed _Generic to catch NULL with a void* type. This seems better than adding a whole new nullptr concept just for this one off "problem".

Great idea ! Now, try to convince the 30 implementers that did the wrong choice and will tell you they'll never change it because of backwards compatibility.

Reply on news.ycombinator.com