Re: [boost] [MPL] A Proposal

On 2016-02-29 14:45, Bruno Dutra wrote:

On Feb 29, 2016 05:46, "Andrey Semashev" wrote:

...

On 2016-02-29 06:48, Edward Diener wrote:

...

On 2/28/2016 7:13 PM, Andrey Semashev wrote:

...

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.

On the other hand we don't want to break code that has been working for a decade just because it happens to depend on a particular implementation detail that hasn't been ported back from Metal, or perhaps even due to an unnexpected bug in it. For such odd cases, there should be a way to override the default behaviour through the preprocessor and get the code back running, even if temporarily while the code is amended/bugs are fixed.

If that's the concern then it's probably better to leave MPL as is and introduce Metal as a separate library. PS: I don't mind breaking code that relies on bugs or implementation details.