In my understanding, standard library is a whole separate piece of software than a compiler is. In my opinion, they should be kept separate.

Advantages of this approach pretty much boil down to "they can evolve independently".


  • Some standard library features could be rewritten in more modern core language features to be more consistent. Sometimes it can lead to huge benefits aside from being consistent. Examples can be most of the algorithms in <algorithm> header when ranges arrive. And pretty much any template when concepts arrive.

  • As standard library uses core language features, sometimes it might be hard to "synchronize them", to follow one pattern and not diverge. Also it could create a feature race, e.g. a feature from core language and a feature from standard library that do mostly the same thing might be rivaling each other to get into the standard. An example can be structured binding. Non declarations are not allowed to be a structured binding expression, because std::tie() does the same thing and it is considered that allowing non declaration binding would unnecessarily complicate things. To reach the conclusion, it required some research and time.

  • Some features simply get into in a broken state (may be they were not broken prior to inclusion). An example can be I/O facilities. Now that core language has template parameter packs, it could be possible to write printf() like functions and have type safety as well. There is an implementation of it, called fmt (Disclaimer: I'm not affiliated with them in any way nor have I used it extensively). Also the synchronization with C I/O library is no longer needed.

There might be more, but those are the only ones that were on top of my head.

So, the question is: why standard comittee chose to slowly fuse standard library and core language? Why were not std::tuple<> and std::initializer_list<> (and some other features) added to the core language instead?

An example of fusing is (in)famous conversion to std::initializer_list<>.

e.g.: auto indices{0, 1, 6, 9}; will result in std::initializer_list<int>.

Also, structured binding:

for (const auto& [key, value]: map) {...} will work even though std::pair is a standard library feature.

  • Could it be because the parser must change? – Frank Hileman Jun 26 '17 at 17:32
  • @FrankHileman, I believe it was only issue with folding expressions, I don't remember that being an issue with the features listed above. – Incomputable Jun 26 '17 at 17:34
  • 3
    Why would you want them to "evolve independently"? What benefit does that bring? – Caleth Jun 27 '17 at 12:13
  • @Caleth, they can be tested independently, and merged into the standard when they are ready. Also, bug fixes can come asynchroniously. – Incomputable Jun 27 '17 at 12:20
  • @Incomputable: "std::pair<>'s layout doesn't have to be the same" Actually, that's not true. std::pair is required by the standard to be a struct with publicly accessible members first and second, in that order. As such, it is required to be able to work with structured binding, without having to use the get/tuple_element interface. – Nicol Bolas Jun 29 '17 at 19:19

I don't think there's really any change here.

There have been a few parts of the compiler that required knowledge of the standard library since the very beginning of C++ (well, maybe not the very beginning, but well before the standard anyway).

For example, a number of expressions (e.g., new expressions and dynamic_cast) can throw exceptions whose types are defined in the standard library. Some other expressions can end up calling abort.

The committee does seem to try to keep this sort of thing to a minimum--they only seem to do so when there's strong motivation and seems to be very little other reasonable route to achieving a goal.


It is my understanding that the C++ standards committee follows the rule that anything which can be efficiently implemented in a library, shall be. This policy exists to keep the C++ compilers from becoming more complex than absolutely necessary, and also minimizes the need to introduce new reserved words into the C++ language itself.

C++ is already one of the most difficult programming languages to correctly parse, so anything which makes it more complex only makes the process of ensuring compilers actually parse the language correctly and generate correct code even more difficult than it already is.

Keeping the core C++ language as simple as possible also keeps the task of porting existing implementations of the language to new platforms as simple as possible.

Writing a new C++ compiler from scratch is already a very non-trivial task.


Have a look at Swift. You can do absolutely nothing without the Swift Standard Library, because even things like integers, booleans and so on and their operations are part of the standard library, not part of the language. And that's Ok. It's because there are language and standard library, and together they produce an implementation. (Even 1 + 2 cannot be compiled using the language only).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.