Re: [boost] Review request: Require a SFINAE capable compiler

Subject: Re: [boost] Review request: Require a SFINAE capable compiler
From: Edward Diener (eldiener_at_[hidden])
Date: 2013-10-13 15:57:08

On 10/13/2013 02:26 PM, Stephen Kelly wrote:
> On 10/13/2013 02:17 PM, John Maddock wrote:
>>> The attached patch removes support for those versions of the compilers
>>> which are not capable of SFINAE.
>>>
>>> This bumps the compiler requirement to remove support for Borland 5.x,
>>> Metrowerks prior to 9.0, and SunPro prior to 5.7. Compilers based on EDG
>>> 238 are also affected, though it is unknown what those are.
>>>
>>> Ok to commit?
>>>
>>>
>>> Please, wait for at least John give you permission.
>>
>> It's OK by me, though as others have already said, best to wait for
>> the 1.55 release to go out first... just in case we need to test
>> patches/bug reports in Trunk.
>
> This is what I don't understand.
>
> I don't see how my work makes this any harder. At *worst*, a bug fix
> will have a part in the positive side of an ifdef for some feature (like
> BOOST_NO_SFINAE), and a part in the negative side of it. I don't think
> that's even a likely scenario. Also, that's assuming the one who writes
> the patch patches both sides of the ifdef.
>
> That is still trivial to cherry-plck into the trunk branch. Or do you
> think it is not trivial? In that case, what makes it non-trivial?
>
> I want to understand the problem that exists and is stalling me.

I do not believe there are that many people questioning the work you are 
doing. The problem is that until 1.55 is officially out, it is possible 
that some change in trunk will still be merged to release and that 
change might involve some of the changes you are making, leading to a 
much more complicated merge. That is why I believe you were asked to 
hold off on your changes to trunk until after 1.55 has been released. In 
that sense your work makes things harder at this moment if a quick late 
merge has to be done. Afterward I am sure your work will make things 
easier for many libraries, but it still is important for library 
developers to know what you have done.