[LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

[Joshua Cranmer 🐧]

On 10/29/2013 8:42 PM, "C. Bergström" wrote:
> On 10/30/13 08:24 AM, Richard Smith wrote:
>>
>>     May I humbly propose you create a c++11-development branch
>>     now/later/anytime and let people start using that. In parallel to
>>     that let people know that pieces of the c++11 branch will
>>     potentially start merging Feb 1st 2014. (roughly 3 months from
>>     today). This gives people time to review things before they hit
>>     trunk, test, discuss and experiment in a way that virtual
>>     discussions simply can't flush out. This hopefully won't hurt your
>>     target of the release-after-next using more modern toolchains and
>>     is *hopefully* a win-win in your view.
>>
>>
>> I don't see how this helps anything. We don't /want/ to have the 
>> hassle of some people developing on a branch and some on trunk, so we 
>> would essentially have trunk stagnating and everyone developing on 
>> the branch. And then we'd merge the branch back again. Net result: 
>> exactly the same as if the people who aren't ready for c++11 stick 
>> with the 3.4 release.
> No its entirely not the same
>
> 1) Branch development is very common - I can't imagine *everyone* will 
> use c++11 immediately and it causing some instant stall on trunk if a 
> branch was made
> 2) As stated before - a branch lets a *real* discussion happen 
> *before* it hits trunk. With any big feature change - isn't it best to 
> be a little conservative instead of potentially break 1st and 
> fix-it-later approach.

The problem is that retrofitting code to use C++11 features is extremely 
invasive into a codebase, and (depending on the feature being changed) 
has a high risk of making many patches fail to apply. A C++11 branch 
isn't going to work: either you will have to transplant patches from the 
C++11 development branch to mainline trunk (depending on the patch, this 
ranges from "maybe easy" to "impossible") or go through cumbersome 
merges on a regular basis to keep the C++11 branch up-to-date. So 
everyone who wants to use C++11 in their code is left struggling in pain 
for development.

At the same time, how will this find bugs? The people who track the 
C++11 development branch would be the people who don't object to using 
C++11 in the first place, and they are going to be the ones who don't 
have the problem. The people who may have the problems are going to be 
following trunk, and, with a C++1 development branch, they're not going 
to know about problems until a large, unbackoutable, nasty merge lands 
on trunk. All you are doing is delaying the pain point.

If you *really* want to to give people time to handle the issues, what 
you do is you make C++11 support mandatory in the build system but don't 
use any [non-polyfilled] features yet. There is just enough C++11 code 
in the tree that would be enabled to flag broken setups, and this is a 
small patch that could be undone without much pain if the problems 
discovered are unfixable.


-- 
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist