What's (probably) in C++20: Kona Trip Report

[mbozzi]

The recent ISO C++ committee meeting in Kona ended yesterday today. C++20 is now feature-complete.

Most importantly,
- Modules have been merged in!
- Coroutines have been merged in!
Lots of great stuff is on track. C++20 is going to be a major change to the way we use the language.

I'm very excited about the new features, but I'm also worried about the rate of change. It is not modules and coroutines that are the source of my worries. I'm more concerned with the conglomeration of tiny changes. These features will have unintended consequences - they have the potential to make C++ worse in unforeseen ways.

https://www.reddit.com/r/cpp/comments/au0c4x/201902_kona_iso_c_committee_trip_report_c20/

[E0p9LyTq]

- Modules have been merged in!
- Coroutines have been merged in!

Anywhere a noob programmer can get an understanding of what modules and coroutines will do for them? I've searched and searched a bit and the links I have found are more technical than helpful.

[mbozzi]

FurryGuy wrote:

Anywhere a noob programmer can get an understanding of what modules and coroutines will do for them?

The primary goal of modules is to improve library encapsulation. It is essentially an alternative for #include that works at a semantic rather than textual level.

A module describes the interface of a library or subsystem. The basic idea is that a programmer can list the names that comprise that interface, and form a module out of it. Later, that module can be imported elsewhere, to make that interface (and not implementation details) usable in that file.

p0947r1 is titled "Another Take on Modules", or Atom, for short. Atom will probably remain a decent approximation of the final design. In particular, section 2 gives an overview of the feature, including a list of design goals:
https://wg21.link/p0947r1#overview

If you want to play with Modules in some form or another, both GCC and Clang (and MSVC, I think) have experimental support.

Coroutines are a general mechanism for asynchronous programming cooperative multitasking. The core language feature is very low-level, but it will interact nicely with the new functional programming stuff that is being added.

This is the best C++-focused explanation I could find (read the articles in chronological order):
https://lewissbaker.github.io/
See also Wikipedia:
https://en.wikipedia.org/wiki/Coroutine

If you want to play with Coroutines, Clang (and MSVC, I think) has experimental support.

See also this page (some links won't work by design until papers are published):
https://herbsutter.com/2019/02/23/trip-report-winter-iso-c-standards-meeting-kona/

[E0p9LyTq]

If you want to play with Modules in some form or another, both GCC and Clang (and MSVC, I think) have experimental support.

I have played around a few times with the experimental support in MSVC, but I don't quite grasp why modules are better than the current system of includes/etc. from that experience.

Other than less typing of the std library includes, that is.

Regarding coroutines, I looked at the wiki page a couple of days ago and could feel my eyes begin to glaze over. It read as being more than a bit on the arcane technical side.

I guess I will just have to keep on mucking around looking for some more MSVC examples on both modules and coroutines and keep on trying to cram all this information into my aged brain.

For a hobby programming and learning to program can be a bit hard. :)

Thanks for the links, I will go turn up the stove temp and fry my brain for a few days reading this stuff.

[mbozzi]

No problem!
I hope those links help. The design isn't really finished yet, so tutorial material is... sparse, to say the least.

Here's some more documentation about modules too:
https://clang.llvm.org/docs/Modules.html
https://gcc.gnu.org/wiki/cxx-modules

If you're familiar with another programming language with "generators" or "asynchronous functions" or even "first-class continuations" you might be able to learn a bit about coroutines from tutorials on those topics.

[helios]

Coroutines aren't really asynchronous. Coroutines are often used to implement asynchronous I/O mechanisms, but this only works if you already have some way to do non-blocking I/O. You can't turn a blocking function into a non-blocking function using only coroutines, unlike with threads.

[Peter87]

I don't quite grasp why modules are better than the current system of includes/etc.

This is what I view as the main advantages, based on what I have read.

* No need to use header guards.
* No need to split the code into header and source files.
* No need to worry about macros being imported when importing another module.
* You don't accidentally end up relying on headers including more than they are guaranteed to, because modules explicitly list what should be made visible, which makes it much easier to write portable code.
* Modules should also be faster but let's wait and see how that turns out.

Other than less typing of the std library includes, that is.

Why is using modules less typing?

[helios]

Honestly my interest in modules is only proportional to how much they can improve compile times.

[E0p9LyTq]

Peter87 wrote:

Why is using modules less typing?

A trivial example, using headers:

#include <iostream>
#include <string>
#include <vector>
#include <iterator>

int main()
{
   std::vector<std::string> v { "Plato", "Descartes", "Bacon" };
   std::copy(v.crbegin(), v.crend(), std::ostream_iterator<std::string>(std::cout, "\n"));
}

The same example, from MSDN, using modules:

// need to enable C+ Modules (experimental) and use C++17 or latest language standard
// example copied from
// https://blogs.msdn.microsoft.com/vcblog/2017/05/05/cpp-modules-in-visual-studio-2017/

#pragma warning(disable : 5050)  // to disable uncaught_exception warning

import std.core;

#pragma warning(disable : 4996)  // to disable uncaught_exception warning

int main()
{
   std::vector<std::string> v { "Plato", "Descartes", "Bacon" };
   std::copy(v.crbegin(), v.crend(), std::ostream_iterator<std::string>(std::cout, "\n"));
}

Instead of including 4 separate headers the module import is less typing. Not that this is a good example, especially since the current experimental support in VS2017 requires using #pragmas to silence MSVC from complaining.

Peter87 wrote:

This is what I view as the main advantages, based on what I have read.

I'm a nuts & bolts kinda guy. Without actual examples of using modules any write-up is hype. Especially since the standard hasn't been set.

Once C++20 becomes official and there are some real world examples, at cppreference for instance, then I can see the advantages of modules by actual testing.

helios wrote:

Coroutines aren't really asynchronous. Coroutines are often used to implement asynchronous I/O mechanisms, but this only works if you already have some way to do non-blocking I/O. You can't turn a blocking function into a non-blocking function using only coroutines, unlike with threads.

Now THAT explanation helps me to understand the basics of coroutines, without my eyes glazing over. :)

Since I don't have an overwhelming need for asynchronous I/O on a recurring basis no wonder why I had a hard time understanding other, more in-depth, write-ups.

[E0p9LyTq]

helios wrote:

Honestly my interest in modules is only proportional to how much they can improve compile times.

If that is all modules will do I will likely adopt using it. Especially with what I call a large project*.

*for me a large project is several hundred lines of code. At worst my average compile time is in seconds, not hours or days.

The ability to add the equivalent of the standard library headers with a single import statement is for me also rather neat and tidy. No need to worry about missing a header include.

[Peter87]

FurryGuy wrote:

import std.core;

Instead of including 4 separate headers the module import is less typing.

This looks great, but I wonder how this will affect compilation times.

Based on what was written in the trip report it doesn't seem like there is going to be anything like std.core in C++20.

blelbache on reddit wrote:

LEWG also discussed the options for modularizing the standard library in C++20. We decided that for C++20, the best option is to make it possible for traditional #includes to be transparently treated as module imports, and to make each standard library header importable. E.g. in C++20, you can import <vector>; - and of course you can still #include <vector>. In the future, we plan to reorganize the standard library and expose new standard library modules.

[E0p9LyTq]

So....if I read correctly what you wrote, Peter, it looks like the standard is heading the way that MS experimented with -- in the future -- going towards a import std.core; style usage. C++20 will only be a step forward on that journey.

While keeping things backwards compatible with headers.

I can live with that.

If all they do is improve compilation speed, and that is yet to be seen with each compiler's implementation, that makes modules a good start.