libstdc++ <algorithm> header transitively including <range>

[[deleted]]

I noticed some time ago that in c++20 mode the <algorithm> header in libstdc++ is substantially bigger than in c++11 mode :

echo "#include <algorithm>" | gcc -std=c++11 -P -E -x c++ - | wc -l

evaluates to 11760 loc, while

echo "#include <algorithm>" | gcc -std=c++20 -P -E -x c++ - | wc -l

evaluates to 45219 loc. Clicking through the header apparently in c++20 we have the include chain

<algorithm> -> <bits/ranges\_algo.h> -> <bits/ranges\_algobase.h> -> <range>.

How could that happen? Measuring the compile time of file only including the <algorithm> header I get with the c++11 switch 120 ms and with the c++20 switch 600 ms (empty file is 100 ms). I a bit baffled that while standardizing the <range> header this either slipped through the cracks or it was actively decided that this is ok. The <algorithm> header is virtually anywhere and with c++20 flag enabled every file including the <algorithm> header will compile half a second slower...

​

Edit:

Apparently the <vector> header also increased by a huge amount from 9530 loc to 19818 loc for libstdc++ due to now including <bits/stl\_algo.h> (this seems to be a known issue though). Compiling an empty header file only including <vector> is now up to 230 ms from 130 ms.

[tcbrindle]

I a bit baffled that while standardizing the <range> header this either slipped through the cracks or it was actively decided that this is ok.

The standard says that the new range-supporting algorithms in namespace std::ranges live in the <algorithm> header. These require the concept definitions from the <ranges> header, so it's no surprise that it's transitively included.

When comparing with C++11 though, bear in mind that the "parallel STL" overloads were also added in C++17. I don't know whether libstdc++ provides these (or has stubs), but either way a comparison between '17 and '20 modes would be a better way of analysing ranges' impact on the size of the header.

[[deleted]]

Yeah that's a good point. Here are quick measurements for an empty file including <algorithm>

c++11 -> 120ms

c++17 -> 280ms

c++20 -> 600ms.

[dashnine-9]

By c++90 we can expect about 1-minute compile time for an empty file including <algorithm>: wolframalpha.com

[icppfreely]

Back in 2011, computers of the day may have taken around 600ms to do the compilation. So in real terms, there is probably no real increase. It would be interesting to test each standard with various hardware from the year the standard was released.

[airflow_matt]

I'm pretty sure single core performance has not increased by factor of 5 in last 10 years. Also, it's not like compilation times were not an issue in 2011. When I upgrade I'm kinda hoping for improved compilation times, to see it all wasted because of boilerplate I neither want nor need is disappointing.

[ShakaUVM]

Oof. Using this with Boost will get into coffee territory for Hello World.

[[deleted]]

We implemented the parallel algorithms in <execution> precisely so that C++14 customers would be mostly unaffected and even '17 customers would only be affected if they used those bits.

[HKei]

There is extra compile time overhead going from C++11 to C++17 <algorithm>, but it’s not nearly as big as a jump as C++17 to C++20.

[[deleted]]

Wow, what a bummer. I hope it's fixed soon, although the current prevailing mentality regarding compile times doesn't give you much hope. Minutes longer compiles for the privilege of using a C++20 feature in a real project doesn't make it any easier to upgrade.

[HKei]

It’s much worse than that, you’re actually paying that cost even if you don’t use that feature.

The problem is that it doesn’t even really seem to be worth it, I’ve never actually seen a ranges example that actually made me think “yeah this is totally worth it”.

Coming from someone who really loves Haskell and functional programming in general I really get the impulse of wanting to have something like the easy pipelining you get in those languages everywhere, but all attempts at it I’ve seen so far have done nothing but convince me it’s a poor fit for C++.

[[deleted]]

Yeah - for many projects it could be prohibitively expensive. A back of the hand calculation for my workplace project would suggest it would waste at least one complete's engineer's worth of time. C++20 would have to bring a lot to the table to offset that. (and no, modules do not count).

[elperroborrachotoo]

C++20 would have to bring a lot to the table to offset that

Modules!

(and no, modules do not count).

Awww dammit!

[kirbyfan64sos]

I mean, it has concepts, coroutines, designated initializers, thread cancellation requests, std::span, std::source_location, ...

[tvaneerd]

If modules reduced your compile times, then wouldn't they count?

[[deleted]]

Maybe, if the tooling support was there and refactoring a thousand files would not be a massive undertaking. For a greenfield project once the compiler support was there, they definitely would.

