Why C++ core language is becoming fused with the standard library?

Question

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".

Disadvantage:

• 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.

Answer 1

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.

Answer 2

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.

Answer 3

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).

Answer 4

C and C++ may be used to write code for things like thermostat controllers, blinkie-light toys, and other devices that don't have any kind of console, file system, or other such features, and may only have a few hundred bytes of RAM available, if that (the code itself is often stored in read-only memory or flash). While it's useful to have the Standard specify how things like console and file I/O should work, there's no reason the language shouldn't be usable to perform tasks that don't require such things, on platforms that don't support them. Separating the libraries from the language makes it easier to identify what parts of the language are "fundamental", and which parts need not be supported on freestanding implementations for platforms where they wouldn't be meaningful or useful.