I see the utility of feature macros for library implementers, especially
for supporting old compilers. I hear the argument that they allow faster
use of new and experimental features, but I don't think that argument
has been sufficiently well articulated and weighed against the damage
done to the majority uses of the language and the evolution of the
language and its tools infrastructure.

I fear the utility of feature macros to define dialects: "if (feature I
don't like) static_assert(false, "don't use this; it's bad for you)."
Fortunately this is (for me) mainly hypothetical, but over the years I
have had *many* hopeful questions along the lines of "is there a
standard way of disabling X?". I strongly prefer to leave such potential
major damage for local gain to non-standard hacks.

Worse: the more macros, the harder it is to develop new tools for C++.
Marcos is a major reason C++ is tool poor compared to more modern
alternatives.

Worse still: Over the last few weeks, I have been traveling, talking
with *many* senior developers from a variety of major C++ users. They
are excited about the promise of modules. In particular, many see it as
an opportunity to finally cleaning up their code to get it more hygienic
by getting rid of most macros, undisciplined aliases, and forward
declarations. Adding macros to the standard could reduce the internal
representation(s) of modules to token soup, and give us "modules" that
do not offer real modularity.

In haste: I am still traveling. I recommend treading very carefully
here. I am not a fan of macros, not even feature macros.

On 10/21/2017 9:03 AM, Herb Sutter wrote:
>>> Furthermore, since we usually are in the business of standardizing
>>> things that users otherwise have to write many times themselves: Has
>>> SG10 considered actively defining a <std-forward-compat> header
>>> library that does the above for all the things it can, the idea being
>>> that users who have to target multiple implementations at various
>>> stages of conformance can include <std-forward-compat> after all their
>>> standard library's own headers and write their code more closely
>>> against the actual latest IS's std:: library,
>>> without having to reinvent the above by hand (incompatibly on
>>> different systems), as a transition tool to help encourage people to
>>> adopt the latest standard?
>> That's a very interesting idea, but might it make more sense for it to be
> done
>> by LWG, as opposed to SG10?
> Whoever owns the feature tests should own how to use and adopt them so I
> would think the <std-forward-compat> header would fall under that. After
> all, it should be kept in sync with the feature tests.
>
> So initially to get the ball rolling, since we have a set of tests already
> that are maintained by SG10, wouldn't it be expected that the initial header
> to be created by SG10 too -- again, just to get the ball rolling?
>
> Going forward, if we standardize feature tests, then we will presumably
> expect each proposal author to suggest a feature test (where appropriate)
> and a <std-forward-compat> mechanism (if appropriate).
>
> Is that reasonable?
>
>
> _______________________________________________
> Features mailing list
> Features_at_[hidden]
> http://www.open-std.org/mailman/listinfo/features