<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
        "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
	<title>To boldly suggest an overall plan for C++23</title>

	<style>
	p {text-align:justify}
	li {text-align:justify}
	blockquote.note
	{
		background-color:#E0E0E0;
		padding-left: 15px;
		padding-right: 15px;
		padding-top: 1px;
		padding-bottom: 1px;
	}
	ins {color:#00A000}
	del {color:#A00000}
	</style>
</head>
<body>

<address align=right>
Document number: P0592R2
<br/>
Audience: EWG, LEWG
<br/>
<br/>
<a href="mailto:ville.voutilainen@gmail.com">Ville Voutilainen</a><br/>
2019-08-04<br/>
</address>
<hr/>
<h1 align=center>To boldly suggest an overall plan for C++23</h1>

<p>
  Many thanks to Herb Sutter, Bjarne Stroustrup, and Mike Miller for
  feedback on the early drafts of this proposal.
</p>

<h2>First things first</h2>

<p>
  C++ ships on time.
</p>

<p>
  C++11 shipped late, C++14 shipped on time, C++17 shipped on
  time, C++20 will ship on time, and C++23 will ship on time.
</p>

<p>
  This plan doesn't change any of that. What is ready to ship
  can ship; what is not, will need to take the next train
  or a separate ship vehicle.
</p>

<p>
  If a planned item cannot make it on time, we will postpone it;
  if it's in the Working Draft and deemed not ready, we will
  rip it out and ship the IS on time.
</p>

<h2>Abstract</h2>
<p>
  Various people have lamented our lack of direction, and that we
  don't have a plan for the next standard (or beyond). Since I
  haven't heard anyone promising to propose such a plan, here goes.
  In a nutshell, the plan is thus: for C++23, let's work towards
  having the following things in that standard:
  <ul>
    <li>Library support for coroutines</li>
    <li>Executors</li>
    <li>Networking</li>
    <li>A modular standard library</li>
  </ul>
  Without a particular ship vehicle yet, we should also make progress on
  <ul>
    <li>Reflection</li>
    <li>Pattern matching</li>
  </ul>
  All good? Agreed? Right, carry on. :) In case you want some
  elaboration, read on. I will elaborate on what C++23 Must Focus On
  and things that should progress during the standardization of C++23,
  but do not necessarily need to be in C++23.
</p>

<h2>High-level priority order, see here if you're concerned about issues and bug fixes</h2>

<p>
  The priority order of handling material is thus:
  <ol>
    <li>Material that is mentioned in this plan.</li>
    <li>Bug fixes, integration fixes for/between existing features, and issue processing.</li>
    <li>Material that is not mentioned in this plan.</li>
  </ol>
</p>

<p>
  This means three things:
  <ul>
    <li>Design groups will discuss material in that priority order.</li>
    <li>Design groups will, when sending material forward for wording
      review, designate which bucket the material belongs to.</li>
    <li>Wording review groups can use this priority order and said
      designation to prioritize their own work.</li>
  </ul>
</p>

<p>
  The priority order doesn't mean that bug fixes can't be considered
  before all on-plan material has been completely processed, or that
  off-plan papers can't be looked at while there are open issues.
  It does, however, allow wording-review groups to do issue processing
  even in a face-to-face meeting before looking at an off-plan paper,
  subject to the wording-review group's own prioritization.
</p>

<p>
  Flushing the pipeline of features that we originally targeted
  for C++20 but couldn't make it are either in the boundary
  of (2) and (3), or just in (3), and that seems just fine.
</p>

<h2>C++23 must-work-on-first items</h2>

<h3>Any C++23-era WG21 subgroup meeting works on no other <em>new</em> material until all possible progress on these items is exhausted first</h3>

<p>
  As stated in the abstract, these items are
  <ul>
    <li>Library support for coroutines</li>
    <li>Executors</li>
    <li>Networking</li>
    <li>A modular standard library</li>
  </ul>
  Keen-eyed readers will notice that these are all library facilities,
  and the must-focus-on list contains no language facilities. That's intentional.
</p>

<h3>Library support for coroutines</h3>

<p>
  Coroutines are in C++20. The only problem is that users can't do anything
  with them, because there are no types that are coroutine-aware. It should
  be fairly non-controversial that we need to fix this problem in C++23.
  What exactly are the coroutine-aware types that should ship in C++23 is
  to-be-defined by LEWG, but in general, the expectation would be that
  there are task types that would be plausible, but we should also take
  another hard look at which existing standard types could or should be made
  coroutine-aware. At any rate, the standard library should provide
  some coroutine-supporting types out of the box.
</p>

<h3>Executors</h3>

<p>
  We need executors for half-everything; we need them for networking,
  we probably need them for audio (if we go further in that direction),
  we need them for heterogeneous hardware, we need them for a better
  async, we need them for better task types. We have been working on
  executors for quite a while, and in C++23, we should deliver.
</p>

<h3>Networking</h3>

<p>
  We should lower the barrier of writing networked C++ applications.
  We have a TS, we have years of existing practice, so once the blocker
  item is resolved, we should standardize networking. This shouldn't
  require much more rationale, but once the foundational facilities
  are in the standard library, writing cross-platform http code that
  requires no additional libraries to be built is right around the corner,
  and we should make that possible.
</p>

<h3>A modular standard library</h3>

<p>
  Now that Modules are in C++20, C++23 should ship with a specification
  of how the functionality of the standard library is exposed as modules.
  While there are many arguably important libraries to modularize,
  the standard library is a very significant one, and should allow
  users to reap the benefits of modules.
</p>

<h2>Items that should make progress, but can land later than C++23,
  or can land in a separate ship vehicle</h2>

<h3>Reflection</h3>

<p>
  Reflection has a lot to offer: more powerful generic programming,
  including proxies, adapters, mediators; all sorts of things
  we use separate code generators for, persistence, remoting, glue code
  interfacing with other languages;
  aspect-oriented programming in general; better logging facilities,
  the list(s) go on and on.
</p>
<p>
  Reflection (and code injection) covers a lot of ground, plugging feature
  holes in areas where programmers want and need to use C++, as opposed
  to trying to handle all this functionality with myriad smaller 'hard-coded'
  language extensions.
</p>
<p>
  We have a TS, we have ongoing work for a constexpr-based approach,
  including prototype implementations. We should ship that work for
  the benefit of our user community, but when and in what form is
  not entirely clear yet.
</p>

<h3>Pattern matching</h3>

<p>
  While we often say that C++ needs new control statements like it
  needs a hole in the head, pattern matching shows a lot of promise
  to deliver better filters/chains/selections than what we can
  approximate with pure-library facilities. Pattern matching
  improves type safety by
  making it easier to write type-safe code than writing the
  conventional C-style or traditional-C++-style alternatives.
  Also, it puts the visitor
  pattern out of business in many cases. It's not just another control
  structure; it interacts with the type system.
</p>
<p>
  There's fair amounts of ongoing work in this area, and we should
  give it air time during the C++23 time frame. How to ship it, and
  in what form, is again not entirely clear yet.
</p>

<h2>Where are nex-gen Ranges in this plan?</h2>

<p>
  We could certainly entertain more Actions and Views in the realm
  of Ranges. Whether such material appears for standardization is a bit
  unknown at this point.
</p>

<h2>What about my favorite idea X, Y, foo and bar?</h2>

<p>
  We need a plan on which we focus, to make sure that the important
  things that we need to deliver are delivered. In order to introduce
  new high-priority items into a plan like this, feel free to try
  and convince the committee that your favorite extension
  is
  <ol>
    <li>truly so important that it is either a must-work-on-first item or must-progress item</li>
    <li>a good idea in general.</li>
  </ol>
</p>

</body>
</html>
