Re: [boost] [config] What to call macros to indicate deprecated/removed components

Subject: Re: [boost] [config] What to call macros to indicate deprecated/removed components
From: Peter Dimov (lists_at_[hidden])
Date: 2017-04-16 12:07:46

John Maddock wrote:

> We now have several former C++ features which are removed in C++17:
>
> auto_ptr
>
> random_shuffle
>
> binders
>
> unary/binary_function
>
> And we're getting requests for configuration macros for these, the 
> question is what to call them?
>
> We could stick with the (easy to implement) existing naming and just use:
>
> BOOST_NO_<FEATURE>

We already have BOOST_NO_AUTO_PTR (and use it). It was originally introduced 
for C++98 libraries that didn't have auto_ptr _yet_, but the effects are 
entirely the same.

> or we could use:
>
> BOOST_<STD>_REMOVED_<FEATURE>

Depends on what we want <STD> to mean. Currently, we can interpret it as a 
prefix that says "<FEATURE> has been first introduced in <STD>", so, for 
instance, if std::bind is removed, we'll call it CXX11_BIND, consequently 
the macro would be BOOST_NO_CXX11_BIND.

Or, as the above suggests, <STD> may tag the standard in which a change is 
taking place, hence BOOST_NO_CXX20_BIND.

The first one makes more sense to me.

For another example besides auto_ptr, consider what we'll do when <codecvt> 
is removed. We already have BOOST_NO_CXX11_HDR_CODECVT, would it not be 
stupid to introduce BOOST_NO_CXX20_HDR_CODECVT just to keep our brass door 
handles shiny? Whether <codecvt> is missing for one reason or another, it's 
missing.