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
_______________________________________________
Features mailing list
[email protected]
http://www.open-std.org/mailman/listinfo/features
