Re: [boost] [MPL] A Proposal

Subject: Re: [boost] [MPL] A Proposal
From: Bruno Dutra (brunocodutra_at_[hidden])
Date: 2016-02-28 19:38:59

2016-02-28 21:13 GMT-03:00 Andrey Semashev <andrey.semashev_at_[hidden]>:

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

One of the reasons for using Boost.MPL is to keep the code compatible
> with C++03. I assume, with your proposed solution this compatibility
> will be preserved, won't it? If so, you could branch the
> implementation based on the language version (or rather, the set of
> enabled/supported C++11 features).
>

I don't propose to change anything in the current Boost.MPL nor in its API,
just provide an alternative backend for it, hence backward compatibility
would always be preserved. Ultimately the more appropriate backend should
be selected based on available features, however the user should be given
the option to override this behaviour and forcedly specify the desired
backend using a preprocessor switch, otherwise it should be completely
transparent.

New projects should be using API v2, i.e. current Metal, unless for some
reason they require C++03, in which case they would have to stick with the
older API, i.e. current Boost.MPL.

Regards,
Bruno