Re: [boost] [MPL] A Proposal

Subject: Re: [boost] [MPL] A Proposal
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-02-29 14:40:07

On 2016-02-29 20:18, Edward Diener wrote:
> 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'm not sure I see the problem. The way I understood the OP, the 
proposed Metal backend for MPL is transparent to the users of MPL. I.e. 
your library will still be using mpl:: components the same way, whether 
or not they are actually implemented by the legacy code or the C++11 new 
one.

> 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.

I wasn't saying that it should. If anything, my comments so far in this 
thread have been against touching MPL if it means breaking compatibility 
(besides bugs and implementation details, that is). Selecting the 
non-backwards-compatible code by defining a macro is not an acceptable 
solution to me.