$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [mpl] multiset
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2015-02-23 02:08:21
Edward Diener <eldiener <at> tropicsoft.com> writes:
>
> [...]
>
> Numerous Boost libraries currently use MPL. If you want to have Hana as
> a Boost library, if it is accepted after review, I think you will have
> to get used to the idea that Boost will have more than one
> metaprogramming library. If Hana proves popular enough with
> metaprogrammers they will switch away from MPL to Hana.
>
> I do not know what you mean by "two metaprogramming libraries
> living side by side" but I believe that two libraries whose purposes are
> similar but whose programming interfaces are different is never a
> detriment to Boost as long as both are quality libraries which other
> programmers find useful.
I apologize; what I said was unclear. I did not mean that the MPL (or Fusion
for that matter) should go away. I also do not expect people to port old code
from MPL/Fusion to Hana, except in some rare cases. Actually, Hana even
provides interoperation with MPL and Fusion, so I do recognize the importance
of these libraries. What I meant is that I think we should strive for a unified
treatment of metaprogramming in the long term. Hence, I would hope that _new_
libraries are written against Hana instead of MPL/Fusion, of course if those
libraries are meant to be used on modern compilers.
As for "two metaprogramming libraries living side by side", I meant that
working on a _new_ C++11/14 type-only MPL is a bad idea IMO, because Hana
is a strict superset of such a type-level only library. Of course, this is
my biased opinion, and it is why I switched from MPL11 to Hana; I thought
it was more promising.
However, I have absolutely nothing bad to say about a revamping of the
current MPL in a backward compatible way, except that it might be hard
(but not impossible) to achieve without breaking some code. Actually, if
someone is interested in attempting a backward compatible MPL, I could
probably provide a good part of the code by just looking at an older
snapshot of the MPL11, before backward compatibility was broken.
Louis