Re: [boost] [mpl] multiset

Subject: Re: [boost] [mpl] multiset
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-02-19 18:33:41

On 2/19/2015 5:19 PM, Robert Ramey wrote:
> Edward Diener-3 wrote
>>> 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.
>
> Just eliminating a few hacks in it is not the same as taking responsibility
> for it.

You are right about this. But MPL is a large library and it should not 
need total comprehension for a Boost developer to make changes to a 
small part of that library if the changes made improve MPL in some way.

>
> A while back Stephen Kelly specified changes to MPL to get rid of  hacks
> for old compilers that nobody should be using anymore, and which would
> simplify the MPL code a bit so that new development could more easily be
> done with the code.
>
> This effort had a couple of issues.  First it changed the scope of mpl from
> a library which would support older compilers to one which would limit
> support to a more modern subset.

Is Boost seriously supposed to support largely obsolete compilers into 
perpetuity with each new release ? I do not think this is viable in all 
cases and cannot see this as a goal of Boost libraries. At some point, 
with some new release, I think it is possible to say for a given library 
that it does not support a largely obsolete compiler.

>  This basically amounts to a change
> of interface.

In the case of Stephen Kelly's removal of old compiler workarounds it 
does not. The interfaces would have remained the same but hacks to 
support VC6 and VC7, as well as some other compilers that no one should 
seriously be using anymore, would have been eliminated. My own feeling 
is that the improvement in making MPL code more understandable would 
have easily been worth removing these ancient hacks and the compilers 
they supported.

>  Another problem is that making such changes is much, much
> tricker than first meets the eye.  It would be huge effort to do it right.

For the removal of MPL hacks that Stephen Kelly did I believe he got 
everything right. But since we never got to try it, even in 'develop', 
we will never know.

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

That is a much bigger change than what Stephen Kelly had tried to do. 
That does not mean I do not think it might be worthwhile if someone 
talented enough and with time enough were to do it.

>
>> But these changes were never made and the opinion
>> was voiced that Hana would supercede MPL so why make any changes to MPL
>> itself. I am with you in believing that until a new  metaprogramming
>> idiom becomes more popular, such as Hana or maybe Eric's blog
>> contribution.
>
> The jury is still out on these efforts.  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.
>
>>   it is worthwhile looking at possible improvements in MPL
>> and it is certainly worthwhile fixing any bug reports which may have
>> been made against MPL.
>>
>> I can understand the nervousness by which others view any changes to
>> MPL, since it is so heavily used by other libraries and such a core
>> library, but I do not understand the point of view that MPL should
>> remain as frozen as possible so as not to cause problems with other
>> libraries which use it.
>
> I think the main concern is that someone makes a fix - which fixes
> his problem - but then walks away from it. Then something breaks
> and the next person does the same thing.  That's not the same as
> having a maintainer take responsibility for it.

If anyone changes anything in a library which breaks anything else it is 
that person's responsibility to fix things. This is true whether it is 
MPL or anything else. I agree it would be good to have a maintainer for 
MPL but a single person trying to take over from Dave and Alexey would 
be a very difficult responsibility. Still I see nothing wrong with 
others who have maintainer status with MPL making changes as long as 
they take responsibility for what they do and of course realize how 
important and central MPL is to so many other Boost libraries so they 
must be very careful.

>
> This is an instance of our larger problem of finding a way to keep
> maintainers for libraries.  It's still not even close to being solved.
>
> Robert Ramey