> Over the last few months I implemented 'compile feature' support
> in the
> CMake buildsystem tool.
>
> This is somewhat related to the work of SG10, in that the macros
> recommended here can be used by this CMake functionality in the
> future.
> These use cases may not be obvious, so I thought I'd list them
> here for
> information and feedback and relate some of the experience.

This is very interesting; thanks for sharing it.

> It appears that if following SD6, code such as
>
> static_assert(__has_include(${header_name}), "header not found")
>
> is not allowed, right?

Right. SD-6 recommends only that __has_include be usable in
preprocessor-if.

> The names of some features known to CMake are not the same as
> those used
> by Clang/SD6. For example:
>
> 1) I don't know what the 'nsdmi' part of __cpp_aggregate_nsdmi
> means, so
> I named that feature 'cxx_aggregate_default_initializers' as it is
> for
> mortal consumption.

"NSDMI" stands for "non-static data member initializer" -- which is an
accurate and adequately-qualified term, but pretty unwieldy.

> 2) cxx_init_captures seemed too generically named, so I added a
> 'lambda'
> to the name: cxx_lambda_init_captures.

Lambdas are the only things that do capturing, at least today. Yes, SG10's
choice will look unfortunate if we ever invent something else that also
captures.

> Consider recommending definition of the __cpp_lib macros in a
> single
> file instead of in multiple files.

Well, I am very, very far from a C++ library implementer, so everything I
say about this should be taken with a kilo of salt.

But I certainly imagined that, when an implementer implemented some small
library feature, he might want to modify only the single file containing the
code that actually needs to be modified to provide the feature, and that he
might add the macro definition to the same file at the same time.

Of course it's possible to imagine some purpose for which that's not the
best way to make the change, but I'd rather it be possible to do the
implementation of simple things simply.

> There are problems with bugs in implementations which I don't
> think I
> have a good solution for.

There's clearly no good solution to bugs, from the perspective of the
specification. (No, wait: "An implementation shall not have bugs." That was
easy. :-)

Clark