AaronBallman

I could imagine misguided readings of some coding standard advice that would lead to that interpretation, but it's still not an interpretation that makes sense to me.

Implementations define undefined behavior all the time and users rely on it. For instance, POSIX defines that you can convert an object pointer into a function pointer (for dlsym to work), or implementations often rely on offsets from a null pointer for their 'offsetof' macro implementation.

Ah! No, those just predate my joining the committee and haven't really come up since they were presented.

Basically, every paper that gets submitted by an author will get some amount of discussion time at the next available meeting as well as feedback from the committee on the proposal. I'm not certain what feedback these papers received (we could look through the meeting minutes for the meetings the papers were discussed at to find out, though).

I don't think it's a myth so much as a misunderstanding of terminology. If an implementation defines some undefined behavior from the standard, it stops being undefined behavior at that point (for that implementation) and is no longer something you need to avoid except for portability concerns.

You're exactly right that this is why there is a distinction between conforming and strictly conforming code.

I think this is correct, assuming that locale is supported by the implementation and wchar_t is wide enough, but I am by no means an expert on character encodings.

> 1. Will the Apple's Blocks extension, which allows creation of Closures and Lambda functions, be included in C2X?

We haven't seen a proposal to add them to C2x, yet. However, there has been some interest within the committee regarding the idea, so I think such a proposal could have some support.

> 2. Are there any plans to improve the _Generic interface (to make it easy to switch on multiple arguements, etc.)?

I haven't seen any such plans, but there is some awareness that _Generic can be hard to use, especially as you try to compose generic operations together.

I must be remembering incorrectly then, thank you!

If that macro is defined, then wchar_t is able to represent every character from the Unicode required character set with the same value as the short code for that character. Which version of Unicode is supported is determined by the date value the macro expands to.

Clang defines that macro for some targets (like the Cloud ABI target), but not others. I'm not certain why the macro is not defined for macOS though (it might be worth a bug report to LLVM, as this could be a simple oversight).

I don't think the book covers strict aliasing, at least not in detail.

Not off the top of my head, but as an example along similar lines, when talking about whether we could realistically specify twos complement integer representations for C2x, we had to determine whether this would require an implementation to emulate twos complement in order to continue to support C. Such emulation might have been too much of a burden for an implementation's users to bear for performance reasons and could have been a reason to not progress the proposal.

When the committee considers proposals, we do consider the implementation burden of the proposal as part of the feature. If parts of the proposal would be an undue burden for an implementation, the committee may request modifications to the proposal, or justification as to why the burden is necessary.