Re: [boost] [MPL] A Proposal

Subject: Re: [boost] [MPL] A Proposal
From: Bruno Dutra (brunocodutra_at_[hidden])
Date: 2016-02-29 17:37:28

2016-02-29 19:11 GMT-03:00 Edward Diener <eldiener_at_[hidden]>:

> On 2/29/2016 2:50 PM, Bruno Dutra wrote:
>
>> 2016-02-29 14:39 GMT-03:00, Edward Diener <eldiener_at_[hidden]>:
>>
>>> 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.
>>>>
>>>
>>> You have a good point with your last sentence. The best thing might be
>>> to put the MPLv2 header files in its own separate version2 sub-directory
>>> structure.
>>>
>>>
>> I don’t meant to say you got it wrong, on the contrary I’m certain you
>> got it right, but before we start misunderstanding ourselves, allow me
>> to clarify some terminology so it is clear to everyone.
>>
>> * Currently Boost.MPL has one API which we all know and love. I call it
>> API v1.
>> * API v1 has currently only one implementation, which is, naturally,
>> that provided by Boost.MPL.
>> * I propose to provide another implementation for API v1 based on
>> Metal, that could be used when the compiler supports C++11. This
>> alternative backend would bring the benefit of faster compilation
>> times and lower memory consumption to older projects.
>>
>
> As long as the Metal API v1 has the exact same syntax, where it exists, as
> the current MPL, there should be no problem with what you propose. In that
> case I agree with Andrey that the level of c++, whether c++11 on up or not,
> can determine whether the current MPL is used or the Metal API v1 is used,
> for the syntax involved. My concern is simply that current Boost libraries
> which use MPL, of which there are quite a few as you know, not be forced to
> change syntactically when Metal is integrated with MPL.
>
>
Exactly, I pose it as a prerequisite that using Metal as a backend for the
current API v1 shall not break any existing code.

Bruno Dutra