Re: [boost] [MPL] A Proposal

Subject: Re: [boost] [MPL] A Proposal
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-02-29 12:18:59

On 2/29/2016 3:45 AM, Andrey Semashev wrote:
> On 2016-02-29 06:48, Edward Diener wrote:
>> On 2/28/2016 7:13 PM, Andrey Semashev wrote:
>>> On Mon, Feb 29, 2016 at 2:17 AM, Bruno Dutra <brunocodutra_at_[hidden]>
>>> wrote:
>>>> Dear Community,
>>>
>>> [snip]
>>>
>>>> My proposal is to make Metal officially into a new revision of
>>>> Boost.MPL's
>>>> API, essentially MPL2 as the original proposal by Robert Ramey put it,
>>>> merging both into one single TMP library. The idea would be to
>>>> provide a
>>>> thin proxy for the current Boost.MPL API which would have two backends
>>>> configurable by preprocessor switches: the original implementation
>>>> and a
>>>> another one based on Metal.
>>>
>>> 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.

I have a library with current MPL code. Someone compiles my library in 
C++11 mode. Is that a good enough use case for you ? Or are you going to 
insist that I rewrite my library using Metal even though it works 
perfectly well in C++11 mode as is ?

I am not against possibly eventually changing my library to use Metal. 
But telling me that my library should be broken because Metal exists  is 
absurd.