Skip to content

Commit 2f0bf64

Browse files
committed
New issue from Hiroaki Ando: Inconsistency between value_or() and error_or() in std::expected
1 parent 99bc97e commit 2f0bf64

File tree

1 file changed

+60
-0
lines changed

1 file changed

+60
-0
lines changed

xml/issue4281.xml

Lines changed: 60 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,60 @@
1+
<?xml version='1.0' encoding='utf-8' standalone='no'?>
2+
<!DOCTYPE issue SYSTEM "lwg-issue.dtd">
3+
4+
<issue num="4281" status="New">
5+
<title>Inconsistency between `value_or()` and `error_or()` in `std::expected`</title>
6+
<section>
7+
<sref ref="[optional.observe]"/>
8+
<sref ref="[expected.object.obs]"/>
9+
</section>
10+
<submitter>Hiroaki Ando</submitter>
11+
<date>27 Jun 2025</date>
12+
<priority>99</priority>
13+
14+
<discussion>
15+
<p>
16+
In <sref ref="[expected.object.obs]"/>/19, the return value of `value_or()`
17+
is specified as follows:
18+
<blockquote>
19+
<i>Returns</i>:
20+
<code>has_value() ? **this : static_cast&lt;T&gt;(std::forward&lt;U&gt;(v))</code>.
21+
</blockquote>
22+
23+
Meanwhile, the return value of `error_or()` is specified as follows (<sref ref="[expected.object.obs]"/>/23):
24+
<blockquote>
25+
<i>Returns</i>:
26+
<code>std::forward&lt;G&gt;(e)</code> if <code>has_value()</code> is <code>true</code>, <code>error()</code> otherwise.
27+
</blockquote>
28+
Since these functions appear to be dual in nature,
29+
it would be preferable to maintain consistent notation.
30+
</p>
31+
<p>
32+
Jonathan adds:
33+
The wording in `expected::error_or` is newer, having been added by
34+
<paper num="P2505R5"/>, and intentionally avoided a conditional expression
35+
(the problems with conditional expressions explained in <paper num="p3177r0"/>
36+
don't actually affect these member functions, due to the non-const prvalue
37+
return type, but determining that there are no pessimized copies in `value_or`
38+
wouldn't be necessary if we didn't specify it with a conditional expression).
39+
The `error_or` wording also avoids using an explicit conversion when the
40+
<i>Mandates</i>: element requires implicit conversion to work anyway.
41+
We might want to rephrase the `value_or` wording to match `error_or`,
42+
or possibly make `value_or` and `error_or` even more explicit:
43+
</p>
44+
<blockquote>
45+
<i>Effects</i>: Equivalent to:
46+
<pre><code>
47+
if (has_value())
48+
return **this;
49+
else
50+
return std::forward&lt;U&gt;(v);
51+
</code></pre>
52+
</blockquote>
53+
</discussion>
54+
55+
<resolution>
56+
<p>
57+
</p>
58+
</resolution>
59+
60+
</issue>

0 commit comments

Comments
 (0)