Re: [boost] [mpl] Merging 'develop' to 'master'

Subject: Re: [boost] [mpl] Merging 'develop' to 'master'
From: Daniel James (dnljms_at_[hidden])
Date: 2014-03-21 05:17:58

On 21 March 2014 02:45, Edward Diener <eldiener_at_[hidden]> wrote:
>
>
> I will have to disagree based on my intuition that replacing MPL with
>> something closer to C++11/C++14 constructs is going to be a major
>> undertaking which will not occur in the near future. Furthermore even
>> if/when it occurs numerous Boost libraries would have to transition to the
>> replacement. I do not think we can afford to hold back any needed changes
>> to MPL based on a conservative approach.
>>
>
What needed changes are being held back? Take a look at the MPL tickets in
trac, this is not the reason that no one is fixing them. Since we're using
git now, nothing is stopping anyone from branching with Stephen Kelly's
changes included and doing whatever these hacks are preventing.

The changes made by Stephen Kelly got rid of support for VC6, VC7 ( VS2002
>>
>>> ) and old versions of gcc ( prior to gcc-4 I believe ).
>>>
>>>
>> They remove support for some other compilers as well. We had an email from
>> someone who still uses Metrowerks which might have problems with the
>> partial template specialization changes.
>>
>
> Should MPL seriously expect to be used by a compiler which still cannot
> implement partial template specialization correctly ? I do not believe so
> even if some clever MPL "hacks" currently may allow it.
>

That's what MPL has mainly been used for. Probably more than its more
esoteric features.

> No one even tests Metrowerks AFAIK. Can we really support any compiler
> which no one tests when that compiler has become so out of date with
> current C++ ?

We don't need to support them, we just need to not break them gratuitously.
In MPL's case, we're not actively supporting any compilers at all.

> I think the best thing to do for MPL is to revert Stephen Kelly's changes,
>> and put them on a branch so that they can be reconsidered later. I'm not
>> saying they're bad - at the very least, removing support for old versions
>> of Visual C++ is a good idea. But I think we need to sort out the
>> libraries' dependants first. I'm going to try to start on some of these
>> soon, but it'll take a while.
>>
>
> I pushed a remote/SKChanges branch based on the point of Stephen Kelly's
> last changes to develop. His changes can currently be reverted on 'develop'
> without conflicts but I am still loath to do this myself. I would still
> like to see if his changes on 'develop' are actually causing any problems
> with other libraries in the 'develop' regression testing.

A lot of MPL's dependants include Stephen Kelly's changes in develop, but
not in master - and there's a reasonable chance that these need to be
merged before MPL. The tests in develop are not going to pick that up.