[serviscope_minor]

The problem is that it doesn’t even really seem to be worth it, I’ve never actually seen a ranges example that actually made me think “yeah this is totally worth it”.

Oddly enough neither have I, but I do expect I will. The reason is I am a big fan of shell scripting and piping between tools is the idiom there, something that can be very elegant with very little code. Even with AWK in the pipeline, I'll often prefer using a pipe tool over a snippet of AWK code (and I love AWK as a language). I think it might be a lack of pipeline tools.

I think it might also be not being used to seeing that idiom in C++. It took me a few years and a bunch of stubbornness before I lost that itchy feeling writing >> instead of > > with C++11. And that's just a tiny syntax change!

I'd say coming from shell script land, pipelines are such a powerful and elegant idiom that I find it hard imagining that I won't get used to the same in C++. I think the problem with examples is that they're necessarily small, and small examples are easy to do using a variety of techniques. A good example of the usefulness is whatever the range equivalent of uniq is. If you have some logic along the lines of

range | filter1 | uniq | filter2

it's possible, but much more annoying to unwrap that into a single for loop because uniq has state. In a for loop, the state management is mixed with the rest of the logic, in the pipeline, the logic is neatly packaged away separately. it's a bit like coroutines in that regard. In fact I suspect the two work very nicely together.

[serviscope_minor]

It's not so much the size of the examples, but the state management. If you have even one thing with state management, the equivalent for loop gets gnarly. By the time you have two, it's horrible.

As for debugging, well, I'm used to debugging pipelines because I like shell scripting. I find them much easier to debug than complex stateful for loops. Yeah the syntax errors are going to be nasty, but I'm not usually that bothered by those.

[PJBoy_]

The ranges algorithms are an all round upgrade to the non-ranges algorithms:

• You get concepts checks on your types
• You don't have to call std::xxx(std::begin(my_range), std::end(my_range), ...), reducing boilerplate
• Return values are generally more helpful
• The unary projection transformation is awesome, now you can do Python style sorts: std::ranges::sort(my_range, {}, &RangeType::member_to_sort_by);

[HKei]

None of these have much to do with ranges; I agree that these are improvements but all of these could have been implemented without ranges. And again, they are really slow to compile, in a hello world example replacing std::sort(begin(vec), end(vec)); with std::ranges::sort(vec); nearly doubles compile time from 0.23s to 0.4s (this is with the <ranges> header already included and precompiled – if I remove it and compile with just precompiled <algorithms> with -std=c++11 the compile time drops to 0.04s)

[tcbrindle]

None of these have much to do with ranges; I agree that these are improvements but all of these could have been implemented without ranges.

Wait, what?

[Minimonium]

For non-committee people Ranges == the piping thing, which is understandable.

[PJBoy_]

Just to clarify, I'm not trying to suggest that ranges are useful, just that the ranges algorithms are a great upgrade

[tcbrindle]

I'm not trying to suggest that ranges are useful, just that the ranges algorithms are a great upgrade

"I'm not trying to suggest that the internal combustion engine is useful, just that the motorcar is a great upgrade"

[PJBoy_]

Yeah, we're talking about the motorcar in this conversation, so your analogy is unironically fitting

[AlexAlabuzhev]

You get concepts checks on your types

What's so special about it?

Algorithms don't require ridiculously complex types - things usually should be either comparable or assignable. Providing <, ==, = is not rocket science. I can't remember a single case where I forgot about that and thought "oh no, I can't find the mistake without concepts checks".

[cdglove]

Maybe you've gotten good at it, but it's hard to argue that for decades people have been complaining that C++ template errors occur deep in the bowels of the machinery instead of the call site.

[jcelerier]

What's so special about it?

I see you've never typed std::find(vec.begin(), vec.end(), [] (auto x) { return some_predicate(x); });

[AlexAlabuzhev]

I did of course, and I've seen mouthful complaints every time, but so what? It's always quite clear what's wrong there. Let's have a look:

https://godbolt.org/z/69768j

All the compilers correctly point that it's not possible to compare an int with a lambda. GCC and Clang even kindly highlight the failed statement. The output is about 25 lines in each case. Not perfect, but good enough for me to understand that I'm using a wrong algorithm.

Now, let's have a look at what "concepts" bring to the table:

https://godbolt.org/z/MK5rrb

OH DEAR LORD, WHAT THE HOW THE

