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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
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>

or we could use:

BOOST_<STD>_REMOVED_<FEATURE>

which is a bit more work as all the scripts that rely on the
BOOST_NO/BOOST_HAS convention need updating.

Any other suggestions/preferences?

Thanks, John.



---
This email has been checked for viruses by AVG.
http://www.avg.com


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
On 16 April 2017 at 11:57, John Maddock via Boost <[hidden email]> wrote:

> We could stick with the (easy to implement) existing naming and just use:
>
> BOOST_NO_<FEATURE>
>
> or we could use:
>
> BOOST_<STD>_REMOVED_<FEATURE>
>
> which is a bit more work as all the scripts that rely on the
> BOOST_NO/BOOST_HAS convention need updating.

No strong opinion, but do we want the default to be that they're available?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 04/16/17 13:57, John Maddock via Boost 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>
>
> or we could use:
>
> BOOST_<STD>_REMOVED_<FEATURE>
>
> which is a bit more work as all the scripts that rely on the
> BOOST_NO/BOOST_HAS convention need updating.
>
> Any other suggestions/preferences?

Previously, we followed the "no macro = no defect" approach, which, if
we consider the presence of the deprecated comonents a defect, would
result in BOOST_CXX17_NO_REMOVED_RANDOM_SHUFFLE meaning random_shuffle
is _present_ when the macro is _defined_. I think such behavior would be
rather contrived, so IMHO it's better to define
BOOST_CXX17_REMOVED_RANDOM_SHUFFLE when random_shuffle is missing. OTOH,
that would also mean that the code will not be compatible with a
"perfect compiler implementing the latest standard" with no macros
defined. Not sure how useful this is.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sun, Apr 16, 2017 at 6:57 AM, John Maddock via Boost 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>
>
> or we could use:
>
> BOOST_<STD>_REMOVED_<FEATURE>
>
> which is a bit more work as all the scripts that rely on the
> BOOST_NO/BOOST_HAS convention need updating.
>
> Any other suggestions/preferences?
>
> Thanks, John.

I like BOOST_NO_FEATURE for features just outright removed.

Removal probably doesn't require a C++ standard version in the macro
since its effects are the same even if it happens many times over, for
some reason. (e.g. If std::exchange was removed in C++20, then added
back in C++2y, then removed in C++2z, there would be no difference
between BOOST_CXX20_REMOVED_STD_EXCHANGE and
BOOST_CXX2Z_REMOVED_STD_EXCHANGE.)

I just didn't like BOOST_NO_CXX17_FEATURE style if FEATURE does not
even exist in C++17 because it is misleading compared to the other
macros which check for existence of features.[1]

Glen

[1] https://github.com/boostorg/config/pull/131

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Daniel James wrote:

> No strong opinion, but do we want the default to be that they're
> available?

This is a good point in principle, but as things are added and then removed,
the correct default for, say, <codecvt>, flips from not available (in C++03)
to available (in C++11) to again not available (in C++20).


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Marcel Raad
In reply to this post by Boost - Dev mailing list
Boost - Dev mailing list wrote
I like BOOST_NO_FEATURE for features just outright removed.

Removal probably doesn't require a C++ standard version in the macro
since its effects are the same even if it happens many times over, for
some reason. (e.g. If std::exchange was removed in C++20, then added
back in C++2y, then removed in C++2z, there would be no difference
between BOOST_CXX20_REMOVED_STD_EXCHANGE and
BOOST_CXX2Z_REMOVED_STD_EXCHANGE.)

Glen
+1. But it would also have exactly the same effect as BOOST_NO_CXX14_STD_EXCHANGE, so perhaps that could also be used instead of BOOST_NO_STD_EXCHANGE.

Marcel