Re: [boost] [MPL] A Proposal

Subject: Re: [boost] [MPL] A Proposal
From: Bruno Dutra (brunocodutra_at_[hidden])
Date: 2016-02-29 15:01:56

2016-02-29 16:42 GMT-03:00, Andrey Semashev <andrey.semashev_at_[hidden]>:
> On 2016-02-29 20:39, 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.
>>
>> 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.
>
> ...and its own separate namespace. With that, it doesn't really differ
> from a completely separate library, which I was suggesting. No need to
> drag the MPLv2 naming as well.
>

Well I would insist in my original proposal, because otherwise we
wouldn't achieve my the desired goal to effectively modernize
Boost.MPL.

I understand your concerns, they are perfectly reasonable, but please
bear in mind that the selection of the more appropriate backend
*shall* be automatic and totally transparent to the user.

A preprocessor switch to override this behaviour would be meant only
for an *exceptional situation* where the user must get the code back
in production and while the issues which prevent the automatic
selection of backends is addressed. Otherwise, should anything go
wrong for whatever reason, the user would have no alternative but to
revert to a previous release of the entire Boost distribution just to
get the code back compiling.

At any rate, should the community deem the risk of adding such a
preprocessor switch much too high, I would not go against it at all.

Regards,
Bruno Dutra