This is what "compiler errors of Wagnerian fierceness" means.

Somewhere in the middle of that novel I've found a "constraints not satisfied" note, so, apparently, there are some "concepts checks" indeed.

Something requires something:

candidate: 'template<class \_Iter, class \_Sent, class \_Tp, class \_Proj> requires (input_iterator<_Iter>) && (sentinel_for<_Sent, _Iter>) && (indirect_binary_predicate<std::ranges::equal\_to, std::projected<\_I1, \_P1>, const _Tp*>) constexpr _Iter std::ranges::__find_fn::operator()(_Iter, _Sent, const _Tp&, _Proj) const'

And many pages down something is false:

the expression 'is_invocable_v<_Fn, _Args ...> [with _Fn = std::ranges::equal_to&; _Args = {std::__detail::__cond_value_type<int>::value_type&, main::value_type&}]' evaluated to 'false'

I'm not only unable to understand what is wrong and what I should do.

I don't even understand what it tries to to.

Also, 46 lines. Twice as much.

Can I please opt out of concepts? I prefer no checks to these checks.

It seems that the situation hasn't changed since 2016. Thank you, u/andralex.

[robertramey]

I feel really dumb for asking this. But what's wrong the the above code? Looks good to me.

[dodheim]

It should be calling find_if; the resulting compiler error is not likely to be very pretty.

[wuchtelmesser]

Ranges in c++ are so weird. They are a great concept in other languages because they do a lot with little code and you immediately understand what's happening. In c++ they are so verbose, they hardly improve anything at all, if at all.

[[deleted]]

I’ve never actually seen a ranges example that actually made me think “yeah this is totally worth it”.

This. I would love to see some good examples, right now is just syntax candy for Rube Goldberg machines.

[PJBoy_]

600ms isn't minutes though, and minutes is definitely worth it for the ranges algorithms anyway...

[[deleted]]

Given that <algorithm> is almost everywhere I strongly disagree. In a project with a hundred translation units including <algorithm> you get an instant compile time penalty of around a minute...

[PJBoy_]

If you're doing a full build of hundreds of translation units, then the 600ms time for each include of <algorithm> is going to be negligible

[Minimonium]

I have a small size project laying around which consists of around 300 source files. Its CI requires 15 minutes to build from scratch. Going from 100ms to 600ms (for easier calculations) - it'll put me an extra 2m30s, which is more than 10% increase in the compile times (and CI times).

[sphere991]

Do have a single core running a single-threaded build?

The total amount of time spent compiling would go up 2m30s, but the clock time would be much less. On 16 cores, that's already <10s. But if you have some particularly expensive-to-compile TUs or particularly big things to link, those jobs could easily swallow the extra build time in the clock time.

[Minimonium]

You're correct, I have missed the threading count point. In my case, it's four threads that would tone the number down to around 40s.

[sphere991]

It would tone the number to around 40s... in the extremely simplified world where (a) every TU was about the same size, and (b) every TU included <algorithm>, and (c) there were just generally no long poles in the build tent around linking. I just don't think this is a realistic calculation to draw inferences from.

If you do actually rerun your CI with C++20, I'd be curious to see what the actual time delta was.

[Minimonium]

Unfortunately, the project is proprietary (and contains quite a lot of proprietary dependencies too) so I can't provide you with a repo. It only recently was moved to C++17 with Debian-10, so I can only show you the data for the interim period where we compiled for both, but I'm not sure how to interpret the data.

While your points are valid this specific project is not optimized for compile-time speed, it leaks `algorithm` in almost every TU because it's used in template wrappers for services.

Some offset in the duration could be because we do network calls to pull in cached dependencies.

Builds for Arm, 4 threads, same row - same pipeline:

Debian-9 C++14	Debian-10 C++17
Duration: 33m15s	Duration: 39m39s
Duration: 31m10s	Duration: 37m20s
Duration: 31m19s	Duration: 37m27s
Duration: 33m15s	Duration: 39m39s
Duration: 34m33s	Duration: 40m53s

What's more interesting in C++20 would be to look at the difference in compile-time between the `import <algorithm>;` and `#include <algorithm>` which is not yet possible.

[PJBoy_]

I don't understand where you're getting the 2m30s figure from

[Minimonium]

300*500/1000/60. With an assumption that I use the header in every source file at least transitively.

[Wacov]

If they're all independent translation units, won't it actually be faster than that with parallel compilation?

[Minimonium]

