<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
        "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
	<title>Evolution status after Rapperswil 2018</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: P1018r1
<br/>
Audience: WG21
<br/>
<br/>
<a href="mailto:ville.voutilainen@gmail.com">Ville Voutilainen</a><br/>
2018-06-09<br/>
</address>
<hr/>
<h1 align=center>Evolution status after Rapperswil 2018</h1>

<h2>Abstract</h2>

<p>
  This paper is a collection of items Evolution has worked
  on up to and in the Rapperswil meeting, their status,
  and plans for the future.
</p>

<h2>Concepts</h2>

<p>
  We discussed P0745R1 (Concepts in-place syntax) and
  P1079 (A minimal solution to the concepts syntax problems).
  While there was support for both approaches, we do not
  yet have an agreement on which approach to take.
</p>
<p>
  Additionally, an adjustment was made for concept
  requirement, in how to define the resulting type
  of an expression. That is,
  <pre><code>
      { E } -> Concept&lt;Args...&gt;;      
  </code></pre>
  will use the exact type of E to check the Concept,
  as opposed to convertible types. Convertible types
  can still be checked by adding more constraints to
  the check.
</p>

<p>
  We reviewed P0782R1, Constraining Concepts Overload Sets.
  This proposal changes dependent calls in constrained
  templates to consider only the overloads that were
  used to satisfy a constraint as viable candidates. Further
  work is expected, and we will revisit the proposal
  in San Diego, as we need to decide the fate of this
  change before C++20 ships.
</p>

<h2>Modules</h2>

<p>
  No consensus yet to move a Modules subset forward. A merge
  of ATOM and the Modules TS will be applied to the Modules
  TS Working Draft.
</p>

<h2>Coroutines</h2>

<p>
  We discussed P1063R0, Core Coroutines. Further work
  was encouraged, but we agreed to move the merge of
  the Coroutines TS forward.
</p>

<h2>Feature-testing macros</h2>

<p>
  We approved the proposal to move feature-testing
  macros into the C++20 Working Draft.
</p>

<h2>Aggregate initialization</h2>

<p>
  Aggregate initialization was discussed at length;
  we approved a change that makes class types
  with user-declared constructors non-aggregates. The
  proposal to allow paren-initializing aggregates
  did not reach consensus yet. We expect to do
  a holistic analysis of initialization.
</p>

<h2>Contracts</h2>

<p>
  Contracts were approved, with the knowledge
  that there are still open questions and issues
  about preconditions and postconditions on
  virtual functions.
</p>

<h2>Generalized alias declarations</h2>

<p>
  P0945R0, Generalizing alias declarations was discussed.
  We are not undoing any typename removals; the idea
  is to find a different syntax for generalized alias
  declarations; further work expected for San Diego.
</p>

<h2>Various constexpr extensions</h2>

<p>
  <ul>
    <li>P1002R0, Try-catch blocks in constexpr functions was approved.
      A constexpr function can contain a try-catch, and constant
      evaluation is okay as long as an exception isn't thrown.</li>
    <li>P0784R3, More constexpr containers was approved. Constexpr
      allocations can now migrate to run-time.</li>
    <li>P1073R0, constexpr! functions was approved. This provides
      always-constexpr functions, which are paramount for
      value-based reflection.</li>
    <li>P0595R1, std::is_constant_evaluated() was approved and
      will go to LEWG next. This allows providing different
      code for constexpr evaluation and non-constexpr
      code.</li>
    <li>P1064R0, Allowing Virtual Function Calls in Constant Expressions
      was approved.</li>
    <li>P1077R0, Allowing Virtual Destructors to be "Trivial" was approved.
    </li>
    <li>P1045R0, constexpr Function Parameters was reviewed. Guidance
    was given to explore providing a new syntax for declaring function templates where there are no dependent types.</li>
  </ul>
</p>

<h2>Template argument deduction</h2>

<p>
  P1021R0, Extensions to Class Template Argument Deduction was reviewed.
  Further work is expected for San Diego, no approvals yet.
</p>

<h2>Deducing this</h2>

<p>
  P0847R0, Deducing this was reviewed. The guidance is to
  go for providing a this-type identifier in the same place
  where cv-qualifiers and ref-qualifiers go, and to make
  using an identifier or using traditional this exclusive
  choices.
</p>

<h2>Unreviewed material</h2>

<p>
  We had quite a pile of papers, and didn't get to all
  of them. There are copy elision papers, move relocation,
  a proposal to embed data in a program, a proposal
  to be able to extract an exception from a std::exception_ptr
  without rethrowing, and other such assorted stuff.
</p>
<p>
  We have papers for tweaks for structured bindings, we
  expect to look at all of those in San Diego.
</p>

</body>

</html>
