[SG10] Example for __cpp_lib_byte

Bjarne Stroustrup bjarne at stroustrup.com
Sun Oct 22 04:28:09 CEST 2017


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 isocpp.open-std.org
> http://www.open-std.org/mailman/listinfo/features



More information about the Features mailing list