C++1z Coroutines a language feature?

Question

Why will coroutines (as of now in the newest drafts for C++1z) be implemented as a core language feature (fancy keywords and all) as opposed to a library extension?

There already exist a couple of implementations for them (Boost.Coroutine, etc), some of which can be made platform independent, from what i have read. Why has the committee decided to bake it into the core language itself?

I'm not saying they shouldn't but Bjarne Stroustrup himself mentioned in some talk (don't know which one any more) that new features should be implemented in libraries as far as possible instead of touching the core language.

So is there a good reason to do so? What are the benefits?

Answer 1

While there are library implementation of coroutines, these tend to have specific restrictions. For example, a library implementation cannot detect what variables need to be maintained when a coroutine is suspended. It is possible to work around this need, e.g., by making the used variables explicit in some form. However, when coroutines should behave like normal functions as much as possible, it should be possible to define local variables.

I don't think any of the implementers of Boost coroutines thinks that their respective library interface is ideal. While it is the best which can be achieved in the currently language, the overall use can be improved.

Answer 2

At CppCon 2015, Gor Nishanov from Microsoft made the argument that C++ Coroutines can be a negative overhead abstraction. The paper from his talk is here.

If you take a look at his example, the ability to use a coroutine simplified the control flow of the network code, and when implemented at the compiler level gives you smaller code that has twice the throughput of the original. He makes the argument that really the ability to yield should be a feature of a C++ function.

They have an initial implementation in Visual Studio 2015, so you can give it a try it out for your use-case and see how it compares to the boost implementation. It looks like they are still trying to hash out if they will use the Async/Yield keywords though, so keep an eye on where the standard goes.

The resumable functions proposal for C++ can be found here and the update here. Unfortunately, it didn't make it into c++17, but is now a technical specification p0057r2. On the upside, it looks like their is support in clang with the -fcoroutines_ts flag and in Visual Studio 2015 Update 2. The keywords also have a co_ prepended to them. So co_await, co_yield etc.

Coroutines are a built in feature in golang, D, python, C#, and will be in the new Javascript standard(ECMA6). If C++ comes up with a more efficient implementation, I wonder if it would displace golang adoption.