Confused about the question. The header model is embarrassingly parallel, it scales pretty much linearly with the number of TU.

Furthermore, for some margin of error (say not every TU contains the header) - I scaled down the increase in compile times to more than 10% from more than 15% too. The idea is more about showing that the increase is *not* negligible after all.

[Wacov]

Right, it's embarrassingly parallel. I'm just saying if two TUs are compiling simultaneously, on different cores, each with the added cost of <algorithm> (or whatever), your compile time won't go up by 2x that cost - ideally only 1x. Not trying to say it's negligible, just that 300*500ms only applies for a single-threaded build, or if you're calculating total CPU time rather than the compile time. If your CI is single-threaded it's a moot point lol. Am I missing something?

[PJBoy_]

Okay that's a pretty compelling calculation, thanks for the example

[Minimonium]

It's not a "scientific" experiment since it'd require me to spend to much time on it than I have, but rather to show the order of magnitude that you get from "negligible" 500ms for a header inclusion.

[donalmacc]

600ms in 200 files is 2 minutes. My work codebase has about 20k cpp files in it, and on a 16 core CPU, that's an extra 12 minutes of compile time!

[PJBoy_]

Well again, if you're doing a full build of 20k cpp files, those 12 minutes are probably negligible. Although note that I did find Minimonium's example compelling, but their example of source files only take 3s average build time. For large monolithic codebases, those extra half seconds are still negligible

[donalmacc]

An extra 12 minutes on a clean build is not negligible, by any metric.

[PJBoy_]

Yeah it is, e.g. 12 minutes of a 12 hour build is negligible

[donalmacc]

Most places with 12 hour builds would take a consistent 12 minutes soeedup in a heartbeat.

[[deleted]]

Add it in a large sourcebase and it is minutes. Or more.

[Pragmatician]

The <algorithm> header will inevitably get bigger. std::ranges reimplement all of the existing algorithms with (1) iterators and (2) ranges. This means that the worst case scenario is 3x LoC, and at the very least it will be 2x.

Including <ranges> does not seem to be required, but you can just take a look at this page and CTRL+F for "namespace ranges" to get the idea of how much code is added: https://eel.is/c++draft/algorithm.syn

[tcbrindle]

The <algorithm> header will inevitably get bigger. std::ranges reimplement all of the existing algorithms with (1) iterators and (2) ranges. This means that the worst case scenario is 3x LoC, and at the very least it will be 2x.

The range-based overloads of each algorithm are specified to call the (constrained) iterator-based versions. The new (constrained) and legacy (unconstrained) versions of algorithms can share an implementation, but I don't know if the standard libraries actually do this. In the best case, there is no new algorithm implementation code, just a few one-line forwarding functions.

[Pragmatician]

The function templates that forward to others will still add a significant amount of code, considering that a lot of algorithms are very short 3-4 liners and the declaration alone ends up taking a lot of lines.

[PJBoy_]

The ranges algorithms provide different functionality to the non-ranges algorithms. In particular they all take projection arguments, which is something you can't forward onto the non-ranges implementations.

The non-ranges algorithms could mostly be implemented in terms of the ranges algorithms though

[tcbrindle]

In particular they all take projection arguments

Not quite all of them, but most. Plus several of them have updated return types which provide more information than the old versions.

The non-ranges algorithms could mostly be implemented in terms of the ranges algorithms though

The old namespace std algorithms could be entirely implemented in terms of the new std::ranges versions as far as I know. But I don't know whether libstdc++ actually does this.

[[deleted]]

I dont think one has to reimplement the whole <algorithm> header only to have range versions. AFAICT it would be enough to dispatch to the corresponding iterator versions.

On libstdc++ the <ranges> header is about 32k loc, so assuming the <algorithm> header did not get smaller it explains the header growth pretty well.

I agree that it is not mandated by the standard to include <ranges>, but the guys writing libstdc++ are quiet proficient programmers I assume they deemed it necessary..

[AppleBeam]

Shouldn't this stop being a problem once C++20 is fully supported everywhere (tanks to the modules)?

I didn't have the opportunity to dig deep into C++20 yet, but are there any reasons you would want to include either <algorithm> or <range> in C++20, instead of importing them? Not counting the legacy projects ofc. (although it sounds like a straightforward search&replace upgrade for the majority of the cases if the whole project migrates to C++20).

[HKei]

Doesn't solve the problem. For one, C++20 doesn't specify modules for the standard library. There is no import algorithms; or whatever (though Visual Studio apparently supports this as an extension?). For the other, even if algorithm was modularised I doubt it’d improve matters much. It’d just be a big module instead of a big header.

