Re: [boost] [mpl] multiset

Subject: Re: [boost] [mpl] multiset
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-02-27 20:32:43

On 2/27/2015 5:01 PM, Bruno Dutra wrote:
> On Feb 27, 2015 6:23 PM, "Edward Diener" <eldiener_at_[hidden]> wrote:
>>
>> On 2/27/2015 3:54 PM, Stephen Kelly wrote:
>>> [...]
>>> The removal of the old code was committed (see 'gitk steveire' in
> mpl.git).
>>>
>>> Daniel James reverted it.
>>>
>>> Feel free to revert the revert.
>>
>>
>> I am not the maintainer of MPL, although I have been granted rights to
> change it. I don't think MPL has a primary maintainer any more so any large
> change needs a consensus AFAICS.
>>
>> The consensus appeared to be that MPL should keep the old code. I agreed
> with you instead. But I am not going to go against the consensus of others
> unless there is an updated general consensus that agrees that MPL need no
> longer support the old compilers that it does.
>
> I'm not familiar with the exact changes to really know which compilers
> would not be supported anymore, but as a general rule, any compiler which
> is not regularly tested is, by definition, not strictly supported.

I do not believe that any of the compilers whose support Stephen Kelly 
removed from MPL are ever currently tested in the regression tests 
matrix. These were really old compiler releases that he intended to 
remove support in MPL for. The hacks to support some of those really old 
compilers were brilliant but they tend to complicate understanding MPL 
code fairly noticeably in a number of situations.

> Perhaps
> it would be a good idea to leave changes merged on develop branch for a
> while so that any testers of affected compilers could report failures. This
> could be serve as a good indication of which compilers are regarded as
> obsolete.

That could certainly be done.

>
> Meanwhile, how should one proceed to assess current consensus regarding
> this topic? Would it suffice to just open a discussion on this mailing list?

That would suffice IMO. Should be its own topic however.