Re: [boost] [MPL] A Proposal

29 Feb 2016

      2016-02-29 16:42 GMT-03:00, Andrey Semashev :
...
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 
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