Narrowly to this specific concern:

> > How can a feature macro be used to disable a feature???
>
> Simple. As I said above:
>
> static_assert(false, "don't use this; it's bad for you");
>
> Place this in a header and require it for corporate use and you are done.

I would be scared of that too, but I have not been able to construct a specific example. How does that work?

There are two kinds of feature tests: library, and language.

As a library example, adapting the one from earlier in this thread:

 #ifdef __cpp_lib_byte
   static_assert(false, "don't use this; it's bad for you");
 #endif

So here is the antipattern -- but it does not disable using the feature, or discourage using the feature. It just breaks the build with no way to actually satisfy the assertion by "not using" the feature, except to not use the updated stdlib at all... and no reasonable shop would block adoption of an entire updated standard library (usually provided by the compiler vendor as part of an upgrade). I can't imagine any stdlib implementation would provide a way to deliberately turn off new standard library features piecemeal (e.g., "/Dstdlib_disable_std_byte").

As an example of a language feature, let's say someone hates fold-expressions and writes:

 #ifdef __cpp_fold_expressions
   static_assert(false, "don't use this; it's bad for you");
 #endif

If the compiler supports the feature, the static_assert fires --- but it does not disable using the feature, or discourage using the feature, because it is not actionable unless the compiler also provides a "/disable-foldexpressions" flag... which I highly doubt any vendor would provide. I know of only a couple of features that compilers regularly have switches to disable -- exceptions and RTTI -- which are historical and not covered by feature tests. I can't imagine any compiler would provide a way to deliberately turn off new standard language features piecemeal.

So: AFAICS feature tests cannot be used to disable a feature disliked by a coding shop, unless the stdlib or the compiler also specifically provide a way to turn off just that specific feature, which currently they do not.

Serious question: Would your concern be satisfied if supporting feature test macros also had a negative requirement that a conforming implementation "must not" provide a way of specifically turning off any feature (or group of features) testable by a feature test macro?


> I hope I'm not giving you new bad ideas. As I said, the equivalent has been
> frequently suggested to me over the years.

But I think this is not the same as what you said had been suggested, which was a standard way to disable a feature. I don't think this can be used that way...?


> I don't think there are good reasons except compatibility and the
> management of language evolution. In principle, we can do without
> #define . My long-term aim is to eliminate #define. By long-term, I do
> not mean next year or C++20. To be responsible stewards of C++'s
> evolution, we must think in decades, and try not to make problems worse
> by short-term fixes.

Agreed. Probably the biggest counterargument, as Ville notes in his paper, is that any solution that requires a new language feature does not solve compatibility with older compilers, whereas macros are (for better or usually worse) understood by all existing compilers.

Herb