Re: [boost] [mpl] multiset

Subject: Re: [boost] [mpl] multiset
From: Bruno Dutra (brunocodutra_at_[hidden])
Date: 2015-02-20 12:38:28

>>> I'm just wondering whether the lack of development of MPL in the past
>>> years
>>> is just incidental, as developers moved on to new frontiers, or if
>>> indeed
>>> if reflects a consensus that MPL is obsolete nowadays, which I find hard
>>> to
>>> believe.
>>
>> I believe it reflects the fact that the two developers mostly
>> responsible for creating MPL are not very active in Boost anymore.
>
> The mpl library provides functionality which is no where else available
> and which many boost libraries depend on.
>
> I believe that the fact is that no one is responsible for it anymore.
> [...]
> My concern about hana is that it
> seems to have evolved way beyond what MPL does and so wouldn't
> serve as a "drop-in" improvement.  I don't know about Eric's effort
> but I believe he's said he can't bring to the level of a boost library
> and no one has expressed any interest.

That's exactly the point I was trying to make. Hana is awesome, but it
doesn't fit as a replacement for MPL, simply because it was meant for
a different purpose. I see no reason why they shouldn't live side by
side, each filling its specific niche.

> The right way would be to:
> define MPL2 - a C++11+ version of mpl.  Re-implement MPL in terms
> of C++11.  This could skip any part of mpl already in the standard.
> Presumably it would be a much smaller effort than the original, but it
> would still be a very large effort.  Remember that MPL is the result of
> efforts of two of the best C++ programmers anywhere.  It would be
> hard to meet that standard.  Of course anyone is willing to try, feel free.
>[...]
> One thing that might be useful would be to set an explicit policy like
> "MPL is only guaranteed to works with:
> MSVC 8.0 and above
> GCC ?? and above
> etc.

That is certainly an audacious idea, but I don't see a better way of
seriously revamping MPL either. I think that was precisely the
original intention of Louis Dionne's MPL11, which ended up deviating
its course and dropping backward API compatibility. Quoting from MPL11
github page:

"This was initially supposed to be a simple C++11 reimplementation of
the Boost.MPL. However, for reasons documented in the rationales, the
library was redesigned and the name does not fit so well anymore."

Perhaps it would be easier to just start off MPL11 and reintroduce
backward compatibility than to start anew.
I wouldn't go so bold as to assert I'm up to the task, but I take it
as a great opportunity for learning and amusing myself, so I'll look
into it at the slow pace my busy life allows me.

That said, I'm with Edward Diener in believing there's lots of room
for improvement in the library as it is and that one should not be
afraid of pushing it forward bit by bit. I understand the concerns
regarding breaking compatibility for older setups, but aren't there
volunteers who run test suites daily, precisely to assure everything
is working as expected across the various setups? One thing that I
noticed though, is that MPL test suite right now does not cover
anywhere near even the documented API, let alone corner cases which
should definitely be tested (running algorithms on empty sequences
comes to mind). A bugfix on which I'm working right now, for instance,
would have been caught a decade ago, had tests been written to cover
the fact, which is explicitly written in the documentation, that
insert_range should work for "Extensible Associative Sequences". As
soon as I get this bug fixed (which is taking way longer than it
should, I must admit), I'll work on expanding current test cases based
on the documentation and file a pull request for that. I just count on
you boost maintainers to help me out by reviewing and accepting my
pull requests as appropriate :)

-- 
*Bruno C. O. Dutra*