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

<h2>Abstract</h2>

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

<h2>Concepts</h2>

<p>
  We reviewed <a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1141r1.html">P1141R1</a>, Yet another approach for constrained declarations,
  and approved it. Core moved it in San Diego. In addition, we approved
  <a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0848r0.html">P0848R0</a>, Conditionally Trivial Special Member Functions.
</p>

<p>
  We did not look at <a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0782r2.html">P0782R2</a>, Constraining Concepts Overload Sets, despite
  it being on the agenda.
  This proposal changes dependent calls in constrained
  templates to consider only the overloads that were
  used to satisfy a constraint as viable candidates. We will
  possibly revisit the proposal
  in Kona, as we need to decide the fate of this
  change before C++20 ships.
</p>

<h2>Modules</h2>

<p>
  The merged Modules proposal, <a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1103r1.pdf">P1103R1</a> was approved, with a bunch
  of fixes, including
  <ul>
    <li>Making the module and import keywords context-sensitive</li>
    <li>Support for inline module partitions</li>
    <li>Change to when a module preamble is considered to end</li>
    <li>Fixes to redefinitions in legacy imports</li>
  </ul>
  The global module fragment was not removed, and the paper
  on retiring pernicious language constructs in module contexts
  was rejected.
</p>
<p>
  The plan has been for quite some time to wait until Kona
  before moving Modules, so as to give implementers more time
  to gain implementation experience.
</p>
<h2>Coroutines</h2>

<p>
  We discussed <a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1063r1.pdf">P1063R1</a>, Core Coroutines. Evolution, again, still,
    has consensus (but far from unanimity) to move the merge of
  the Coroutines TS forward.
</p>

<h2>Aggregate initialization</h2>

<p>
  The proposal to allow paren-initializing aggregates,
  <a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0960r1.html">P0960</a>, was approved.
</p>

<h2>Contracts</h2>

<p>
  The change to allow preconditions and postconditions to use
  private mambers, <a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1289r0.pdf">P1289R0</a>, was approved.
</p>
<p>
  We discussed UB and optimizations at quite some length; the work
  on that problem is ongoing, and we'll see more in Kona.
</p>


<h2>Some constexpr extensions</h2>

<p>
  <ul>
    <li><a href=http://wiki.edg.com/pub/Wg21sandiego2018/EvolutionWorkingGroup/P1327R0.html>P1327</a>, allowing dynamic_cast in constant expression
      was approved. It's also possible to use typeid and its
      comparison in constant expressions.</li>
    <li>We approved being able to change the active member of
      a union in constant expressions.</li>
    <li>We approved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1073r2.html">P1073</a>, "consteval".
    <li>We discussed "for..." and "for constexpr". Further work
      is expected with encouragement that we want facilities
      like that.</li>
  </ul>
</p>

<h2>Template argument deduction</h2>

<p>
  We approved fixes that allow CTAD on aggregates,
  alias templates, and using inherited constructors.
</p>

<h2>All Your Spaceships Are Belong to Us</h2>

<p>The papers <a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1185r0.html">P1185</a> and <a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1186r0.html">P1186</a> were approved. We expect further discussion
  on spaceship in Kona.
</p>
<p>
  There was no consensus on making comparison operators chain,
  nor was there encouragement for further work in that area.
</p>

<h2>Structured bindings</h2>

<p>
  We discussed removing the need for tuple_element and
  allowing explicit typing of bindings. There was no consensus
  for either; Pattern Matching can solve the latter problem.
</p>

<h2>Defaulted special member functions and noexcept</h2>

<p>
  We approved <a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1286r0.html">P1286</a>, which changes noexcept on defaulted special
  member functions to no longer require the noexcept-spec to match
  what would've been implicitly generated.
</p>

<h2>Guaranteed constant initialization for non-constexpr
  variables</h2>

<p>
  We discussed <a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1143r0.md">P1143</a>, Adding the [[constinit]] attribute,
  and we expect to see a revision in Kona. The current guidance
  is for a keyword instead of an attribute.
</p>

<h2>Deprecations</h2>

<p>
  Deprecating volatile was discussed; a revised proposal is expected for
  Kona.
</p>
<p>
  <a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1161r0.html">P1161</a>, Deprecate uses of the comma operator in subscripting expressions,
  was approved. This paves the way to multi-argument subscripting. We
  didn't approve making that possible yet, but the deprecation is
  approved.
</p>
</body>

</html>
