Re: [boost] [config] Positive feature macros, r2

Subject: Re: [boost] [config] Positive feature macros, r2
From: Edward Diener (eldiener_at_[hidden])
Date: 2018-01-26 00:22:12

On 1/25/2018 11:51 AM, Peter Dimov via Boost wrote:
> I'd like to revisit the topic of Boost.Config feature macros, 
> specifically that in my opinion, positive feature macros 
> (BOOST_CXX17_FEATURE) make more sense than negative macros 
> (BOOST_NO_CXX17_FEATURE) in the current environment.
> 
> Negative macros made sense in the past when they signified bugs and 
> deficiencies in the compiler as measured against a static standard. 
> Nowadays, the standard, such as it is, is in constant motion and macros 
> indicate merely a current state of development for both the compiler and 
> the standard.
> 
> The arguments for positive macros are the same as last time:
> 
> - adding a new negative macro requires changes to all legacy compilers 
> that do not and will never implement the feature; a positive macro only 
> requires changes to active compilers.
> 
> - positive macros are a better match for the standard feature macros, 
> which are positive. When we see a standard feature macro being set, we 
> typically would set ours as well. This means that the amount of changes 
> required to add a new macro is further reduced; we only need to touch 
> compiler-specific config files if the compiler either does not implement 
> feature macros, or sets them incorrectly (in our considered opinion.)
> 
> TL;DR we should switch to positive feature macros in Boost.Config, and 
> delaying this switch just accumulates more unnecessary code in 
> Boost.Config.

I agree with Peter, basically because it makes for much more readable 
code as well as the reason Peter gives, because we do not have to 
consistently be changing config headers just to say that something X 
does not support some new Y.

I understand Steven's comment that this is much churn for seemingly 
little, but when one realizes that the design seems now wrong, even just 
syntactically, then churn is justified IMO.

I think we can support the _NO_ forms for a few releases, while 
deprecating them, while we add any new macros as positive features,
and basically tell library developers to change their code to use the 
new positive macros. I do agree that all our _NO_ macros need to have a 
positive equivalent whenever the _NO_ macro is for a general feature 
rather than for specific compiler weaknesses ( I realize this is 
judgmental ). Telling end-user to change their own code to use the 
positive form is a PITA, but I would still do it. I feel strongly that 
Peter is right and the negative forms we have propagated is the wrong 
syntactical design for config as C++ goes forward with new features and 
new releases.

We might also be able to write some code, Python or C++, which searches 
some set of files for all the current config _NO_ macros being used and 
prints the file name, line number, and line in some sort of summary 
file. We could do this as an aid both for library developers and 
end-user switching from the _NO_ form to the proposed positive form of 
any given config macro.

I know when I programmed cxxd I purposely wanted to provide my own cxxd 
macros as positive things rather than mimic the _NO_ form of the config 
macros, even when heavily using config underneath to implement cxxd. So 
I know people may consider me biased because of that, but that is still 
the way I see this issue as far as the _NO_ forms are concerned.

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.