Re: [boost] [config] Rethinking feature macros?

Subject: Re: [boost] [config] Rethinking feature macros?
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-11-06 13:22:31

On 11/6/2017 7:45 AM, Peter Dimov via Boost wrote:
> Andrey Semashev wrote:
> 
>> Besides, I believe this is not Boost's prerogative to define compiler 
>> and standard library-specific macros.
> 
> Steven made the same good point - we should not define these macros 
> because someone else may decide to do it too.
> 
>> Boost.Config macros do not necessarilly correspond to what the 
>> compiler defines. Compilers lie sometimes by defining a macro while 
>> the corresponding feature is broken.
> 
> That's true in principle but I've found this practice questionable and 
> can't help but note that in my specific example of 
> __cpp_noexcept_function_type, if Config doesn't define the macro my code 
> will break, regardless of whether the feature is broken. I want to know 
> if the feature is present, not whether someone arbitrarily considers it 
> broken. But that's really a side issue.
> 
>> Also, on the std-proposals list (IIRC) there was a discussion about 
>> SD-6 macros, and there were even initiatives to entirely drop the 
>> whole idea.
> 
> I don't remember a time when this wasn't the case.
> 
> The objections to the specific idea of defining SD-6 macros in Config 
> are solid, but nobody has said anything about the inefficiencies in our 
> current approach that are caused by us defining negative macros instead 
> of positive ones. We can avoid the problem of not being allowed to 
> define "foreign" macros by having our own names for them and defining 
> them automatically when the standard macro is defined.
> 
> #ifdef __cpp_noexcept_function_type
> # define BOOST_CPP_NOEXCEPT_FUNCTION_TYPE
> #endif

This is a better idea, if only to align Boost Config macro names with 
the SD-6 macros.

> 
> Positive macros suffer from the problem of one forgetting to include 
> config.hpp a bit more than negative macros do, but using our names 
> avoids the other problem Steven brings up, that things would silently 
> work in this case on g++/clang++.
> 
> (Of course the above doesn't work for library macros because we don't 
> want to include the whole STL but we still can use positive macros 
> there, we just need to define them ourselves appropriately.)

Theoretically a good idea, but we then end up with defining Boost 
equivalent SD-6 macros, where the compiler macros are based on SD-6 and 
the library macros are based on Boost Config logic.