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

[Chandler Carruth]

On Wed, Nov 6, 2013 at 1:07 AM, David Chisnall
<David.Chisnall at cl.cam.ac.uk>wrote:

> I think his point was that we encourage out-of-tree projects to follow
> ToT[1] and so announcing in x.y that x.(y+1) will use C++11 (or C++14)
> feature Z means that people may start using that feature in ToT as soon as
> the x.y release is branched (which may be even before the announcement that
> x.(y+1) will use the new feature).
>

So, this email discussion, and the summary email I sent to the dev lists is
the announcement. So there will be some time for folks to do this. I think
*no* warning is too little warning, but I don't think that's what we're
talking about here.

That said, I completely agree that this is a relatively aggressive schedule
for ToT. I also like that you draw analogy to the API changes which I view
is quite similar.


>
> If the new feature requires out-of-tree LLVM users to upgrade their
> toolchains then we may only be giving them a month or less warning, even if
> we are giving downstream packagers 6 months.
>
> Given how hard we already make it for people to follow ToT for out-of-tree
> projects (and how much we shout at them when they don't), I'd rather that
> we didn't make it any harder.
>

I actually am not sure about the shouting at people when they don't follow
ToT with their out-of-tree projects.

I see a lot more pressure for folks to do their work in the open than to do
closed source work against ToT. I think that's actually reasonably healthy
for the project. The (very significant) overhead of tracking ToT or even
release-to-release changes (and the workarounds for the bugs that never get
a patch release) tend to heavily incentivize people to contribute back
their changes. One of the primary benefits of pushing changes back into the
open source repo is that now API updates are done for you.

So, *if* you need to maintain an out of tree project (and there are a bunch
of really good reasons to do this!), you end up paying a steep tax to track
*either* ToT or each release.

In the case of tracking ToT, I think that the cost of dealing with API
changes is tremendously higher than switching to a C++11 supporting
toolchain. (Of course, in aggregate. Each API change may be cheaper, but
they come in such frequency that the total cost seems likely to dwarf that
of the toolchain rev.)


>
> And with my downstream packager hat on, it's frustrating that we don't
> make it easier, because we end up having to make sure that it's possible to
> install half a dozen different versions of LLVM simultaneously because
> there are always some projects that depend on an old one and only have the
> manpower to handle the API churn every few releases - I think we've now
> finally got rid of the ones that depend on LLVM 2.6, but 2.8 is still quite
> popular.
>

Again, I think the API issues are far and away the dominant concerns here.
I'm not trying to say your concern is invalid; while I would pick a
different tradeoff, its still at most a tradeoff and reasonable people can
disagree about the right tradeoff to make. However, even from this
perspective, I feel like the cost and tradeoffs you face with APIs dwarf
those you face with us starting to use C++11. It seems like if this is what
we should be optimizing for, we should start by fixing the API churn issue
and then look at other sources of churn. However, thus far the project has
chosen *not* to optimize for this, and instead to optimize for in-tree
efforts. Using C++11 seems like icing on this cake.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131107/f1708c37/attachment.html>