Re: [boost] [mpl] multiset

Subject: Re: [boost] [mpl] multiset
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-02-25 02:56:45

Le 25/02/15 00:06, Bruno Dutra a écrit :
> 2015-02-24 18:46 GMT-03:00 Vicente J. Botet Escriba <
> vicente.botet_at_[hidden]>:
>
>> Either I expressed myself incorrectly or you miss-understood me. When I
>> said easier I was thinking on a new library compared to a library that has
>> to preserve MPL compatibility.
>>
>> BTW, I like a lot your library. However I don't think it would be easy to
>> introduce its design on the C++ standard library. IMHO pure
>> meta-programming additions should be easier to introduce. Of course, I can
>> be wrong.
>>
>>
> Do you see anything so broken within MPL's design that justifies dropping
> backwards compatibility and redesign a new library from scratch?
Don't misunderstand me. I'm not against a GSoC project that work on 
extensions of the MPL library. Just that I don't want to mentor it. I 
prefer to spend my time on a meta library that can take advantage of the 
new C++11/c++14 features without having the constraint of backward 
compatibility.
> Is it
> really necessary, considering the existence of other modern options which
> already focus on an strict C++14 approach, such as Hana?
I find as moder the Eric's Meta library than the Louis's Hana library. 
The scope is just different.
>
> IMO the fact it mimics the standard library is very positive, for it makes
> transition much easier for someone used to the STL first experimenting with
> metaprogramming. It sure is not the best design for an essentially
> functional library, but I don't see why it could not provide various
> interfaces, one of them being iterators, i.e. preserving its current
> interface.
I believe that a meta-programming library should be based more on pure 
functional programming design than on STL. This doesn't mean that the 
names shouldn't be adapted to the C++ world.
> Taking a closer look at the code, the bulk of it really is just dealing
> with broken compilers. On one hand I totally agree that getting rid of
> (some of) them would simplify things a lot, counting on the fact that
> anyone that can put up with such an outdated compiler as MSVC 6 could as
> well tolerate using a not so outdated version of boost. On the other hand,
> I think this is one of the greatest achievements of MPL and I would resist
> the idea at first, until it proves really necessary.
>
> In any case, I fail to see a very good reason for deprecating MPL in favor
> of a completely new design, assuming the desire to also maintain a pure
> metaprogramming library that is.
>
>
It is not my intention to deprecate MPL. I'm just looking for some 
meta-programming utilities that can be proposed to the C++ standard.

Vicente