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.