<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
  "http://www.w3.org/TR/html4/strict.dtd">
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">

<style type="text/css">

body { color: #000000; background-color: #FFFFFF; }
del { text-decoration: line-through; color: #8B0040; }
ins { text-decoration: underline; color: #005100; }

p.example { margin-left: 2em; }
pre.example { margin-left: 2em; }
div.example { margin-left: 2em; }

code.extract { background-color: #F5F6A2; }
pre.extract { margin-left: 2em; background-color: #F5F6A2;
  border: 1px solid #E1E28E; }

p.function { }
.attribute { margin-left: 2em; }
.attribute dt { float: left; font-style: italic;
  padding-right: 1ex; }
.attribute dd { margin-left: 0em; }

blockquote.std { color: #000000; background-color: #F1F1F1;
  border: 1px solid #D1D1D1;
  padding-left: 0.5em; padding-right: 0.5em; }
blockquote.stddel { text-decoration: line-through;
  color: #000000; background-color: #FFEBFF;
  border: 1px solid #ECD7EC;
  padding-left: 0.5empadding-right: 0.5em; ; }

blockquote.stdins { text-decoration: underline;
  color: #000000; background-color: #C8FFC8;
  border: 1px solid #B3EBB3; padding: 0.5em; }

table { border: 1px solid black; border-spacing: 0px;
  margin-left: auto; margin-right: auto; }
th { text-align: left; vertical-align: top;
  padding-left: 0.8em; border: none; }
td { text-align: left; vertical-align: top;
  padding-left: 0.8em; border: none; }

</style>

<title>A Class for Status and Optional Value</title>
</head>

<body>
<h1>A Class for Status and Optional Value</h1>

<p>
Committee: ISO/IEC JTC1 SC22 WG21 EWG Evolution<br>
Document Number: P0262r0<br>
Date: 2016-02-14<br>
Authors: Lawrence Crowl, Chris Mysen<br>
Reply To: Lawrence Crowl, Lawrence@Crowl.org
</p>

<p>
<a href="#Introduction">Introduction</a><br>
<a href="#Discussion">Discussion</a><br>
<a href="#Solution">Solution</a><br>
<a href="#Examples">Examples</a><br>
<a href="#Revision">Revision History</a><br>
</p>


<h2><a name="Introduction">Introduction</a></h2>

<p>
The current proposal for concurrent queues,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0260r0.html">
P0260r0 C++ Concurrent Queues</a>,
has two separate waiting pop operations,
one with a return value
one with an output reference parameter.
These functions provide essentially the same semantics,
but differ how they signal disappointment.
See
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0157r0.html">P0157r0
Handling Disappointment in C++</a>.
</p>

<blockquote>
<pre>
<code>Value queue::value_pop();
queue_op_status queue::wait_pop(<var>Value</var>&amp;);</code>
</pre>
</blockquote>

<p>
This design has two consequences.
</p>

<ul>
<li><p>
A bad status for <code>value_pop</code> will result in an exception.
</p></li>

<li><p>
Use of the <code>wait_pop</code> operation
requires a <code><var>Value</var></code>
that is essentially default constructible.
</p></li>
</ul>

<p>
Chandler Carruth suggested
having a return value that comprised both status and value.
</p>

<blockquote>
<pre>
<code><var>something</var>&lt;queue_op_status, <var>Value</var>&gt; queue::pop();</code>
</pre>
</blockquote>

<p>
The essential point of the design
is that <code><var>something</var></code> may or may not contain a value,
and that
accessing a non-existent value results in an exception.
</p>

<p>
This design would
normalize the form of the functions,
move exception generation to accessing a non-existent value, and
enable use of types with no default constructor as elements.
</p>

<p>
This paper proposes a mechanism to provide this combined status and value.
While such a proposal could be folded into the queue proposal alone,
the true value of such a mechanism
would be its widespread use throughout the library,
particularly in concurrent data structures
where it is not technically possible
to provide separate access functions for status and value.
Therefore, we should either commit to or abandon such a mechanism.
</p>


<h2><a name="Discussion">Discussion</a></h2>

<p>
The value is clearly related to the class template <code>optional</code>,
as defined by 
<a href="http://www.open-std.org/JTC1/sc22/wg21/docs/papers/2013/n3793.html">
N3793 A proposal to add a utility class to represent optional objects
(Revision 5)</a>.
The problem could be solved
with a tuple of the status and an <code>optional</code>.
That approach would require more verbose code at each use,
which we prefer to avoid.
</p>

<p>
However, the need is almost directly met by
the class template <code>expected</code>,
as defined by 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4109.pdf">
N4109 A proposal to add a utility class to represent expected monad
- Revision 1</a>.
</p>

<p>
In our view, the weakness in the <code>expected</code> proposal
is that you get either a value or an error, but not both.
In the queue proposal,
operations return a status, not an error.
The distinction is that
a queue's inability to deliver a value
is often not an error,
but simply a normal part of interacting with concurrent objects.
For example, <code>try_pop</code>
can return <code>queue_op_status::empty</code>,
which clearly does not indicate an error.
</p>

<p>
The distinction has a design effect
when more than one status may be associated with a value.
For example,
a concurrent queue could provide
both a status indicating success with low contention
and a status indicating success with high contention.
In both cases,
the value alone provides less information.
</p>

<p>
So, we prefer a design in which a status is always provided,
but the value is optional.
Users of the design will need to define which statuses have values.
</p>



<h2><a name="Solution">Solution</a></h2>

<p>
The design is a simpler version of that which appears in 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4109.pdf">
N4109 A proposal to add a utility class to represent expected monad
- Revision 1</a>.
</p>

<p>
The working name for the proposed class is <code>status_value</code>.
</p>

<blockquote>
<pre>
<code>template&lt;typename Status, typename Value&gt; class status_value;</code>
</pre>
</blockquote>

<p>
Construction of a <code>status_value</code>
can be done with or without a value.
</p>

<blockquote>
<pre>
<code>status_value::status_value(Status s);
status_value::status_value(Status s, Value&amp;&amp; v);
status_value::status_value(Status s, const Value&amp; v);</code>
</pre>
</blockquote>

<p>
Construction of <code>status_value</code> must include a status.
</p>

<blockquote>
<pre>
<code>status_value::status_value() = delete;</code>
</pre>
</blockquote>

<p>
A <code>status_value</code> may be moved.
A copy operation would make the type unusable
for non-copyable contained objects,
so we do not provide a copy operation.
</p>

<blockquote>
<pre>
<code>status_value::status_value(status_value&amp;&amp; sv);</code>
</pre>
</blockquote>

<p>
They may be queried for status.
The design assumes that inlining will remove the cost of returning a reference
for cheap copyable types.
</p>

<blockquote>
<pre>
<code>const Status&amp; status_value::status() const;</code>
</pre>
</blockquote>

<p>
They may be queried for whether or not they have a value.
</p>

<blockquote>
<pre>
<code>bool status_value::has_value() const;
status_value::operator bool() const;</code>
</pre>
</blockquote>

<p>
They may provide access to their value.
If they have no value, an exception of type <code>Status</code>,
with the status value passed to the constructor,
is thrown.
</p>

<blockquote>
<pre>
<code>const Value&amp; status_value::value() const;
Value&amp; status_value::value();
const Value&amp; status_value::operator *() const;
Value&amp; status_value::operator *();</code>
</pre>
</blockquote>

<p>
This design enables moving out of the class
by calling <code>std::move</code> on the result of the non-const functions.
</p>


<h2><a name="Examples">Examples</a></h2>

<p>
The outlined solution changes typical code
for the proposed concurrent queue
from
</p>

<blockquote>
<pre>
<code>Value e = q.value_pop();</code>
</pre>
</blockquote>

<p>
into
</p>

<blockquote>
<pre>
<code>Value e = q.value_pop().value();</code>
</pre>
</blockquote>


<p>
and from
</p>

<blockquote>
<pre>
<code>Value e;
queue_op_status s = q.wait_pop(e);
if ( s == queue_op_status::success )
   do_something_with(e);
else
   do_something_else_with(s);</code>
</pre>
</blockquote>

<p>
into
</p>

<blockquote>
<pre>
<code>auto sv = q.wait_pop();
if ( sv.status() == queue_op_status::success )
  do_something_with(sv.value());
else
  do_something_else_with(sv.status());</code>
</pre>
</blockquote>

<p>
or for handling all statuses that have values
</p>

<blockquote>
<pre>
<code>if ( auto sv = q.wait_pop() )
  // Via the implicit conversion to bool, a value is known to be present.
  do_something_with(*sv);
else
  // Via the implicit conversion to bool, a value is known to be absent.
  do_something_else_with(sv.status());</code>
</pre>
</blockquote>

<p>
With both sets of changes,
the handling of disappointment is decided by the caller,
not by the set of operations provided by the queue.
</p>


<h2><a name="Revision">Revision History</a></h2>

<p>
This paper revises N4233 - 2014-10-10 as follows.
</p>

<ul>
<li><p>
Add a reference to
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0157r0.html">P0157r0
Handling Disappointment in C++</a>.
</p></li>
<li><p>
Add a discussion of a tuple of status and optional.
</p></li>
<li><p>
Explicitly avoid copying for <code>status_value</code> objects.
</p></li>
<li><p>
Make the <code>status</code> member function return a reference,
which enables efficient access to non-trivial status objects.
</p></li>
<li><p>
Clarify the mechanism for moving out of a <code>status_value</code>.
</p></li>
<li><p>
Change the running example
to <code>value_pop</code> versus <code>wait_pop</code>,
which is the essential example of different handling of disappointment.
</p></li>
<li><p>
Add clarification of the example using implicit conversion to bool
in a variable declaration in a condition.
</p></li>
</ul>

</body></html>
