...

TL;DR we should switch to positive feature macros in Boost.Config, and delaying this switch just accumulates more unnecessary code in Boost.Config.

My opinion hasn't changed since the last discussion - if we move to positive macros then please convert all existing macros as well. I wouldn't want to remember which one is positive or negative.

+1 on that. I've been mostly silent on this because: * Other folks have expressed what I feel as well (but I'm notoriously slow to embrace change, so treat that with a pinch of salt). * The number of new macros has slowed very significantly in recent years. * The number of actively developed compilers is very much lower than in the past. * I see no great gain for *users* of the library. * We currently separate standardized features which are all BOOST_NO_* and vendor extensions which are all BOOST_HAS_*. For compilers that are effectively "dead", we could just add a catch all macro: #define BOOST_OBSOLETE_COMPILER year and then set all macros past "year" in suffix.hpp, so if we had #define BOOST_OBSOLETE_COMPILER 2011 Then set all BOOST_NO_CXX11_* macros and later in suffix.hpp and job done. John. --- This email has been checked for viruses by AVG. http://www.avg.com

On Jan 25, 2018, at 11:39 AM, Peter Dimov via Boost wrote:

Steven Watanabe wrote:

...

I'm opposed to this, as I believe that it simply creates pointless churn. I consider the proposed benefits to be utterly insignificant.

It does not bother you that when adding a feature macro one needs to remember to add it to all compiler configurations, live or dead? And that if one forgets nobody is any the wiser?

It does not bother you that we can't just add

#if defined(__cpp_foo) && __cpp_foo >= 201400 # define BOOST_CXX14_FOO #endif

in one place and have it mostly work, instead of touching O(N) files?

I think it would be better to define the positive macros like this: #ifndef BOOST_CXX14_FOO #if defined(__cpp_foo) && __cpp_foo >= 201400 # define BOOST_CXX14_FOO 1 #else # define BOOST_CXX14_FOO 0 #endif #endif This way: - We get a warning when checking the macro when it hasn’t been defined properly - The user can easily override the value with `-DBOOST_CXX14_FOO=0` during compilation because a feature turns out to be buggy.

AMDG On 01/26/2018 08:30 AM, Peter Dimov via Boost wrote:

As written, this does not allow the latter. The general case is:

// prefix.hpp:

#if defined(__cpp_foo) && __cpp_foo >= 201400 # define BOOST_CXX14_FOO #endif

// compiler/bar.hpp:

#if __BAR_VERSION__ >= 12 && __BAR_VERSION__ < 18 // have foo, don't have feature macros yet # define BOOST_CXX14_FOO #endif

#if __BAR_VERSION__ == 21 && __cplusplus >= 201700 // bar++ version 21 has a bug in foo in -std=c++17 mode # undef BOOST_CXX14_FOO #endif

If you define to 0 or 1 in prefix.hpp, the information of whether the user overrode is lost, and the compiler-specific config can still stomp over the user define.

Just apply the defaults after the compiler specific configuration instead of before, and there's no problem. In Christ, Steven Watanabe

Of course if we decide to follow Peter's suggestion and make the change, it is, as always, who is going to do the work. It would be ridiculous to lay this all on John. I am volunteering to help if needed, and I imagine Peter would also, so it would be a matter of finding those people with the time to make this happen if we decided to do it.

I think that since this is effectively Config.v2 we're talking about here, and since I have absolutely no time for this anyway, then if it's decided that this is the way forward, it would be better if the maintenance baton were handed on to someone else at this point: BTW this is absolutely not me "chucking my toys out of the pram", just a realistic assessment that I have neither time nor much inclination for this at this time.  I would obviously try and provide constructive criticism / help as I can.  I'm also frankly amazed that the design has worked as well as it has for so long - there's an awful lot of hard one knowledge encoded in the Config headers, and I hope that can be retained. BTW, if we're looking at a redesign, and potentially a lot of churn in client code, I think I'd like to see at least a mini-review before any change:  Boost.Config is so central to everything and the effects of substantive change potentially so damaging if we get wrong, that some extra-special caution is required in this particular case IMO. Best, John. --- This email has been checked for viruses by AVG. http://www.avg.com

John Maddock wrote:

BTW, if we're looking at a redesign, and potentially a lot of churn in client code, I think I'd like to see at least a mini-review before any change: Boost.Config is so central to everything and the effects of substantive change potentially so damaging if we get wrong, that some extra-special caution is required in this particular case IMO.

This has gone quite a bit further than what I had in mind. I did not intend a redesign or churn in existing client code, but merely (a) for new macros being added to be of the positive variety and (b) to take advantage of the standard feature macros so that our future maintenance work is minimized. Of course for consistency we would probably add positive macros to match our negative ones, but I did not envisage removing the existing macros or necessarily changing any existing code. I can see why one would think, well, if we're to change things, why not change them even more. Perhaps we should. It's just not what I proposed, or propose. To put it in the most succinct terms, my goal was minimization of the necessary diffs required to support a new feature or a new compiler version. Redesigning things from the ground up is rather out of scope.