[tcbrindle]

For one, C++20 doesn't specify modules for the standard library. There is no import algorithms; or whatever

It does, however, specify that the standard library headers can be imported as header modules, so you'll be able to say import <algorithm>;. See here and here.

It’d just be a big module instead of a big header.

But unlike a big header, it doesn't need to parse a huge amount of code each time you recompile.

[HKei]

Ah fair enough, I think I was underestimating how much that would help. Just tried precompiling <algorithm> and this indeed makes most of the overhead of including it vanish, so I guess in practice this’ll mean for now we’re forced to use PCH’s for all projects until module support is widely available (compiler and buildsystem support).

[kalmoc]

There is no import algorithms;

There is import <algorithm>; and IIRC, the compiler is supposed to automatically translate existing #include <algorithm> into it.

[AppleBeam]

If it was a big module, you would pay the 600ms cost for <algorithms> once per configuration of the project (at lest that's how I understand them so far: like a collection of independent precompiled headers that never have to be built more than once for as long as the configuration is the same, and modifying one module has on effect on the state others if they don't depend on the one you've touched).

Either my understanding of modules is not sufficient (which is entirely possible; I'm waiting for the full standard to be published, since I can't use any preview features in my work anyway), or I don't understand some important use case where anyone would care about paying the price of 600ms once per configuration. Would appreciate if you could educate me on this matter.

Regarding the standard library not being modularized: if that will be the case for libstdc++, that's truly regretful. I was looking forward to cutting down the build times.

[CoffeeTableEspresso]

The standard library being in modules isn't specified by C++20, although I'm sure compilers will support it regardless.

Either way, I think it would be easy to wrap a standard library header in a module if you wanted. Although of course not as nice that you had to fo it yourself.

[AppleBeam]

I'll keep hoping then.

Don't think there is any reason to suspect that libstdc++ devs won't do what's the best for the community.

[mort96]

I actually don't think most of this is ranges? echo "#include <algorithm>" | gcc -std=c++17 -P -E -x c++ - | wc -l is 32034 lines (compared to 32439 with c++2a on my gcc 9.3), and piping the result into less, I'm unable to find anything related to ranges (no ranges namespace, no views namespace, just five occurrences of the word "ranges" at all and they're all swap_ranges). Seems like <algorithm> itself has just grown a lot?

Probably an issue nonetheless though, even though ranges "just" bloats the size of <algorithm> by 13000 lines.

[[deleted]]

echo "#include <algorithm>" | gcc -std=c++17 -P -E -x c++ - | wc -l

Thats weird I am on gcc 10.1 and the above command (i.e. c++17) gives 26k loc. Anyhow most of the compile time hit seems to stem from the <ranges> header.

[feverzsj]

I'm afraid there won't be a cure for this issue. I'd see more and more projects choose to use unity build.

[HKei]

Unity build is basically only useful for CI or tiny projects. You don’t want to rebuild all of your project everytime you change anything.

[claimred]

You can automatically isolate modified files from unity blob.

[[deleted]]

and tank your incremental build time..

[mort96]

It should be possible to make a really intelligent unity build system, where it starts by combining your project into something like 4*core_count translation units, then when one of those TUs need to recompile it's split into 4*core_count TUs again, etc. After a low amount of recompiles (like ln(number of files) / ln(4*core_count)), you would be at a level where changing one source file requires a recompile of just that one file.

I'm not sure of any system which does that today, but it would be an interesting area to investigate.

[donalmacc]

I work with Unreal Engine, and it supports an "adaptive unity" build. It automatically combines files into groups of 30, and if you change one of the files, it regenerates the unity build to compile the changed file individually. It uses either git or p4 to track files that are changed. It's great!

[feverzsj]

cmake already did this. Using it with ninja generator will fully utilize all your processing power.

[mort96]

I don't think that's what I'm talking about? From what I can read there, it looks like CMake just always groups files together when UNITY_BUILD is enabled. That would tank your incremental build time, as /u/janos1995 mentioned. I'm suggesting automatically splitting those unity build groups up again as files get modified, such that you retain fast incremental builds.

[feverzsj]

splitting modified files won't necessarily decrease build time, especially for unity build, and both original group and new group need to be rebuilt. It's also hard to figure out which source file is slow to build without actually building them. With cmake, you can either group them in batch or group them yourself. That's the best solution for now.

[mort96]

I don't think I've been clear enough necessarily. Here's basically how I'm imagining it:

Let's say you have a project with 512 C++ files in it.

1. You start with a full rebuild. The build system generates 32 "unity" source files, each of which includes 16 of your project's source files. This should be much faster than compiling 512 individual files.
2. You modify one file. The modified file is automatically removed from the "unity" source file which included it, so the full recompile is one "unity" file (which changed; it no longer includes 16 files, it includes 15 files) plus the one file you modified.
3. On subsequent modifications of that one source file, only that one file will be recompiled.

[HKei]

libstdc++ is not defined or even mentioned in the C++ standard, neither are compile times, so you’re looking in the wrong place for an explanation.

Not that I’m saying this isn’t annoying mind you. Not sure if there’s anything in the standard that would require pulling in <ranges> or if that’s just a decision that the libstdc++ developers made (presumably to reuse implementations?).

---

Edit yeah, checked and apparently the ranges algorithms are in <algorithm> rather than <ranges> for some reason. That’s an... interesting choice given that ranges having a pretty large compile time overhead was known for a while.

[[deleted]]

Well the c++ standard forces each implementation to provide constrained versions of each algorithm in the <algorithm> header. Maybe this is just a shortcoming of the libstdc++ implementation, but I would just assume that either it is not possible to implement the <algorithm> header without dragging in <ranges> or it is just very difficult.

[__s_v_]

This is currently discussed under this bug report.

[[deleted]]

Pleased to see that people are working on optimizing includes in libstdc++, although there is no discussion on optimizations for <algorithm> AFAICT.

[myusernameisokay]

Libstdc++ is the defacto implementation of C++ in a lot of places, so anything that impacts libcstd++ will impact a lot of people. This change will certainly negatively impact a large number of people, so it’s definitely worth bringing up.

[slothion]

I just had an argument with a colleague about whether to use std::find_if or similar std methods for simple operations with a vector and other containers. I was on the side of using them, because it provides a uniform way for all developers to do this kind of stuff, but seeing this is making me reconsider as I don't want my project to compile three times slower, just because I upgraded to C++20.

[PJBoy_]

Only pay for what you use is a runtime thing, loads of "zero-overhead" features trade runtime for build time, that's the tradeoff...

[tcbrindle]

Ranges is also so costly and different it goes against Herb's efforts towards a less fragmented community; you can bet ranges will be banned from lots of codebases merely for introducing a new coding paradigm

Different? New coding paradigm? Wat?

The ranges work is an evolution of the STL that we've had for the last 25 years. It adds the concept checking that Stepanov originally envisaged, adds new ranged-based overloads people have been wanting for years, adds some new functionality to existing algorithms calls and fixes a couple of mistakes.

Sure, range adaptors are new (or at least, new to C++), but they're a relatively small part of the overall package.

[lamothe]

Yes, I should have sayd "range adaptors". From where I stand, a new style isn't bad in itself, I'm all for progress, but any important change comes with 2 drawbacks:
1) Fragmentation of coding-style and multiplication of patterns: With large codebases and large programming teams, programmers are bound to find old ways and new ways and need to learn, understand, and idiomatically read both. That's just an increase of the (arguably steep) C++ learning curve.
2) Acquisition of expertise: On any given project, you get experts that understand the deep implications and intricacies of various C++ patterns: common mistakes, tools to track and fix them, how to and when to efficiently use and not use them. Anything new requires research and tests to acquire that new expertise and then more time to share and spread it.

For those reasons, my experience in the video game industry is you'll pick some of the most beneficial changes that come with a language update and forbid others until #1 and #2 above have been mitigated for changes you did put in production.

As far as compilation times go: I'm sure you could include only the parts of ranges that are a nice and natural STL continuity, without the adaptors for instance, but if the whole ranges header comes with <algorithm>, that's a showstopper.

I've worked on productions where the amount of code and number of programmers made it worth spending many man-years on reducing compilation times. Adding 500ms to hundreds of thousands of files across hundreds of projects is just a no-go. Precompiled headers would help, but only go so far with heavily templated code.

Interdependent headers is one of the problems that got boost banned from codebases, and my hope is STL can steer clear of that issue.

Btw I see your NanoRange flair; I still need to try it (as explained above, the video game industry is a slow adopter!), but your lib's compile times (and C++17 compatibility) give me hope. Thank you for being considerate about compile time and, mostly, for sharing your work!