> The old code will have to include <stdnoreturn.h> if they used the "noreturn" compiler-specific keyword, while waiting for the glacial ISO WG progress.
Huh? stdnoreturn.h only makes sense with the new _Noreturn keyword. The old code can keep using __attribute__((noreturn)) or (if it was portable code) nothing at all, without including any headers.
> Crap like <stdnoreturn.h> is just pointless ornamentation, cluttering our source code.
I think C's "add seemingly randomly named include files to the top of your code to use different parts of the standard library" is pointless, and I'd like to see the whole standard library included by default (using some yet-to-be-invented more flexible PCH magic to ensure it doesn't slow down compilation). But in lieu of that, it's hardly a big jump from library to syntax - and if keeping backward compatibility isn't hard, why not do it?
I tend to agree with you about C include files, but observe that you can get more or less the same effect with a single "myproject.h" file included in your myproject-x source files.
> C's "add seemingly randomly named include files to the top of your code to use different parts of the standard library" is pointless
But doesn't most languages do this? Like java's imports (only a really small subset is included by default) or python. I would have thought that namespace separation is a good thing.
I don't use Java, but Python has a reasonably large set of builtins, and the base modules like os and sys provide a lot more - C would require a longer list of includes. Still, I would like to be able to write something like "mmap::mmap" and have Python automatically figure out what to import, keeping the namespace separation but eliminating the redundancy of explicit imports.
(maybe pick something other than double colons, heh.)
Huh? stdnoreturn.h only makes sense with the new _Noreturn keyword. The old code can keep using __attribute__((noreturn)) or (if it was portable code) nothing at all, without including any headers.
> Crap like <stdnoreturn.h> is just pointless ornamentation, cluttering our source code.
I think C's "add seemingly randomly named include files to the top of your code to use different parts of the standard library" is pointless, and I'd like to see the whole standard library included by default (using some yet-to-be-invented more flexible PCH magic to ensure it doesn't slow down compilation). But in lieu of that, it's hardly a big jump from library to syntax - and if keeping backward compatibility isn't hard, why not do it?