Re: [boost] [MPL] A Proposal

Subject: Re: [boost] [MPL] A Proposal
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-02-29 06:51:33

On 2016-02-29 14:45, Bruno Dutra wrote:
> On Feb 29, 2016 05:46, "Andrey Semashev" <andrey.semashev_at_[hidden]> wrote:
>>
>> On 2016-02-29 06:48, Edward Diener wrote:
>>>
>>> On 2/28/2016 7:13 PM, Andrey Semashev wrote:
>>>>
>>>> I don't think it needs to be controlled with preprocessor switches. In
>>>> fact, it's best to avoid config macros as much as possible because it
>>>> complicates the use of the library in other libraries.
>>>
>>> I disagree with this. Simply because you are compiling with c++11 on up
>>> will not necessarily mean that you want to use the Metal additions to
>>> Boost.MPL rather than the current Boost.MPL. Certainly the programmer
>>> should have a choice even when C++11 is be used in the compilation.
>>
>> I don't see a use case where you would want a C++03 implementation on a C++11 capable compiler. On the other hand I can easily see the situation where several libraries using Boost.MPLv2 conflict because they have defined different config macros for it.
>
> On the other hand we don't want to break code that has been working
> for a decade just because it happens to depend on a particular
> implementation detail that hasn't been ported back from Metal, or
> perhaps even due to an unnexpected bug in it. For such odd cases,
> there should be a way to override the default behaviour through the
> preprocessor and get the code back running, even if temporarily while
> the code is amended/bugs are fixed.

If that's the concern then it's probably better to leave MPL as is and 
introduce Metal as a separate library.

PS: I don't mind breaking code that relies on bugs or implementation 
details.