Topic: Draft proposal: A useful `optional<T&>`
Author: joseph.thomson@gmail.com
Date: Tue, 28 Feb 2017 17:57:35 -0800 (PST)
Raw View
------=_Part_4664_2052418259.1488333455659
Content-Type: multipart/alternative;
boundary="----=_Part_4665_1502083685.1488333455659"
------=_Part_4665_1502083685.1488333455659
Content-Type: text/plain; charset=UTF-8
Given that the auxiliary proposal for "optional references" in N3672
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html> was
not accepted into C++17 (as far as I can tell), I have prepared a draft
proposal (see attached) for an alternative specification of `optional<T&>`
that focuses on the "optional reference" function parameter use case. I
would appreciate any thoughts or feedback.
Regards,
Joseph
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d2b93847-7b95-4ca0-b18e-666c6071e4e5%40isocpp.org.
------=_Part_4665_1502083685.1488333455659
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Given that the auxiliary proposal for "optional refer=
ences" in <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/paper=
s/2013/n3672.html">N3672</a> was not accepted into C++17 (as far as I can t=
ell), I have prepared a draft proposal (see attached) for an alternative sp=
ecification of <span style=3D"font-family: courier new,monospace;">`optiona=
l<T&>`</span> that focuses on the "optional reference" =
function parameter use case. I would appreciate any thoughts or feedback.<b=
r><br>Regards,<br><br>Joseph<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d2b93847-7b95-4ca0-b18e-666c6071e4e5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d2b93847-7b95-4ca0-b18e-666c6071e4e5=
%40isocpp.org</a>.<br />
------=_Part_4665_1502083685.1488333455659--
------=_Part_4664_2052418259.1488333455659
Content-Type: text/html; charset=UTF-8; name=optional-ref.html
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename=optional-ref.html
X-Attachment-Id: 9a3465e9-05b3-4af9-9e31-88b5bc421383
Content-ID: <9a3465e9-05b3-4af9-9e31-88b5bc421383>
<!DOCTYPE html>
<html>
<head>
<title>optional-ref</title>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8" />
<style type=3D"text/css">
/* GitHub stylesheet for MarkdownPad (http://markdownpad.com) */
/* Author: Nicolas Hery - http://nicolashery.com */
/* Version: b13fe65ca28d2e568c6ed5d7f06581183df8f2ff */
/* Source: https://github.com/nicolahery/markdownpad-github */
/* RESET
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D*/
html, body, div, span, applet, object, iframe, h1, h2, h3, h4, h5, h6, p, b=
lockquote, pre, a, abbr, acronym, address, big, cite, code, del, dfn, em, i=
mg, ins, kbd, q, s, samp, small, strike, strong, sub, sup, tt, var, b, u, i=
, center, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, cap=
tion, tbody, tfoot, thead, tr, th, td, article, aside, canvas, details, emb=
ed, figure, figcaption, footer, header, hgroup, menu, nav, output, ruby, se=
ction, summary, time, mark, audio, video {
margin: 0;
padding: 0;
border: 0;
}
/* BODY
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D*/
body {
font-family: Helvetica, arial, freesans, clean, sans-serif;
font-size: 14px;
line-height: 1.6;
color: #333;
background-color: #fff;
padding: 20px;
max-width: 960px;
margin: 0 auto;
}
body>*:first-child {
margin-top: 0 !important;
}
body>*:last-child {
margin-bottom: 0 !important;
}
/* BLOCKS
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D*/
p, blockquote, ul, ol, dl, table, pre {
margin: 15px 0;
}
/* HEADERS
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D*/
h1, h2, h3, h4, h5, h6 {
margin: 20px 0 10px;
padding: 0;
font-weight: bold;
-webkit-font-smoothing: antialiased;
}
h1 tt, h1 code, h2 tt, h2 code, h3 tt, h3 code, h4 tt, h4 code, h5 tt, h5 c=
ode, h6 tt, h6 code {
font-size: inherit;
}
h1 {
font-size: 28px;
color: #000;
}
h2 {
font-size: 24px;
border-bottom: 1px solid #ccc;
color: #000;
}
h3 {
font-size: 18px;
}
h4 {
font-size: 16px;
}
h5 {
font-size: 14px;
}
h6 {
color: #777;
font-size: 14px;
}
body>h2:first-child, body>h1:first-child, body>h1:first-child+h2, body>h3:f=
irst-child, body>h4:first-child, body>h5:first-child, body>h6:first-child {
margin-top: 0;
padding-top: 0;
}
a:first-child h1, a:first-child h2, a:first-child h3, a:first-child h4, a:f=
irst-child h5, a:first-child h6 {
margin-top: 0;
padding-top: 0;
}
h1+p, h2+p, h3+p, h4+p, h5+p, h6+p {
margin-top: 10px;
}
/* LINKS
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D*/
a {
color: #4183C4;
text-decoration: none;
}
a:hover {
text-decoration: underline;
}
/* LISTS
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D*/
ul, ol {
padding-left: 30px;
}
ul li > :first-child,=20
ol li > :first-child,=20
ul li ul:first-of-type,=20
ol li ol:first-of-type,=20
ul li ol:first-of-type,=20
ol li ul:first-of-type {
margin-top: 0px;
}
ul ul, ul ol, ol ol, ol ul {
margin-bottom: 0;
}
dl {
padding: 0;
}
dl dt {
font-size: 14px;
font-weight: bold;
font-style: italic;
padding: 0;
margin: 15px 0 5px;
}
dl dt:first-child {
padding: 0;
}
dl dt>:first-child {
margin-top: 0px;
}
dl dt>:last-child {
margin-bottom: 0px;
}
dl dd {
margin: 0 0 15px;
padding: 0 15px;
}
dl dd>:first-child {
margin-top: 0px;
}
dl dd>:last-child {
margin-bottom: 0px;
}
/* CODE
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D*/
pre, code, tt {
font-size: 12px;
font-family: Consolas, "Liberation Mono", Courier, monospace;
}
code, tt {
margin: 0 0px;
padding: 0px 0px;
white-space: nowrap;
border: 1px solid #eaeaea;
background-color: #f8f8f8;
border-radius: 3px;
}
pre>code {
margin: 0;
padding: 0;
white-space: pre;
border: none;
background: transparent;
}
pre {
background-color: #f8f8f8;
border: 1px solid #ccc;
font-size: 13px;
line-height: 19px;
overflow: auto;
padding: 6px 10px;
border-radius: 3px;
}
pre code, pre tt {
background-color: transparent;
border: none;
}
kbd {
-moz-border-bottom-colors: none;
-moz-border-left-colors: none;
-moz-border-right-colors: none;
-moz-border-top-colors: none;
background-color: #DDDDDD;
background-image: linear-gradient(#F1F1F1, #DDDDDD);
background-repeat: repeat-x;
border-color: #DDDDDD #CCCCCC #CCCCCC #DDDDDD;
border-image: none;
border-radius: 2px 2px 2px 2px;
border-style: solid;
border-width: 1px;
font-family: "Helvetica Neue",Helvetica,Arial,sans-serif;
line-height: 10px;
padding: 1px 4px;
}
/* QUOTES
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D*/
blockquote {
border-left: 4px solid #DDD;
padding: 0 15px;
color: #777;
}
blockquote>:first-child {
margin-top: 0px;
}
blockquote>:last-child {
margin-bottom: 0px;
}
/* HORIZONTAL RULES
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D*/
hr {
clear: both;
margin: 15px 0;
height: 0px;
overflow: hidden;
border: none;
background: transparent;
border-bottom: 4px solid #ddd;
padding: 0;
}
/* TABLES
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D*/
table th {
font-weight: bold;
}
table th, table td {
border: 1px solid #ccc;
padding: 6px 13px;
}
table tr {
border-top: 1px solid #ccc;
background-color: #fff;
}
table tr:nth-child(2n) {
background-color: #f8f8f8;
}
/* IMAGES
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D*/
img {
max-width: 100%
}
</style>
</head>
<body>
<h1>A useful <code>optional<T&></code></h1>
<p>Joseph Thomson <<a href=3D"mailto:&#=
106;oseph.thomson=
4;gmail.com">josep=
8;.thomson@gmai&=
#x6c;.com</a>><br />
1st Draft (1 March 2017)</p>
<h2>Introduction</h2>
<p>The original <code>optional</code> proposal, <a href=3D"http://www.open-=
std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html">N3672</a>, included an =
auxillary proposal for an <code>optional<T&></code> specializatio=
n that ultimately was not accepted into the C++17 standard. This proposal s=
uggests an alternative specification that is geared towards supporting &quo=
t;optional reference" parameters.</p>
<h2>Motivation</h2>
<p>Objects are often passed by <em>value</em> if they are cheap to copy.</p=
>
<pre><code>void f(T t); // pass by value
</code></pre>
<p>They are often passed by <em>const reference</em> if they are expensive =
or impossible to copy.</p>
<pre><code>void f(T const& t); pass by reference
</code></pre>
<p>And <a href=3D"http://en.cppreference.com/w/cpp/utility/optional"><code>=
optional</code></a> can be used to allow either a value or "no value&q=
uot; to be passed.</p>
<pre><code>void f(optional<T> t); // optionally pass by value
</code></pre>
<p>But <code>optional</code> cannot be used to pass parameters by const ref=
erence (the same limitation applies to pass by <em>non-const</em> reference=
).</p>
<pre><code>void f(optional<T const&>); // optionally pass by refe=
rence (illegal!)
</code></pre>
<p>The usual solution is to pass by pointer.</p>
<pre><code>void f(T const* t); // optionally pass by "reference"
</code></pre>
<p>However, this approach has shortcomings:</p>
<ul>
<li><strong>Temporary objects cannot be passed by pointer to const</strong>=
=E2=80=94It is not possible to take the address of an rvalue, so a named te=
mporary must be explicitly created and its address taken.</li>
<li><strong>The calling syntax is not consistent with pass by reference</st=
rong>=E2=80=94An object can be passed directly by reference, while its addr=
ess must be taken using <code>&</code> to pass it by pointer. In partic=
ular, this means that "optional references" of this kind are not =
compatible with generic code that expects pass by value/reference.</li>
<li><strong>It does not convey intent</strong>=E2=80=94Sometimes pointers a=
re assumed to be "not null". It is not explicitly clear that <cod=
e>T*</code> represents an <em>optional</em> parameter and that passing a nu=
ll pointer indicates "no reference".</li>
<li><strong>It is not statically type safe</strong>=E2=80=94Pointers can re=
present many different things. The compiler will allow the result of expres=
sions such as <code>new T</code> or <code>end(c_array)</code> to be passed =
to "optional reference" parameters of this kind, potentially resu=
lting in resource leaks or undefined behaviour.</li>
</ul>
<p>We define <code>optional<T&></code> as an alternative to <code=
>T*</code> that addresses these issues.</p>
<h2>Example</h2>
<p>A function can take an optional parameter <em>by reference</em> using <c=
ode>optional<T&></code>:</p>
<pre><code>void f(optional<int const&> o);
</code></pre>
<p>And can be called with <code>nullopt</code> or a <code>T</code>:</p>
<pre><code>f(nullopt);
f(42);
</code></pre>
<p>An <code>optional<T&></code> behaves like an <code>optional<=
;T></code>:</p>
<pre><code>void f(optional<int const&> o) {
if (o) // contextual conversion to `bool`
if (o =3D=3D 42) // mixed comparison with `T`
int i =3D *o; // access using `*` or `->`
}
</code></pre>
<p>But it cannot be "rebound" to reference another object after c=
onstruction (just like <code>T&</code>):</p>
<pre><code> o =3D i; // error: `operator=3D` is deleted
o =3D nullopt; // error: `operator=3D` is deleted
o.swap(o2); // error: `swap` not defined
o.reset(); // error: `reset` not defined
o.emplace(i); // error: `emplace` not defined
</code></pre>
<h2>Design rationale</h2>
<h3>Initialization from <code>T&&</code></h3>
<p>Initialization from <code>T&&</code> is essential to allow tempo=
raries to be passed to <code>optional<T const&></code> parameters=
.. N3672 disabled construction from <code>T&&</code> to prevent the =
accidental formation of dangling references by programmers who mistakenly e=
xpect <code>optional<T const&></code> to extend the lifetime of t=
emporaries as <code>T const&</code> does.</p>
<pre><code>optional<int const&> o =3D 42; // dangling
</code></pre>
<p>Given that function parameters are the primary use case for <code>option=
al<T&></code>, we feel this is a price worth paying to achieve fu=
nctional parity with <code>T&</code>=E2=80=94especially given that <a h=
ref=3D"http://en.cppreference.com/w/cpp/string/basic_string_view"><code>bas=
ic_string_view</code></a>, a reference-like type with similar semantics, ma=
kes the same compromise with construction from <a href=3D"http://en.cpprefe=
rence.com/w/cpp/string/basic_string"><code>basic_string</code></a>.</p>
<pre><code>string_view s =3D "hello, world"s; // dangling
</code></pre>
<h3>Copy assignment</h3>
<p>N3672 discussed how the semantics of copy assignment for <code>optional&=
lt;T&></code> proved controversial, noting that both value and refer=
ence semantics seem to be equally valid models. They ultimately chose <em>r=
eference</em> semantics, copying the behaviour of <a href=3D"http://en.cppr=
eference.com/w/cpp/utility/functional/reference_wrapper"><code>reference_wr=
apper</code></a> and <a href=3D"http://www.boost.org/doc/libs/release/libs/=
optional/doc/html/index.html"><code>boost::optional</code></a>. They mentio=
ned that most people insisted that <code>optional<T&></code> be c=
opy assignable, although no rationale was given. We have decided instead to=
<em>disable</em> copy assignment of <code>optional<T&></code>.</=
p>
<p>A copy assignment operation, <code>a =3D b</code>, where <code>a</code> =
and <code>b</code> are of type <code>optional<T></code>, is enabled i=
f <code>T</code> is both copy constructible and copy assignable, and has th=
e following behaviour:</p>
<ul>
<li>
If <code>a</code> contains no value and
<ul>
<li><code>b</code> contains no value, then nothing happens.</li>
<li><code>b</code> contains a value, then the value contained in <code>a</c=
ode> is initialized from <code>*b</code>.</li>
</ul>
</li>
<li>
If <code>a</code> contains a value and
<ul>
<li><code>b</code> contains no value, then the value contained in <code>a</=
code> is destroyed.</li>
<li><code>b</code> contains a value, then the value contained in <code>a</c=
ode> is assigned from <code>*b</code>.</li>
</ul>
</li>
</ul>
<p>Under this definition, copy assignment of <code>optional<T&></=
code> would be enabled, but because initialization and assignment of <code>=
T&</code> have <em>reference</em> and <em>value</em> semantics respecti=
vely, its semantics would depend on the initial value of <code>a</code>. Sp=
ecifically, <code>a</code> will be set to reference whatever <code>b</code>=
references (reference semantics), <em>unless</em> both <code>a</code> and =
<code>b</code> contain a value, in which case <code>a =3D b</code> will be =
equivalent to <code>*a =3D *b</code> (value semantics). Given that such irr=
egular behaviour is undesirable, we have two options:</p>
<ol>
<li>Specialize the behaviour of copy assignment of <code>optional<T&=
></code></li>
<li>Disable copy assignment of <code>optional<T&></code></li>
</ol>
<p>Contrary to N3672, we can't see how it is possible to specify value sema=
ntics for <code>optional<T&></code> when there is no underlying o=
bject to which to copy if <code>a</code> contains no value; reference seman=
tics seem to be the only viable option. However, we suggest that users may =
expect <code>optional<T&></code> to be semantically similar to <c=
ode>T&</code>, given that <code>optional<T></code> is otherwise s=
emantically similar to <code>T</code>. Since this is not possible, we belie=
ve it is better to disable copy assignment altogether than to specify diffe=
rent and potentially surprising behaviour. We cite the <a href=3D"https://i=
socpp.org/blog/2012/11/on-vectorbool">problems</a> caused by <a href=3D"htt=
p://en.cppreference.com/w/cpp/container/vector"><code>vector<bool></c=
ode></a> as an example of how specializing behaviour in "clever" =
ways can cause significant pain.</p>
<p>There may be some concern that disabling copy assignment means that <cod=
e>optional<T&></code> is not <em>regular</em> and therefore inter=
operates poorly with algorithms and containers. However, the role of a regu=
lar "optional reference" type is already filled by <code>optional=
<reference_wrapper<T>></code>, which has reference copy assignm=
ent semantics <em>and</em> prohibits construction from <code>T&&</c=
ode>. Moreover, it has a semi-regular non-optional counterpart (<code>refer=
ence_wrapper<T></code>), whereas <code>optional<T&></code> =
does not (<code>T&</code> is not even an object type). We feel it is mo=
re productive to design <code>optional<T&></code> to address an u=
nsolved use-case ("optional reference" parameters) than to try an=
d force regularity for regularity's sake.</p>
</body>
</html>
<!-- This document was created with MarkdownPad, the Markdown editor for Wi=
ndows (http://markdownpad.com) -->
------=_Part_4664_2052418259.1488333455659--
.
Author: Vishal Oza <vickoza@gmail.com>
Date: Tue, 28 Feb 2017 20:34:40 -0800 (PST)
Raw View
------=_Part_10212_1511213382.1488342881082
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I really do not like the optional syntax. I think is adds more to the run t=
ime without reason. While I like references in general, i think putting the=
m within optional syntax is bad. To use a reference the object must exist =
first. To use optional should you have to first create an object that you w=
ill never use just to use optional syntax? I would rather compare agianst n=
ullptr for optional arguments, since nullptr can be campared against both r=
aw and smart pointers. Yes raw pointers have used in classic c/c++ code but=
I believe that these code bases will be retied soon. I think optional synt=
ax may cause people to overthink about how to use optional.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/d8aad9b7-8f68-4ed8-bdf2-dcc3fffb7ab9%40isocpp.or=
g.
------=_Part_10212_1511213382.1488342881082--
.
Author: joseph.thomson@gmail.com
Date: Tue, 28 Feb 2017 21:04:05 -0800 (PST)
Raw View
------=_Part_9467_1781134499.1488344645523
Content-Type: multipart/alternative;
boundary="----=_Part_9468_1364047618.1488344645523"
------=_Part_9468_1364047618.1488344645523
Content-Type: text/plain; charset=UTF-8
On Wednesday, 1 March 2017 12:34:41 UTC+8, Vishal Oza wrote:
>
> I really do not like the optional syntax.
Why?
> I think is adds more to the run time without reason.
What does it add to the run-time? Most likely `optional<T&>` would be
implemented using a single `T*`, so it should have zero run-time overhead
compared to raw pointers.
> While I like references in general, i think putting them within optional
> syntax is bad. To use a reference the object must exist first. To use
> optional should you have to first create an object that you will never use
> just to use optional syntax?
I am unsure what you are saying here. You have to have an object with which
to construct either `T&` *or* `optional<T&>`. In fact, one of the
advantages of `optional<T const&>` over `T const*` is that you don't have
to create a named temporary.
> I would rather compare agianst nullptr for optional arguments, since
> nullptr can be campared against both raw and smart pointers.
I don't know what smart pointers have to do with this. `optional<T>` uses
`nullopt` for good reason
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html#rationale.no_nullptr>.
Similar reasoning applies to `optional<T&>`.
> Yes raw pointers have used in classic c/c++ code but I believe that these
> code bases will be retied soon.
Is this an argument for or against using raw pointers instead of
`optional<T&>`??
I think optional syntax may cause people to overthink about how to use
> optional.
I think it's pretty simple: use `T` to pass by value and `T&` to pass by
reference; use `optional` if the parameter is not mandatory. These are two
simple rules that can be taught independently of each other. If
`optional<T&>` is not supported then you have to teach an extra
special-case rule that `T*` should be used if you want to pass by reference
*and* the parameter is not mandatory, and the rules are now interdependent.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4d6c3771-30ab-402a-8508-4a3ec389deda%40isocpp.org.
------=_Part_9468_1364047618.1488344645523
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, 1 March 2017 12:34:41 UTC+8, Vishal Oza wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">I really do not like the op=
tional syntax.</blockquote><div><br>Why?<br>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">I think is adds more to the run time without re=
ason.</blockquote><div><br>What does it add to the run-time? Most likely <s=
pan style=3D"font-family: courier new,monospace;">`optional<T&>`<=
/span> would be implemented using a single <span style=3D"font-family: cour=
ier new,monospace;">`T*`</span>, so it should have zero run-time overhead c=
ompared to raw pointers.<br>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;">While I like references in general, i think putting them within o=
ptional syntax is bad. To use a reference the object =C2=A0must exist first=
.. To use optional should you have to first create an object that you will n=
ever use just to use optional syntax?</blockquote><div><br>I am unsure what=
you are saying here. You have to have an object with which to construct ei=
ther <span style=3D"font-family: courier new,monospace;">`T&`</span> <i=
>or</i> <span style=3D"font-family: courier new,monospace;">`optional<T&=
amp;>`</span>. In fact, one of the advantages of <span style=3D"font-fam=
ily: courier new,monospace;">`optional<T const&>`</span> over <sp=
an style=3D"font-family: courier new,monospace;">`T const*`</span> is that =
you don't have to create a named temporary.<br>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;">I would rather compare agianst nullptr for=
optional arguments, since nullptr can be campared against both raw and sma=
rt pointers.</blockquote><div><br>I don't know what smart pointers have=
to do with this. <span style=3D"font-family: courier new,monospace;">`opti=
onal<T>`</span> uses <span style=3D"font-family: courier new,monospac=
e;">`nullopt`</span> for <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/=
docs/papers/2013/n3672.html#rationale.no_nullptr">good reason</a>. Similar =
reasoning applies to <span style=3D"font-family: courier new,monospace;">`o=
ptional<T&>`</span>.<br>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;">Yes raw pointers have used in classic c/c++ code but I beli=
eve that these code bases will be retied soon.</blockquote><div><br>Is this=
an argument for or against using raw pointers instead of <span style=3D"fo=
nt-family: courier new,monospace;">`optional<T&>`</span>??<br><br=
></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I think optional syntax=
=C2=A0may cause people to overthink about how to use optional.</blockquote=
><div><br>I think it's pretty simple: use <span style=3D"font-family: c=
ourier new,monospace;">`T`</span> to pass by value and <span style=3D"font-=
family: courier new,monospace;">`T&`</span> to pass by reference; use <=
span style=3D"font-family: courier new,monospace;">`optional`</span> if the=
parameter is not mandatory. These are two simple rules that can be taught =
independently of each other. If <span style=3D"font-family: courier new,mon=
ospace;">`optional<T&>`</span> is not supported then you have to =
teach an extra special-case rule that <span style=3D"font-family: courier n=
ew,monospace;">`T*`</span> should be used if you want to pass by reference =
<i>and</i> the parameter is not mandatory, and the rules are now interdepen=
dent.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4d6c3771-30ab-402a-8508-4a3ec389deda%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4d6c3771-30ab-402a-8508-4a3ec389deda=
%40isocpp.org</a>.<br />
------=_Part_9468_1364047618.1488344645523--
------=_Part_9467_1781134499.1488344645523--
.
Author: Barry Revzin <barry.revzin@gmail.com>
Date: Wed, 1 Mar 2017 06:08:47 -0800 (PST)
Raw View
------=_Part_510_1879991429.1488377328154
Content-Type: multipart/alternative;
boundary="----=_Part_511_1382541539.1488377328154"
------=_Part_511_1382541539.1488377328154
Content-Type: text/plain; charset=UTF-8
On Tuesday, February 28, 2017 at 7:57:35 PM UTC-6, joseph....@gmail.com
wrote:
>
> Given that the auxiliary proposal for "optional references" in N3672
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html> was
> not accepted into C++17 (as far as I can tell), I have prepared a draft
> proposal (see attached) for an alternative specification of `optional<T&>`
> that focuses on the "optional reference" function parameter use case. I
> would appreciate any thoughts or feedback.
>
> Regards,
>
> Joseph
>
You have an example with:
void f(optional<int const&> );
f(42);
This basically guarantees a dangling reference, as the 42 is going to be
pound to optional's constructor and then you're taking a pointer to that
parameter, which dies at the end of the constructor. For optional<T
const&>, you definitely need to delete the T const&& constructor as well as
the U&& constructor.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3613efa7-0853-4040-b04c-f299176c45fe%40isocpp.org.
------=_Part_511_1382541539.1488377328154
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, February 28, 2017 at 7:57:35 PM UTC-6,=
joseph....@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr">Given that the auxiliary proposal for "optional referen=
ces" in <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/=
2013/n3672.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.hre=
f=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc=
1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3672.html\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNGv3DoyO1iTWrxSaNDwbFdsywM-SA';return true;" onclick=3D=
"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.=
org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3672.html\x26sa\x3dD\x26=
sntz\x3d1\x26usg\x3dAFQjCNGv3DoyO1iTWrxSaNDwbFdsywM-SA';return true;">N=
3672</a> was not accepted into C++17 (as far as I can tell), I have prepare=
d a draft proposal (see attached) for an alternative specification of <span=
style=3D"font-family:courier new,monospace">`optional<T&>`</span=
> that focuses on the "optional reference" function parameter use=
case. I would appreciate any thoughts or feedback.<br><br>Regards,<br><br>=
Joseph<br></div></blockquote><div><br></div><div>You have an example with:<=
br></div><div><br></div><div><div class=3D"prettyprint" style=3D"background=
-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style:=
solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettypri=
nt"><div class=3D"subprettyprint"><font color=3D"#660066"><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">optional</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify"><</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">const<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">&></=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>f</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #06=
6;" class=3D"styled-by-prettify">42</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">);</span></font></div></code></div><br>This basica=
lly guarantees a dangling reference, as the 42 is going to be pound to opti=
onal's constructor and then you're taking a pointer to that paramet=
er, which dies at the end of the constructor. For optional<T const&&=
gt;, you definitely need to delete the T const&& constructor as wel=
l as the U&& constructor.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3613efa7-0853-4040-b04c-f299176c45fe%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3613efa7-0853-4040-b04c-f299176c45fe=
%40isocpp.org</a>.<br />
------=_Part_511_1382541539.1488377328154--
------=_Part_510_1879991429.1488377328154--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 1 Mar 2017 22:20:47 +0800
Raw View
--Apple-Mail=_EA207B1B-B462-4DCB-B071-8873CDF32975
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2017=E2=80=9303=E2=80=9301, at 10:08 PM, Barry Revzin <barry.revzin@gm=
ail.com> wrote:
>=20
> You have an example with:
>=20
> void f(optional<int const&> );
> f(42);
>=20
> This basically guarantees a dangling reference, as the 42 is going to be =
pound to optional's constructor and then you're taking a pointer to that pa=
rameter, which dies at the end of the constructor. For optional<T const&>, =
you definitely need to delete the T const&& constructor as well as the U&& =
constructor.
The parameter lives through the full-expression. No lifetime extension is i=
nvolved in passing 42 to int const&, and passing it to optional<int const&>=
works just the same.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/70BDF548-9A7A-4B87-A3FA-021CD18AD62D%40gmail.com=
..
--Apple-Mail=_EA207B1B-B462-4DCB-B071-8873CDF32975
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2017=E2=80=9303=
=E2=80=9301, at 10:08 PM, Barry Revzin <<a href=3D"mailto:barry.revzin@g=
mail.com" class=3D"">barry.revzin@gmail.com</a>> wrote:</div><br class=
=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">=
You have an example with:<br class=3D""><div class=3D""><br class=3D""></di=
v><div class=3D""><div class=3D"prettyprint" style=3D"background-color: rgb=
(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bor=
der-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div cl=
ass=3D"subprettyprint"><font color=3D"#660066" class=3D""><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">void</span><span style=3D"" class=
=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(</span><span style=3D"" class=3D"styled-by-prettify">optio=
nal</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><sp=
an style=3D"" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">const</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">&></span><span style=3D"" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">);</span><span style=3D"" class=3D"styled-by-prettify"><br class=3D"=
">f</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span style=3D"color: #066;" class=3D"styled-by-prettify">42</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">);</span></font></div></=
code></div><br class=3D"">This basically guarantees a dangling reference, a=
s the 42 is going to be pound to optional's constructor and then you're tak=
ing a pointer to that parameter, which dies at the end of the constructor. =
For optional<T const&>, you definitely need to delete the T const=
&& constructor as well as the U&& constructor.<br class=3D"=
"></div></div></div></blockquote><br class=3D""></div><div>The parameter li=
ves through the full-expression. No lifetime extension is involved in passi=
ng <font face=3D"Courier" class=3D"">42</font> to <font face=3D"Courier" cl=
ass=3D"">int const&</font>, and passing it to <font face=3D"Courier" cl=
ass=3D"">optional<int const&></font> works just the same.</div><d=
iv><br class=3D""></div></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/70BDF548-9A7A-4B87-A3FA-021CD18AD62D%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/70BDF548-9A7A-4B87-A3FA-021CD18AD62D%=
40gmail.com</a>.<br />
--Apple-Mail=_EA207B1B-B462-4DCB-B071-8873CDF32975--
.
Author: Barry Revzin <barry.revzin@gmail.com>
Date: Wed, 1 Mar 2017 07:17:28 -0800 (PST)
Raw View
------=_Part_10594_863605677.1488381448746
Content-Type: multipart/alternative;
boundary="----=_Part_10595_611179136.1488381448746"
------=_Part_10595_611179136.1488381448746
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, March 1, 2017 at 8:20:53 AM UTC-6, David Krauss wrote:
>
>
> On 2017=E2=80=9303=E2=80=9301, at 10:08 PM, Barry Revzin <barry....@gmail=
..com=20
> <javascript:>> wrote:
>
> You have an example with:
>
> void f(optional<int const&> );
> f(42);
>
> This basically guarantees a dangling reference, as the 42 is going to be=
=20
> pound to optional's constructor and then you're taking a pointer to that=
=20
> parameter, which dies at the end of the constructor. For optional<T=20
> const&>, you definitely need to delete the T const&& constructor as well =
as=20
> the U&& constructor.
>
>
> The parameter lives through the full-expression. No lifetime extension is=
=20
> involved in passing 42 to int const&, and passing it to optional<int=20
> const&> works just the same.
>
>
Which may be fine if the full-expression happens to encompass the lifetime=
=20
of the optional (hopefully f() doesn't store it somewhere!) But then:
optional<int const&> o =3D 42;
Now any subsequent use of o is outside of that full expression that=20
encompasses the lifetime of 42.=20
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/79f42718-4442-4a2a-a394-43924712f142%40isocpp.or=
g.
------=_Part_10595_611179136.1488381448746
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, March 1, 2017 at 8:20:53 AM UTC-6, D=
avid Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=
=3D"word-wrap:break-word"><br><div><blockquote type=3D"cite"><div>On 2017=
=E2=80=9303=E2=80=9301, at 10:08 PM, Barry Revzin <<a href=3D"javascript=
:" target=3D"_blank" gdf-obfuscated-mailto=3D"K8rYLnavCQAJ" rel=3D"nofollow=
" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D=
"this.href=3D'javascript:';return true;">barry....@gmail.com</a>>=
; wrote:</div><br><div><div dir=3D"ltr">You have an example with:<br><div><=
br></div><div><div style=3D"background-color:rgb(250,250,250);border-color:=
rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word">=
<code><div><font color=3D"#660066"><span style=3D"color:#008">void</span><s=
pan> f</span><span style=3D"color:#660">(</span><span>optional</span><span =
style=3D"color:#660"><</span><span style=3D"color:#008">int</span><span>=
</span><span style=3D"color:#008">const</span><span style=3D"color:#660">&=
amp;></span><span> </span><span style=3D"color:#660">);</span><span><br>=
f</span><span style=3D"color:#660">(</span><span style=3D"color:#066">42</s=
pan><span style=3D"color:#660">);</span></font></div></code></div><br>This =
basically guarantees a dangling reference, as the 42 is going to be pound t=
o optional's constructor and then you're taking a pointer to that p=
arameter, which dies at the end of the constructor. For optional<T const=
&>, you definitely need to delete the T const&& constructor =
as well as the U&& constructor.<br></div></div></div></blockquote><=
br></div><div>The parameter lives through the full-expression. No lifetime =
extension is involved in passing <font face=3D"Courier">42</font> to <font =
face=3D"Courier">int const&</font>, and passing it to <font face=3D"Cou=
rier">optional<int const&></font> works just the same.</div><div>=
<br></div></div></blockquote><div><br></div><div>Which may be fine if the f=
ull-expression happens to encompass the lifetime of the optional (hopefully=
<font face=3D"courier new, monospace">f()</font> doesn't store it some=
where!) But then:</div><div><br></div><div><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><font color=3D"#660066"><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">optional</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">const</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">&></span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> o </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify=
">42</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</spa=
n></font></div></code></div><br>Now any subsequent use of <font face=3D"cou=
rier new, monospace">o</font> is outside of that full expression that encom=
passes the lifetime of <font face=3D"courier new, monospace">42</font>.=C2=
=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/79f42718-4442-4a2a-a394-43924712f142%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/79f42718-4442-4a2a-a394-43924712f142=
%40isocpp.org</a>.<br />
------=_Part_10595_611179136.1488381448746--
------=_Part_10594_863605677.1488381448746--
.
Author: joseph.thomson@gmail.com
Date: Wed, 1 Mar 2017 07:34:06 -0800 (PST)
Raw View
------=_Part_10553_1182610767.1488382446729
Content-Type: multipart/alternative;
boundary="----=_Part_10554_1655420684.1488382446729"
------=_Part_10554_1655420684.1488382446729
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, 1 March 2017 23:17:29 UTC+8, Barry Revzin wrote:
>
>
>
> On Wednesday, March 1, 2017 at 8:20:53 AM UTC-6, David Krauss wrote:
>>
>>
>> On 2017=E2=80=9303=E2=80=9301, at 10:08 PM, Barry Revzin <barry....@gmai=
l.com> wrote:
>>
>> You have an example with:
>>
>> void f(optional<int const&> );
>> f(42);
>>
>> This basically guarantees a dangling reference, as the 42 is going to be=
=20
>> pound to optional's constructor and then you're taking a pointer to that=
=20
>> parameter, which dies at the end of the constructor. For optional<T=20
>> const&>, you definitely need to delete the T const&& constructor as well=
as=20
>> the U&& constructor.
>>
>>
>> The parameter lives through the full-expression. No lifetime extension i=
s=20
>> involved in passing 42 to int const&, and passing it to optional<int=20
>> const&> works just the same.
>>
>>
> Which may be fine if the full-expression happens to encompass the lifetim=
e=20
> of the optional (hopefully f() doesn't store it somewhere!) But then:
>
> optional<int const&> o =3D 42;
>
> Now any subsequent use of o is outside of that full expression that=20
> encompasses the lifetime of 42.
>
I address this in the "Design rationale" section of the proposal. I believe=
=20
that this is a price worth paying to allow temporaries to be passed to `opt=
ional<T=20
const&>` parameters. I note that `string_view` , set for standardization in=
=20
C++17, sets precedent by making the very same compromise:
string_view s =3D "hello, world"s; // dangling
Also, now that I think of it, this issue is likely to be addressed in the=
=20
future by the lifetime extension proposal=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0066r0.pdf>=20
(which mentions the `string_view` issue as a motivating example). I should=
=20
probably add this comment to the proposal.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/461d5582-b67d-4ec7-b195-7c5e8fbddbb1%40isocpp.or=
g.
------=_Part_10554_1655420684.1488382446729
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, 1 March 2017 23:17:29 UTC+8, Barry Revzin w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><br>=
On Wednesday, March 1, 2017 at 8:20:53 AM UTC-6, David Krauss wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><br><d=
iv><blockquote type=3D"cite"><div>On 2017=E2=80=9303=E2=80=9301, at 10:08 P=
M, Barry Revzin <<a rel=3D"nofollow">barry....@gmail.com</a>> wrote:<=
/div><br><div><div dir=3D"ltr">You have an example with:<br><div><br></div>=
<div><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,1=
87,187);border-style:solid;border-width:1px;word-wrap:break-word"><code><di=
v><font color=3D"#660066"><span style=3D"color:#008">void</span><span> f</s=
pan><span style=3D"color:#660">(</span><span>optional</span><span style=3D"=
color:#660"><</span><span style=3D"color:#008">int</span><span> </span><=
span style=3D"color:#008">const</span><span style=3D"color:#660">&><=
/span><span> </span><span style=3D"color:#660">);</span><span><br>f</span><=
span style=3D"color:#660">(</span><span style=3D"color:#066">42</span><span=
style=3D"color:#660">);</span></font></div></code></div><br>This basically=
guarantees a dangling reference, as the 42 is going to be pound to optiona=
l's constructor and then you're taking a pointer to that parameter,=
which dies at the end of the constructor. For optional<T const&>=
, you definitely need to delete the T const&& constructor as well a=
s the U&& constructor.<br></div></div></div></blockquote><br></div>=
<div>The parameter lives through the full-expression. No lifetime extension=
is involved in passing <font face=3D"Courier">42</font> to <font face=3D"C=
ourier">int const&</font>, and passing it to <font face=3D"Courier">opt=
ional<int const&></font> works just the same.</div><div><br></div=
></div></blockquote><div><br></div><div>Which may be fine if the full-expre=
ssion happens to encompass the lifetime of the optional (hopefully <font fa=
ce=3D"courier new, monospace">f()</font> doesn't store it somewhere!) B=
ut then:</div><div><br></div><div><div style=3D"background-color:rgb(250,25=
0,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px;wo=
rd-wrap:break-word"><code><div><font color=3D"#660066"><span style=3D"color=
:#000">optional</span><span style=3D"color:#660"><</span><span style=3D"=
color:#008">int</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#008">const</span><span style=3D"color:#660">&></span><span style=
=3D"color:#000"> o </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> </span><span style=3D"color:#066">42</span><span style=3D"=
color:#660">;</span></font></div></code></div><br>Now any subsequent use of=
<font face=3D"courier new, monospace">o</font> is outside of that full exp=
ression that encompasses the lifetime of <font face=3D"courier new, monospa=
ce">42</font>.</div></div></blockquote><div><br>I address this in the "=
;Design rationale" section of the proposal. I believe that this is a p=
rice worth paying to allow temporaries to be passed to <span style=3D"font-=
family: courier new,monospace;">`optional<T const&>`</span> param=
eters. I note that <span style=3D"font-family: courier new,monospace;">`str=
ing_view`</span> , set for standardization in C++17, sets precedent by maki=
ng the very same compromise:<br><br><div style=3D"background-color: rgb(250=
, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-=
width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;"=
class=3D"styled-by-prettify">string_view s </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"st=
yled-by-prettify">"hello, world"</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">s</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pret=
tify">// dangling</span></div></code></div><br>Also, now that I think of it=
, this issue is likely to be addressed in the future by the <a href=3D"http=
://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0066r0.pdf">lifetime e=
xtension proposal</a> (which mentions the <span style=3D"font-family: couri=
er new,monospace;">`string_view`</span> issue as a motivating example). I s=
hould probably add this comment to the proposal.<br><br><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/461d5582-b67d-4ec7-b195-7c5e8fbddbb1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/461d5582-b67d-4ec7-b195-7c5e8fbddbb1=
%40isocpp.org</a>.<br />
------=_Part_10554_1655420684.1488382446729--
------=_Part_10553_1182610767.1488382446729--
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 2 Mar 2017 00:08:28 +0800
Raw View
--Apple-Mail=_1AF7E7EA-FE70-4E69-9378-091CECE3D083
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2017=E2=80=9303=E2=80=9301, at 11:17 PM, Barry Revzin <barry.revzin@gm=
ail.com> wrote:
>=20
> Which may be fine if the full-expression happens to encompass the lifetim=
e of the optional (hopefully f() doesn't store it somewhere!) But then:
>=20
> optional<int const&> o =3D 42;
>=20
> Now any subsequent use of o is outside of that full expression that encom=
passes the lifetime of 42.=20
True, but initialization directly from a prvalue will never leave the optio=
nal empty, so why use it instead of the bare reference?
Even for references, more sophisticated initializers, for example f(42) if =
it returns its argument, already fail to apply lifetime extension.
In the scope of the generalized lifetime extension problem, optional<int co=
nst&> is no different from string_view or any other observer. Standard clas=
ses that would benefit from GLE provide extra motivation for a core languag=
e fix. But instances of familiar lifetime extension issues shouldn=E2=80=99=
t count against library proposals, unless perhaps usability is really compr=
omised.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/E5B6D6C6-98C2-447A-9FDB-00E001DA7BE9%40gmail.com=
..
--Apple-Mail=_1AF7E7EA-FE70-4E69-9378-091CECE3D083
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2017=E2=80=9303=
=E2=80=9301, at 11:17 PM, Barry Revzin <<a href=3D"mailto:barry.revzin@g=
mail.com" class=3D"">barry.revzin@gmail.com</a>> wrote:</div><br class=
=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" style=3D"fo=
nt-family: Helvetica; font-size: 12px; font-style: normal; font-variant: no=
rmal; font-weight: normal; letter-spacing: normal; orphans: auto; text-alig=
n: start; text-indent: 0px; text-transform: none; white-space: normal; wido=
ws: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D"">Wh=
ich may be fine if the full-expression happens to encompass the lifetime of=
the optional (hopefully <font face=3D"courier new, monospace" class=
=3D"">f()</font> doesn't store it somewhere!) But then:<br class=3D"">=
<div class=3D""><br class=3D""></div><div class=3D""><div class=3D"prettypr=
int" style=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb(1=
87, 187, 187); word-wrap: break-word;"><code class=3D"prettyprint"><div cla=
ss=3D"subprettyprint"><font color=3D"#660066" class=3D""><span class=3D"sty=
led-by-prettify" style=3D"">optional</span><span class=3D"styled-by-prettif=
y" style=3D"color: rgb(102, 102, 0);"><</span><span class=3D"styled-by-p=
rettify" style=3D"color: rgb(0, 0, 136);">int</span><span class=3D"styled-b=
y-prettify" style=3D""><span class=3D"Apple-converted-space"> </span><=
/span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 136);">c=
onst</span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102,=
0);">&></span><span class=3D"styled-by-prettify" style=3D""><span c=
lass=3D"Apple-converted-space"> </span>o<span class=3D"Apple-converted=
-space"> </span></span><span class=3D"styled-by-prettify" style=3D"col=
or: rgb(102, 102, 0);">=3D</span><span class=3D"styled-by-prettify" style=
=3D""><span class=3D"Apple-converted-space"> </span></span><span class=
=3D"styled-by-prettify" style=3D"color: rgb(0, 102, 102);">42</span><span c=
lass=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">;</span></fo=
nt></div></code></div><br class=3D"">Now any subsequent use of<span class=
=3D"Apple-converted-space"> </span><font face=3D"courier new, monospac=
e" class=3D"">o</font><span class=3D"Apple-converted-space"> </span>is=
outside of that full expression that encompasses the lifetime of<span clas=
s=3D"Apple-converted-space"> </span><font face=3D"courier new, monospa=
ce" class=3D"">42</font>. </div></div></div></blockquote><br class=3D"=
"></div><div>True, but initialization directly from a prvalue will never le=
ave the <font face=3D"Courier" class=3D"">optional</font> empty, so why use=
it instead of the bare reference?</div><div><br class=3D""></div><div>Even=
for references, more sophisticated initializers, for example <font face=3D=
"Courier" class=3D"">f(42)</font> if it returns its argument, already fail =
to apply lifetime extension.</div><div><br class=3D""></div><div>In the sco=
pe of the generalized lifetime extension problem, <font face=3D"Courier" cl=
ass=3D"">optional<int const&></font> is no different from <font f=
ace=3D"Courier" class=3D"">string_view</font> or any other observer. Standa=
rd classes that would benefit from GLE provide extra motivation for a core =
language fix. But instances of familiar lifetime extension issues shouldn=
=E2=80=99t count against library proposals, unless perhaps usability is rea=
lly compromised.</div><div><br class=3D""></div></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/E5B6D6C6-98C2-447A-9FDB-00E001DA7BE9%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/E5B6D6C6-98C2-447A-9FDB-00E001DA7BE9%=
40gmail.com</a>.<br />
--Apple-Mail=_1AF7E7EA-FE70-4E69-9378-091CECE3D083--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Wed, 1 Mar 2017 16:00:27 -0800 (PST)
Raw View
------=_Part_5677_1166082390.1488412827235
Content-Type: multipart/alternative;
boundary="----=_Part_5678_364585892.1488412827236"
------=_Part_5678_364585892.1488412827236
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, February 28, 2017 at 5:57:35 PM UTC-8, joseph....@gmail.com=20
wrote:
>
> Given that the auxiliary proposal for "optional references" in N3672=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html> was=
=20
> not accepted into C++17 (as far as I can tell), I have prepared a draft=
=20
> proposal (see attached) for an alternative specification of `optional<T&>=
`=20
> that focuses on the "optional reference" function parameter use case. I=
=20
> would appreciate any thoughts or feedback.
>
I also miss optional<T&>, and optional<void> for that matter, because if we=
=20
had those two things, then we could easily implement the shared state of=20
future<X> in terms of optional<X> for all X.
However, I don't understand why you'd want optional<T&> to behave so=20
unusually differently from optional<T> w.r.t. copy assignment and such.=20
IMNSHO, optional<T&> should behave identically to=20
optional<reference_wrapper<T>>, which is to say, almost identically to T*.
Can you add something to your paper explaining (or rehashing) exactly what=
=20
are the arguments against the above (or N3672-style) semantics?
N3672 has some discussion of copy assignment; but of course it doesn't=20
contain any discussion of the reasons it itself was rejected, and it's=20
*those* reasons that your paper is building on top of, right?
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html#optional=
_ref.rationale.assign
I would also like to see your proposal include a normative requirement that=
=20
sizeof(optional<T&>) =3D=3D sizeof(T*).
Orthogonally, I'd like to see a normative requirement that=20
sizeof(optional<reference_wrapper<T>>) =3D=3D sizeof(reference_wrapper<T>) =
=3D=3D=20
sizeof(T*). No major vendor currently provides this, but I wish they did.
=E2=80=93Arthur
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/0e7455f0-f8f1-488c-8cf0-81793cae193c%40isocpp.or=
g.
------=_Part_5678_364585892.1488412827236
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, February 28, 2017 at 5:57:35 PM UTC-8, joseph.=
....@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">Given that the auxiliary proposal for "optional references&qu=
ot; in <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n=
3672.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc=
22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3672.html\x26sa\x3dD\x26sntz\x3d1\x26us=
g\x3dAFQjCNGv3DoyO1iTWrxSaNDwbFdsywM-SA';return true;" onclick=3D"this.=
href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2F=
jtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3672.html\x26sa\x3dD\x26sntz\x=
3d1\x26usg\x3dAFQjCNGv3DoyO1iTWrxSaNDwbFdsywM-SA';return true;">N3672</=
a> was not accepted into C++17 (as far as I can tell), I have prepared a dr=
aft proposal (see attached) for an alternative specification of <span style=
=3D"font-family:courier new,monospace">`optional<T&>`</span> that=
focuses on the "optional reference" function parameter use case.=
I would appreciate any thoughts or feedback.<br></div></blockquote><div><b=
r></div><div>I also miss <font face=3D"courier new, monospace">optional<=
T&></font>, and <font face=3D"courier new, monospace">optional<vo=
id></font> for that matter, because if we had those two things, then we =
could easily implement the shared state of <font face=3D"courier new, monos=
pace">future<X></font> in terms of <font face=3D"courier new, monospa=
ce">optional<X></font> for all <font face=3D"courier new, monospace">=
X</font>.</div><div>However, I don't understand why you'd want <fon=
t face=3D"courier new, monospace">optional<T&></font> to behave s=
o unusually differently from <font face=3D"courier new, monospace">optional=
<T></font> w.r.t. copy assignment and such. IMNSHO, <font face=3D"cou=
rier new, monospace">optional<T&></font> should behave identicall=
y to <font face=3D"courier new, monospace">optional<reference_wrapper<=
;T>></font>, which is to say, almost identically to <font face=3D"cou=
rier new, monospace">T*</font>.</div><div>Can you add something to your pap=
er explaining (or rehashing) exactly what are the arguments against the abo=
ve (or N3672-style) semantics?</div><div><br></div><div>N3672 has some disc=
ussion of copy assignment; but of course it doesn't contain any discuss=
ion of the reasons it itself was rejected, and it's <i>those</i> reason=
s that your paper is building on top of, right?</div><div><a href=3D"http:/=
/www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html#optional_ref.r=
ationale.assign">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3=
672.html#optional_ref.rationale.assign</a><br></div><div><br></div><div>I w=
ould also like to see your proposal include a normative requirement that si=
zeof(optional<T&>) =3D=3D sizeof(T*).</div><div><br></div><div>Or=
thogonally, I'd like to see a normative requirement that sizeof(optiona=
l<reference_wrapper<T>>) =3D=3D sizeof(reference_wrapper<T&g=
t;) =3D=3D sizeof(T*). No major vendor currently provides this, but I wish =
they did.</div><div><br></div><div>=E2=80=93Arthur</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0e7455f0-f8f1-488c-8cf0-81793cae193c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0e7455f0-f8f1-488c-8cf0-81793cae193c=
%40isocpp.org</a>.<br />
------=_Part_5678_364585892.1488412827236--
------=_Part_5677_1166082390.1488412827235--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 1 Mar 2017 16:41:17 -0800 (PST)
Raw View
------=_Part_21_489889458.1488415277858
Content-Type: multipart/alternative;
boundary="----=_Part_22_249524398.1488415277858"
------=_Part_22_249524398.1488415277858
Content-Type: text/plain; charset=UTF-8
On Wednesday, March 1, 2017 at 7:00:27 PM UTC-5, Arthur O'Dwyer wrote:
>
> On Tuesday, February 28, 2017 at 5:57:35 PM UTC-8, joseph....@gmail.com
> wrote:
>>
>> Given that the auxiliary proposal for "optional references" in N3672
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html> was
>> not accepted into C++17 (as far as I can tell), I have prepared a draft
>> proposal (see attached) for an alternative specification of
>> `optional<T&>` that focuses on the "optional reference" function
>> parameter use case. I would appreciate any thoughts or feedback.
>>
>
> I also miss optional<T&>, and optional<void> for that matter, because if
> we had those two things, then we could easily implement the shared state of
> future<X> in terms of optional<X> for all X.
> However, I don't understand why you'd want optional<T&> to behave so
> unusually differently from optional<T> w.r.t. copy assignment and such.
> IMNSHO, optional<T&> should behave identically to
> optional<reference_wrapper<T>>, which is to say, almost identically to T*.
> Can you add something to your paper explaining (or rehashing) exactly what
> are the arguments against the above (or N3672-style) semantics?
>
> N3672 has some discussion of copy assignment; but of course it doesn't
> contain any discussion of the reasons it itself was rejected, and it's
> *those* reasons that your paper is building on top of, right?
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html#optional_ref.rationale.assign
>
> I would also like to see your proposal include a normative requirement
> that sizeof(optional<T&>) == sizeof(T*).
>
> Orthogonally, I'd like to see a normative requirement that
> sizeof(optional<reference_wrapper<T>>) == sizeof(reference_wrapper<T>) ==
> sizeof(T*). No major vendor currently provides this, but I wish they did.
>
>
Such a guarantee is contingent on having a system where a struct of a
pointer type is never bigger than the pointer. Nothing in the standard at
present requires this from an implementation.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d27734a0-8ffd-4a59-bd2f-a5fd8b0023c3%40isocpp.org.
------=_Part_22_249524398.1488415277858
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, March 1, 2017 at 7:00:27 PM UTC-5, A=
rthur O'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">On Tuesday, February 28, 2017 at 5:57:35 PM UTC-8, <a>joseph....=
@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r">Given that the auxiliary proposal for "optional references" in=
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.h=
tml" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'htt=
p://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fw=
g21%2Fdocs%2Fpapers%2F2013%2Fn3672.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dA=
FQjCNGv3DoyO1iTWrxSaNDwbFdsywM-SA';return true;" onclick=3D"this.href=
=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1=
%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3672.html\x26sa\x3dD\x26sntz\x3d1\=
x26usg\x3dAFQjCNGv3DoyO1iTWrxSaNDwbFdsywM-SA';return true;">N3672</a> w=
as not accepted into C++17 (as far as I can tell), I have prepared a draft =
proposal (see attached) for an alternative specification of <span style=3D"=
font-family:courier new,monospace">`optional<T&>`</span> that foc=
uses on the "optional reference" function parameter use case. I w=
ould appreciate any thoughts or feedback.<br></div></blockquote><div><br></=
div><div>I also miss <font face=3D"courier new, monospace">optional<T&am=
p;></font>, and <font face=3D"courier new, monospace">optional<void&g=
t;</font> for that matter, because if we had those two things, then we coul=
d easily implement the shared state of <font face=3D"courier new, monospace=
">future<X></font> in terms of <font face=3D"courier new, monospace">=
optional<X></font> for all <font face=3D"courier new, monospace">X</f=
ont>.</div><div>However, I don't understand why you'd want <font fa=
ce=3D"courier new, monospace">optional<T&></font> to behave so un=
usually differently from <font face=3D"courier new, monospace">optional<=
T></font> w.r.t. copy assignment and such. IMNSHO, <font face=3D"courier=
new, monospace">optional<T&></font> should behave identically to=
<font face=3D"courier new, monospace">optional<reference_wrapper<T&g=
t;></font><wbr>, which is to say, almost identically to <font face=3D"co=
urier new, monospace">T*</font>.</div><div>Can you add something to your pa=
per explaining (or rehashing) exactly what are the arguments against the ab=
ove (or N3672-style) semantics?</div><div><br></div><div>N3672 has some dis=
cussion of copy assignment; but of course it doesn't contain any discus=
sion of the reasons it itself was rejected, and it's <i>those</i> reaso=
ns that your paper is building on top of, right?</div><div><a href=3D"http:=
//www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html#optional_ref.=
rationale.assign" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjt=
c1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3672.html%23optional_ref.rationa=
le.assign\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFKnJCdNzkiQrODIsLxcsygvCZ=
UwA';return true;" onclick=3D"this.href=3D'http://www.google.com/ur=
l?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2=
F2013%2Fn3672.html%23optional_ref.rationale.assign\x26sa\x3dD\x26sntz\x3d1\=
x26usg\x3dAFQjCNFKnJCdNzkiQrODIsLxcsygvCZUwA';return true;">http://www.=
open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2013/<wbr>n3672.html#optional_=
ref.<wbr>rationale.assign</a><br></div><div><br></div><div>I would also lik=
e to see your proposal include a normative requirement that sizeof(optional=
<T&>) =3D=3D sizeof(T*).</div><div><br></div><div>Orthogonally, I=
'd like to see a normative requirement that sizeof(optional<referenc=
e_<wbr>wrapper<T>>) =3D=3D sizeof(reference_wrapper<T>) =3D=
=3D sizeof(T*). No major vendor currently provides this, but I wish they di=
d.</div><br></div></blockquote><div><br>Such a guarantee is contingent on h=
aving a system where a struct of a pointer type is never bigger than the po=
inter. Nothing in the standard at present requires this from an implementat=
ion. <br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d27734a0-8ffd-4a59-bd2f-a5fd8b0023c3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d27734a0-8ffd-4a59-bd2f-a5fd8b0023c3=
%40isocpp.org</a>.<br />
------=_Part_22_249524398.1488415277858--
------=_Part_21_489889458.1488415277858--
.
Author: Joseph Thomson <joseph.thomson@gmail.com>
Date: Thu, 2 Mar 2017 10:36:20 +0800
Raw View
--001a113cd0da6293660549b64b8f
Content-Type: text/plain; charset=UTF-8
On Thu, Mar 2, 2017 at 8:00 AM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:
> On Tuesday, February 28, 2017 at 5:57:35 PM UTC-8, joseph....@gmail.com
> wrote:
>>
>> Given that the auxiliary proposal for "optional references" in N3672
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html> was
>> not accepted into C++17 (as far as I can tell), I have prepared a draft
>> proposal (see attached) for an alternative specification of
>> `optional<T&>` that focuses on the "optional reference" function
>> parameter use case. I would appreciate any thoughts or feedback.
>>
>
> I also miss optional<T&>, and optional<void> for that matter, because if
> we had those two things, then we could easily implement the shared state of
> future<X> in terms of optional<X> for all X.
>
The idea of `optional<void>` strikes me as odd. In what sense can you have
a value of type `void`? It seems like it would essentially be a glorified
`bool`.
Do you mean `future::get` would be implemented something like this?
T future<T>::get() {
wait();
return *state->value; // `value` is of type `optional<T>`
}
This feels like shifting the complexity of `future` into `optional` for no
reason other than to keep the complexity out of `future`. I like it when
you can simplify higher-level code as a natural result of using
well-designed low-level components, but `optional<void>` doesn't seem like
a well-designed feature to me.
> However, I don't understand why you'd want optional<T&> to behave so
> unusually differently from optional<T> w.r.t. copy assignment and such.
> IMNSHO, optional<T&> should behave identically to
> optional<reference_wrapper<T>>, which is to say, almost identically to T*.
> Can you add something to your paper explaining (or rehashing) exactly what
> are the arguments against the above (or N3672-style) semantics?
>
On the contrary, the copy assignment behaviour for `optional<T&>` proposed
by *N3672* was unusually different from that of `optional<T>`. The copy
assignment semantics of `optional<T>` reflect the copy assignment semantics
of `T`: `optional<int>` has the same copy assignment semantics as `int`
(value semantics) and `optional<int*>` has the same copy assignment
semantics as `int*` (reference semantics); why then should `optional<int&>`
have the same copy assignment semantics as `int*`? This is inconsistent and
potentially surprising behaviour. `T&` cannot be rebound after
initialization, so neither should `optional<T&>`.
The problem, as explained in my paper, is that the nature of `optional<T>`
makes it impossible to give `optional<int&>` the same copy assignment
behaviour as `int&`. At best, we can give it an unholy mixture of value and
reference semantics that depend on the initial state of the `optional<int&>`.
Thus, the only reasonable option left to us is to disable copy assignment
altogether.
I will try to present my argument more clearly in the next draft.
N3672 has some discussion of copy assignment; but of course it doesn't
> contain any discussion of the reasons it itself was rejected, and it's
> *those* reasons that your paper is building on top of, right?
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/
> n3672.html#optional_ref.rationale.assign
>
Yes, I mentioned that they gave no reasoning for the general consensus that
`optional<T&>` should be copy assignable. I would certainly like to know,
but I have a feeling it was along the lines of ,"`optional<T&>` *must* be a
regular type", which I also address in the paper.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHocnE-wdUkci9oh6jcYD3jktLfqgvHApeX-qTywQA7f_ZtKLQ%40mail.gmail.com.
--001a113cd0da6293660549b64b8f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Mar 2, 2017 at 8:00 AM, Arthur O'Dwyer <span dir=3D"ltr"><<a hre=
f=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@gm=
ail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div dir=3D"ltr"><span class=3D"gmail-">On Tuesday, February 28, 20=
17 at 5:57:35 PM UTC-8, <a href=3D"mailto:joseph....@gmail.com" target=3D"_=
blank">joseph....@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"ltr">Given that the auxiliary proposal for "o=
ptional references" in <a href=3D"http://www.open-std.org/jtc1/sc22/wg=
21/docs/papers/2013/n3672.html" rel=3D"nofollow" target=3D"_blank">N3672</a=
> was not accepted into C++17 (as far as I can tell), I have prepared a dra=
ft proposal (see attached) for an alternative specification of <span style=
=3D"font-family:courier new,monospace">`optional<T&>`</span> that=
focuses on the "optional reference" function parameter use case.=
I would appreciate any thoughts or feedback.<br></div></blockquote><div><b=
r></div></span><div>I also miss <font face=3D"courier new, monospace">optio=
nal<T&></font>, and <font face=3D"courier new, monospace">optiona=
l<void></font> for that matter, because if we had those two things, t=
hen we could easily implement the shared state of <font face=3D"courier new=
, monospace">future<X></font> in terms of <font face=3D"courier new, =
monospace">optional<X></font> for all <font face=3D"courier new, mono=
space">X</font>.</div></div></blockquote><div><br></div><div>The idea of <s=
pan style=3D"font-family:monospace,monospace">`optional<void>`</span>=
strikes me as odd. In what sense can you have a value of type <span style=
=3D"font-family:monospace,monospace">`void`</span>? It seems like it would =
essentially be a glorified <span style=3D"font-family:monospace,monospace">=
`bool`</span>.<br><br>Do you mean <span style=3D"font-family:monospace,mono=
space">`future::get`</span> would be implemented something like this?<br><b=
r></div><div style=3D"margin-left:40px"><span style=3D"font-family:monospac=
e,monospace">T future<T>::get() {<br></span></div><div style=3D"margi=
n-left:40px"><span style=3D"font-family:monospace,monospace">=C2=A0 wait();=
<br></span></div><div style=3D"margin-left:40px"><span style=3D"font-family=
:monospace,monospace">=C2=A0 return *state->value; // `value` is of type=
`optional<T>`<br></span></div><div><div style=3D"margin-left:40px"><=
span style=3D"font-family:monospace,monospace">}</span><br></div><br></div>=
<div>This feels like shifting the complexity of <span style=3D"font-family:=
monospace,monospace">`future`</span> into <span style=3D"font-family:monosp=
ace,monospace">`optional`</span> for no reason other than to keep the compl=
exity out of <span style=3D"font-family:monospace,monospace">`future`</span=
>. I like it when you can simplify higher-level code as a natural result of=
using well-designed low-level components, but <span style=3D"font-family:m=
onospace,monospace">`optional<void>`</span> doesn't seem like a w=
ell-designed feature to me.<br></div><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div dir=3D"ltr"><div>However, I don't und=
erstand why you'd want <font face=3D"courier new, monospace">optional&l=
t;T&></font> to behave so unusually differently from <font face=3D"c=
ourier new, monospace">optional<T></font> w.r.t. copy assignment and =
such. IMNSHO, <font face=3D"courier new, monospace">optional<T&><=
/font> should behave identically to <font face=3D"courier new, monospace">o=
ptional<reference_wrapper<T>></font><wbr>, which is to say, alm=
ost identically to <font face=3D"courier new, monospace">T*</font>.</div><d=
iv>Can you add something to your paper explaining (or rehashing) exactly wh=
at are the arguments against the above (or N3672-style) semantics?</div></d=
iv></blockquote><div>=C2=A0<br></div>On the contrary, the copy assignment b=
ehaviour for <span style=3D"font-family:monospace,monospace">`optional<T=
&>`</span> proposed by <i>N3672</i> was unusually different from tha=
t of <span style=3D"font-family:monospace,monospace">`optional<T>`</s=
pan>. The copy assignment semantics of <span style=3D"font-family:monospace=
,monospace">`optional<T>`</span> reflect the copy assignment semantic=
s of <span style=3D"font-family:monospace,monospace">`T`</span>: <span styl=
e=3D"font-family:monospace,monospace">`optional<int>`</span> has the =
same copy assignment semantics as <span style=3D"font-family:monospace,mono=
space">`int`</span> (value semantics) and <span style=3D"font-family:monosp=
ace,monospace">`optional<int*>`</span> has the same copy assignment s=
emantics as <span style=3D"font-family:monospace,monospace">`int*`</span> (=
reference semantics); why then should <span style=3D"font-family:monospace,=
monospace">`optional<int&>`</span> have the same copy assignment =
semantics as <span style=3D"font-family:monospace,monospace">`int*`</span>?=
This is inconsistent and potentially surprising behaviour. <span style=3D"=
font-family:monospace,monospace">`T&`</span> cannot be rebound after in=
itialization, so neither should <span style=3D"font-family:monospace,monosp=
ace">`optional<T&>`</span>.<br><br></div><div>The problem, as exp=
lained in my paper, is that the nature of <span style=3D"font-family:monosp=
ace,monospace">`optional<T>`</span> makes it impossible to give <span=
style=3D"font-family:monospace,monospace">`optional<int&>`</span=
> the same copy assignment behaviour as <span style=3D"font-family:monospac=
e,monospace">`int&`</span>. At best, we can give it an unholy mixture o=
f value and reference semantics that depend on the initial state of the <sp=
an style=3D"font-family:monospace,monospace">`optional<int&>`</sp=
an>. Thus, the only reasonable option left to us is to disable copy assignm=
ent altogether.<br><br>I will try to present my argument more clearly in th=
e next draft.<br><br></div><div class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div dir=3D"ltr"><div></div><div>N3672 has som=
e discussion of copy assignment; but of course it doesn't contain any d=
iscussion of the reasons it itself was rejected, and it's <i>those</i> =
reasons that your paper is building on top of, right?</div><div><a href=3D"=
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html#optional=
_ref.rationale.assign" target=3D"_blank">http://www.open-std.org/jtc1/<wbr>=
sc22/wg21/docs/papers/2013/<wbr>n3672.html#optional_ref.<wbr>rationale.assi=
gn</a><br></div></div></blockquote><div>=C2=A0<br></div><div>Yes, I mention=
ed that they gave no reasoning for the general consensus that <span style=
=3D"font-family:monospace,monospace">`optional<T&>`</span> should=
be copy assignable. I would certainly like to know, but I have a feeling i=
t was along the lines of ,"<span style=3D"font-family:monospace,monosp=
ace">`optional<T&>`</span> <i>must</i> be a regular type", w=
hich I also address in the paper.<br></div><br></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHocnE-wdUkci9oh6jcYD3jktLfqgvHApeX-=
qTywQA7f_ZtKLQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHocnE-wdUkci9oh=
6jcYD3jktLfqgvHApeX-qTywQA7f_ZtKLQ%40mail.gmail.com</a>.<br />
--001a113cd0da6293660549b64b8f--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 1 Mar 2017 19:18:55 -0800 (PST)
Raw View
------=_Part_53_2019211929.1488424735644
Content-Type: multipart/alternative;
boundary="----=_Part_54_140763198.1488424735644"
------=_Part_54_140763198.1488424735644
Content-Type: text/plain; charset=UTF-8
On Wednesday, March 1, 2017 at 9:36:22 PM UTC-5, Joseph Thomson wrote:
>
> On Thu, Mar 2, 2017 at 8:00 AM, Arthur O'Dwyer <arthur....@gmail.com
> <javascript:>> wrote:
>
>> On Tuesday, February 28, 2017 at 5:57:35 PM UTC-8, joseph....@gmail.com
>> wrote:
>>>
>>> Given that the auxiliary proposal for "optional references" in N3672
>>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html>
>>> was not accepted into C++17 (as far as I can tell), I have prepared a draft
>>> proposal (see attached) for an alternative specification of
>>> `optional<T&>` that focuses on the "optional reference" function
>>> parameter use case. I would appreciate any thoughts or feedback.
>>>
>>
>> I also miss optional<T&>, and optional<void> for that matter, because if
>> we had those two things, then we could easily implement the shared state of
>> future<X> in terms of optional<X> for all X.
>>
>
> The idea of `optional<void>` strikes me as odd. In what sense can you
> have a value of type `void`? It seems like it would essentially be a
> glorified `bool`.
>
> Do you mean `future::get` would be implemented something like this?
>
> T future<T>::get() {
> wait();
> return *state->value; // `value` is of type `optional<T>`
> }
>
> This feels like shifting the complexity of `future` into `optional` for
> no reason other than to keep the complexity out of `future`. I like it
> when you can simplify higher-level code as a natural result of using
> well-designed low-level components, but `optional<void>` doesn't seem
> like a well-designed feature to me.
>
>
>> However, I don't understand why you'd want optional<T&> to behave so
>> unusually differently from optional<T> w.r.t. copy assignment and such.
>> IMNSHO, optional<T&> should behave identically to
>> optional<reference_wrapper<T>>, which is to say, almost identically to T*
>> .
>> Can you add something to your paper explaining (or rehashing) exactly
>> what are the arguments against the above (or N3672-style) semantics?
>>
>
> On the contrary, the copy assignment behaviour for `optional<T&>`
> proposed by *N3672* was unusually different from that of `optional<T>`.
> The copy assignment semantics of `optional<T>` reflect the copy
> assignment semantics of `T`: `optional<int>` has the same copy assignment
> semantics as `int` (value semantics) and `optional<int*>` has the same
> copy assignment semantics as `int*` (reference semantics);
>
No it doesn't. `optional<int*>` and `int*` both have value semantics, with
respect to the object in question. That object being a *pointer*.
It only has reference semantics with respect to the object being pointed
to. But that's fundamentally no different than `optional<int>`, if that
`int` just so happens to be a handle into some system that represents an
object. `optional<int>` still has value semantics in that case.
It's questions like this that make me feel that `optional` references are a
*terrible* idea. Some people will expect it to have one behavior, others
will expect it to have a contradictory one, and in the end only one side
will be happy. Coupled with the fact that `T*` works adequately as an
`optional<T&>`, and I just don't see the need for it.
why then should `optional<int&>` have the same copy assignment semantics as
> `int*`? This is inconsistent and potentially surprising behaviour. `T&`
> cannot be rebound after initialization, so neither should `optional<T&>`.
>
> The problem, as explained in my paper, is that the nature of `optional<T>`
> makes it impossible to give `optional<int&>` the same copy assignment
> behaviour as `int&`. At best, we can give it an unholy mixture of value
> and reference semantics that depend on the initial state of the
> `optional<int&>`. Thus, the only reasonable option left to us is to
> disable copy assignment altogether.
>
> I will try to present my argument more clearly in the next draft.
>
> N3672 has some discussion of copy assignment; but of course it doesn't
>> contain any discussion of the reasons it itself was rejected, and it's
>> *those* reasons that your paper is building on top of, right?
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html#optional_ref.rationale.assign
>>
>
> Yes, I mentioned that they gave no reasoning for the general consensus
> that `optional<T&>` should be copy assignable. I would certainly like to
> know, but I have a feeling it was along the lines of ,"`optional<T&>`
> *must* be a regular type", which I also address in the paper.
>
If you make a specialization of `optional` that fundamentally behaves
differently from `optional`, then you're walking straight into the
`vector<bool>` problem. Only instead of making just one specialization
that's deficient, you're making an *entire category *of specializations
that are different.
If my function takes an `optional<T>`, where `T` is deduced or some such, I
shouldn't have to worry that some nitwit is going to come along as
instantiate it with `T&`. I should not have to guard this function with
`enable_if` or `requires` just to be able to ensure sane behavior.
If you're going to change aspects of the type's interface like that, then I
would prefer that you just made a new type with a compatible interface.
Then you can come up with an "Nullable" concept that matches it. There's no
reason to name this type `optional`.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ac923837-80f4-4618-a0b4-87c72af16b54%40isocpp.org.
------=_Part_54_140763198.1488424735644
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, March 1, 2017 at 9:36:22 PM UTC-5, Joseph Th=
omson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div><div class=3D"gmail_quote">On Thu, Mar 2, 2017 at 8:00 AM, Arthur O'=
;Dwyer <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"jkYl9pjXCQAJ" rel=3D"nofollow" onmousedown=3D"this.hre=
f=3D'javascript:';return true;" onclick=3D"this.href=3D'javascr=
ipt:';return true;">arthur....@gmail.com</a>></span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span>On Tues=
day, February 28, 2017 at 5:57:35 PM UTC-8, <a>joseph....@gmail.com</a> wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Given=
that the auxiliary proposal for "optional references" in <a href=
=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html" rel=
=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.=
google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdo=
cs%2Fpapers%2F2013%2Fn3672.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGv3=
DoyO1iTWrxSaNDwbFdsywM-SA';return true;" onclick=3D"this.href=3D'ht=
tp://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2F=
wg21%2Fdocs%2Fpapers%2F2013%2Fn3672.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3d=
AFQjCNGv3DoyO1iTWrxSaNDwbFdsywM-SA';return true;">N3672</a> was not acc=
epted into C++17 (as far as I can tell), I have prepared a draft proposal (=
see attached) for an alternative specification of <span style=3D"font-famil=
y:courier new,monospace">`optional<T&>`</span> that focuses on th=
e "optional reference" function parameter use case. I would appre=
ciate any thoughts or feedback.<br></div></blockquote><div><br></div></span=
><div>I also miss <font face=3D"courier new, monospace">optional<T&&=
gt;</font>, and <font face=3D"courier new, monospace">optional<void><=
/font> for that matter, because if we had those two things, then we could e=
asily implement the shared state of <font face=3D"courier new, monospace">f=
uture<X></font> in terms of <font face=3D"courier new, monospace">opt=
ional<X></font> for all <font face=3D"courier new, monospace">X</font=
>.</div></div></blockquote><div><br></div><div>The idea of <span style=3D"f=
ont-family:monospace,monospace">`optional<void>`</span> strikes me as=
odd. In what sense can you have a value of type <span style=3D"font-family=
:monospace,monospace">`void`</span>? It seems like it would essentially be =
a glorified <span style=3D"font-family:monospace,monospace">`bool`</span>.<=
br><br>Do you mean <span style=3D"font-family:monospace,monospace">`future:=
:get`</span> would be implemented something like this?<br><br></div><div st=
yle=3D"margin-left:40px"><span style=3D"font-family:monospace,monospace">T =
future<T>::get() {<br></span></div><div style=3D"margin-left:40px"><s=
pan style=3D"font-family:monospace,monospace">=C2=A0 wait();<br></span></di=
v><div style=3D"margin-left:40px"><span style=3D"font-family:monospace,mono=
space">=C2=A0 return *state->value; // `value` is of type `optional<T=
>`<br></span></div><div><div style=3D"margin-left:40px"><span style=3D"f=
ont-family:monospace,monospace">}</span><br></div><br></div><div>This feels=
like shifting the complexity of <span style=3D"font-family:monospace,monos=
pace">`future`</span> into <span style=3D"font-family:monospace,monospace">=
`optional`</span> for no reason other than to keep the complexity out of <s=
pan style=3D"font-family:monospace,monospace">`future`</span>. I like it wh=
en you can simplify higher-level code as a natural result of using well-des=
igned low-level components, but <span style=3D"font-family:monospace,monosp=
ace">`optional<void>`</span> doesn't seem like a well-designed fe=
ature to me.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"ltr"><div>However, I don't understand why you=
'd want <font face=3D"courier new, monospace">optional<T&></f=
ont> to behave so unusually differently from <font face=3D"courier new, mon=
ospace">optional<T></font> w.r.t. copy assignment and such. IMNSHO, <=
font face=3D"courier new, monospace">optional<T&></font> should b=
ehave identically to <font face=3D"courier new, monospace">optional<refe=
rence_wrapper<T>></font><wbr>, which is to say, almost identically=
to <font face=3D"courier new, monospace">T*</font>.</div><div>Can you add =
something to your paper explaining (or rehashing) exactly what are the argu=
ments against the above (or N3672-style) semantics?</div></div></blockquote=
><div>=C2=A0<br></div>On the contrary, the copy assignment behaviour for <s=
pan style=3D"font-family:monospace,monospace">`optional<T&>`</spa=
n> proposed by <i>N3672</i> was unusually different from that of <span styl=
e=3D"font-family:monospace,monospace">`optional<T>`</span>. The copy =
assignment semantics of <span style=3D"font-family:monospace,monospace">`op=
tional<T>`</span> reflect the copy assignment semantics of <span styl=
e=3D"font-family:monospace,monospace">`T`</span>: <span style=3D"font-famil=
y:monospace,monospace">`optional<int>`</span> has the same copy assig=
nment semantics as <span style=3D"font-family:monospace,monospace">`int`</s=
pan> (value semantics) and <span style=3D"font-family:monospace,monospace">=
`optional<int*>`</span> has the same copy assignment semantics as <sp=
an style=3D"font-family:monospace,monospace">`int*`</span> (reference seman=
tics);</div></div></div></blockquote><div><br>No it doesn't. `optional&=
lt;int*>` and `int*` both have value semantics, with respect to the obje=
ct in question. That object being a <i>pointer</i>.<br><br>It only has refe=
rence semantics with respect to the object being pointed to. But that's=
fundamentally no different than `optional<int>`, if that `int` just =
so happens to be a handle into some system that represents an object. `opti=
onal<int>` still has value semantics in that case.<br><br>It's qu=
estions like this that make me feel that `optional` references are a <i>ter=
rible</i> idea. Some people will expect it to have one behavior, others wil=
l expect it to have a contradictory one, and in the end only one side will =
be happy. Coupled with the fact that `T*` works adequately as an `optional&=
lt;T&>`, and I just don't see the need for it.<br><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote">why then should <span style=3D"font-family:monospace,monos=
pace">`optional<int&>`</span> have the same copy assignment seman=
tics as <span style=3D"font-family:monospace,monospace">`int*`</span>? This=
is inconsistent and potentially surprising behaviour. <span style=3D"font-=
family:monospace,monospace">`T&`</span> cannot be rebound after initial=
ization, so neither should <span style=3D"font-family:monospace,monospace">=
`optional<T&>`</span>.<br></div></div></div></blockquote><div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-l=
eft: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><br></blockquote></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div =
class=3D"gmail_quote"></div><div>The problem, as explained in my paper, is =
that the nature of <span style=3D"font-family:monospace,monospace">`optiona=
l<T>`</span> makes it impossible to give <span style=3D"font-family:m=
onospace,monospace">`optional<int&>`</span> the same copy assignm=
ent behaviour as <span style=3D"font-family:monospace,monospace">`int&`=
</span>. At best, we can give it an unholy mixture of value and reference s=
emantics that depend on the initial state of the <span style=3D"font-family=
:monospace,monospace">`optional<int&>`</span>. Thus, the only rea=
sonable option left to us is to disable copy assignment altogether.<br><br>=
I will try to present my argument more clearly in the next draft.<br><br></=
div><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
><div>N3672 has some discussion of copy assignment; but of course it doesn&=
#39;t contain any discussion of the reasons it itself was rejected, and it&=
#39;s <i>those</i> reasons that your paper is building on top of, right?</d=
iv><div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/=
n3672.html#optional_ref.rationale.assign" target=3D"_blank" rel=3D"nofollow=
" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F=
%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3672.htm=
l%23optional_ref.rationale.assign\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF=
KnJCdNzkiQrODIsLxcsygvCZUwA';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%=
2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3672.html%23optional_ref.rationale.assign\=
x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFKnJCdNzkiQrODIsLxcsygvCZUwA';r=
eturn true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2013/<=
wbr>n3672.html#optional_ref.<wbr>rationale.assign</a><br></div></div></bloc=
kquote><div>=C2=A0<br></div><div>Yes, I mentioned that they gave no reasoni=
ng for the general consensus that <span style=3D"font-family:monospace,mono=
space">`optional<T&>`</span> should be copy assignable. I would c=
ertainly like to know, but I have a feeling it was along the lines of ,&quo=
t;<span style=3D"font-family:monospace,monospace">`optional<T&>`<=
/span> <i>must</i> be a regular type", which I also address in the pap=
er.=C2=A0</div></div></div></div></blockquote><div><br>If you make a specia=
lization of `optional` that fundamentally behaves differently from `optiona=
l`, then you're walking straight into the `vector<bool>` problem.=
Only instead of making just one specialization that's deficient, you&#=
39;re making an <i>entire category </i>of specializations that are differen=
t.<br><br>If my function takes an `optional<T>`, where `T` is deduced=
or some such, I shouldn't have to worry that some nitwit is going to c=
ome along as instantiate it with `T&`. I should not have to guard this =
function with `enable_if` or `requires` just to be able to ensure sane beha=
vior.<br><br>If you're going to change aspects of the type's interf=
ace like that, then I would prefer that you just made a new type with a com=
patible interface. Then you can come up with an "Nullable" concep=
t that matches it. There's no reason to name this type `optional`.<br><=
/div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ac923837-80f4-4618-a0b4-87c72af16b54%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ac923837-80f4-4618-a0b4-87c72af16b54=
%40isocpp.org</a>.<br />
------=_Part_54_140763198.1488424735644--
------=_Part_53_2019211929.1488424735644--
.
Author: Joseph Thomson <joseph.thomson@gmail.com>
Date: Thu, 2 Mar 2017 12:16:50 +0800
Raw View
--001a11c159dcc67f000549b7b24e
Content-Type: text/plain; charset=UTF-8
On Thu, Mar 2, 2017 at 11:18 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, March 1, 2017 at 9:36:22 PM UTC-5, Joseph Thomson wrote:
>>
>> On Thu, Mar 2, 2017 at 8:00 AM, Arthur O'Dwyer <arthur....@gmail.com>
>> wrote:
>>
>>> On Tuesday, February 28, 2017 at 5:57:35 PM UTC-8, joseph....@gmail.com
>>> wrote:
>>>
>> However, I don't understand why you'd want optional<T&> to behave so
>>> unusually differently from optional<T> w.r.t. copy assignment and such.
>>> IMNSHO, optional<T&> should behave identically to
>>> optional<reference_wrapper<T>>, which is to say, almost identically to
>>> T*.
>>> Can you add something to your paper explaining (or rehashing) exactly
>>> what are the arguments against the above (or N3672-style) semantics?
>>>
>>
>> On the contrary, the copy assignment behaviour for `optional<T&>`
>> proposed by *N3672* was unusually different from that of `optional<T>`.
>> The copy assignment semantics of `optional<T>` reflect the copy
>> assignment semantics of `T`: `optional<int>` has the same copy
>> assignment semantics as `int` (value semantics) and `optional<int*>` has
>> the same copy assignment semantics as `int*` (reference semantics);
>>
>
> No it doesn't. `optional<int*>` and `int*` both have value semantics, with
> respect to the object in question. That object being a *pointer*.
>
>
It only has reference semantics with respect to the object being pointed
> to. But that's fundamentally no different than `optional<int>`, if that
> `int` just so happens to be a handle into some system that represents an
> object. `optional<int>` still has value semantics in that case.
>
I'm using the terminology
<https://isocpp.org/wiki/faq/value-vs-ref-semantics#val-vs-ref-semantics>
as defined by the isocpp website. Yeah, technically only initialization of
`T&` has true reference semantics and everything else in C++ has value
semantics. But this is nitpicking and is totally irrelevant to the issue at
hand.
It's questions like this that make me feel that `optional` references are a
> *terrible* idea. Some people will expect it to have one behavior, others
> will expect it to have a contradictory one, and in the end only one side
> will be happy.
>
The expectation that copy assignment of `optional<T&>` have the same
semantics as copy assignment of `T*` is, in my opinion, a result of the
erroneous belief that the inability to rebind `T&` is somehow a bug in its
design, that it is somehow reasonable to think of `T&` as a `T*` that
cannot be null. It seems that `optional<T&>` is seen as an opportunity to
"fix" this bug by allowing `T&` to be rebound by defining pointer-like copy
assignment semantics. The problem is that the inability to rebind `T&` is
*not* a bug; it is a feature. A `T&` is essentially an alias of an existing
object of type `T`, and behaves in almost every way like an object of type
`T`, *including* copy assignment.
I believe that there is an *objective* case to be made *against* giving
`optional<T&>` reference copy assignment semantics. It makes no more sense
for `optional<T&>` to have pointer-like copy assignment behaviour that it
would for `tuple<T&>` to have pointer-like copy assignment behaviour (which
it doesn't). `optional<T>` is conceptually a *container* of `T` and it
should behave as such.
> Coupled with the fact that `T*` works adequately as an `optional<T&>`, and
> I just don't see the need for it.
>
I outline four ways in which `T*` is inadequate in my paper.
> why then should `optional<int&>` have the same copy assignment semantics
>> as `int*`? This is inconsistent and potentially surprising behaviour.
>> `T&` cannot be rebound after initialization, so neither should
>> `optional<T&>`.
>>
>
>> The problem, as explained in my paper, is that the nature of
>> `optional<T>` makes it impossible to give `optional<int&>` the same copy
>> assignment behaviour as `int&`. At best, we can give it an unholy
>> mixture of value and reference semantics that depend on the initial state
>> of the `optional<int&>`. Thus, the only reasonable option left to us is
>> to disable copy assignment altogether.
>>
>> I will try to present my argument more clearly in the next draft.
>>
>> N3672 has some discussion of copy assignment; but of course it doesn't
>>> contain any discussion of the reasons it itself was rejected, and it's
>>> *those* reasons that your paper is building on top of, right?
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n367
>>> 2.html#optional_ref.rationale.assign
>>>
>>
>> Yes, I mentioned that they gave no reasoning for the general consensus
>> that `optional<T&>` should be copy assignable. I would certainly like to
>> know, but I have a feeling it was along the lines of ,"`optional<T&>`
>> *must* be a regular type", which I also address in the paper.
>>
>
> If you make a specialization of `optional` that fundamentally behaves
> differently from `optional`, then you're walking straight into the
> `vector<bool>` problem. Only instead of making just one specialization
> that's deficient, you're making an *entire category *of specializations
> that are different.
>
Disabling operations that do not make sense or are not possible for a
particular type is common practice. It is not possible to implement
assignment of `optional<T&>` in a way that is consistent with `optional<T>`,
so it should be disabled. Specifying reference semantics would make copy
assignment of `optional<T&>` behave fundamentally differently from
`optional<T>`. I would argue that this is in fact *worse* than
`vector<bool>`: at least with `vector<bool>` any programming errors are
likely to be caught at compile-time.
> If my function takes an `optional<T>`, where `T` is deduced or some such,
> I shouldn't have to worry that some nitwit is going to come along as
> instantiate it with `T&`. I should not have to guard this function with
> `enable_if` or `requires` just to be able to ensure sane behavior.
>
If you indiscriminately take an `optional<T>` for all `T` then you are
likely to run into problems regardless of whether `T` can be a reference
type, just as if you indiscriminately take a `T`. Concepts will make this
problem easier to manage. Even so, if my code expects `optional<T>` to be
copy assignable, then you will get a compile-time error if `T` is a
reference type (you would get a run-time bug if `optional<T&>` had
reference copy assignment semantics).
> If you're going to change aspects of the type's interface like that, then
> I would prefer that you just made a new type with a compatible interface.
> Then you can come up with an "Nullable" concept that matches it. There's no
> reason to name this type `optional`.
>
I'm not changing aspects of the interface. I'm disabling features that
cannot be implemented for a particular type. As I mentioned, this is
standard practice throughout the standard library.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHocnE-Z%2BJxVpQrv99EOsaJwsPWh9b%3DtYZncW24qG%2BfFpuNVig%40mail.gmail.com.
--001a11c159dcc67f000549b7b24e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Mar 2, 2017 at 11:18 AM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr">On Wednesday, March 1, 2017 at 9:36:22 PM UTC-5, Joseph Thomson wr=
ote:<span class=3D"gmail-"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Thu, Mar 2, 2017 at 8=
:00 AM, Arthur O'Dwyer <span dir=3D"ltr"><<a rel=3D"nofollow">arthur=
.....@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><span>On Tuesday, February 28, 2017 at 5:57=
:35 PM UTC-8, <a>joseph....@gmail.com</a> wrote:</span></div></blockquote><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Howe=
ver, I don't understand why you'd want <font face=3D"courier new, m=
onospace">optional<T&></font> to behave so unusually differently =
from <font face=3D"courier new, monospace">optional<T></font> w.r.t. =
copy assignment and such. IMNSHO, <font face=3D"courier new, monospace">opt=
ional<T&></font> should behave identically to <font face=3D"couri=
er new, monospace">optional<reference_wrapper<T>></font><wbr>, =
which is to say, almost identically to <font face=3D"courier new, monospace=
">T*</font>.</div><div>Can you add something to your paper explaining (or r=
ehashing) exactly what are the arguments against the above (or N3672-style)=
semantics?</div></div></blockquote><div>=C2=A0<br></div>On the contrary, t=
he copy assignment behaviour for <span style=3D"font-family:monospace,monos=
pace">`optional<T&>`</span> proposed by <i>N3672</i> was unusuall=
y different from that of <span style=3D"font-family:monospace,monospace">`o=
ptional<T>`</span>. The copy assignment semantics of <span style=3D"f=
ont-family:monospace,monospace">`optional<T>`</span> reflect the copy=
assignment semantics of <span style=3D"font-family:monospace,monospace">`T=
`</span>: <span style=3D"font-family:monospace,monospace">`optional<int&=
gt;`</span> has the same copy assignment semantics as <span style=3D"font-f=
amily:monospace,monospace">`int`</span> (value semantics) and <span style=
=3D"font-family:monospace,monospace">`optional<int*>`</span> has the =
same copy assignment semantics as <span style=3D"font-family:monospace,mono=
space">`int*`</span> (reference semantics);</div></div></div></blockquote><=
/span><div><br>No it doesn't. `optional<int*>` and `int*` both ha=
ve value semantics, with respect to the object in question. That object bei=
ng a <i>pointer</i>.<br></div></div></blockquote><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex"><div>=C2=A0</div></blockquote><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div dir=3D"ltr"><div>It only has reference se=
mantics with respect to the object being pointed to. But that's fundame=
ntally no different than `optional<int>`, if that `int` just so happe=
ns to be a handle into some system that represents an object. `optional<=
int>` still has value semantics in that case.<br></div></div></blockquot=
e><div>=C2=A0</div><div>I'm using the <a href=3D"https://isocpp.org/wik=
i/faq/value-vs-ref-semantics#val-vs-ref-semantics">terminology</a> as defin=
ed by the isocpp website. Yeah, technically only initialization of <span st=
yle=3D"font-family:monospace,monospace">`T&`</span>
has true reference semantics and everything else in C++ has value=20
semantics. But this is nitpicking and is totally irrelevant to the issue
at hand.<br><br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div dir=3D"ltr"><div>It's questions like this that make me feel that `o=
ptional` references are a <i>terrible</i> idea. Some people will expect it =
to have one behavior, others will expect it to have a contradictory one, an=
d in the end only one side will be happy.</div></div></blockquote><div><br>=
</div><div>The expectation that copy assignment of <span style=3D"font-fami=
ly:monospace,monospace">`optional<T&>`</span> have the same seman=
tics as copy assignment of <span style=3D"font-family:monospace,monospace">=
`T*`</span> is, in my opinion, a result of the erroneous belief that the in=
ability to rebind <span style=3D"font-family:monospace,monospace">`T&`<=
/span> is somehow a bug in its design, that it is somehow reasonable to thi=
nk of <span style=3D"font-family:monospace,monospace">`T&`</span> as a =
<span style=3D"font-family:monospace,monospace">`T*`</span> that cannot be =
null. It seems that <span style=3D"font-family:monospace,monospace">`option=
al<T&>`</span> is seen as an opportunity to "fix" this =
bug by allowing <span style=3D"font-family:monospace,monospace">`T&`</s=
pan> to be rebound by defining pointer-like copy assignment semantics. The =
problem is that the inability to rebind <span style=3D"font-family:monospac=
e,monospace">`T&`</span> is <i>not</i> a bug; it is a feature. A <span =
style=3D"font-family:monospace,monospace">`T&`</span> is essentially an=
alias of an existing object of type <span style=3D"font-family:monospace,m=
onospace">`T`</span>, and behaves in almost every way like an object of typ=
e <span style=3D"font-family:monospace,monospace">`T`</span>, <i>including<=
/i> copy assignment.<br><br></div><div>I believe that there is an <i>object=
ive</i> case to be made <i>against</i> giving <span style=3D"font-family:mo=
nospace,monospace">`optional<T&>`</span> reference copy assignmen=
t semantics. It makes no more sense for <span style=3D"font-family:monospac=
e,monospace">`optional<T&>`</span> to have pointer-like copy assi=
gnment behaviour that it would for <span style=3D"font-family:monospace,mon=
ospace">`tuple<T&>`</span> to have pointer-like copy assignment b=
ehaviour (which it doesn't). <span style=3D"font-family:monospace,monos=
pace">`optional<T>`</span> is conceptually a <i>container</i> of <spa=
n style=3D"font-family:monospace,monospace">`T`</span> and it should behave=
as such.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><div>Coupled with the fact that `T*` works adeq=
uately as an `optional<T&>`, and I just don't see the need fo=
r it.<br></div></div></blockquote><div><br></div><div>I outline four ways i=
n which <span style=3D"font-family:monospace,monospace">`T*`</span> is inad=
equate in my paper.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><div dir=3D"ltr"><div></div><span class=3D"gmail-"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div c=
lass=3D"gmail_quote">why then should <span style=3D"font-family:monospace,m=
onospace">`optional<int&>`</span> have the same copy assignment s=
emantics as <span style=3D"font-family:monospace,monospace">`int*`</span>? =
This is inconsistent and potentially surprising behaviour. <span style=3D"f=
ont-family:monospace,monospace">`T&`</span> cannot be rebound after ini=
tialization, so neither should <span style=3D"font-family:monospace,monospa=
ce">`optional<T&>`</span>.<br></div></div></div></blockquote><div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><br></blockquote></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div=
class=3D"gmail_quote"></div><div>The problem, as explained in my paper, is=
that the nature of <span style=3D"font-family:monospace,monospace">`option=
al<T>`</span> makes it impossible to give <span style=3D"font-family:=
monospace,monospace">`optional<int&>`</span> the same copy assign=
ment behaviour as <span style=3D"font-family:monospace,monospace">`int&=
`</span>. At best, we can give it an unholy mixture of value and reference =
semantics that depend on the initial state of the <span style=3D"font-famil=
y:monospace,monospace">`optional<int&>`</span>. Thus, the only re=
asonable option left to us is to disable copy assignment altogether.<br><br=
>I will try to present my argument more clearly in the next draft.<br><br><=
/div><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr=
"><div>N3672 has some discussion of copy assignment; but of course it doesn=
't contain any discussion of the reasons it itself was rejected, and it=
's <i>those</i> reasons that your paper is building on top of, right?</=
div><div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013=
/n3672.html#optional_ref.rationale.assign" rel=3D"nofollow" target=3D"_blan=
k">http://www.open-std.org/jtc1/s<wbr>c22/wg21/docs/papers/2013/n367<wbr>2.=
html#optional_ref.rationale.<wbr>assign</a><br></div></div></blockquote><di=
v>=C2=A0<br></div><div>Yes, I mentioned that they gave no reasoning for the=
general consensus that <span style=3D"font-family:monospace,monospace">`op=
tional<T&>`</span> should be copy assignable. I would certainly l=
ike to know, but I have a feeling it was along the lines of ,"<span st=
yle=3D"font-family:monospace,monospace">`optional<T&>`</span> <i>=
must</i> be a regular type", which I also address in the paper.=C2=A0<=
/div></div></div></div></blockquote></span><div><br>If you make a specializ=
ation of `optional` that fundamentally behaves differently from `optional`,=
then you're walking straight into the `vector<bool>` problem. On=
ly instead of making just one specialization that's deficient, you'=
re making an <i>entire category </i>of specializations that are different.<=
br></div></div></blockquote><div><br></div><div>Disabling operations that d=
o not make sense or are not possible for a particular type is common practi=
ce. It is not possible to implement assignment of <span style=3D"font-famil=
y:monospace,monospace">`optional<T&>`</span> in a way that is con=
sistent with <span style=3D"font-family:monospace,monospace">`optional<T=
>`</span>, so it should be disabled. Specifying reference semantics woul=
d make copy assignment of <span style=3D"font-family:monospace,monospace">`=
optional<T&>`</span> behave fundamentally differently from `optio=
nal<T>`. I would argue that this is in fact <i>worse</i> than <span s=
tyle=3D"font-family:monospace,monospace">`vector<bool>`</span>: at le=
ast with <span style=3D"font-family:monospace,monospace">`vector<bool>=
;`</span> any programming errors are likely to be caught at compile-time.<b=
r></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr"><div>If my function takes an `optional<T>`, where `T=
` is deduced or some such, I shouldn't have to worry that some nitwit i=
s going to come along as instantiate it with `T&`. I should not have to=
guard this function with `enable_if` or `requires` just to be able to ensu=
re sane behavior.<br></div></div></blockquote><div><br></div><div>If you in=
discriminately take an <span style=3D"font-family:monospace,monospace">`opt=
ional<T>`</span> for all <span style=3D"font-family:monospace,monospa=
ce">`T`</span> then you are likely to run into problems regardless of wheth=
er <span style=3D"font-family:monospace,monospace">`T`</span> can be a refe=
rence type, just as if you indiscriminately take a <span style=3D"font-fami=
ly:monospace,monospace">`T`</span>. Concepts will make this problem easier =
to manage. Even so, if my code expects <span style=3D"font-family:monospace=
,monospace">`optional<T>`</span> to be copy assignable, then you will=
get a compile-time error if <span style=3D"font-family:monospace,monospace=
">`T`</span> is a reference type (you would get a run-time bug if <span sty=
le=3D"font-family:monospace,monospace">`optional<T&>`</span> had =
reference copy assignment semantics).<br></div><div>=C2=A0</div><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>If you're =
going to change aspects of the type's interface like that, then I would=
prefer that you just made a new type with a compatible interface. Then you=
can come up with an "Nullable" concept that matches it. There=
9;s no reason to name this type `optional`.<br></div></div></blockquote><di=
v><br></div><div>I'm not changing aspects of the interface. I'm dis=
abling features that cannot be implemented for a particular type. As I ment=
ioned, this is standard practice throughout the standard library.<br></div>=
</div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHocnE-Z%2BJxVpQrv99EOsaJwsPWh9b%3Dt=
YZncW24qG%2BfFpuNVig%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHocnE-Z%2=
BJxVpQrv99EOsaJwsPWh9b%3DtYZncW24qG%2BfFpuNVig%40mail.gmail.com</a>.<br />
--001a11c159dcc67f000549b7b24e--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 1 Mar 2017 21:19:27 -0800 (PST)
Raw View
------=_Part_62_106725106.1488431967613
Content-Type: multipart/alternative;
boundary="----=_Part_63_1969553516.1488431967614"
------=_Part_63_1969553516.1488431967614
Content-Type: text/plain; charset=UTF-8
On Wednesday, March 1, 2017 at 11:16:52 PM UTC-5, Joseph Thomson wrote:
>
> On Thu, Mar 2, 2017 at 11:18 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> On Wednesday, March 1, 2017 at 9:36:22 PM UTC-5, Joseph Thomson wrote:
>>>
>>> On Thu, Mar 2, 2017 at 8:00 AM, Arthur O'Dwyer <arthur....@gmail.com>
>>> wrote:
>>>
>>>> On Tuesday, February 28, 2017 at 5:57:35 PM UTC-8, joseph....@gmail.com
>>>> wrote:
>>>>
>>> However, I don't understand why you'd want optional<T&> to behave so
>>>> unusually differently from optional<T> w.r.t. copy assignment and
>>>> such. IMNSHO, optional<T&> should behave identically to
>>>> optional<reference_wrapper<T>>, which is to say, almost identically to
>>>> T*.
>>>> Can you add something to your paper explaining (or rehashing) exactly
>>>> what are the arguments against the above (or N3672-style) semantics?
>>>>
>>>
>>> On the contrary, the copy assignment behaviour for `optional<T&>`
>>> proposed by *N3672* was unusually different from that of `optional<T>`.
>>> The copy assignment semantics of `optional<T>` reflect the copy
>>> assignment semantics of `T`: `optional<int>` has the same copy
>>> assignment semantics as `int` (value semantics) and `optional<int*>`
>>> has the same copy assignment semantics as `int*` (reference semantics);
>>>
>>
>> No it doesn't. `optional<int*>` and `int*` both have value semantics,
>> with respect to the object in question. That object being a *pointer*.
>>
>
>>
> It only has reference semantics with respect to the object being pointed
>> to. But that's fundamentally no different than `optional<int>`, if that
>> `int` just so happens to be a handle into some system that represents an
>> object. `optional<int>` still has value semantics in that case.
>>
>
> I'm using the terminology
> <https://isocpp.org/wiki/faq/value-vs-ref-semantics#val-vs-ref-semantics>
> as defined by the isocpp website. Yeah, technically only initialization of
> `T&` has true reference semantics and everything else in C++ has value
> semantics. But this is nitpicking and is totally irrelevant to the issue at
> hand.
>
No, it's actually very relevant to the issue at hand. It shows that
`optional<T*>` is at its core a very different thing from `optional<T&>`.
It reinforces that references are not values. It reinforces the idea that
`optional` is a value type, and therefore should only be able to contain
other value types.
You want to put a non-value type into a type that is meant to contain
values.
It's questions like this that make me feel that `optional` references are a
>> *terrible* idea. Some people will expect it to have one behavior, others
>> will expect it to have a contradictory one, and in the end only one side
>> will be happy.
>>
>
> The expectation that copy assignment of `optional<T&>` have the same
> semantics as copy assignment of `T*` is, in my opinion, a result of the
> erroneous belief that the inability to rebind `T&` is somehow a bug in
> its design, that it is somehow reasonable to think of `T&` as a `T*` that
> cannot be null. It seems that `optional<T&>` is seen as an opportunity to
> "fix" this bug by allowing `T&` to be rebound by defining pointer-like
> copy assignment semantics. The problem is that the inability to rebind
> `T&` is *not* a bug; it is a feature. A `T&` is essentially an alias of
> an existing object of type `T`, and behaves in almost every way like an
> object of type `T`, *including* copy assignment.
>
> I believe that there is an *objective* case to be made *against* giving
> `optional<T&>` reference copy assignment semantics.
>
It's easy to declare that your subjective opinion is objective, but that
doesn't make it true. There are just as many people who *want* rebindable
references as those who think rebinding is bad. And they can make arguments
for it too. I fail to see how your argument is any more objective than
theirs.
My problem with the whole `optional<T&>` discussion is that it boils down
to 3 choices:
1) Break `optional<T&>`'s interface, thus effectively making it a new type
(see below), but we'll keep the same name for some reason.
2) Make `optional<T&>`'s assignment operator rebind the reference, thus
making it effectively equivalent to `operator<T*>`.
3) Make `optional<T&>`s assignment operator only rebind the reference if
the optional is disengaged, thus creating wildly inconsistent behavior.
To me, all of these are *equally* bad. I'll take the problems with `T*`
over those choices any day of the week.
It makes no more sense for `optional<T&>` to have pointer-like copy
> assignment behaviour that it would for `tuple<T&>` to have pointer-like
> copy assignment behaviour (which it doesn't). `optional<T>` is
> conceptually a *container* of `T` and it should behave as such.
>
We don't allow containers of references. Nor `any`, or `variant`. And
you've essentially outlined why: because either we make them behave like
T*, or we make `optional` fundamentally different from the expected
interface.
Coupled with the fact that `T*` works adequately as an `optional<T&>`, and
>> I just don't see the need for it.
>>
>
> I outline four ways in which `T*` is inadequate in my paper.
>
I found them no more compelling coming from your paper than I have from
other people's statements.
why then should `optional<int&>` have the same copy assignment semantics as
>>> `int*`? This is inconsistent and potentially surprising behaviour. `T&`
>>> cannot be rebound after initialization, so neither should `optional<T&>`
>>> .
>>>
>>
>>> The problem, as explained in my paper, is that the nature of
>>> `optional<T>` makes it impossible to give `optional<int&>` the same
>>> copy assignment behaviour as `int&`. At best, we can give it an unholy
>>> mixture of value and reference semantics that depend on the initial state
>>> of the `optional<int&>`. Thus, the only reasonable option left to us is
>>> to disable copy assignment altogether.
>>>
>>> I will try to present my argument more clearly in the next draft.
>>>
>>> N3672 has some discussion of copy assignment; but of course it doesn't
>>>> contain any discussion of the reasons it itself was rejected, and it's
>>>> *those* reasons that your paper is building on top of, right?
>>>>
>>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html#optional_ref.rationale.assign
>>>>
>>>
>>> Yes, I mentioned that they gave no reasoning for the general consensus
>>> that `optional<T&>` should be copy assignable. I would certainly like
>>> to know, but I have a feeling it was along the lines of ,"`optional<T&>`
>>> *must* be a regular type", which I also address in the paper.
>>>
>>
>> If you make a specialization of `optional` that fundamentally behaves
>> differently from `optional`, then you're walking straight into the
>> `vector<bool>` problem. Only instead of making just one specialization
>> that's deficient, you're making an *entire category *of specializations
>> that are different.
>>
>
> Disabling operations that do not make sense or are not possible for a
> particular type is common practice.
>
Every `optional` can be empty; that's a fundamental part of its interface.
But also fundamental is that every non-const `optional` can be *made empty*
if it wasn't. Also, every non-const `optional` can be given a new value,
even if it has one. These are fundamental parts of the interface.
In your world, there are two types of `optional`s: those which are mutable
and those which are not. I see no reason why an immutable `optional` should
be spelled `optional`. The ability to destroy and recreate what gets stored
there is *not* optional.
That's why I compare it to `vector<bool>`; because code that uses it must
treat it in a completely different way. Whereas code that uses a
`vector<T>` for some move-only type simply has to avoid `insert` and other
copying functions. You can still put things into the sequence and remove
things from the sequence. You still have that level of control.
If you make a `vector<T>` for an immobile type, then `vector` becomes
dysfunctional.
> It is not possible to implement assignment of `optional<T&>` in a way
> that is consistent with `optional<T>`, so it should be disabled.
> Specifying reference semantics would make copy assignment of
> `optional<T&>` behave fundamentally differently from `optional<T>`. I
> would argue that this is in fact *worse* than `vector<bool>`: at least
> with `vector<bool>` any programming errors are likely to be caught at
> compile-time.
>
>
>> If my function takes an `optional<T>`, where `T` is deduced or some such,
>> I shouldn't have to worry that some nitwit is going to come along as
>> instantiate it with `T&`. I should not have to guard this function with
>> `enable_if` or `requires` just to be able to ensure sane behavior.
>>
>
> If you indiscriminately take an `optional<T>` for all `T` then you are
> likely to run into problems regardless of whether `T` can be a reference
> type, just as if you indiscriminately take a `T`.
>
Nonsense. As previously stated, there are many operations on `optional`
that don't care about the characteristics of `T`. You remove several of
them, which transforms the object into something else. It becomes
immutable, when before it was a mutable type.
Just like `vector<bool>` stops being a contiguous array of `T`s.
> Concepts will make this problem easier to manage. Even so, if my code
> expects `optional<T>` to be copy assignable, then you will get a
> compile-time error if `T` is a reference type (you would get a run-time
> bug if `optional<T&>` had reference copy assignment semantics).
>
So, why should I clutter up my code with needless `enable_if/requires`
clauses just to stop you from passing me something I don't want to deal
with? Wouldn't it make sense to make this a new type with its own name, so
that users who want to pass optional references can do so?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/61143db4-f213-4339-ae53-721f25f1a088%40isocpp.org.
------=_Part_63_1969553516.1488431967614
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, March 1, 2017 at 11:16:52 PM UTC-5, Joseph T=
homson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote">On Thu, Mar 2, 2017 at 11:18 AM, Nicol Bola=
s <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"f7tWzBTdCQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;javascript:';return true;" onclick=3D"this.href=3D'javascript:&=
#39;;return true;">jmck...@gmail.com</a>></span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">On Wednesday, March 1=
, 2017 at 9:36:22 PM UTC-5, Joseph Thomson wrote:<span><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quo=
te">On Thu, Mar 2, 2017 at 8:00 AM, Arthur O'Dwyer <span dir=3D"ltr">&l=
t;<a rel=3D"nofollow">arthur....@gmail.com</a>></span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span>On Tuesda=
y, February 28, 2017 at 5:57:35 PM UTC-8, <a>joseph....@gmail.com</a> wrote=
:</span></div></blockquote><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div dir=3D"ltr"><div>However, I don't understand why you'd want =
<font face=3D"courier new, monospace">optional<T&></font> to beha=
ve so unusually differently from <font face=3D"courier new, monospace">opti=
onal<T></font> w.r.t. copy assignment and such. IMNSHO, <font face=3D=
"courier new, monospace">optional<T&></font> should behave identi=
cally to <font face=3D"courier new, monospace">optional<reference_wrappe=
r<T>></font><wbr>, which is to say, almost identically to <font fa=
ce=3D"courier new, monospace">T*</font>.</div><div>Can you add something to=
your paper explaining (or rehashing) exactly what are the arguments agains=
t the above (or N3672-style) semantics?</div></div></blockquote><div>=C2=A0=
<br></div>On the contrary, the copy assignment behaviour for <span style=3D=
"font-family:monospace,monospace">`optional<T&>`</span> proposed =
by <i>N3672</i> was unusually different from that of <span style=3D"font-fa=
mily:monospace,monospace">`optional<T>`</span>. The copy assignment s=
emantics of <span style=3D"font-family:monospace,monospace">`optional<T&=
gt;`</span> reflect the copy assignment semantics of <span style=3D"font-fa=
mily:monospace,monospace">`T`</span>: <span style=3D"font-family:monospace,=
monospace">`optional<int>`</span> has the same copy assignment semant=
ics as <span style=3D"font-family:monospace,monospace">`int`</span> (value =
semantics) and <span style=3D"font-family:monospace,monospace">`optional<=
;int*>`</span> has the same copy assignment semantics as <span style=3D"=
font-family:monospace,monospace">`int*`</span> (reference semantics);</div>=
</div></div></blockquote></span><div><br>No it doesn't. `optional<in=
t*>` and `int*` both have value semantics, with respect to the object in=
question. That object being a <i>pointer</i>.<br></div></div></blockquote>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div>=C2=A0</div></blockq=
uote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><di=
v>It only has reference semantics with respect to the object being pointed =
to. But that's fundamentally no different than `optional<int>`, i=
f that `int` just so happens to be a handle into some system that represent=
s an object. `optional<int>` still has value semantics in that case.<=
br></div></div></blockquote><div>=C2=A0</div><div>I'm using the <a href=
=3D"https://isocpp.org/wiki/faq/value-vs-ref-semantics#val-vs-ref-semantics=
" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https:=
//www.google.com/url?q\x3dhttps%3A%2F%2Fisocpp.org%2Fwiki%2Ffaq%2Fvalue-vs-=
ref-semantics%23val-vs-ref-semantics\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQj=
CNFTMxAN3_znBPVhhX_Lf-HFw6wVLg';return true;" onclick=3D"this.href=3D&#=
39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fisocpp.org%2Fwiki%2Ffaq%2F=
value-vs-ref-semantics%23val-vs-ref-semantics\x26sa\x3dD\x26sntz\x3d1\x26us=
g\x3dAFQjCNFTMxAN3_znBPVhhX_Lf-HFw6wVLg';return true;">terminology</a> =
as defined by the isocpp website. Yeah, technically only initialization of =
<span style=3D"font-family:monospace,monospace">`T&`</span>
has true reference semantics and everything else in C++ has value=20
semantics. But this is nitpicking and is totally irrelevant to the issue
at hand.<br></div></div></div></div></blockquote><div><br>No, it's act=
ually very relevant to the issue at hand. It shows that `optional<T*>=
` is at its core a very different thing from `optional<T&>`. It r=
einforces that references are not values. It reinforces the idea that `opti=
onal` is a value type, and therefore should only be able to contain other v=
alue types.<br><br>You want to put a non-value type into a type that is mea=
nt to contain values.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div> </div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>It's qu=
estions like this that make me feel that `optional` references are a <i>ter=
rible</i> idea. Some people will expect it to have one behavior, others wil=
l expect it to have a contradictory one, and in the end only one side will =
be happy.</div></div></blockquote><div><br></div><div>The expectation that =
copy assignment of <span style=3D"font-family:monospace,monospace">`optiona=
l<T&>`</span> have the same semantics as copy assignment of <span=
style=3D"font-family:monospace,monospace">`T*`</span> is, in my opinion, a=
result of the erroneous belief that the inability to rebind <span style=3D=
"font-family:monospace,monospace">`T&`</span> is somehow a bug in its d=
esign, that it is somehow reasonable to think of <span style=3D"font-family=
:monospace,monospace">`T&`</span> as a <span style=3D"font-family:monos=
pace,monospace">`T*`</span> that cannot be null. It seems that <span style=
=3D"font-family:monospace,monospace">`optional<T&>`</span> is see=
n as an opportunity to "fix" this bug by allowing <span style=3D"=
font-family:monospace,monospace">`T&`</span> to be rebound by defining =
pointer-like copy assignment semantics. The problem is that the inability t=
o rebind <span style=3D"font-family:monospace,monospace">`T&`</span> is=
<i>not</i> a bug; it is a feature. A <span style=3D"font-family:monospace,=
monospace">`T&`</span> is essentially an alias of an existing object of=
type <span style=3D"font-family:monospace,monospace">`T`</span>, and behav=
es in almost every way like an object of type <span style=3D"font-family:mo=
nospace,monospace">`T`</span>, <i>including</i> copy assignment.<br></div><=
/div></div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding=
-left: 1ex;"><div><br></div></blockquote><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div=
>I believe that there is an <i>objective</i> case to be made <i>against</i>=
giving <span style=3D"font-family:monospace,monospace">`optional<T&=
>`</span> reference copy assignment semantics.</div></div></div></div></=
blockquote><div><br>It's easy to declare that your subjective opinion i=
s objective, but that doesn't make it true. There are just as many peop=
le who <i>want</i> rebindable references as those who think rebinding is ba=
d. And they can make arguments for it too. I fail to see how your argument =
is any more objective than theirs.<br><br>My problem with the whole `option=
al<T&>` discussion is that it boils down to 3 choices:<br><br>1) =
Break `optional<T&>`'s interface, thus effectively making it =
a new type (see below), but we'll keep the same name for some reason.<b=
r>2) Make `optional<T&>`'s assignment operator rebind the ref=
erence, thus making it effectively equivalent to `operator<T*>`.<br>3=
) Make `optional<T&>`s assignment operator only rebind the refere=
nce if the optional is disengaged, thus creating wildly inconsistent behavi=
or.<br><br>To me, all of these are <i>equally</i> bad. I'll take the pr=
oblems with `T*` over those choices any day of the week.<br><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D=
"gmail_quote"><div>It makes no more sense for <span style=3D"font-family:mo=
nospace,monospace">`optional<T&>`</span> to have pointer-like cop=
y assignment behaviour that it would for <span style=3D"font-family:monospa=
ce,monospace">`tuple<T&>`</span> to have pointer-like copy assign=
ment behaviour (which it doesn't). <span style=3D"font-family:monospace=
,monospace">`optional<T>`</span> is conceptually a <i>container</i> o=
f <span style=3D"font-family:monospace,monospace">`T`</span> and it should =
behave as such.<br></div></div></div></div></blockquote><div><br>We don'=
;t allow containers of references. Nor `any`, or `variant`. And you've =
essentially outlined why: because either we make them behave like T*, or we=
make `optional` fundamentally different from the expected interface.<br><b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>=
<div class=3D"gmail_quote"><div></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"ltr"><div>Coupled with the fact that `T*` works ad=
equately as an `optional<T&>`, and I just don't see the need =
for it.<br></div></div></blockquote><div><br></div><div>I outline four ways=
in which <span style=3D"font-family:monospace,monospace">`T*`</span> is in=
adequate in my paper.</div></div></div></div></blockquote><div><br>I found =
them no more compelling coming from your paper than I have from other peopl=
e's statements.<br><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div> </div><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div></div><span><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div =
class=3D"gmail_quote">why then should <span style=3D"font-family:monospace,=
monospace">`optional<int&>`</span> have the same copy assignment =
semantics as <span style=3D"font-family:monospace,monospace">`int*`</span>?=
This is inconsistent and potentially surprising behaviour. <span style=3D"=
font-family:monospace,monospace">`T&`</span> cannot be rebound after in=
itialization, so neither should <span style=3D"font-family:monospace,monosp=
ace">`optional<T&>`</span>.<br></div></div></div></blockquote><di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><br></blockquote></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><di=
v class=3D"gmail_quote"></div><div>The problem, as explained in my paper, i=
s that the nature of <span style=3D"font-family:monospace,monospace">`optio=
nal<T>`</span> makes it impossible to give <span style=3D"font-family=
:monospace,monospace">`optional<int&>`</span> the same copy assig=
nment behaviour as <span style=3D"font-family:monospace,monospace">`int&=
;`</span>. At best, we can give it an unholy mixture of value and reference=
semantics that depend on the initial state of the <span style=3D"font-fami=
ly:monospace,monospace">`optional<int&>`</span>. Thus, the only r=
easonable option left to us is to disable copy assignment altogether.<br><b=
r>I will try to present my argument more clearly in the next draft.<br><br>=
</div><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"lt=
r"><div>N3672 has some discussion of copy assignment; but of course it does=
n't contain any discussion of the reasons it itself was rejected, and i=
t's <i>those</i> reasons that your paper is building on top of, right?<=
/div><div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/201=
3/n3672.html#optional_ref.rationale.assign" rel=3D"nofollow" target=3D"_bla=
nk" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%=
2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3672.h=
tml%23optional_ref.rationale.assign\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjC=
NFKnJCdNzkiQrODIsLxcsygvCZUwA';return true;" onclick=3D"this.href=3D=
9;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc2=
2%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3672.html%23optional_ref.rationale.assig=
n\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFKnJCdNzkiQrODIsLxcsygvCZUwA'=
;return true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2013=
/<wbr>n3672.html#optional_ref.<wbr>rationale.assign</a><br></div></div></bl=
ockquote><div>=C2=A0<br></div><div>Yes, I mentioned that they gave no reaso=
ning for the general consensus that <span style=3D"font-family:monospace,mo=
nospace">`optional<T&>`</span> should be copy assignable. I would=
certainly like to know, but I have a feeling it was along the lines of ,&q=
uot;<span style=3D"font-family:monospace,monospace">`optional<T&>=
`</span> <i>must</i> be a regular type", which I also address in the p=
aper.=C2=A0</div></div></div></div></blockquote></span><div><br>If you make=
a specialization of `optional` that fundamentally behaves differently from=
`optional`, then you're walking straight into the `vector<bool>`=
problem. Only instead of making just one specialization that's deficie=
nt, you're making an <i>entire category </i>of specializations that are=
different.<br></div></div></blockquote><div><br></div><div>Disabling opera=
tions that do not make sense or are not possible for a particular type is c=
ommon practice.</div></div></div></div></blockquote><div><br>Every `optiona=
l` can be empty; that's a fundamental part of its interface. But also f=
undamental is that every non-const `optional` can be <i>made empty</i> if i=
t wasn't. Also, every non-const `optional` can be given a new value, ev=
en if it has one. These are fundamental parts of the interface.<br><br>In y=
our world, there are two types of `optional`s: those which are mutable and =
those which are not. I see no reason why an immutable `optional` should be =
spelled `optional`. The ability to destroy and recreate what gets stored th=
ere is <i>not</i> optional.<br><br>That's why I compare it to `vector&l=
t;bool>`; because code that uses it must treat it in a completely differ=
ent way. Whereas code that uses a `vector<T>` for some move-only type=
simply has to avoid `insert` and other copying functions. You can still pu=
t things into the sequence and remove things from the sequence. You still h=
ave that level of control.<br><br>If you make a `vector<T>` for an im=
mobile type, then `vector` becomes dysfunctional.<br>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmai=
l_quote"><div>It is not possible to implement assignment of <span style=3D"=
font-family:monospace,monospace">`optional<T&>`</span> in a way t=
hat is consistent with <span style=3D"font-family:monospace,monospace">`opt=
ional<T>`</span>, so it should be disabled. Specifying reference sema=
ntics would make copy assignment of <span style=3D"font-family:monospace,mo=
nospace">`optional<T&>`</span> behave fundamentally differently f=
rom `optional<T>`. I would argue that this is in fact <i>worse</i> th=
an <span style=3D"font-family:monospace,monospace">`vector<bool>`</sp=
an>: at least with <span style=3D"font-family:monospace,monospace">`vector&=
lt;bool>`</span> any programming errors are likely to be caught at compi=
le-time.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><div>If my function takes an `optional<T>=
`, where `T` is deduced or some such, I shouldn't have to worry that so=
me nitwit is going to come along as instantiate it with `T&`. I should =
not have to guard this function with `enable_if` or `requires` just to be a=
ble to ensure sane behavior.<br></div></div></blockquote><div><br></div><di=
v>If you indiscriminately take an <span style=3D"font-family:monospace,mono=
space">`optional<T>`</span> for all <span style=3D"font-family:monosp=
ace,monospace">`T`</span> then you are likely to run into problems regardle=
ss of whether <span style=3D"font-family:monospace,monospace">`T`</span> ca=
n be a reference type, just as if you indiscriminately take a <span style=
=3D"font-family:monospace,monospace">`T`</span>.</div></div></div></div></b=
lockquote><div><br>Nonsense. As previously stated, there are many operation=
s on `optional` that don't care about the characteristics of `T`. You r=
emove several of them, which transforms the object into something else. It =
becomes immutable, when before it was a mutable type.<br><br>Just like `vec=
tor<bool>` stops being a contiguous array of `T`s.<br>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote"><div>Concepts will make this problem easier to manage. Eve=
n so, if my code expects <span style=3D"font-family:monospace,monospace">`o=
ptional<T>`</span> to be copy assignable, then you will get a compile=
-time error if <span style=3D"font-family:monospace,monospace">`T`</span> i=
s a reference type (you would get a run-time bug if <span style=3D"font-fam=
ily:monospace,monospace">`optional<T&>`</span> had reference copy=
assignment semantics).<br></div></div></div></div></blockquote><div><br>So=
, why should I clutter up my code with needless `enable_if/requires` clause=
s just to stop you from passing me something I don't want to deal with?=
Wouldn't it make sense to make this a new type with its own name, so t=
hat users who want to pass optional references can do so?</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/61143db4-f213-4339-ae53-721f25f1a088%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/61143db4-f213-4339-ae53-721f25f1a088=
%40isocpp.org</a>.<br />
------=_Part_63_1969553516.1488431967614--
------=_Part_62_106725106.1488431967613--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Wed, 1 Mar 2017 22:44:02 -0800
Raw View
--f403045f585e3f64660549b9c1fb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Mar 1, 2017 at 6:36 PM, Joseph Thomson <joseph.thomson@gmail.com>
wrote:
> On Thu, Mar 2, 2017 at 8:00 AM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com=
>
> wrote:
>
>> On Tuesday, February 28, 2017 at 5:57:35 PM UTC-8, joseph....@gmail.com
>> wrote:
>>>
>>> Given that the auxiliary proposal for "optional references" in N3672
>>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html>
>>> was not accepted into C++17 (as far as I can tell), I have prepared a d=
raft
>>> proposal (see attached) for an alternative specification of
>>> `optional<T&>` that focuses on the "optional reference" function
>>> parameter use case. I would appreciate any thoughts or feedback.
>>>
>>
>> I also miss optional<T&>, and optional<void> for that matter, because if
>> we had those two things, then we could easily implement the shared state=
of
>> future<X> in terms of optional<X> for all X.
>>
>
> The idea of `optional<void>` strikes me as odd. In what sense can you
> have a value of type `void`? It seems like it would essentially be a
> glorified `bool`.
>
> Do you mean `future::get` would be implemented something like this?
>
> T future<T>::get() {
> wait();
> return *state->value; // `value` is of type `optional<T>`
> }
>
Yes. That is almost EXACTLY the implementation that I would use of
future<T> for any T (void and reference types included). The only change
I'd need to make would be irrelevant-to-the-current-discussion protection
against two threads calling get() simultaneously.
> This feels like shifting the complexity of `future` into `optional` for
> no reason other than to keep the complexity out of `future`. I like it
> when you can simplify higher-level code as a natural result of using
> well-designed low-level components, but `optional<void>` doesn't seem
> like a well-designed feature to me.
>
Why does optional<void> not seem like a well-designed feature to you? What
part of its interface is acceptable to you in the context of future<void>,
but objectionable in the context of optional<void>?
It seems to me that both types model a "possibly nonexistent" T; the only
difference is that future<T> carries a lot of baggage around concurrency
(and thus reference-counting of the shared state), whereas optional<T> does
not. And if we can implement the more complex feature in terms of the
simpler feature, then we win. If we have to repeat all the metaprogramming
in two places (with slightly different SFINAE in each place!), then we lose=
..
>
>
>> However, I don't understand why you'd want optional<T&> to behave so
>> unusually differently from optional<T> w.r.t. copy assignment and such.
>> IMNSHO, optional<T&> should behave identically to
>> optional<reference_wrapper<T>>, which is to say, almost identically to T=
*
>> .
>> Can you add something to your paper explaining (or rehashing) exactly
>> what are the arguments against the above (or N3672-style) semantics?
>>
>
> On the contrary, the copy assignment behaviour for `optional<T&>`
> proposed by *N3672* was unusually different from that of `optional<T>`.
> The copy assignment semantics of `optional<T>` reflect the copy
> assignment semantics of `T`: `optional<int>` has the same copy assignment
> semantics as `int` (value semantics) and `optional<int*>` has the same
> copy assignment semantics as `int*` (reference semantics); why then
> should `optional<int&>` have the same copy assignment semantics as `int*`=
?
> This is inconsistent and potentially surprising behaviour. `T&` cannot be
> rebound after initialization, so neither should `optional<T&>`.
>
Like Nicol, I too think you've got your terms wrong here.
For any type T, optional<T>::operator=3D has value semantics: specifically,
it means "Please make the state of the optional<T> object on the left side
of the =3D sign match the state of the optional<T> object on the right side
of the =3D sign."
So for example
int i, j;
optional<int&> odest =3D anything();
optional<int&> osrc =3D j;
odest =3D osrc;
assert(&(*odest) =3D=3D &j);
The above test case should pass, no matter what value is returned from
anything(). Whether anything() returns make_optional<int&>(i) or
optional<int&>{} is completely irrelevant, because two lines later we
overwrite the value of odest with osrc, which is an engaged optional
containing "reference to j". So after the assignment, we must have that
odest is *also* an engaged optional containing "reference to j".
I'm not sure, but I think you might be getting confused by the levels of
indirection here (e.g. your comment about optional<int*> makes me think
so). I'm distinguishing between
odest =3D osrc; // odest acquires the same value as osrc
and
*odest =3D *osrc; // odest and osrc must both be engaged; the referent
of odest acquires the same value as the referent of osrc
In the former case we are assigning optional<int&> objects. In the latter
case we are assigning between int& references; i.e.
int i, j;
optional<int&> oi =3D i;
optional<int&> oj =3D j;
*oi =3D *oj; // equivalent to `i =3D j`
This is the same way std::reference_wrapper<T> and std::future<T&> work =E2=
=80=94
i.e., value-assigning a reference_wrapper or future *object* is not the
same thing as reference-assigning the *contained reference* =E2=80=94 so I'=
m not
sure where the problem is. If I'm missing something subtle, please
highlight it for me.
If the problem is inconsistency with std::tuple<T&> =E2=80=94 which does
assign-through, as otherwise std::tie() wouldn't work =E2=80=94 well, I'm o=
kay with
that inconsistency. Honestly, as cool as std::tie was in 2011 (and it was
very cool!), I don't think I'd use it at all in new code.
(Obviously I'm assuming that optional<T&> is implemented behind the scenes
in terms of a T*, just like future<T&> and reference_wrapper<T> and
tuple<T&> are today. Furthermore, since references can't be null, we're
free to use the null representation as a "disengaged" marker, so that
sizeof(optional<T&>) can be the same as sizeof(T*). Furthermore,
optional<T&> can be, and should be required to be, trivially copyable, just
like reference_wrapper<T>. Furthermore, I'd like to see it be trivially
destructible, even though reference_wrapper<T> somewhy isn't required to
be.)
=E2=80=93Arthur
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0%2BCN-Oebuoi%2B3rFM0t9xARk%3DLFccR7D3ZumS=
_i32VXmSA%40mail.gmail.com.
--f403045f585e3f64660549b9c1fb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Mar 1, 2017 at 6:36 PM, Joseph Thomson <span dir=
=3D"ltr"><<a href=3D"mailto:joseph.thomson@gmail.com" target=3D"_blank">=
joseph.thomson@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra=
"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On=
Thu, Mar 2, 2017 at 8:00 AM, Arthur O'Dwyer <span dir=3D"ltr"><<a h=
ref=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@=
gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><span class=3D"m_924676599839107641gmail-">On T=
uesday, February 28, 2017 at 5:57:35 PM UTC-8, <a href=3D"mailto:joseph....=
@gmail.com" target=3D"_blank">joseph....@gmail.com</a> wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Given that the auxilia=
ry proposal for "optional references" in <a href=3D"http://www.op=
en-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html" rel=3D"nofollow" tar=
get=3D"_blank">N3672</a> was not accepted into C++17 (as far as I can tell)=
, I have prepared a draft proposal (see attached) for an alternative specif=
ication of <span style=3D"font-family:courier new,monospace">`optional<T=
&>`</span> that focuses on the "optional reference" functi=
on parameter use case. I would appreciate any thoughts or feedback.<br></di=
v></blockquote><div><br></div></span><div>I also miss <font face=3D"courier=
new, monospace">optional<T&></font>, and <font face=3D"courier n=
ew, monospace">optional<void></font> for that matter, because if we h=
ad those two things, then we could easily implement the shared state of <fo=
nt face=3D"courier new, monospace">future<X></font> in terms of <font=
face=3D"courier new, monospace">optional<X></font> for all <font fac=
e=3D"courier new, monospace">X</font>.</div></div></blockquote><div><br></d=
iv></span><div>The idea of <span style=3D"font-family:monospace,monospace">=
`optional<void>`</span> strikes me as odd. In what sense can you have=
a value of type <span style=3D"font-family:monospace,monospace">`void`</sp=
an>? It seems like it would essentially be a glorified <span style=3D"font-=
family:monospace,monospace">`bool`</span>.<br><br>Do you mean <span style=
=3D"font-family:monospace,monospace">`future::get`</span> would be implemen=
ted something like this?<br><br></div><div style=3D"margin-left:40px"><span=
style=3D"font-family:monospace,monospace">T future<T>::get() {<br></=
span></div><div style=3D"margin-left:40px"><span style=3D"font-family:monos=
pace,monospace">=C2=A0 wait();<br></span></div><div style=3D"margin-left:40=
px"><span style=3D"font-family:monospace,monospace">=C2=A0 return *state-&g=
t;value; // `value` is of type `optional<T>`<br></span></div><div><di=
v style=3D"margin-left:40px"><span style=3D"font-family:monospace,monospace=
">}</span></div></div></div></div></div></blockquote><div><br></div><div>Ye=
s. That is almost EXACTLY the implementation that I would use of future<=
T> for any T (void and reference types included). The only change I'=
d need to make would be irrelevant-to-the-current-discussion protection aga=
inst two threads calling get() simultaneously.</div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div c=
lass=3D"gmail_quote"><div>This feels like shifting the complexity of <span =
style=3D"font-family:monospace,monospace">`future`</span> into <span style=
=3D"font-family:monospace,monospace">`optional`</span> for no reason other =
than to keep the complexity out of <span style=3D"font-family:monospace,mon=
ospace">`future`</span>. I like it when you can simplify higher-level code =
as a natural result of using well-designed low-level components, but <span =
style=3D"font-family:monospace,monospace">`optional<void>`</span> doe=
sn't seem like a well-designed feature to me.<br></div></div></div></di=
v></blockquote><div><br></div><div>Why does optional<void> not seem l=
ike a well-designed feature to you? What part of its interface is acceptabl=
e to you in the context of future<void>, but objectionable in the con=
text of optional<void>?</div><div><br></div><div>It seems to me that =
both types model a "possibly nonexistent" T; the only difference =
is that future<T> carries a lot of baggage around concurrency (and th=
us reference-counting of the shared state), whereas optional<T> does =
not.=C2=A0 And if we can implement the more complex feature in terms of the=
simpler feature, then we win. If we have to repeat all the metaprogramming=
in two places (with slightly different SFINAE in each place!), then we los=
e.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv class=3D"gmail_extra"><div class=3D"gmail_quote"><div></div><span class=
=3D""><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv dir=3D"ltr"><div>However, I don't understand why you'd want <fon=
t face=3D"courier new, monospace">optional<T&></font> to behave s=
o unusually differently from <font face=3D"courier new, monospace">optional=
<T></font> w.r.t. copy assignment and such. IMNSHO, <font face=3D"cou=
rier new, monospace">optional<T&></font> should behave identicall=
y to <font face=3D"courier new, monospace">optional<reference_wrapper<=
;T>></font><wbr>, which is to say, almost identically to <font face=
=3D"courier new, monospace">T*</font>.</div><div>Can you add something to y=
our paper explaining (or rehashing) exactly what are the arguments against =
the above (or N3672-style) semantics?</div></div></blockquote><div>=C2=A0<b=
r></div></span>On the contrary, the copy assignment behaviour for <span sty=
le=3D"font-family:monospace,monospace">`optional<T&>`</span> prop=
osed by <i>N3672</i> was unusually different from that of <span style=3D"fo=
nt-family:monospace,monospace">`optional<T>`</span>. The copy assignm=
ent semantics of <span style=3D"font-family:monospace,monospace">`optional&=
lt;T>`</span> reflect the copy assignment semantics of <span style=3D"fo=
nt-family:monospace,monospace">`T`</span>: <span style=3D"font-family:monos=
pace,monospace">`optional<int>`</span> has the same copy assignment s=
emantics as <span style=3D"font-family:monospace,monospace">`int`</span> (v=
alue semantics) and <span style=3D"font-family:monospace,monospace">`option=
al<int*>`</span> has the same copy assignment semantics as <span styl=
e=3D"font-family:monospace,monospace">`int*`</span> (reference semantics); =
why then should <span style=3D"font-family:monospace,monospace">`optional&l=
t;int&>`</span> have the same copy assignment semantics as <span sty=
le=3D"font-family:monospace,monospace">`int*`</span>? This is inconsistent =
and potentially surprising behaviour. <span style=3D"font-family:monospace,=
monospace">`T&`</span> cannot be rebound after initialization, so neith=
er should <span style=3D"font-family:monospace,monospace">`optional<T&am=
p;>`</span>.<br></div></div></div></blockquote><div><br></div><div>Like =
Nicol, I too think you've got your terms wrong here.</div><div>For any =
type T, optional<T>::operator=3D has value semantics: specifically, i=
t means "Please make the state of the optional<T> object on the =
left side of the =3D sign match the state of the optional<T> object o=
n the right side of the =3D sign."</div><div><br></div><div>So for exa=
mple</div><div><br></div><div>=C2=A0 =C2=A0 int i, j;</div><div>=C2=A0 =C2=
=A0 optional<int&> odest =3D anything();</div><div>=C2=A0 =C2=A0 =
optional<int&> osrc =3D j;</div><div>=C2=A0 =C2=A0 odest =3D osrc=
;</div><div>=C2=A0 =C2=A0 assert(&(*odest) =3D=3D &j);</div><div><b=
r></div><div>The above test case should pass, no matter what value is retur=
ned from anything(). Whether anything() returns make_optional<int&&g=
t;(i) or optional<int&>{} is completely irrelevant, because two l=
ines later we overwrite the value of odest with osrc, which is an engaged o=
ptional containing "reference to j". So after the assignment, we =
must have that odest is <i>also</i> an engaged optional containing "re=
ference to j".</div><div><br></div><div>I'm not sure, but I think =
you might be getting confused by the levels of indirection here (e.g. your =
comment about optional<int*> makes me think so). I'm distinguishi=
ng between</div><div><br></div><div>=C2=A0 =C2=A0 odest =3D osrc; =C2=A0// =
odest acquires the same value as osrc</div><div><br></div><div>and</div><di=
v><br></div><div>=C2=A0 =C2=A0 *odest =3D *osrc; =C2=A0// odest and osrc mu=
st both be engaged; the referent of odest acquires the same value as the re=
ferent of osrc</div><div><br></div><div>In the former case we are assigning=
optional<int&> objects. In the latter case we are assigning betw=
een int& references; i.e.</div><div><br></div><div>=C2=A0 =C2=A0 int i,=
j;</div><div>=C2=A0 =C2=A0 optional<int&> oi =3D i;</div><div>=
=C2=A0 =C2=A0 optional<int&> oj =3D j;</div><div>=C2=A0 =C2=A0 *o=
i =3D *oj; =C2=A0// equivalent to `i =3D j`</div><div><br></div><div>This i=
s the same way std::reference_wrapper<T> and std::future<T&>=
; work =E2=80=94 i.e., value-assigning a reference_wrapper or future=C2=A0<=
i>object</i> is not the same thing as reference-assigning the <i>contained =
reference</i> =E2=80=94 so I'm not sure where the problem is. If I'=
m missing something subtle, please highlight it for me.</div><div><br></div=
><div>If the problem is inconsistency with std::tuple<T&> =E2=80=
=94 which does assign-through, as otherwise std::tie() wouldn't work =
=E2=80=94 well, I'm okay with that inconsistency. Honestly, as cool as =
std::tie was in 2011 (and it was very cool!), I don't think I'd use=
it at all in new code.</div><div><br></div><div>(Obviously I'm assumin=
g that optional<T&> is implemented behind the scenes in terms of =
a T*, just like future<T&> and reference_wrapper<T> and tup=
le<T&> are today. Furthermore, since references can't be null=
, we're free to use the null representation as a "disengaged"=
marker, so that sizeof(optional<T&>) can be the same as sizeof(T=
*). Furthermore, optional<T&> can be, and should be required to b=
e, trivially copyable, just like reference_wrapper<T>. Furthermore, I=
'd like to see it be trivially destructible, even though reference_wrap=
per<T> somewhy isn't required to be.)</div><div><br></div><div>=
=E2=80=93Arthur</div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2BCN-Oebuoi%2B3rFM0t9xARk%3DL=
FccR7D3ZumS_i32VXmSA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2BC=
N-Oebuoi%2B3rFM0t9xARk%3DLFccR7D3ZumS_i32VXmSA%40mail.gmail.com</a>.<br />
--f403045f585e3f64660549b9c1fb--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 2 Mar 2017 01:52:08 -0500
Raw View
--f403045ea3e03531fe0549b9de81
Content-Type: text/plain; charset=UTF-8
On Wed, Mar 1, 2017 at 7:00 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:
> On Tuesday, February 28, 2017 at 5:57:35 PM UTC-8, joseph....@gmail.com
> wrote:
>>
>> Given that the auxiliary proposal for "optional references" in N3672
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html> was
>> not accepted into C++17 (as far as I can tell), I have prepared a draft
>> proposal (see attached) for an alternative specification of
>> `optional<T&>` that focuses on the "optional reference" function
>> parameter use case. I would appreciate any thoughts or feedback.
>>
>
> I also miss optional<T&>, and optional<void> for that matter, because if
> we had those two things, then we could easily implement the shared state of
> future<X> in terms of optional<X> for all X.
> However, I don't understand why you'd want optional<T&> to behave so
> unusually differently from optional<T> w.r.t. copy assignment and such.
> IMNSHO, optional<T&> should behave identically to
> optional<reference_wrapper<T>>, which is to say, almost identically to T*.
>
"T& DOES NOT work like reference_wrapper<T>, so optional<T&> SHOULD work
like optional<reference_wrapper<T>>"
I'm not a fan of that (il)logic.
Tony
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbitByVwT1BvhoGcUEdDZMyrvO2v6w6%3DnaXQ7g9DLN-3CLA%40mail.gmail.com.
--f403045ea3e03531fe0549b9de81
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Mar 1, 2017 at 7:00 PM, Arthur O'Dwyer <span dir=3D"ltr">&l=
t;<a href=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.o=
dwyer@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><span class=3D"">On Tuesday, February 28, 2017 at 5:57:35 PM =
UTC-8, <a href=3D"mailto:joseph....@gmail.com" target=3D"_blank">joseph....=
@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r">Given that the auxiliary proposal for "optional references" in=
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.h=
tml" rel=3D"nofollow" target=3D"_blank">N3672</a> was not accepted into C++=
17 (as far as I can tell), I have prepared a draft proposal (see attached) =
for an alternative specification of <span style=3D"font-family:courier new,=
monospace">`optional<T&>`</span> that focuses on the "option=
al reference" function parameter use case. I would appreciate any thou=
ghts or feedback.<br></div></blockquote><div><br></div></span><div>I also m=
iss <font face=3D"courier new, monospace">optional<T&></font>, an=
d <font face=3D"courier new, monospace">optional<void></font> for tha=
t matter, because if we had those two things, then we could easily implemen=
t the shared state of <font face=3D"courier new, monospace">future<X>=
</font> in terms of <font face=3D"courier new, monospace">optional<X>=
</font> for all <font face=3D"courier new, monospace">X</font>.</div><div>H=
owever, I don't understand why you'd want <font face=3D"courier new=
, monospace">optional<T&></font> to behave so unusually different=
ly from <font face=3D"courier new, monospace">optional<T></font> w.r.=
t. copy assignment and such. IMNSHO, <font face=3D"courier new, monospace">=
optional<T&></font> should behave identically to <font face=3D"co=
urier new, monospace">optional<reference_wrapper<T>></font><wbr=
>, which is to say, almost identically to <font face=3D"courier new, monosp=
ace">T*</font>.</div></div></blockquote><div><br><br></div><div>"T&=
; DOES NOT work like reference_wrapper<T>, so optional<T&> =
SHOULD work like optional<reference_wrapper<T>>"<br><br></=
div><div>I'm not a fan of that (il)logic.<br><br></div><div>Tony<br>=C2=
=A0<br></div><br></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbitByVwT1BvhoGcUEdDZMyrvO2v6w6%3=
DnaXQ7g9DLN-3CLA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbitByVwT1B=
vhoGcUEdDZMyrvO2v6w6%3DnaXQ7g9DLN-3CLA%40mail.gmail.com</a>.<br />
--f403045ea3e03531fe0549b9de81--
.
Author: Joseph Thomson <joseph.thomson@gmail.com>
Date: Thu, 2 Mar 2017 16:11:59 +0800
Raw View
--001a11c159dcc4b3960549bafbbc
Content-Type: text/plain; charset=UTF-8
On Thu, Mar 2, 2017 at 1:19 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, March 1, 2017 at 11:16:52 PM UTC-5, Joseph Thomson wrote:
>>
>> On Thu, Mar 2, 2017 at 11:18 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> On Wednesday, March 1, 2017 at 9:36:22 PM UTC-5, Joseph Thomson wrote:
>>>>
>>>> On Thu, Mar 2, 2017 at 8:00 AM, Arthur O'Dwyer <arthur....@gmail.com>
>>>> wrote:
>>>>
>>>>> On Tuesday, February 28, 2017 at 5:57:35 PM UTC-8,
>>>>> joseph....@gmail.com wrote:
>>>>>
>>>> However, I don't understand why you'd want optional<T&> to behave so
>>>>> unusually differently from optional<T> w.r.t. copy assignment and
>>>>> such. IMNSHO, optional<T&> should behave identically to
>>>>> optional<reference_wrapper<T>>, which is to say, almost identically
>>>>> to T*.
>>>>> Can you add something to your paper explaining (or rehashing) exactly
>>>>> what are the arguments against the above (or N3672-style) semantics?
>>>>>
>>>>
>>>> On the contrary, the copy assignment behaviour for `optional<T&>`
>>>> proposed by *N3672* was unusually different from that of `optional<T>`.
>>>> The copy assignment semantics of `optional<T>` reflect the copy
>>>> assignment semantics of `T`: `optional<int>` has the same copy
>>>> assignment semantics as `int` (value semantics) and `optional<int*>`
>>>> has the same copy assignment semantics as `int*` (reference semantics);
>>>>
>>>
>>> No it doesn't. `optional<int*>` and `int*` both have value semantics,
>>> with respect to the object in question. That object being a *pointer*.
>>>
>>
>>>
>> It only has reference semantics with respect to the object being pointed
>>> to. But that's fundamentally no different than `optional<int>`, if that
>>> `int` just so happens to be a handle into some system that represents an
>>> object. `optional<int>` still has value semantics in that case.
>>>
>>
>> I'm using the terminology
>> <https://isocpp.org/wiki/faq/value-vs-ref-semantics#val-vs-ref-semantics>
>> as defined by the isocpp website. Yeah, technically only initialization of
>> `T&` has true reference semantics and everything else in C++ has value
>> semantics. But this is nitpicking and is totally irrelevant to the issue at
>> hand.
>>
>
> No, it's actually very relevant to the issue at hand. It shows that
> `optional<T*>` is at its core a very different thing from `optional<T&>`.
> It reinforces that references are not values. It reinforces the idea that
> `optional` is a value type, and therefore should only be able to contain
> other value types.
>
> You want to put a non-value type into a type that is meant to contain
> values.
>
`optional` is *currently* only defined for value types. I want to define
its behaviour for reference types. It is possible to define `optional<T&>`
to be consistent with the behaviour of `optional<T>`. If this weren't the
case, I would agree with you that it should be a different type.
> It's questions like this that make me feel that `optional` references are
>>> a *terrible* idea. Some people will expect it to have one behavior,
>>> others will expect it to have a contradictory one, and in the end only one
>>> side will be happy.
>>>
>>
>> The expectation that copy assignment of `optional<T&>` have the same
>> semantics as copy assignment of `T*` is, in my opinion, a result of the
>> erroneous belief that the inability to rebind `T&` is somehow a bug in
>> its design, that it is somehow reasonable to think of `T&` as a `T*`
>> that cannot be null. It seems that `optional<T&>` is seen as an
>> opportunity to "fix" this bug by allowing `T&` to be rebound by defining
>> pointer-like copy assignment semantics. The problem is that the inability
>> to rebind `T&` is *not* a bug; it is a feature. A `T&` is essentially an
>> alias of an existing object of type `T`, and behaves in almost every way
>> like an object of type `T`, *including* copy assignment.
>>
>
>> I believe that there is an *objective* case to be made *against* giving
>> `optional<T&>` reference copy assignment semantics.
>>
>
> It's easy to declare that your subjective opinion is objective, but that
> doesn't make it true. There are just as many people who *want* rebindable
> references as those who think rebinding is bad. And they can make arguments
> for it too. I fail to see how your argument is any more objective than
> theirs.
>
Forget the term "objective". I believe my case is superior from the
standpoint of consistency with `optional<T>`. The argument for allowing
`optional<T&>` to be rebound amounts to, "`optional<T&>` should be copy
assignable because regularity is good, despite the fact that `T&` is not
even an object type, that it will require a complete redefinition of copy
assignment for this specialization, that the copy assignment behaviour will
not match that of `T&`, and that `optional<reference_wrapper<T>>` already
fits my use case."
> My problem with the whole `optional<T&>` discussion is that it boils down
> to 3 choices:
>
> 1) Break `optional<T&>`'s interface, thus effectively making it a new type
> (see below), but we'll keep the same name for some reason.
> 2) Make `optional<T&>`'s assignment operator rebind the reference, thus
> making it effectively equivalent to `operator<T*>`.
> 3) Make `optional<T&>`s assignment operator only rebind the reference if
> the optional is disengaged, thus creating wildly inconsistent behavior.
>
I contest the claim that I am breaking the interface. On the contrary, I
believe that option 2 breaks the interface (the `vector<bool>` problem).
> To me, all of these are *equally* bad. I'll take the problems with `T*`
> over those choices any day of the week.
>
> It makes no more sense for `optional<T&>` to have pointer-like copy
>> assignment behaviour that it would for `tuple<T&>` to have pointer-like
>> copy assignment behaviour (which it doesn't). `optional<T>` is
>> conceptually a *container* of `T` and it should behave as such.
>>
>
> We don't allow containers of references. Nor `any`, or `variant`. And
> you've essentially outlined why: because either we make them behave like
> T*, or we make `optional` fundamentally different from the expected
> interface.
>
I'm not talking STL containers obviously. I wouldn't support allowing
references to be stored in `any` because it wouldn't be possible to support
reference-like assignment semantics (and `any` is always copy assignable).
It might be possible to store references in `variant`, but I imagine
specifying its behaviour could get quite complicated. Probably best avoided
unless there is a clear use case (like there is for `optional<T&>`).
Coupled with the fact that `T*` works adequately as an `optional<T&>`, and
>>> I just don't see the need for it.
>>>
>>
>> I outline four ways in which `T*` is inadequate in my paper.
>>
>
> I found them no more compelling coming from your paper than I have from
> other people's statements.
>
I have the additional case that with `optional<T&>`, the rules around "pass
by value vs. pass by reference" and "mandatory vs. optional" become
orthogonal, more consistent, and therefore easier for beginners to learn.
The rules *should* be:
- Add `&` or `const&` to pass by reference
- Add `optional` when the parameter is not mandatory
Instead, the rules are:
- Add `&` or `const&` to pass by reference
- Add `optional` when the parameter is not mandatory
- *Except* when passing by reference *and* when the parameter is not
mandatory, in which case use `T*` instead (oh and, by the way, `T*` has
completely different semantics to `T` and `T&`)
why then should `optional<int&>` have the same copy assignment semantics as
>>>> `int*`? This is inconsistent and potentially surprising behaviour. `T&`
>>>> cannot be rebound after initialization, so neither should
>>>> `optional<T&>`.
>>>>
>>>
>>>> The problem, as explained in my paper, is that the nature of
>>>> `optional<T>` makes it impossible to give `optional<int&>` the same
>>>> copy assignment behaviour as `int&`. At best, we can give it an unholy
>>>> mixture of value and reference semantics that depend on the initial state
>>>> of the `optional<int&>`. Thus, the only reasonable option left to us
>>>> is to disable copy assignment altogether.
>>>>
>>>> I will try to present my argument more clearly in the next draft.
>>>>
>>>> N3672 has some discussion of copy assignment; but of course it doesn't
>>>>> contain any discussion of the reasons it itself was rejected, and it's
>>>>> *those* reasons that your paper is building on top of, right?
>>>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n367
>>>>> 2.html#optional_ref.rationale.assign
>>>>>
>>>>
>>>> Yes, I mentioned that they gave no reasoning for the general consensus
>>>> that `optional<T&>` should be copy assignable. I would certainly like
>>>> to know, but I have a feeling it was along the lines of ,"
>>>> `optional<T&>` *must* be a regular type", which I also address in the
>>>> paper.
>>>>
>>>
>>> If you make a specialization of `optional` that fundamentally behaves
>>> differently from `optional`, then you're walking straight into the
>>> `vector<bool>` problem. Only instead of making just one specialization
>>> that's deficient, you're making an *entire category *of specializations
>>> that are different.
>>>
>>
>> Disabling operations that do not make sense or are not possible for a
>> particular type is common practice.
>>
>
> Every `optional` can be empty; that's a fundamental part of its interface.
> But also fundamental is that every non-const `optional` can be *made
> empty* if it wasn't.
>
True. I don't see any technical reason why assignment from `nullopt_t` and
the `reset` function cannot be defined.
> Also, every non-const `optional` can be given a new value, even if it has
> one. These are fundamental parts of the interface.
>
Not true:
struct foo {
foo& operator=(foo const&) = delete;
};
foo f;
optional<foo const> o;
o = f; // error: use of deleted function
Note that `optional<T>` *could* have been specified to allow copy/move
assignment even if copy/move assignment weren't defined for `T`. The
behaviour of `optional<T>` reflects the behaviour of the contained object.
An `optional` containing a reference gets its copy assignment operator
deleted much like a class containing a reference does, because defining it
would give inconsistent behaviour.
In your world, there are two types of `optional`s: those which are mutable
> and those which are not. I see no reason why an immutable `optional` should
> be spelled `optional`. The ability to destroy and recreate what gets stored
> there is *not* optional.
>
Destroy, yes; recreate, not necessarily (as just demonstrated).
> That's why I compare it to `vector<bool>`; because code that uses it must
> treat it in a completely different way. Whereas code that uses a
> `vector<T>` for some move-only type simply has to avoid `insert` and other
> copying functions. You can still put things into the sequence and remove
> things from the sequence. You still have that level of control.
>
> If you make a `vector<T>` for an immobile type, then `vector` becomes
> dysfunctional.
>
`vector<T>` is not `optional<T>`. `optional<T&>` is perfectly usable even
if it is not copy assignable, much like `vector<T>` is still usable for a
move-only `T`. You can even store `optional<T&>` in containers; you just
get limited functionality (not dysfunctionality).
> It is not possible to implement assignment of `optional<T&>` in a way
>> that is consistent with `optional<T>`, so it should be disabled.
>> Specifying reference semantics would make copy assignment of
>> `optional<T&>` behave fundamentally differently from `optional<T>`. I
>> would argue that this is in fact *worse* than `vector<bool>`: at least
>> with `vector<bool>` any programming errors are likely to be caught at
>> compile-time.
>>
>>
>>> If my function takes an `optional<T>`, where `T` is deduced or some
>>> such, I shouldn't have to worry that some nitwit is going to come along as
>>> instantiate it with `T&`. I should not have to guard this function with
>>> `enable_if` or `requires` just to be able to ensure sane behavior.
>>>
>>
>> If you indiscriminately take an `optional<T>` for all `T` then you are
>> likely to run into problems regardless of whether `T` can be a reference
>> type, just as if you indiscriminately take a `T`.
>>
>
> Nonsense. As previously stated, there are many operations on `optional`
> that don't care about the characteristics of `T`. You remove several of
> them, which transforms the object into something else. It becomes
> immutable, when before it was a mutable type.
>
The copy/move operations of `optional<T>` *do* care about the
characteristics of `T`. Copy construction requires
`is_copy_constructible_v<T>`. Move construction requires
`is_move_constructible_v<T>`. Copy assignment requires
`is_copy_constructible_v<T>
&& is_copy_assignable_v<T>`. Move assignment requires
`is_move_constructible_v<T>
&& is_move_assignable_v<T>`.
> Just like `vector<bool>` stops being a contiguous array of `T`s.
>
>
>> Concepts will make this problem easier to manage. Even so, if my code
>> expects `optional<T>` to be copy assignable, then you will get a
>> compile-time error if `T` is a reference type (you would get a run-time
>> bug if `optional<T&>` had reference copy assignment semantics).
>>
>
> So, why should I clutter up my code with needless `enable_if/requires`
> clauses just to stop you from passing me something I don't want to deal
> with? Wouldn't it make sense to make this a new type with its own name, so
> that users who want to pass optional references can do so?
>
As I've just shown, if you indiscriminately accept an `optional<T>`
parameter for any type `T`, I can pass you any number of types that will
disable the various copy/move operations. Do you have a use case where
`optional<T&>` specifically would cause a problem?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHocnE_1bqkd6SFsa5PZrDO32%2BJfrTZzbnT3WnYr-FQYYW9MHw%40mail.gmail.com.
--001a11c159dcc4b3960549bafbbc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Mar 2, 2017 at 1:19 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D=
"ltr">On Wednesday, March 1, 2017 at 11:16:52 PM UTC-5, Joseph Thomson wrot=
e:<span class=3D"gmail-"><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr"><div><div class=3D"gmail_quote">On Thu, Mar 2, 2017 at 11:=
18 AM, Nicol Bolas <span dir=3D"ltr"><<a rel=3D"nofollow">jmck...@gmail.=
com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr">On Wednesday, March 1, 2017 at 9:36:22 PM UTC-5, Josep=
h Thomson wrote:<span><blockquote class=3D"gmail_quote" style=3D"margin:0px=
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote">On Thu, Mar 2, 2017 at 8:00 A=
M, Arthur O'Dwyer <span dir=3D"ltr"><<a rel=3D"nofollow">arthur....@=
gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><span>On Tuesday, February 28, 2017 at 5:57:35 =
PM UTC-8, <a>joseph....@gmail.com</a> wrote:</span></div></blockquote><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>However,=
I don't understand why you'd want <font face=3D"courier new, monos=
pace">optional<T&></font> to behave so unusually differently from=
<font face=3D"courier new, monospace">optional<T></font> w.r.t. copy=
assignment and such. IMNSHO, <font face=3D"courier new, monospace">optiona=
l<T&></font> should behave identically to <font face=3D"courier n=
ew, monospace">optional<reference_wrapper<T>></font><wbr>, whic=
h is to say, almost identically to <font face=3D"courier new, monospace">T*=
</font>.</div><div>Can you add something to your paper explaining (or rehas=
hing) exactly what are the arguments against the above (or N3672-style) sem=
antics?</div></div></blockquote><div>=C2=A0<br></div>On the contrary, the c=
opy assignment behaviour for <span style=3D"font-family:monospace,monospace=
">`optional<T&>`</span> proposed by <i>N3672</i> was unusually di=
fferent from that of <span style=3D"font-family:monospace,monospace">`optio=
nal<T>`</span>. The copy assignment semantics of <span style=3D"font-=
family:monospace,monospace">`optional<T>`</span> reflect the copy ass=
ignment semantics of <span style=3D"font-family:monospace,monospace">`T`</s=
pan>: <span style=3D"font-family:monospace,monospace">`optional<int>`=
</span> has the same copy assignment semantics as <span style=3D"font-famil=
y:monospace,monospace">`int`</span> (value semantics) and <span style=3D"fo=
nt-family:monospace,monospace">`optional<int*>`</span> has the same c=
opy assignment semantics as <span style=3D"font-family:monospace,monospace"=
>`int*`</span> (reference semantics);</div></div></div></blockquote></span>=
<div><br>No it doesn't. `optional<int*>` and `int*` both have val=
ue semantics, with respect to the object in question. That object being a <=
i>pointer</i>.<br></div></div></blockquote><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex"><div>=C2=A0</div></blockquote><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex"><div dir=3D"ltr"><div>It only has reference semantic=
s with respect to the object being pointed to. But that's fundamentally=
no different than `optional<int>`, if that `int` just so happens to =
be a handle into some system that represents an object. `optional<int>=
;` still has value semantics in that case.<br></div></div></blockquote><div=
>=C2=A0</div><div>I'm using the <a href=3D"https://isocpp.org/wiki/faq/=
value-vs-ref-semantics#val-vs-ref-semantics" rel=3D"nofollow" target=3D"_bl=
ank">terminology</a> as defined by the isocpp website. Yeah, technically on=
ly initialization of <span style=3D"font-family:monospace,monospace">`T&=
;`</span>
has true reference semantics and everything else in C++ has value=20
semantics. But this is nitpicking and is totally irrelevant to the issue
at hand.<br></div></div></div></div></blockquote></span><div><br>No, it=
9;s actually very relevant to the issue at hand. It shows that `optional<=
;T*>` is at its core a very different thing from `optional<T&>=
`. It reinforces that references are not values. It reinforces the idea tha=
t `optional` is a value type, and therefore should only be able to contain =
other value types.<br><br>You want to put a non-value type into a type that=
is meant to contain values.<br></div></div></blockquote><div><br></div><di=
v><span style=3D"font-family:monospace,monospace">`optional`</span> is <i>c=
urrently</i> only defined for value types. I want to define its behaviour f=
or reference types. It is possible to define <span style=3D"font-family:mon=
ospace,monospace">`optional<T&>`</span> to be consistent with the=
behaviour of <span style=3D"font-family:monospace,monospace">`optional<=
T>`</span>. If this weren't the case, I would agree with you that it=
should be a different type.<br></div><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex"><div dir=3D"ltr"><span class=3D"gmail-"><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div cla=
ss=3D"gmail_quote"><div> </div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr"><div>It's questions like this that make me feel =
that `optional` references are a <i>terrible</i> idea. Some people will exp=
ect it to have one behavior, others will expect it to have a contradictory =
one, and in the end only one side will be happy.</div></div></blockquote><d=
iv><br></div><div>The expectation that copy assignment of <span style=3D"fo=
nt-family:monospace,monospace">`optional<T&>`</span> have the sam=
e semantics as copy assignment of <span style=3D"font-family:monospace,mono=
space">`T*`</span> is, in my opinion, a result of the erroneous belief that=
the inability to rebind <span style=3D"font-family:monospace,monospace">`T=
&`</span> is somehow a bug in its design, that it is somehow reasonable=
to think of <span style=3D"font-family:monospace,monospace">`T&`</span=
> as a <span style=3D"font-family:monospace,monospace">`T*`</span> that can=
not be null. It seems that <span style=3D"font-family:monospace,monospace">=
`optional<T&>`</span> is seen as an opportunity to "fix"=
; this bug by allowing <span style=3D"font-family:monospace,monospace">`T&a=
mp;`</span> to be rebound by defining pointer-like copy assignment semantic=
s. The problem is that the inability to rebind <span style=3D"font-family:m=
onospace,monospace">`T&`</span> is <i>not</i> a bug; it is a feature. A=
<span style=3D"font-family:monospace,monospace">`T&`</span> is essenti=
ally an alias of an existing object of type <span style=3D"font-family:mono=
space,monospace">`T`</span>, and behaves in almost every way like an object=
of type <span style=3D"font-family:monospace,monospace">`T`</span>, <i>inc=
luding</i> copy assignment.<br></div></div></div></div></blockquote><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div><br></div></blockquote><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div cl=
ass=3D"gmail_quote"><div></div><div>I believe that there is an <i>objective=
</i> case to be made <i>against</i> giving <span style=3D"font-family:monos=
pace,monospace">`optional<T&>`</span> reference copy assignment s=
emantics.</div></div></div></div></blockquote></span><div><br>It's easy=
to declare that your subjective opinion is objective, but that doesn't=
make it true. There are just as many people who <i>want</i> rebindable ref=
erences as those who think rebinding is bad. And they can make arguments fo=
r it too. I fail to see how your argument is any more objective than theirs=
..<br></div></div></blockquote><div><br></div><div>Forget the term "obj=
ective". I believe my case is superior from the standpoint of consiste=
ncy with <span style=3D"font-family:monospace,monospace">`optional<T>=
`</span>. The argument for allowing <span style=3D"font-family:monospace,mo=
nospace">`optional<T&>`</span> to be rebound amounts to, "<s=
pan style=3D"font-family:monospace,monospace">`optional<T&>`</spa=
n> should be copy assignable because regularity is good, despite the fact t=
hat <span style=3D"font-family:monospace,monospace">`T&`</span> is not =
even an object type, that it will require a complete redefinition of copy a=
ssignment for this specialization, that the copy assignment behaviour will =
not match that of <span style=3D"font-family:monospace,monospace">`T&`<=
/span>, and that <span style=3D"font-family:monospace,monospace">`optional&=
lt;reference_wrapper<T>>`</span> already fits my use case."<b=
r></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr"><div>My problem with the whole `optional<T&>` di=
scussion is that it boils down to 3 choices:<br><br>1) Break `optional<T=
&>`'s interface, thus effectively making it a new type (see belo=
w), but we'll keep the same name for some reason.<br>2) Make `optional&=
lt;T&>`'s assignment operator rebind the reference, thus making =
it effectively equivalent to `operator<T*>`.<br>3) Make `optional<=
T&>`s assignment operator only rebind the reference if the optional =
is disengaged, thus creating wildly inconsistent behavior.<br></div></div><=
/blockquote><div><br></div><div>I contest the claim that I am breaking the =
interface. On the contrary, I believe that option 2 breaks the interface (t=
he <span style=3D"font-family:monospace,monospace">`vector<bool>`</sp=
an> problem).<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><div>To me, all of these are <i>equally</i>=
bad. I'll take the problems with `T*` over those choices any day of th=
e week.<br><br></div><span class=3D"gmail-"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>It=
makes no more sense for <span style=3D"font-family:monospace,monospace">`o=
ptional<T&>`</span> to have pointer-like copy assignment behaviou=
r that it would for <span style=3D"font-family:monospace,monospace">`tuple&=
lt;T&>`</span> to have pointer-like copy assignment behaviour (which=
it doesn't). <span style=3D"font-family:monospace,monospace">`optional=
<T>`</span> is conceptually a <i>container</i> of <span style=3D"font=
-family:monospace,monospace">`T`</span> and it should behave as such.<br></=
div></div></div></div></blockquote></span><div><br>We don't allow conta=
iners of references. Nor `any`, or `variant`. And you've essentially ou=
tlined why: because either we make them behave like T*, or we make `optiona=
l` fundamentally different from the expected interface.<br></div></div></bl=
ockquote><div>=C2=A0<br></div><div>I'm not talking STL containers obvio=
usly. I wouldn't support allowing references to be stored in <span styl=
e=3D"font-family:monospace,monospace">`any`</span> because it wouldn't =
be possible to support reference-like assignment semantics (and <span style=
=3D"font-family:monospace,monospace">`any`</span> is always copy assignable=
). It might be possible to store references in <span style=3D"font-family:m=
onospace,monospace">`variant`</span>, but I imagine specifying its behaviou=
r could get quite complicated. Probably best avoided unless there is a clea=
r use case (like there is for <span style=3D"font-family:monospace,monospac=
e">`optional<T&>`</span>).<br></div><div><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span class=3D"gmail-"=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><d=
iv class=3D"gmail_quote"><div></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><div>Coupled with the fact that `T*` works adeq=
uately as an `optional<T&>`, and I just don't see the need fo=
r it.<br></div></div></blockquote><div><br></div><div>I outline four ways i=
n which <span style=3D"font-family:monospace,monospace">`T*`</span> is inad=
equate in my paper.</div></div></div></div></blockquote></span><div><br>I f=
ound them no more compelling coming from your paper than I have from other =
people's statements.<br></div></div></blockquote><div><br></div><div>I =
have the additional case that with <span style=3D"font-family:monospace,mon=
ospace">`optional<T&>`</span>, the rules around "pass by val=
ue vs. pass by reference" and "mandatory vs. optional" becom=
e orthogonal, more consistent, and therefore easier for beginners to learn.=
The rules <i>should</i> be:<br><ul><li>Add <span style=3D"font-family:mono=
space,monospace">`&`</span> or <span style=3D"font-family:monospace,mon=
ospace">`const&`</span> to pass by reference</li><li>Add <span style=3D=
"font-family:monospace,monospace">`optional`</span> when the parameter is n=
ot mandatory</li></ul><p>Instead, the rules are:</p><ul><li>Add <span style=
=3D"font-family:monospace,monospace">`&`</span> or <span style=3D"font-=
family:monospace,monospace">`const&`</span> to pass by reference</li><l=
i>Add <span style=3D"font-family:monospace,monospace">`optional`</span> whe=
n the parameter is not mandatory</li><li><i>Except</i> when passing by refe=
rence <i>and</i> when the parameter is not mandatory, in which case use <sp=
an style=3D"font-family:monospace,monospace">`T*`</span> instead (oh and, b=
y the way, <span style=3D"font-family:monospace,monospace">`T*`</span> has =
completely different semantics to <span style=3D"font-family:monospace,mono=
space">`T`</span> and <span style=3D"font-family:monospace,monospace">`T&am=
p;`</span>)<br></li></ul></div><div></div><blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"ltr"><div></div><span class=3D"gmail-"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote"><div> </div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr"><div></div><span><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">why then shou=
ld <span style=3D"font-family:monospace,monospace">`optional<int&>=
;`</span> have the same copy assignment semantics as <span style=3D"font-fa=
mily:monospace,monospace">`int*`</span>? This is inconsistent and potential=
ly surprising behaviour. <span style=3D"font-family:monospace,monospace">`T=
&`</span> cannot be rebound after initialization, so neither should <sp=
an style=3D"font-family:monospace,monospace">`optional<T&>`</span=
>.<br></div></div></div></blockquote><div><blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><br></blockquote></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"></div><div>=
The problem, as explained in my paper, is that the nature of <span style=3D=
"font-family:monospace,monospace">`optional<T>`</span> makes it impos=
sible to give <span style=3D"font-family:monospace,monospace">`optional<=
int&>`</span> the same copy assignment behaviour as <span style=3D"f=
ont-family:monospace,monospace">`int&`</span>. At best, we can give it =
an unholy mixture of value and reference semantics that depend on the initi=
al state of the <span style=3D"font-family:monospace,monospace">`optional&l=
t;int&>`</span>. Thus, the only reasonable option left to us is to d=
isable copy assignment altogether.<br><br>I will try to present my argument=
more clearly in the next draft.<br><br></div><div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><div dir=3D"ltr"><div>N3672 has some discussion o=
f copy assignment; but of course it doesn't contain any discussion of t=
he reasons it itself was rejected, and it's <i>those</i> reasons that y=
our paper is building on top of, right?</div><div><a href=3D"http://www.ope=
n-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html#optional_ref.rationale=
..assign" rel=3D"nofollow" target=3D"_blank">http://www.open-std.org/jtc1/s<=
wbr>c22/wg21/docs/papers/2013/n367<wbr>2.html#optional_ref.rationale.<wbr>a=
ssign</a><br></div></div></blockquote><div>=C2=A0<br></div><div>Yes, I ment=
ioned that they gave no reasoning for the general consensus that <span styl=
e=3D"font-family:monospace,monospace">`optional<T&>`</span> shoul=
d be copy assignable. I would certainly like to know, but I have a feeling =
it was along the lines of ,"<span style=3D"font-family:monospace,monos=
pace">`optional<T&>`</span> <i>must</i> be a regular type", =
which I also address in the paper.=C2=A0</div></div></div></div></blockquot=
e></span><div><br>If you make a specialization of `optional` that fundament=
ally behaves differently from `optional`, then you're walking straight =
into the `vector<bool>` problem. Only instead of making just one spec=
ialization that's deficient, you're making an <i>entire category </=
i>of specializations that are different.<br></div></div></blockquote><div><=
br></div><div>Disabling operations that do not make sense or are not possib=
le for a particular type is common practice.</div></div></div></div></block=
quote></span><div><br>Every `optional` can be empty; that's a fundament=
al part of its interface. But also fundamental is that every non-const `opt=
ional` can be <i>made empty</i> if it wasn't.</div></div></blockquote><=
div><br></div><div>True. I don't see any technical reason why assignmen=
t from <span style=3D"font-family:monospace,monospace">`nullopt_t`</span> a=
nd the <span style=3D"font-family:monospace,monospace">`reset`</span> funct=
ion cannot be defined.<br></div><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex"><div dir=3D"ltr"><div>Also, every non-const `option=
al` can be given a new value, even if it has one. These are fundamental par=
ts of the interface.<br></div></div></blockquote><div><br></div><div>Not tr=
ue:<br></div><div><br><div style=3D"margin-left:40px"><span style=3D"font-f=
amily:monospace,monospace">struct foo {</span><br><span style=3D"font-famil=
y:monospace,monospace">=C2=A0 foo& operator=3D(foo const&) =3D dele=
te;</span><br><span style=3D"font-family:monospace,monospace">};</span><br>=
<span style=3D"font-family:monospace,monospace"></span><br><span style=3D"f=
ont-family:monospace,monospace">foo f;</span><br><span style=3D"font-family=
:monospace,monospace">optional<foo const> o;</span><br><span style=3D=
"font-family:monospace,monospace">o =3D f; // error: use of deleted functio=
n</span><br></div>=C2=A0<br></div><div>Note that <span style=3D"font-family=
:monospace,monospace">`optional<T>`</span> <i>could</i> have been spe=
cified to allow copy/move assignment even if copy/move assignment weren'=
;t defined for <span style=3D"font-family:monospace,monospace">`T`</span>. =
The behaviour of <span style=3D"font-family:monospace,monospace">`optional&=
lt;T>`</span> reflects the behaviour of the contained object. An <span s=
tyle=3D"font-family:monospace,monospace">`optional`</span> containing a ref=
erence gets its copy assignment operator deleted much like a class containi=
ng a reference does, because defining it would give inconsistent behaviour.=
<br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr"><div>In your world, there are two types of `optional`s: th=
ose which are mutable and those which are not. I see no reason why an immut=
able `optional` should be spelled `optional`. The ability to destroy and re=
create what gets stored there is <i>not</i> optional.<br></div></div></bloc=
kquote><div><br></div><div>Destroy, yes; recreate, not necessarily (as just=
demonstrated).<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"ltr"><div>That's why I compare it to `vect=
or<bool>`; because code that uses it must treat it in a completely di=
fferent way. Whereas code that uses a `vector<T>` for some move-only =
type simply has to avoid `insert` and other copying functions. You can stil=
l put things into the sequence and remove things from the sequence. You sti=
ll have that level of control.<br><br>If you make a `vector<T>` for a=
n immobile type, then `vector` becomes dysfunctional. <br></div></div></blo=
ckquote><div><br></div><div><span style=3D"font-family:monospace,monospace"=
>`vector<T>`</span> is not <span style=3D"font-family:monospace,monos=
pace">`optional<T>`</span>. <span style=3D"font-family:monospace,mono=
space">`optional<T&>`</span> is perfectly usable even if it is no=
t copy assignable, much like <span style=3D"font-family:monospace,monospace=
">`vector<T>`</span> is still usable for a move-only <span style=3D"f=
ont-family:monospace,monospace">`T`</span>. You can even store <span style=
=3D"font-family:monospace,monospace">`optional<T&>`</span> in con=
tainers; you just get limited functionality (not dysfunctionality).<br></di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div d=
ir=3D"ltr"><span class=3D"gmail-"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>It is not =
possible to implement assignment of <span style=3D"font-family:monospace,mo=
nospace">`optional<T&>`</span> in a way that is consistent with <=
span style=3D"font-family:monospace,monospace">`optional<T>`</span>, =
so it should be disabled. Specifying reference semantics would make copy as=
signment of <span style=3D"font-family:monospace,monospace">`optional<T&=
amp;>`</span> behave fundamentally differently from `optional<T>`.=
I would argue that this is in fact <i>worse</i> than <span style=3D"font-f=
amily:monospace,monospace">`vector<bool>`</span>: at least with <span=
style=3D"font-family:monospace,monospace">`vector<bool>`</span> any =
programming errors are likely to be caught at compile-time.<br></div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><div>If my function takes an `optional<T>`, where `T` is deduced =
or some such, I shouldn't have to worry that some nitwit is going to co=
me along as instantiate it with `T&`. I should not have to guard this f=
unction with `enable_if` or `requires` just to be able to ensure sane behav=
ior.<br></div></div></blockquote><div><br></div><div>If you indiscriminatel=
y take an <span style=3D"font-family:monospace,monospace">`optional<T>=
;`</span> for all <span style=3D"font-family:monospace,monospace">`T`</span=
> then you are likely to run into problems regardless of whether <span styl=
e=3D"font-family:monospace,monospace">`T`</span> can be a reference type, j=
ust as if you indiscriminately take a <span style=3D"font-family:monospace,=
monospace">`T`</span>.</div></div></div></div></blockquote></span><div><br>=
Nonsense. As previously stated, there are many operations on `optional` tha=
t don't care about the characteristics of `T`. You remove several of th=
em, which transforms the object into something else. It becomes immutable, =
when before it was a mutable type.<br></div></div></blockquote><div><br></d=
iv><div>The copy/move operations of <span style=3D"font-family:monospace,mo=
nospace">`optional<T>`</span> <i>do</i> care about the characteristic=
s of <span style=3D"font-family:monospace,monospace">`T`</span>. Copy const=
ruction requires <span style=3D"font-family:monospace,monospace">`is_copy_c=
onstructible_v<T>`</span>. Move construction requires <span style=3D"=
font-family:monospace,monospace">`is_move_constructible_v<T>`</span>.=
Copy assignment requires <span style=3D"font-family:monospace,monospace">`=
is_copy_constructible_v<T> && is_copy_assignable_v<T>`<=
/span>. Move assignment requires <span style=3D"font-family:monospace,monos=
pace">`is_move_constructible_v<T> && is_move_assignable_v<=
T>`</span>.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr"><div>Just like `vector<bool>` stops =
being a contiguous array of `T`s.<br>=C2=A0</div><span class=3D"gmail-"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div c=
lass=3D"gmail_quote"><div>Concepts will make this problem easier to manage.=
Even so, if my code expects <span style=3D"font-family:monospace,monospace=
">`optional<T>`</span> to be copy assignable, then you will get a com=
pile-time error if <span style=3D"font-family:monospace,monospace">`T`</spa=
n> is a reference type (you would get a run-time bug if <span style=3D"font=
-family:monospace,monospace">`optional<T&>`</span> had reference =
copy assignment semantics).<br></div></div></div></div></blockquote></span>=
<div><br>So, why should I clutter up my code with needless `enable_if/requi=
res` clauses just to stop you from passing me something I don't want to=
deal with? Wouldn't it make sense to make this a new type with its own=
name, so that users who want to pass optional references can do so?<span c=
lass=3D"gmail-"></span></div></div></blockquote><div><br>As I've just s=
hown, if you indiscriminately accept an <span style=3D"font-family:monospac=
e,monospace">`optional<T>`</span> parameter for any type <span style=
=3D"font-family:monospace,monospace">`T`</span>, I can pass you any number =
of types that will disable the various copy/move operations. Do you have a =
use case where <span style=3D"font-family:monospace,monospace">`optional<=
;T&>`</span> specifically would cause a problem?<br></div></div></di=
v></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHocnE_1bqkd6SFsa5PZrDO32%2BJfrTZzbn=
T3WnYr-FQYYW9MHw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHocnE_1bqkd6S=
Fsa5PZrDO32%2BJfrTZzbnT3WnYr-FQYYW9MHw%40mail.gmail.com</a>.<br />
--001a11c159dcc4b3960549bafbbc--
.
Author: Joseph Thomson <joseph.thomson@gmail.com>
Date: Thu, 2 Mar 2017 17:11:15 +0800
Raw View
--001a1141b4b0b509950549bbcfa3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thu, Mar 2, 2017 at 2:44 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:
> On Wed, Mar 1, 2017 at 6:36 PM, Joseph Thomson <joseph.thomson@gmail.com>
> wrote:
>
>> On Thu, Mar 2, 2017 at 8:00 AM, Arthur O'Dwyer <arthur.j.odwyer@gmail.co=
m
>> > wrote:
>>
>>> On Tuesday, February 28, 2017 at 5:57:35 PM UTC-8, joseph....@gmail.com
>>> wrote:
>>>>
>>>> Given that the auxiliary proposal for "optional references" in N3672
>>>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html>
>>>> was not accepted into C++17 (as far as I can tell), I have prepared a =
draft
>>>> proposal (see attached) for an alternative specification of
>>>> `optional<T&>` that focuses on the "optional reference" function
>>>> parameter use case. I would appreciate any thoughts or feedback.
>>>>
>>>
>>> I also miss optional<T&>, and optional<void> for that matter, because
>>> if we had those two things, then we could easily implement the shared s=
tate
>>> of future<X> in terms of optional<X> for all X.
>>>
>>
>> The idea of `optional<void>` strikes me as odd. In what sense can you
>> have a value of type `void`? It seems like it would essentially be a
>> glorified `bool`.
>>
>> Do you mean `future::get` would be implemented something like this?
>>
>> T future<T>::get() {
>> wait();
>> return *state->value; // `value` is of type `optional<T>`
>> }
>>
>
> Yes. That is almost EXACTLY the implementation that I would use of
> future<T> for any T (void and reference types included). The only change
> I'd need to make would be irrelevant-to-the-current-discussion protection
> against two threads calling get() simultaneously.
>
>
>> This feels like shifting the complexity of `future` into `optional` for
>> no reason other than to keep the complexity out of `future`. I like it
>> when you can simplify higher-level code as a natural result of using
>> well-designed low-level components, but `optional<void>` doesn't seem
>> like a well-designed feature to me.
>>
>
> Why does optional<void> not seem like a well-designed feature to you? Wha=
t
> part of its interface is acceptable to you in the context of future<void>=
,
> but objectionable in the context of optional<void>?
>
Well, an asynchronous operation doesn't necessarily need to produce a
value, so what would `async([](){});` return if `future<void>` were not
defined? On the other hand, `optional<void>` can just be replaced with
`bool`.
> It seems to me that both types model a "possibly nonexistent" T; the only
> difference is that future<T> carries a lot of baggage around concurrency
> (and thus reference-counting of the shared state), whereas optional<T> do=
es
> not. And if we can implement the more complex feature in terms of the
> simpler feature, then we win. If we have to repeat all the metaprogrammin=
g
> in two places (with slightly different SFINAE in each place!), then we lo=
se.
>
The difference is that `future<T>` represents the result of an asynchronous
operation (which might be nothing) while `optional<T>` represents a `T`
that may or may not exist. In what sense can a `void` exist or not exist?
It just doesn't make an awful lot of sense to me. We shouldn't force a
design that doesn't make sense based on a single use case.
>
>>
>>> However, I don't understand why you'd want optional<T&> to behave so
>>> unusually differently from optional<T> w.r.t. copy assignment and such.
>>> IMNSHO, optional<T&> should behave identically to
>>> optional<reference_wrapper<T>>, which is to say, almost identically to
>>> T*.
>>> Can you add something to your paper explaining (or rehashing) exactly
>>> what are the arguments against the above (or N3672-style) semantics?
>>>
>>
>> On the contrary, the copy assignment behaviour for `optional<T&>`
>> proposed by *N3672* was unusually different from that of `optional<T>`.
>> The copy assignment semantics of `optional<T>` reflect the copy
>> assignment semantics of `T`: `optional<int>` has the same copy
>> assignment semantics as `int` (value semantics) and `optional<int*>` has
>> the same copy assignment semantics as `int*` (reference semantics); why
>> then should `optional<int&>` have the same copy assignment semantics as
>> `int*`? This is inconsistent and potentially surprising behaviour. `T&`
>> cannot be rebound after initialization, so neither should `optional<T&>`=
..
>>
>
> Like Nicol, I too think you've got your terms wrong here.
> For any type T, optional<T>::operator=3D has value semantics: specificall=
y,
> it means "Please make the state of the optional<T> object on the left sid=
e
> of the =3D sign match the state of the optional<T> object on the right si=
de
> of the =3D sign."
>
> So for example
>
> int i, j;
> optional<int&> odest =3D anything();
> optional<int&> osrc =3D j;
> odest =3D osrc;
> assert(&(*odest) =3D=3D &j);
>
> The above test case should pass, no matter what value is returned from
> anything(). Whether anything() returns make_optional<int&>(i) or
> optional<int&>{} is completely irrelevant, because two lines later we
> overwrite the value of odest with osrc, which is an engaged optional
> containing "reference to j". So after the assignment, we must have that
> odest is *also* an engaged optional containing "reference to j".
>
This is pointer-like behaviour; `optional<T&>` should have reference-like
behaviour, because the behaviour of `optional<T>` reflects the behaviour of
`T`. After an assignment, the only condition that needs to hold true is
that the values of the two objects are equal:
a =3D b;
assert(a =3D=3D b);
I'm not sure, but I think you might be getting confused by the levels of
> indirection here (e.g. your comment about optional<int*> makes me think
> so). I'm distinguishing between
>
> odest =3D osrc; // odest acquires the same value as osrc
>
> and
>
> *odest =3D *osrc; // odest and osrc must both be engaged; the refere=
nt
> of odest acquires the same value as the referent of osrc
>
> In the former case we are assigning optional<int&> objects. In the latter
> case we are assigning between int& references; i.e.
>
> int i, j;
> optional<int&> oi =3D i;
> optional<int&> oj =3D j;
> *oi =3D *oj; // equivalent to `i =3D j`
>
> This is the same way std::reference_wrapper<T> and std::future<T&> work =
=E2=80=94
> i.e., value-assigning a reference_wrapper or future *object* is not the
> same thing as reference-assigning the *contained reference* =E2=80=94 so =
I'm not
> sure where the problem is. If I'm missing something subtle, please
> highlight it for me.
>
Again, this is pointer-like behaviour. `reference_wrapper` and `future`
have pointer-like assignment semantics. `reference_wrapper<T>` needs to be
copy assignable so that it can be regular, and interoperate well with
algorithms and containers. `future<T&>` represents the result of an
operation, so it makes sense that it would not want to make a copy of the
referenced object. The behaviour of `optional<T&>` should be consistent
with `optional<T>`, which means that copy assignment of `optional<T&>`
should have the same effect as copy assignment of `T&`. It should *not*
have pointer-like copy assignment semantics.
If the problem is inconsistency with std::tuple<T&> =E2=80=94 which does
> assign-through, as otherwise std::tie() wouldn't work =E2=80=94 well, I'm=
okay with
> that inconsistency. Honestly, as cool as std::tie was in 2011 (and it was
> very cool!), I don't think I'd use it at all in new code.
>
This is not the problem, though `tuple<T&>` should not have pointer-like
assignment semantics for similar reasons.
(Obviously I'm assuming that optional<T&> is implemented behind the scenes
> in terms of a T*, just like future<T&> and reference_wrapper<T> and
> tuple<T&> are today. Furthermore, since references can't be null, we're
> free to use the null representation as a "disengaged" marker, so that
> sizeof(optional<T&>) can be the same as sizeof(T*). Furthermore,
> optional<T&> can be, and should be required to be, trivially copyable, ju=
st
> like reference_wrapper<T>. Furthermore, I'd like to see it be trivially
> destructible, even though reference_wrapper<T> somewhy isn't required to
> be.)
>
Yes, that's all fine.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAHocnE_EO_VKJkpRgt49_Qxt5gtSAMqXXkjQt1aLtO%2BW5=
zK54g%40mail.gmail.com.
--001a1141b4b0b509950549bbcfa3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Mar 2, 2017 at 2:44 PM, Arthur O'Dwyer <span dir=3D"ltr"><<a hre=
f=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@gm=
ail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div dir=3D"ltr"><span class=3D"gmail-">On Wed, Mar 1, 2017 at 6:36=
PM, Joseph Thomson <span dir=3D"ltr"><<a href=3D"mailto:joseph.thomson@=
gmail.com" target=3D"_blank">joseph.thomson@gmail.com</a>></span> wrote:=
<br></span><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span clas=
s=3D"gmail-"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"=
ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span>On Thu, Ma=
r 2, 2017 at 8:00 AM, Arthur O'Dwyer <span dir=3D"ltr"><<a href=3D"m=
ailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@gmail.co=
m</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div dir=3D"ltr"><span class=3D"gmail-m_1605690409916359694m_924676599839=
107641gmail-">On Tuesday, February 28, 2017 at 5:57:35 PM UTC-8, <a href=3D=
"mailto:joseph....@gmail.com" target=3D"_blank">joseph....@gmail.com</a> wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Give=
n that the auxiliary proposal for "optional references" in <a hre=
f=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html" re=
l=3D"nofollow" target=3D"_blank">N3672</a> was not accepted into C++17 (as =
far as I can tell), I have prepared a draft proposal (see attached) for an =
alternative specification of <span style=3D"font-family:courier new,monospa=
ce">`optional<T&>`</span> that focuses on the "optional refe=
rence" function parameter use case. I would appreciate any thoughts or=
feedback.<br></div></blockquote><div><br></div></span><div>I also miss <fo=
nt face=3D"courier new, monospace">optional<T&></font>, and <font=
face=3D"courier new, monospace">optional<void></font> for that matte=
r, because if we had those two things, then we could easily implement the s=
hared state of <font face=3D"courier new, monospace">future<X></font>=
in terms of <font face=3D"courier new, monospace">optional<X></font>=
for all <font face=3D"courier new, monospace">X</font>.</div></div></block=
quote><div><br></div></span><div>The idea of <span style=3D"font-family:mon=
ospace,monospace">`optional<void>`</span> strikes me as odd. In what =
sense can you have a value of type <span style=3D"font-family:monospace,mon=
ospace">`void`</span>? It seems like it would essentially be a glorified <s=
pan style=3D"font-family:monospace,monospace">`bool`</span>.<br><br>Do you =
mean <span style=3D"font-family:monospace,monospace">`future::get`</span> w=
ould be implemented something like this?<br><br></div><div style=3D"margin-=
left:40px"><span style=3D"font-family:monospace,monospace">T future<T>=
;::get() {<br></span></div><div style=3D"margin-left:40px"><span style=3D"f=
ont-family:monospace,monospace">=C2=A0 wait();<br></span></div><div style=
=3D"margin-left:40px"><span style=3D"font-family:monospace,monospace">=C2=
=A0 return *state->value; // `value` is of type `optional<T>`<br><=
/span></div><div><div style=3D"margin-left:40px"><span style=3D"font-family=
:monospace,monospace">}</span></div></div></div></div></div></blockquote><d=
iv><br></div></span><div>Yes. That is almost EXACTLY the implementation tha=
t I would use of future<T> for any T (void and reference types includ=
ed). The only change I'd need to make would be irrelevant-to-the-curren=
t-<wbr>discussion protection against two threads calling get() simultaneous=
ly.</div><span class=3D"gmail-"><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><div>This feels like shifting the complexity of <span s=
tyle=3D"font-family:monospace,monospace">`future`</span> into <span style=
=3D"font-family:monospace,monospace">`optional`</span> for no reason other =
than to keep the complexity out of <span style=3D"font-family:monospace,mon=
ospace">`future`</span>. I like it when you can simplify higher-level code =
as a natural result of using well-designed low-level components, but <span =
style=3D"font-family:monospace,monospace">`optional<void>`</span> doe=
sn't seem like a well-designed feature to me.<br></div></div></div></di=
v></blockquote><div><br></div></span><div>Why does optional<void> not=
seem like a well-designed feature to you? What part of its interface is ac=
ceptable to you in the context of future<void>, but objectionable in =
the context of optional<void>?</div></div></div></div></blockquote><d=
iv><br></div><div>Well, an asynchronous operation doesn't necessarily n=
eed to produce a value, so what would <span style=3D"font-family:monospace,=
monospace">`async([](){});`</span> return if <span style=3D"font-family:mon=
ospace,monospace">`future<void>`</span> were not defined? On the othe=
r hand, <span style=3D"font-family:monospace,monospace">`optional<void&g=
t;`</span> can just be replaced with <span style=3D"font-family:monospace,m=
onospace">`bool`</span>.<br></div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div>It seems to me that both types model a "pos=
sibly nonexistent" T; the only difference is that future<T> carr=
ies a lot of baggage around concurrency (and thus reference-counting of the=
shared state), whereas optional<T> does not.=C2=A0 And if we can imp=
lement the more complex feature in terms of the simpler feature, then we wi=
n. If we have to repeat all the metaprogramming in two places (with slightl=
y different SFINAE in each place!), then we lose.</div></div></div></div></=
blockquote><div><br></div><div>The difference is that <span style=3D"font-f=
amily:monospace,monospace">`future<T>`</span> represents the result o=
f an asynchronous operation (which might be nothing) while <span style=3D"f=
ont-family:monospace,monospace">`optional<T>`</span> represents a <sp=
an style=3D"font-family:monospace,monospace">`T`</span> that may or may not=
exist. In what sense can a <span style=3D"font-family:monospace,monospace"=
>`void`</span> exist or not exist? It just doesn't make an awful lot of=
sense to me. We shouldn't force a design that doesn't make sense b=
ased on a single use case.<br></div><div>=C2=A0 <br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra=
"><div class=3D"gmail_quote"><span class=3D"gmail-"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div=
class=3D"gmail_quote"><div></div><span><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>However, I don't=
understand why you'd want <font face=3D"courier new, monospace">option=
al<T&></font> to behave so unusually differently from <font face=
=3D"courier new, monospace">optional<T></font> w.r.t. copy assignment=
and such. IMNSHO, <font face=3D"courier new, monospace">optional<T&=
></font> should behave identically to <font face=3D"courier new, monospa=
ce">optional<reference_wrapper<T>></font><wbr>, which is to say=
, almost identically to <font face=3D"courier new, monospace">T*</font>.</d=
iv><div>Can you add something to your paper explaining (or rehashing) exact=
ly what are the arguments against the above (or N3672-style) semantics?</di=
v></div></blockquote><div>=C2=A0<br></div></span>On the contrary, the copy =
assignment behaviour for <span style=3D"font-family:monospace,monospace">`o=
ptional<T&>`</span> proposed by <i>N3672</i> was unusually differ=
ent from that of <span style=3D"font-family:monospace,monospace">`optional&=
lt;T>`</span>. The copy assignment semantics of <span style=3D"font-fami=
ly:monospace,monospace">`optional<T>`</span> reflect the copy assignm=
ent semantics of <span style=3D"font-family:monospace,monospace">`T`</span>=
: <span style=3D"font-family:monospace,monospace">`optional<int>`</sp=
an> has the same copy assignment semantics as <span style=3D"font-family:mo=
nospace,monospace">`int`</span> (value semantics) and <span style=3D"font-f=
amily:monospace,monospace">`optional<int*>`</span> has the same copy =
assignment semantics as <span style=3D"font-family:monospace,monospace">`in=
t*`</span> (reference semantics); why then should <span style=3D"font-famil=
y:monospace,monospace">`optional<int&>`</span> have the same copy=
assignment semantics as <span style=3D"font-family:monospace,monospace">`i=
nt*`</span>? This is inconsistent and potentially surprising behaviour. <sp=
an style=3D"font-family:monospace,monospace">`T&`</span> cannot be rebo=
und after initialization, so neither should <span style=3D"font-family:mono=
space,monospace">`optional<T&>`</span>.<br></div></div></div></bl=
ockquote><div><br></div></span><div>Like Nicol, I too think you've got =
your terms wrong here.</div><div>For any type T, optional<T>::operato=
r=3D has value semantics: specifically, it means "Please make the stat=
e of the optional<T> object on the left side of the =3D sign match th=
e state of the optional<T> object on the right side of the =3D sign.&=
quot;</div><div><br></div><div>So for example</div><div><br></div><div>=C2=
=A0 =C2=A0 int i, j;</div><div>=C2=A0 =C2=A0 optional<int&> odest=
=3D anything();</div><div>=C2=A0 =C2=A0 optional<int&> osrc =3D =
j;</div><div>=C2=A0 =C2=A0 odest =3D osrc;</div><div>=C2=A0 =C2=A0 assert(&=
amp;(*odest) =3D=3D &j);</div><div><br></div><div>The above test case s=
hould pass, no matter what value is returned from anything(). Whether anyth=
ing() returns make_optional<int&>(i) or optional<int&>{=
} is completely irrelevant, because two lines later we overwrite the value =
of odest with osrc, which is an engaged optional containing "reference=
to j". So after the assignment, we must have that odest is <i>also</i=
> an engaged optional containing "reference to j".</div></div></d=
iv></div></blockquote><div><br></div><div>This is pointer-like behaviour; <=
span style=3D"font-family:monospace,monospace">`optional<T&>`</sp=
an> should have reference-like behaviour, because the behaviour of `<span s=
tyle=3D"font-family:monospace,monospace">optional<T>`</span> reflects=
the behaviour of <span style=3D"font-family:monospace,monospace">`T`</span=
>. After an assignment, the only condition that needs to hold true is that =
the values of the two objects are equal:<br><br></div><div style=3D"margin-=
left:40px"><span style=3D"font-family:monospace,monospace">a =3D b;</span><=
/div><div style=3D"margin-left:40px"><span style=3D"font-family:monospace,m=
onospace">assert(a =3D=3D b);</span></div></div><div class=3D"gmail_quote">=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div=
class=3D"gmail_extra"><div class=3D"gmail_quote"><div></div><div>I'm n=
ot sure, but I think you might be getting confused by the levels of indirec=
tion here (e.g. your comment about optional<int*> makes me think so).=
I'm distinguishing between</div><div><br></div><div>=C2=A0 =C2=A0 odes=
t =3D osrc; =C2=A0// odest acquires the same value as osrc</div><div><br></=
div><div>and</div><div><br></div><div>=C2=A0 =C2=A0 *odest =3D *osrc; =C2=
=A0// odest and osrc must both be engaged; the referent of odest acquires t=
he same value as the referent of osrc</div><div><br></div><div>In the forme=
r case we are assigning optional<int&> objects. In the latter cas=
e we are assigning between int& references; i.e.</div><div><br></div><d=
iv>=C2=A0 =C2=A0 int i, j;</div><div>=C2=A0 =C2=A0 optional<int&>=
oi =3D i;</div><div>=C2=A0 =C2=A0 optional<int&> oj =3D j;</div>=
<div>=C2=A0 =C2=A0 *oi =3D *oj; =C2=A0// equivalent to `i =3D j`</div><div>=
<br></div><div>This is the same way std::reference_wrapper<T> and std=
::future<T&> work =E2=80=94 i.e., value-assigning a reference_wra=
pper or future=C2=A0<i>object</i> is not the same thing as reference-assign=
ing the <i>contained reference</i> =E2=80=94 so I'm not sure where the =
problem is. If I'm missing something subtle, please highlight it for me=
..</div></div></div></div></blockquote><div>=C2=A0<br></div><div>Again, this=
is pointer-like behaviour. <span style=3D"font-family:monospace,monospace"=
>`reference_wrapper`</span> and <span style=3D"font-family:monospace,monosp=
ace">`future`</span> have pointer-like assignment semantics. <span style=3D=
"font-family:monospace,monospace">`reference_wrapper<T>`</span> needs=
to be copy assignable so that it can be regular, and interoperate well wit=
h algorithms and containers. <span style=3D"font-family:monospace,monospace=
">`future<T&>`</span> represents the result of an operation, so i=
t makes sense that it would not want to make a copy of the referenced objec=
t. The behaviour of <span style=3D"font-family:monospace,monospace">`option=
al<T&>`</span> should be consistent with <span style=3D"font-fami=
ly:monospace,monospace">`optional<T>`</span>, which means that copy a=
ssignment of <span style=3D"font-family:monospace,monospace">`optional<T=
&>`</span> should have the same effect as copy assignment of <span s=
tyle=3D"font-family:monospace,monospace">`T&`</span>. It should <i>not<=
/i> have pointer-like copy assignment semantics.<br></div><div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div></div><div>If the problem =
is inconsistency with std::tuple<T&> =E2=80=94 which does assign-=
through, as otherwise std::tie() wouldn't work =E2=80=94 well, I'm =
okay with that inconsistency. Honestly, as cool as std::tie was in 2011 (an=
d it was very cool!), I don't think I'd use it at all in new code.<=
/div></div></div></div></blockquote><div>=C2=A0<br></div><div>This is not t=
he problem, though <span style=3D"font-family:monospace,monospace">`tuple&l=
t;T&>`</span> should not have pointer-like assignment semantics for =
similar reasons.<br></div><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">(Obviously I=
9;m assuming that optional<T&> is implemented behind the scenes i=
n terms of a T*, just like future<T&> and reference_wrapper<T&=
gt; and tuple<T&> are today. Furthermore, since references can=
9;t be null, we're free to use the null representation as a "disen=
gaged" marker, so that sizeof(optional<T&>) can be the same =
as sizeof(T*). Furthermore, optional<T&> can be, and should be re=
quired to be, trivially copyable, just like reference_wrapper<T>. Fur=
thermore, I'd like to see it be trivially destructible, even though ref=
erence_wrapper<T> somewhy isn't required to be.)<div class=3D"gma=
il_quote"><span class=3D"gmail-HOEnZb"></span></div></div></div></blockquot=
e><div><br></div><div>Yes, that's all fine. <br></div></div></div></div=
>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHocnE_EO_VKJkpRgt49_Qxt5gtSAMqXXkjQ=
t1aLtO%2BW5zK54g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHocnE_EO_VKJk=
pRgt49_Qxt5gtSAMqXXkjQt1aLtO%2BW5zK54g%40mail.gmail.com</a>.<br />
--001a1141b4b0b509950549bbcfa3--
.
Author: Joseph Thomson <joseph.thomson@gmail.com>
Date: Fri, 3 Mar 2017 10:02:47 +0800
Raw View
--f403043c49483a49090549c9f153
Content-Type: text/plain; charset=UTF-8
On Thu, Mar 2, 2017 at 4:11 PM, Joseph Thomson <joseph.thomson@gmail.com>
wrote:
> On Thu, Mar 2, 2017 at 1:19 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>> On Wednesday, March 1, 2017 at 11:16:52 PM UTC-5, Joseph Thomson wrote:
>>>
>>> On Thu, Mar 2, 2017 at 11:18 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>>>
>>>> On Wednesday, March 1, 2017 at 9:36:22 PM UTC-5, Joseph Thomson wrote:
>>>>>
>>>>> On Thu, Mar 2, 2017 at 8:00 AM, Arthur O'Dwyer <arthur....@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> On Tuesday, February 28, 2017 at 5:57:35 PM UTC-8,
>>>>>> joseph....@gmail.com wrote:
>>>>>>
>>>>> However, I don't understand why you'd want optional<T&> to behave so
>>>>>> unusually differently from optional<T> w.r.t. copy assignment and
>>>>>> such. IMNSHO, optional<T&> should behave identically to
>>>>>> optional<reference_wrapper<T>>, which is to say, almost identically
>>>>>> to T*.
>>>>>> Can you add something to your paper explaining (or rehashing) exactly
>>>>>> what are the arguments against the above (or N3672-style) semantics?
>>>>>>
>>>>>
>>>>> On the contrary, the copy assignment behaviour for `optional<T&>`
>>>>> proposed by *N3672* was unusually different from that of `optional<T>`.
>>>>> The copy assignment semantics of `optional<T>` reflect the copy
>>>>> assignment semantics of `T`: `optional<int>` has the same copy
>>>>> assignment semantics as `int` (value semantics) and `optional<int*>`
>>>>> has the same copy assignment semantics as `int*` (reference
>>>>> semantics);
>>>>>
>>>>
>>>> No it doesn't. `optional<int*>` and `int*` both have value semantics,
>>>> with respect to the object in question. That object being a *pointer*.
>>>>
>>>
>>>>
>>> It only has reference semantics with respect to the object being pointed
>>>> to. But that's fundamentally no different than `optional<int>`, if that
>>>> `int` just so happens to be a handle into some system that represents an
>>>> object. `optional<int>` still has value semantics in that case.
>>>>
>>>
>>> I'm using the terminology
>>> <https://isocpp.org/wiki/faq/value-vs-ref-semantics#val-vs-ref-semantics>
>>> as defined by the isocpp website. Yeah, technically only initialization of
>>> `T&` has true reference semantics and everything else in C++ has value
>>> semantics. But this is nitpicking and is totally irrelevant to the issue at
>>> hand.
>>>
>>
>> No, it's actually very relevant to the issue at hand. It shows that
>> `optional<T*>` is at its core a very different thing from `optional<T&>`.
>> It reinforces that references are not values. It reinforces the idea that
>> `optional` is a value type, and therefore should only be able to contain
>> other value types.
>>
>> You want to put a non-value type into a type that is meant to contain
>> values.
>>
>
> `optional` is *currently* only defined for value types. I want to define
> its behaviour for reference types. It is possible to define `optional<T&>`
> to be consistent with the behaviour of `optional<T>`. If this weren't the
> case, I would agree with you that it should be a different type.
>
>
>> It's questions like this that make me feel that `optional` references are
>>>> a *terrible* idea. Some people will expect it to have one behavior,
>>>> others will expect it to have a contradictory one, and in the end only one
>>>> side will be happy.
>>>>
>>>
>>> The expectation that copy assignment of `optional<T&>` have the same
>>> semantics as copy assignment of `T*` is, in my opinion, a result of the
>>> erroneous belief that the inability to rebind `T&` is somehow a bug in
>>> its design, that it is somehow reasonable to think of `T&` as a `T*`
>>> that cannot be null. It seems that `optional<T&>` is seen as an
>>> opportunity to "fix" this bug by allowing `T&` to be rebound by
>>> defining pointer-like copy assignment semantics. The problem is that the
>>> inability to rebind `T&` is *not* a bug; it is a feature. A `T&` is
>>> essentially an alias of an existing object of type `T`, and behaves in
>>> almost every way like an object of type `T`, *including* copy
>>> assignment.
>>>
>>
>>> I believe that there is an *objective* case to be made *against* giving
>>> `optional<T&>` reference copy assignment semantics.
>>>
>>
>> It's easy to declare that your subjective opinion is objective, but that
>> doesn't make it true. There are just as many people who *want*
>> rebindable references as those who think rebinding is bad. And they can
>> make arguments for it too. I fail to see how your argument is any more
>> objective than theirs.
>>
>
> Forget the term "objective". I believe my case is superior from the
> standpoint of consistency with `optional<T>`. The argument for allowing
> `optional<T&>` to be rebound amounts to, "`optional<T&>` should be copy
> assignable because regularity is good, despite the fact that `T&` is not
> even an object type, that it will require a complete redefinition of copy
> assignment for this specialization, that the copy assignment behaviour will
> not match that of `T&`, and that `optional<reference_wrapper<T>>` already
> fits my use case."
>
>
>> My problem with the whole `optional<T&>` discussion is that it boils down
>> to 3 choices:
>>
>> 1) Break `optional<T&>`'s interface, thus effectively making it a new
>> type (see below), but we'll keep the same name for some reason.
>> 2) Make `optional<T&>`'s assignment operator rebind the reference, thus
>> making it effectively equivalent to `operator<T*>`.
>> 3) Make `optional<T&>`s assignment operator only rebind the reference if
>> the optional is disengaged, thus creating wildly inconsistent behavior.
>>
>
> I contest the claim that I am breaking the interface. On the contrary, I
> believe that option 2 breaks the interface (the `vector<bool>` problem).
>
>
>> To me, all of these are *equally* bad. I'll take the problems with `T*`
>> over those choices any day of the week.
>>
>> It makes no more sense for `optional<T&>` to have pointer-like copy
>>> assignment behaviour that it would for `tuple<T&>` to have pointer-like
>>> copy assignment behaviour (which it doesn't). `optional<T>` is
>>> conceptually a *container* of `T` and it should behave as such.
>>>
>>
>> We don't allow containers of references. Nor `any`, or `variant`. And
>> you've essentially outlined why: because either we make them behave like
>> T*, or we make `optional` fundamentally different from the expected
>> interface.
>>
>
> I'm not talking STL containers obviously. I wouldn't support allowing
> references to be stored in `any` because it wouldn't be possible to
> support reference-like assignment semantics (and `any` is always copy
> assignable). It might be possible to store references in `variant`, but I
> imagine specifying its behaviour could get quite complicated. Probably best
> avoided unless there is a clear use case (like there is for `optional<T&>`
> ).
>
> Coupled with the fact that `T*` works adequately as an `optional<T&>`, and
>>>> I just don't see the need for it.
>>>>
>>>
>>> I outline four ways in which `T*` is inadequate in my paper.
>>>
>>
>> I found them no more compelling coming from your paper than I have from
>> other people's statements.
>>
>
> I have the additional case that with `optional<T&>`, the rules around
> "pass by value vs. pass by reference" and "mandatory vs. optional" become
> orthogonal, more consistent, and therefore easier for beginners to learn.
> The rules *should* be:
>
> - Add `&` or `const&` to pass by reference
> - Add `optional` when the parameter is not mandatory
>
> Instead, the rules are:
>
> - Add `&` or `const&` to pass by reference
> - Add `optional` when the parameter is not mandatory
> - *Except* when passing by reference *and* when the parameter is not
> mandatory, in which case use `T*` instead (oh and, by the way, `T*`
> has completely different semantics to `T` and `T&`)
>
> why then should `optional<int&>` have the same copy assignment semantics
>>>>> as `int*`? This is inconsistent and potentially surprising behaviour.
>>>>> `T&` cannot be rebound after initialization, so neither should
>>>>> `optional<T&>`.
>>>>>
>>>>
>>>>> The problem, as explained in my paper, is that the nature of
>>>>> `optional<T>` makes it impossible to give `optional<int&>` the same
>>>>> copy assignment behaviour as `int&`. At best, we can give it an
>>>>> unholy mixture of value and reference semantics that depend on the initial
>>>>> state of the `optional<int&>`. Thus, the only reasonable option left
>>>>> to us is to disable copy assignment altogether.
>>>>>
>>>>> I will try to present my argument more clearly in the next draft.
>>>>>
>>>>> N3672 has some discussion of copy assignment; but of course it doesn't
>>>>>> contain any discussion of the reasons it itself was rejected, and it's
>>>>>> *those* reasons that your paper is building on top of, right?
>>>>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n367
>>>>>> 2.html#optional_ref.rationale.assign
>>>>>>
>>>>>
>>>>> Yes, I mentioned that they gave no reasoning for the general consensus
>>>>> that `optional<T&>` should be copy assignable. I would certainly like
>>>>> to know, but I have a feeling it was along the lines of ,"
>>>>> `optional<T&>` *must* be a regular type", which I also address in the
>>>>> paper.
>>>>>
>>>>
>>>> If you make a specialization of `optional` that fundamentally behaves
>>>> differently from `optional`, then you're walking straight into the
>>>> `vector<bool>` problem. Only instead of making just one specialization
>>>> that's deficient, you're making an *entire category *of
>>>> specializations that are different.
>>>>
>>>
>>> Disabling operations that do not make sense or are not possible for a
>>> particular type is common practice.
>>>
>>
>> Every `optional` can be empty; that's a fundamental part of its
>> interface. But also fundamental is that every non-const `optional` can be *made
>> empty* if it wasn't.
>>
>
> True. I don't see any technical reason why assignment from `nullopt_t`
> and the `reset` function cannot be defined.
>
>
>> Also, every non-const `optional` can be given a new value, even if it has
>> one. These are fundamental parts of the interface.
>>
>
> Not true:
>
> struct foo {
> foo& operator=(foo const&) = delete;
> };
>
> foo f;
> optional<foo const> o;
> o = f; // error: use of deleted function
>
> Note that `optional<T>` *could* have been specified to allow copy/move
> assignment even if copy/move assignment weren't defined for `T`. The
> behaviour of `optional<T>` reflects the behaviour of the contained
> object. An `optional` containing a reference gets its copy assignment
> operator deleted much like a class containing a reference does, because
> defining it would give inconsistent behaviour.
>
It has occurred to me that we can also define `emplace` without causing
problems, so we *can* allow `optional<T&>` to change what it references,
just not using copy assignment. Note that we still cannot define `swap`,
since it suffers from the same problem as copy assignment (we cannot make
it semantically similar to `swap` for references). Would this make the
design any less objectionable to you? Drawing up a preliminary technical
spec, my version of `optional<T&>` currently looks like this:
template <class T> class optional<T&> {public:
typedef T value_type;
// 20.6.3.1, constructors
constexpr optional() noexcept;
constexpr optional(nullopt_t) noexcept;
constexpr optional(T&) noexcept;
template <class U> constexpr optional(const optional<U>&) noexcept;
// 20.6.3.2, assignment
optional& operator=(nullopt_t) noexcept;
optional& operator=(const optional&) = delete;
// 20.6.3.3, observers
constexpr T* operator->() const;
constexpr T& operator*() const;
constexpr explicit operator bool() const noexcept;
constexpr T& value() const;
template <class U> constexpr T value_or(U&&) const;
// 20.6.3.4, modifiers
void reset() noexcept;
void emplace(T&) noexcept;
void emplace(T&&) = delete;
private:
T* val // exposition only
}
> In your world, there are two types of `optional`s: those which are mutable
>> and those which are not. I see no reason why an immutable `optional` should
>> be spelled `optional`. The ability to destroy and recreate what gets stored
>> there is *not* optional.
>>
>
> Destroy, yes; recreate, not necessarily (as just demonstrated).
>
>
>> That's why I compare it to `vector<bool>`; because code that uses it must
>> treat it in a completely different way. Whereas code that uses a
>> `vector<T>` for some move-only type simply has to avoid `insert` and other
>> copying functions. You can still put things into the sequence and remove
>> things from the sequence. You still have that level of control.
>>
>> If you make a `vector<T>` for an immobile type, then `vector` becomes
>> dysfunctional.
>>
>
> `vector<T>` is not `optional<T>`. `optional<T&>` is perfectly usable even
> if it is not copy assignable, much like `vector<T>` is still usable for a
> move-only `T`. You can even store `optional<T&>` in containers; you just
> get limited functionality (not dysfunctionality).
>
>
>> It is not possible to implement assignment of `optional<T&>` in a way
>>> that is consistent with `optional<T>`, so it should be disabled.
>>> Specifying reference semantics would make copy assignment of
>>> `optional<T&>` behave fundamentally differently from `optional<T>`. I
>>> would argue that this is in fact *worse* than `vector<bool>`: at least
>>> with `vector<bool>` any programming errors are likely to be caught at
>>> compile-time.
>>>
>>>
>>>> If my function takes an `optional<T>`, where `T` is deduced or some
>>>> such, I shouldn't have to worry that some nitwit is going to come along as
>>>> instantiate it with `T&`. I should not have to guard this function with
>>>> `enable_if` or `requires` just to be able to ensure sane behavior.
>>>>
>>>
>>> If you indiscriminately take an `optional<T>` for all `T` then you are
>>> likely to run into problems regardless of whether `T` can be a
>>> reference type, just as if you indiscriminately take a `T`.
>>>
>>
>> Nonsense. As previously stated, there are many operations on `optional`
>> that don't care about the characteristics of `T`. You remove several of
>> them, which transforms the object into something else. It becomes
>> immutable, when before it was a mutable type.
>>
>
> The copy/move operations of `optional<T>` *do* care about the
> characteristics of `T`. Copy construction requires
> `is_copy_constructible_v<T>`. Move construction requires
> `is_move_constructible_v<T>`. Copy assignment requires `is_copy_constructible_v<T>
> && is_copy_assignable_v<T>`. Move assignment requires `is_move_constructible_v<T>
> && is_move_assignable_v<T>`.
>
>
>> Just like `vector<bool>` stops being a contiguous array of `T`s.
>>
>>
>>> Concepts will make this problem easier to manage. Even so, if my code
>>> expects `optional<T>` to be copy assignable, then you will get a
>>> compile-time error if `T` is a reference type (you would get a run-time
>>> bug if `optional<T&>` had reference copy assignment semantics).
>>>
>>
>> So, why should I clutter up my code with needless `enable_if/requires`
>> clauses just to stop you from passing me something I don't want to deal
>> with? Wouldn't it make sense to make this a new type with its own name, so
>> that users who want to pass optional references can do so?
>>
>
> As I've just shown, if you indiscriminately accept an `optional<T>`
> parameter for any type `T`, I can pass you any number of types that will
> disable the various copy/move operations. Do you have a use case where
> `optional<T&>` specifically would cause a problem?
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHocnE-ayi0j7gNYzwX8-yQ%2B83byAagGOeTB_hKGNEpfAZB8iQ%40mail.gmail.com.
--f403043c49483a49090549c9f153
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Mar 2, 2017 at 4:11 PM, Joseph Thomson <span dir=3D"ltr"><<a href=3D=
"mailto:joseph.thomson@gmail.com" target=3D"_blank">joseph.thomson@gmail.co=
m</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><s=
pan class=3D"gmail-">On Thu, Mar 2, 2017 at 1:19 PM, Nicol Bolas <span dir=
=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmcke=
sson@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr">On Wednesday, March 1, 2017 at 11:16:52 PM =
UTC-5, Joseph Thomson wrote:<span class=3D"gmail-m_607101740440477199gmail-=
"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><=
div class=3D"gmail_quote">On Thu, Mar 2, 2017 at 11:18 AM, Nicol Bolas <spa=
n dir=3D"ltr"><<a rel=3D"nofollow">jmck...@gmail.com</a>></span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">On=
Wednesday, March 1, 2017 at 9:36:22 PM UTC-5, Joseph Thomson wrote:<span><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div=
class=3D"gmail_quote">On Thu, Mar 2, 2017 at 8:00 AM, Arthur O'Dwyer <=
span dir=3D"ltr"><<a rel=3D"nofollow">arthur....@gmail.com</a>></span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><span>On Tuesday, February 28, 2017 at 5:57:35 PM UTC-8, <a>joseph....@=
gmail.com</a> wrote:</span></div></blockquote><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><div dir=3D"ltr"><div>However, I don't understand =
why you'd want <font face=3D"courier new, monospace">optional<T&=
></font> to behave so unusually differently from <font face=3D"courier n=
ew, monospace">optional<T></font> w.r.t. copy assignment and such. IM=
NSHO, <font face=3D"courier new, monospace">optional<T&></font> s=
hould behave identically to <font face=3D"courier new, monospace">optional&=
lt;reference_wrapper<T>></font><wbr>, which is to say, almost iden=
tically to <font face=3D"courier new, monospace">T*</font>.</div><div>Can y=
ou add something to your paper explaining (or rehashing) exactly what are t=
he arguments against the above (or N3672-style) semantics?</div></div></blo=
ckquote><div>=C2=A0<br></div>On the contrary, the copy assignment behaviour=
for <span style=3D"font-family:monospace,monospace">`optional<T&>=
;`</span> proposed by <i>N3672</i> was unusually different from that of <sp=
an style=3D"font-family:monospace,monospace">`optional<T>`</span>. Th=
e copy assignment semantics of <span style=3D"font-family:monospace,monospa=
ce">`optional<T>`</span> reflect the copy assignment semantics of <sp=
an style=3D"font-family:monospace,monospace">`T`</span>: <span style=3D"fon=
t-family:monospace,monospace">`optional<int>`</span> has the same cop=
y assignment semantics as <span style=3D"font-family:monospace,monospace">`=
int`</span> (value semantics) and <span style=3D"font-family:monospace,mono=
space">`optional<int*>`</span> has the same copy assignment semantics=
as <span style=3D"font-family:monospace,monospace">`int*`</span> (referenc=
e semantics);</div></div></div></blockquote></span><div><br>No it doesn'=
;t. `optional<int*>` and `int*` both have value semantics, with respe=
ct to the object in question. That object being a <i>pointer</i>.<br></div>=
</div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>=
=C2=A0</div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr"><div>It only has reference semantics with respect to the o=
bject being pointed to. But that's fundamentally no different than `opt=
ional<int>`, if that `int` just so happens to be a handle into some s=
ystem that represents an object. `optional<int>` still has value sema=
ntics in that case.<br></div></div></blockquote><div>=C2=A0</div><div>I'=
;m using the <a href=3D"https://isocpp.org/wiki/faq/value-vs-ref-semantics#=
val-vs-ref-semantics" rel=3D"nofollow" target=3D"_blank">terminology</a> as=
defined by the isocpp website. Yeah, technically only initialization of <s=
pan style=3D"font-family:monospace,monospace">`T&`</span>
has true reference semantics and everything else in C++ has value=20
semantics. But this is nitpicking and is totally irrelevant to the issue
at hand.<br></div></div></div></div></blockquote></span><div><br>No, it=
9;s actually very relevant to the issue at hand. It shows that `optional<=
;T*>` is at its core a very different thing from `optional<T&>=
`. It reinforces that references are not values. It reinforces the idea tha=
t `optional` is a value type, and therefore should only be able to contain =
other value types.<br><br>You want to put a non-value type into a type that=
is meant to contain values.<br></div></div></blockquote><div><br></div></s=
pan><div><span style=3D"font-family:monospace,monospace">`optional`</span> =
is <i>currently</i> only defined for value types. I want to define its beha=
viour for reference types. It is possible to define <span style=3D"font-fam=
ily:monospace,monospace">`optional<T&>`</span> to be consistent w=
ith the behaviour of <span style=3D"font-family:monospace,monospace">`optio=
nal<T>`</span>. If this weren't the case, I would agree with you =
that it should be a different type.<br></div><span class=3D"gmail-"><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><span class=3D"gmail-m_607101740440477199gmail-"><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote=
"><div> </div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D=
"ltr"><div>It's questions like this that make me feel that `optional` r=
eferences are a <i>terrible</i> idea. Some people will expect it to have on=
e behavior, others will expect it to have a contradictory one, and in the e=
nd only one side will be happy.</div></div></blockquote><div><br></div><div=
>The expectation that copy assignment of <span style=3D"font-family:monospa=
ce,monospace">`optional<T&>`</span> have the same semantics as co=
py assignment of <span style=3D"font-family:monospace,monospace">`T*`</span=
> is, in my opinion, a result of the erroneous belief that the inability to=
rebind <span style=3D"font-family:monospace,monospace">`T&`</span> is =
somehow a bug in its design, that it is somehow reasonable to think of <spa=
n style=3D"font-family:monospace,monospace">`T&`</span> as a <span styl=
e=3D"font-family:monospace,monospace">`T*`</span> that cannot be null. It s=
eems that <span style=3D"font-family:monospace,monospace">`optional<T&am=
p;>`</span> is seen as an opportunity to "fix" this bug by all=
owing <span style=3D"font-family:monospace,monospace">`T&`</span> to be=
rebound by defining pointer-like copy assignment semantics. The problem is=
that the inability to rebind <span style=3D"font-family:monospace,monospac=
e">`T&`</span> is <i>not</i> a bug; it is a feature. A <span style=3D"f=
ont-family:monospace,monospace">`T&`</span> is essentially an alias of =
an existing object of type <span style=3D"font-family:monospace,monospace">=
`T`</span>, and behaves in almost every way like an object of type <span st=
yle=3D"font-family:monospace,monospace">`T`</span>, <i>including</i> copy a=
ssignment.<br></div></div></div></div></blockquote><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><div><br></div></blockquote><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quot=
e"><div></div><div>I believe that there is an <i>objective</i> case to be m=
ade <i>against</i> giving <span style=3D"font-family:monospace,monospace">`=
optional<T&>`</span> reference copy assignment semantics.</div></=
div></div></div></blockquote></span><div><br>It's easy to declare that =
your subjective opinion is objective, but that doesn't make it true. Th=
ere are just as many people who <i>want</i> rebindable references as those =
who think rebinding is bad. And they can make arguments for it too. I fail =
to see how your argument is any more objective than theirs.<br></div></div>=
</blockquote><div><br></div></span><div>Forget the term "objective&quo=
t;. I believe my case is superior from the standpoint of consistency with <=
span style=3D"font-family:monospace,monospace">`optional<T>`</span>. =
The argument for allowing <span style=3D"font-family:monospace,monospace">`=
optional<T&>`</span> to be rebound amounts to, "<span style=
=3D"font-family:monospace,monospace">`optional<T&>`</span> should=
be copy assignable because regularity is good, despite the fact that <span=
style=3D"font-family:monospace,monospace">`T&`</span> is not even an o=
bject type, that it will require a complete redefinition of copy assignment=
for this specialization, that the copy assignment behaviour will not match=
that of <span style=3D"font-family:monospace,monospace">`T&`</span>, a=
nd that <span style=3D"font-family:monospace,monospace">`optional<refere=
nce_wrapper<T><wbr>>`</span> already fits my use case."<br></=
div><span class=3D"gmail-"><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><div dir=3D"ltr"><div>My problem with the whole `optiona=
l<T&>` discussion is that it boils down to 3 choices:<br><br>1) B=
reak `optional<T&>`'s interface, thus effectively making it a=
new type (see below), but we'll keep the same name for some reason.<br=
>2) Make `optional<T&>`'s assignment operator rebind the refe=
rence, thus making it effectively equivalent to `operator<T*>`.<br>3)=
Make `optional<T&>`s assignment operator only rebind the referen=
ce if the optional is disengaged, thus creating wildly inconsistent behavio=
r.<br></div></div></blockquote><div><br></div></span><div>I contest the cla=
im that I am breaking the interface. On the contrary, I believe that option=
2 breaks the interface (the <span style=3D"font-family:monospace,monospace=
">`vector<bool>`</span> problem).<br></div><span class=3D"gmail-"><di=
v>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D=
"ltr"><div>To me, all of these are <i>equally</i> bad. I'll take the pr=
oblems with `T*` over those choices any day of the week.<br><br></div><span=
class=3D"gmail-m_607101740440477199gmail-"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>It=
makes no more sense for <span style=3D"font-family:monospace,monospace">`o=
ptional<T&>`</span> to have pointer-like copy assignment behaviou=
r that it would for <span style=3D"font-family:monospace,monospace">`tuple&=
lt;T&>`</span> to have pointer-like copy assignment behaviour (which=
it doesn't). <span style=3D"font-family:monospace,monospace">`optional=
<T>`</span> is conceptually a <i>container</i> of <span style=3D"font=
-family:monospace,monospace">`T`</span> and it should behave as such.<br></=
div></div></div></div></blockquote></span><div><br>We don't allow conta=
iners of references. Nor `any`, or `variant`. And you've essentially ou=
tlined why: because either we make them behave like T*, or we make `optiona=
l` fundamentally different from the expected interface.<br></div></div></bl=
ockquote><div>=C2=A0<br></div></span><div>I'm not talking STL container=
s obviously. I wouldn't support allowing references to be stored in <sp=
an style=3D"font-family:monospace,monospace">`any`</span> because it wouldn=
't be possible to support reference-like assignment semantics (and <spa=
n style=3D"font-family:monospace,monospace">`any`</span> is always copy ass=
ignable). It might be possible to store references in <span style=3D"font-f=
amily:monospace,monospace">`variant`</span>, but I imagine specifying its b=
ehaviour could get quite complicated. Probably best avoided unless there is=
a clear use case (like there is for <span style=3D"font-family:monospace,m=
onospace">`optional<T&>`</span>).<br></div><span class=3D"gmail-"=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><span class=3D"gmail-m_607101740440477199gmail-"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_=
quote"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div di=
r=3D"ltr"><div>Coupled with the fact that `T*` works adequately as an `opti=
onal<T&>`, and I just don't see the need for it.<br></div></d=
iv></blockquote><div><br></div><div>I outline four ways in which <span styl=
e=3D"font-family:monospace,monospace">`T*`</span> is inadequate in my paper=
..</div></div></div></div></blockquote></span><div><br>I found them no more =
compelling coming from your paper than I have from other people's state=
ments.<br></div></div></blockquote><div><br></div></span><div>I have the ad=
ditional case that with <span style=3D"font-family:monospace,monospace">`op=
tional<T&>`</span>, the rules around "pass by value vs. pass=
by reference" and "mandatory vs. optional" become orthogona=
l, more consistent, and therefore easier for beginners to learn. The rules =
<i>should</i> be:<br><ul><li>Add <span style=3D"font-family:monospace,monos=
pace">`&`</span> or <span style=3D"font-family:monospace,monospace">`co=
nst&`</span> to pass by reference</li><li>Add <span style=3D"font-famil=
y:monospace,monospace">`optional`</span> when the parameter is not mandator=
y</li></ul><p>Instead, the rules are:</p><ul><li>Add <span style=3D"font-fa=
mily:monospace,monospace">`&`</span> or <span style=3D"font-family:mono=
space,monospace">`const&`</span> to pass by reference</li><li>Add <span=
style=3D"font-family:monospace,monospace">`optional`</span> when the param=
eter is not mandatory</li><li><i>Except</i> when passing by reference <i>an=
d</i> when the parameter is not mandatory, in which case use <span style=3D=
"font-family:monospace,monospace">`T*`</span> instead (oh and, by the way, =
<span style=3D"font-family:monospace,monospace">`T*`</span> has completely =
different semantics to <span style=3D"font-family:monospace,monospace">`T`<=
/span> and <span style=3D"font-family:monospace,monospace">`T&`</span>)=
<br></li></ul></div><span class=3D"gmail-"><div></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div dir=3D"ltr"><div></div><span class=3D"gma=
il-m_607101740440477199gmail-"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div> </div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div></div><span=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><d=
iv class=3D"gmail_quote">why then should <span style=3D"font-family:monospa=
ce,monospace">`optional<int&>`</span> have the same copy assignme=
nt semantics as <span style=3D"font-family:monospace,monospace">`int*`</spa=
n>? This is inconsistent and potentially surprising behaviour. <span style=
=3D"font-family:monospace,monospace">`T&`</span> cannot be rebound afte=
r initialization, so neither should <span style=3D"font-family:monospace,mo=
nospace">`optional<T&>`</span>.<br></div></div></div></blockquote=
><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><br></blockquote></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div=
><div class=3D"gmail_quote"></div><div>The problem, as explained in my pape=
r, is that the nature of <span style=3D"font-family:monospace,monospace">`o=
ptional<T>`</span> makes it impossible to give <span style=3D"font-fa=
mily:monospace,monospace">`optional<int&>`</span> the same copy a=
ssignment behaviour as <span style=3D"font-family:monospace,monospace">`int=
&`</span>. At best, we can give it an unholy mixture of value and refer=
ence semantics that depend on the initial state of the <span style=3D"font-=
family:monospace,monospace">`optional<int&>`</span>. Thus, the on=
ly reasonable option left to us is to disable copy assignment altogether.<b=
r><br>I will try to present my argument more clearly in the next draft.<br>=
<br></div><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div>N3672 has some discussion of copy assignment; but of course i=
t doesn't contain any discussion of the reasons it itself was rejected,=
and it's <i>those</i> reasons that your paper is building on top of, r=
ight?</div><div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/pape=
rs/2013/n3672.html#optional_ref.rationale.assign" rel=3D"nofollow" target=
=3D"_blank">http://www.open-std.org/jtc1/s<wbr>c22/wg21/docs/papers/2013/n3=
67<wbr>2.html#optional_ref.rationale.<wbr>assign</a><br></div></div></block=
quote><div>=C2=A0<br></div><div>Yes, I mentioned that they gave no reasonin=
g for the general consensus that <span style=3D"font-family:monospace,monos=
pace">`optional<T&>`</span> should be copy assignable. I would ce=
rtainly like to know, but I have a feeling it was along the lines of ,"=
;<span style=3D"font-family:monospace,monospace">`optional<T&>`</=
span> <i>must</i> be a regular type", which I also address in the pape=
r.=C2=A0</div></div></div></div></blockquote></span><div><br>If you make a =
specialization of `optional` that fundamentally behaves differently from `o=
ptional`, then you're walking straight into the `vector<bool>` pr=
oblem. Only instead of making just one specialization that's deficient,=
you're making an <i>entire category </i>of specializations that are di=
fferent.<br></div></div></blockquote><div><br></div><div>Disabling operatio=
ns that do not make sense or are not possible for a particular type is comm=
on practice.</div></div></div></div></blockquote></span><div><br>Every `opt=
ional` can be empty; that's a fundamental part of its interface. But al=
so fundamental is that every non-const `optional` can be <i>made empty</i> =
if it wasn't.</div></div></blockquote><div><br></div></span><div>True. =
I don't see any technical reason why assignment from <span style=3D"fon=
t-family:monospace,monospace">`nullopt_t`</span> and the <span style=3D"fon=
t-family:monospace,monospace">`reset`</span> function cannot be defined.<br=
></div><span class=3D"gmail-"><div>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"ltr"><div>Also, every non-const `optional=
` can be given a new value, even if it has one. These are fundamental parts=
of the interface.<br></div></div></blockquote><div><br></div></span><div>N=
ot true:<br></div><div><br><div style=3D"margin-left:40px"><span style=3D"f=
ont-family:monospace,monospace">struct foo {</span><br><span style=3D"font-=
family:monospace,monospace">=C2=A0 foo& operator=3D(foo const&) =3D=
delete;</span><br><span style=3D"font-family:monospace,monospace">};</span=
><br><span style=3D"font-family:monospace,monospace"></span><br><span style=
=3D"font-family:monospace,monospace">foo f;</span><br><span style=3D"font-f=
amily:monospace,monospace">optional<foo const> o;</span><br><span sty=
le=3D"font-family:monospace,monospace">o =3D f; // error: use of deleted fu=
nction</span><br></div>=C2=A0<br></div><div>Note that <span style=3D"font-f=
amily:monospace,monospace">`optional<T>`</span> <i>could</i> have bee=
n specified to allow copy/move assignment even if copy/move assignment were=
n't defined for <span style=3D"font-family:monospace,monospace">`T`</sp=
an>. The behaviour of <span style=3D"font-family:monospace,monospace">`opti=
onal<T>`</span> reflects the behaviour of the contained object. An <s=
pan style=3D"font-family:monospace,monospace">`optional`</span> containing =
a reference gets its copy assignment operator deleted much like a class con=
taining a reference does, because defining it would give inconsistent behav=
iour.<br></div></div></div></div></blockquote><div><br></div><div>It has oc=
curred to me that we can also define <span style=3D"font-family:monospace,m=
onospace">`emplace`</span> without causing problems, so we <i>can</i> allow=
<span style=3D"font-family:monospace,monospace">`optional<T&>`</=
span> to change what it references, just not using copy assignment. Note th=
at we still cannot define <span style=3D"font-family:monospace,monospace">`=
swap`</span>, since it suffers from the same problem as copy assignment (we=
cannot make it semantically similar to <span style=3D"font-family:monospac=
e,monospace">`swap`</span> for references). Would this make the design any =
less objectionable to you? Drawing up a preliminary technical spec, my vers=
ion of <span style=3D"font-family:monospace,monospace">`optional<T&&=
gt;`</span> currently looks like this:<br><span class=3D"gmail-Apple-style-=
span" style=3D"border-collapse:separate;color:rgb(0,0,0);font-family:"=
times new roman";font-style:normal;font-variant:normal;font-weight:nor=
mal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform=
:none;white-space:normal;word-spacing:0px;font-size:medium"><span class=3D"=
gmail-Apple-style-span" style=3D"color:rgb(51,51,51);font-family:helvetica,=
arial,freesans,clean,sans-serif;font-size:14px;line-height:22px"><pre style=
=3D"margin:15px 0px;padding:6px 10px;border-width:1px;font-size:13px;font-f=
amily:consolas,"liberation mono",courier,monospace;background-col=
or:rgb(248,248,248);border-style:solid;border-color:rgb(204,204,204);line-h=
eight:19px;overflow:auto;border-radius:3px"><span class=3D"gmail-pl-k" styl=
e=3D"margin:0px;padding:0px;border-width:0px;border-style:initial;border-co=
lor:initial;color:rgb(167,29,93)">template </span><<span class=3D"gmail-=
pl-k" style=3D"margin:0px;padding:0px;border-width:0px;border-style:initial=
;border-color:initial;color:rgb(167,29,93)">class</span> <span class=3D"gma=
il-pl-en" style=3D"margin:0px;padding:0px;border-width:0px;border-style:ini=
tial;border-color:initial;color:rgb(121,93,163)">T</span>> <span class=
=3D"gmail-pl-k" style=3D"margin:0px;padding:0px;border-width:0px;border-sty=
le:initial;border-color:initial;color:rgb(167,29,93)">class</span> <span cl=
ass=3D"gmail-pl-en" style=3D"margin:0px;padding:0px;border-width:0px;border=
-style:initial;border-color:initial;color:rgb(121,93,163)">optional</span>&=
lt;T&> {
<span class=3D"gmail-pl-k" style=3D"margin:0px;padding:0px;border-width:0px=
;border-style:initial;border-color:initial;color:rgb(167,29,93)">public:</s=
pan>
<span class=3D"gmail-pl-k" style=3D"margin:0px;padding:0px;border-width:0=
px;border-style:initial;border-color:initial;color:rgb(167,29,93)">typedef<=
/span> T value_type;
<span class=3D"gmail-pl-c" style=3D"margin:0px;padding:0px;border-width:0=
px;border-style:initial;border-color:initial;color:rgb(150,152,150)"><span =
class=3D"gmail-pl-c" style=3D"margin:0px;padding:0px;border-width:0px;borde=
r-style:initial;border-color:initial;color:rgb(150,152,150)">//</span> 20.6=
..3.1, constructors</span>
<span class=3D"gmail-pl-k" style=3D"margin:0px;padding:0px;border-width:0=
px;border-style:initial;border-color:initial;color:rgb(167,29,93)">constexp=
r</span> <span class=3D"gmail-pl-en" style=3D"margin:0px;padding:0px;border=
-width:0px;border-style:initial;border-color:initial;color:rgb(121,93,163)"=
>optional</span>() <span class=3D"gmail-pl-k" style=3D"margin:0px;padding:0=
px;border-width:0px;border-style:initial;border-color:initial;color:rgb(167=
,29,93)">noexcept</span>;
<span class=3D"gmail-pl-k" style=3D"margin:0px;padding:0px;border-width:0=
px;border-style:initial;border-color:initial;color:rgb(167,29,93)">constexp=
r</span> <span class=3D"gmail-pl-en" style=3D"margin:0px;padding:0px;border=
-width:0px;border-style:initial;border-color:initial;color:rgb(121,93,163)"=
>optional</span>(<span class=3D"gmail-pl-c1" style=3D"margin:0px;padding:0p=
x;border-width:0px;border-style:initial;border-color:initial;color:rgb(0,13=
4,179)">nullopt_t</span>) <span class=3D"gmail-pl-k" style=3D"margin:0px;pa=
dding:0px;border-width:0px;border-style:initial;border-color:initial;color:=
rgb(167,29,93)">noexcept</span>;
<span class=3D"gmail-pl-k" style=3D"margin:0px;padding:0px;border-width:0=
px;border-style:initial;border-color:initial;color:rgb(167,29,93)">constexp=
r</span> <span class=3D"gmail-pl-en" style=3D"margin:0px;padding:0px;border=
-width:0px;border-style:initial;border-color:initial;color:rgb(121,93,163)"=
>optional</span>(T&) <span class=3D"gmail-pl-k" style=3D"margin:0px;pad=
ding:0px;border-width:0px;border-style:initial;border-color:initial;color:r=
gb(167,29,93)">noexcept</span>;
<span class=3D"gmail-pl-k" style=3D"margin:0px;padding:0px;border-width:0=
px;border-style:initial;border-color:initial;color:rgb(167,29,93)">template=
</span><<span class=3D"gmail-pl-k" style=3D"margin:0px;padding:0px;bord=
er-width:0px;border-style:initial;border-color:initial;color:rgb(167,29,93)=
">class</span> <span class=3D"gmail-pl-en" style=3D"margin:0px;padding:0px;=
border-width:0px;border-style:initial;border-color:initial;color:rgb(121,93=
,163)">U</span>> <span class=3D"gmail-pl-k" style=3D"margin:0px;padding:=
0px;border-width:0px;border-style:initial;border-color:initial;color:rgb(16=
7,29,93)">constexpr</span> <span class=3D"gmail-pl-en" style=3D"margin:0px;=
padding:0px;border-width:0px;border-style:initial;border-color:initial;colo=
r:rgb(121,93,163)">optional</span>(<span class=3D"gmail-pl-k" style=3D"marg=
in:0px;padding:0px;border-width:0px;border-style:initial;border-color:initi=
al;color:rgb(167,29,93)">const</span> optional<U>&) <span class=
=3D"gmail-pl-k" style=3D"margin:0px;padding:0px;border-width:0px;border-sty=
le:initial;border-color:initial;color:rgb(167,29,93)">noexcept</span>;
<span class=3D"gmail-pl-c" style=3D"margin:0px;padding:0px;border-width:0=
px;border-style:initial;border-color:initial;color:rgb(150,152,150)"><span =
class=3D"gmail-pl-c" style=3D"margin:0px;padding:0px;border-width:0px;borde=
r-style:initial;border-color:initial;color:rgb(150,152,150)">//</span> 20.6=
..3.2, assignment</span>
optional& <span class=3D"gmail-pl-k" style=3D"margin:0px;padding:0px;=
border-width:0px;border-style:initial;border-color:initial;color:rgb(167,29=
,93)">operator</span>=3D(<span class=3D"gmail-pl-c1" style=3D"margin:0px;pa=
dding:0px;border-width:0px;border-style:initial;border-color:initial;color:=
rgb(0,134,179)">nullopt_t</span>) noexcept;
optional& <span class=3D"gmail-pl-k" style=3D"margin:0px;padding:0px;=
border-width:0px;border-style:initial;border-color:initial;color:rgb(167,29=
,93)">operator</span>=3D(<span class=3D"gmail-pl-k" style=3D"margin:0px;pad=
ding:0px;border-width:0px;border-style:initial;border-color:initial;color:r=
gb(167,29,93)">const</span> optional&) =3D <span class=3D"gmail-pl-k" s=
tyle=3D"margin:0px;padding:0px;border-width:0px;border-style:initial;border=
-color:initial;color:rgb(167,29,93)">delete</span>;
<span class=3D"gmail-pl-c" style=3D"margin:0px;padding:0px;border-width:0=
px;border-style:initial;border-color:initial;color:rgb(150,152,150)"><span =
class=3D"gmail-pl-c" style=3D"margin:0px;padding:0px;border-width:0px;borde=
r-style:initial;border-color:initial;color:rgb(150,152,150)">//</span> 20.6=
..3.3, observers</span>
<span class=3D"gmail-pl-k" style=3D"margin:0px;padding:0px;border-width:0=
px;border-style:initial;border-color:initial;color:rgb(167,29,93)">constexp=
r</span> T* <span class=3D"gmail-pl-k" style=3D"margin:0px;padding:0px;bord=
er-width:0px;border-style:initial;border-color:initial;color:rgb(167,29,93)=
">operator</span>->() <span class=3D"gmail-pl-k" style=3D"margin:0px;pad=
ding:0px;border-width:0px;border-style:initial;border-color:initial;color:r=
gb(167,29,93)">const</span>;
<span class=3D"gmail-pl-k" style=3D"margin:0px;padding:0px;border-width:0=
px;border-style:initial;border-color:initial;color:rgb(167,29,93)">constexp=
r</span> T& <span class=3D"gmail-pl-k" style=3D"margin:0px;padding:0px;=
border-width:0px;border-style:initial;border-color:initial;color:rgb(167,29=
,93)">operator</span>*() <span class=3D"gmail-pl-k" style=3D"margin:0px;pad=
ding:0px;border-width:0px;border-style:initial;border-color:initial;color:r=
gb(167,29,93)">const</span>;
<span class=3D"gmail-pl-k" style=3D"margin:0px;padding:0px;border-width:0=
px;border-style:initial;border-color:initial;color:rgb(167,29,93)">constexp=
r</span> <span class=3D"gmail-pl-k" style=3D"margin:0px;padding:0px;border-=
width:0px;border-style:initial;border-color:initial;color:rgb(167,29,93)">e=
xplicit</span> <span class=3D"gmail-pl-k" style=3D"margin:0px;padding:0px;b=
order-width:0px;border-style:initial;border-color:initial;color:rgb(167,29,=
93)">operator</span> <span class=3D"gmail-pl-en" style=3D"margin:0px;paddin=
g:0px;border-width:0px;border-style:initial;border-color:initial;color:rgb(=
121,93,163)">bool</span>() <span class=3D"gmail-pl-k" style=3D"margin:0px;p=
adding:0px;border-width:0px;border-style:initial;border-color:initial;color=
:rgb(167,29,93)">const</span> <span class=3D"gmail-pl-k" style=3D"margin:0p=
x;padding:0px;border-width:0px;border-style:initial;border-color:initial;co=
lor:rgb(167,29,93)">noexcept</span>;
<span class=3D"gmail-pl-k" style=3D"margin:0px;padding:0px;border-width:0=
px;border-style:initial;border-color:initial;color:rgb(167,29,93)">constexp=
r</span> T& <span class=3D"gmail-pl-en" style=3D"margin:0px;padding:0px=
;border-width:0px;border-style:initial;border-color:initial;color:rgb(121,9=
3,163)">value</span>() <span class=3D"gmail-pl-k" style=3D"margin:0px;paddi=
ng:0px;border-width:0px;border-style:initial;border-color:initial;color:rgb=
(167,29,93)">const</span>;
<span class=3D"gmail-pl-k" style=3D"margin:0px;padding:0px;border-width:0=
px;border-style:initial;border-color:initial;color:rgb(167,29,93)">template=
</span><<span class=3D"gmail-pl-k" style=3D"margin:0px;padding:0px;bord=
er-width:0px;border-style:initial;border-color:initial;color:rgb(167,29,93)=
">class</span> <span class=3D"gmail-pl-en" style=3D"margin:0px;padding:0px;=
border-width:0px;border-style:initial;border-color:initial;color:rgb(121,93=
,163)">U</span>> <span class=3D"gmail-pl-k" style=3D"margin:0px;padding:=
0px;border-width:0px;border-style:initial;border-color:initial;color:rgb(16=
7,29,93)">constexpr</span> T <span class=3D"gmail-pl-en" style=3D"margin:0p=
x;padding:0px;border-width:0px;border-style:initial;border-color:initial;co=
lor:rgb(121,93,163)">value_or</span>(U&&) <span class=3D"gmail-pl-k=
" style=3D"margin:0px;padding:0px;border-width:0px;border-style:initial;bor=
der-color:initial;color:rgb(167,29,93)">const</span>;
<span class=3D"gmail-pl-c" style=3D"margin:0px;padding:0px;border-width:0=
px;border-style:initial;border-color:initial;color:rgb(150,152,150)"><span =
class=3D"gmail-pl-c" style=3D"margin:0px;padding:0px;border-width:0px;borde=
r-style:initial;border-color:initial;color:rgb(150,152,150)">//</span> 20.6=
..3.4, modifiers</span>
<span class=3D"gmail-pl-k" style=3D"margin:0px;padding:0px;border-width:0=
px;border-style:initial;border-color:initial;color:rgb(167,29,93)">void</sp=
an> <span class=3D"gmail-pl-en" style=3D"margin:0px;padding:0px;border-widt=
h:0px;border-style:initial;border-color:initial;color:rgb(121,93,163)">rese=
t</span>() <span class=3D"gmail-pl-k" style=3D"margin:0px;padding:0px;borde=
r-width:0px;border-style:initial;border-color:initial;color:rgb(167,29,93)"=
>noexcept</span>;
<span class=3D"gmail-pl-k" style=3D"margin:0px;padding:0px;border-width:0=
px;border-style:initial;border-color:initial;color:rgb(167,29,93)">void</sp=
an> <span class=3D"gmail-pl-en" style=3D"margin:0px;padding:0px;border-widt=
h:0px;border-style:initial;border-color:initial;color:rgb(121,93,163)">empl=
ace</span>(T&) <span class=3D"gmail-pl-k" style=3D"margin:0px;padding:0=
px;border-width:0px;border-style:initial;border-color:initial;color:rgb(167=
,29,93)">noexcept</span>;
<span class=3D"gmail-pl-k" style=3D"margin:0px;padding:0px;border-width:0=
px;border-style:initial;border-color:initial;color:rgb(167,29,93)">void</sp=
an> <span class=3D"gmail-pl-en" style=3D"margin:0px;padding:0px;border-widt=
h:0px;border-style:initial;border-color:initial;color:rgb(121,93,163)">empl=
ace</span>(T&&) =3D delete;
<span class=3D"gmail-pl-k" style=3D"margin:0px;padding:0px;border-width:0px=
;border-style:initial;border-color:initial;color:rgb(167,29,93)">private:</=
span>
T* val <span class=3D"gmail-pl-c" style=3D"margin:0px;padding:0px;border-=
width:0px;border-style:initial;border-color:initial;color:rgb(150,152,150)"=
><span class=3D"gmail-pl-c" style=3D"margin:0px;padding:0px;border-width:0p=
x;border-style:initial;border-color:initial;color:rgb(150,152,150)">//</spa=
n> exposition only</span>
}</pre></span></span></div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><span class=3D"gmail-"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><div>In your world, there are two types of =
`optional`s: those which are mutable and those which are not. I see no reas=
on why an immutable `optional` should be spelled `optional`. The ability to=
destroy and recreate what gets stored there is <i>not</i> optional.<br></d=
iv></div></blockquote><div><br></div></span><div>Destroy, yes; recreate, no=
t necessarily (as just demonstrated).<br></div><span class=3D"gmail-"><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><div>That's why I compare it to `vector<bool>`; because code =
that uses it must treat it in a completely different way. Whereas code that=
uses a `vector<T>` for some move-only type simply has to avoid `inse=
rt` and other copying functions. You can still put things into the sequence=
and remove things from the sequence. You still have that level of control.=
<br><br>If you make a `vector<T>` for an immobile type, then `vector`=
becomes dysfunctional. <br></div></div></blockquote><div><br></div></span>=
<div><span style=3D"font-family:monospace,monospace">`vector<T>`</spa=
n> is not <span style=3D"font-family:monospace,monospace">`optional<T>=
;`</span>. <span style=3D"font-family:monospace,monospace">`optional<T&a=
mp;>`</span> is perfectly usable even if it is not copy assignable, much=
like <span style=3D"font-family:monospace,monospace">`vector<T>`</sp=
an> is still usable for a move-only <span style=3D"font-family:monospace,mo=
nospace">`T`</span>. You can even store <span style=3D"font-family:monospac=
e,monospace">`optional<T&>`</span> in containers; you just get li=
mited functionality (not dysfunctionality).<br></div><span class=3D"gmail-"=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div di=
r=3D"ltr"><span class=3D"gmail-m_607101740440477199gmail-"><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail=
_quote"><div>It is not possible to implement assignment of <span style=3D"f=
ont-family:monospace,monospace">`optional<T&>`</span> in a way th=
at is consistent with <span style=3D"font-family:monospace,monospace">`opti=
onal<T>`</span>, so it should be disabled. Specifying reference seman=
tics would make copy assignment of <span style=3D"font-family:monospace,mon=
ospace">`optional<T&>`</span> behave fundamentally differently fr=
om `optional<T>`. I would argue that this is in fact <i>worse</i> tha=
n <span style=3D"font-family:monospace,monospace">`vector<bool>`</spa=
n>: at least with <span style=3D"font-family:monospace,monospace">`vector&l=
t;bool>`</span> any programming errors are likely to be caught at compil=
e-time.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><div>If my function takes an `optional<T>=
`, where `T` is deduced or some such, I shouldn't have to worry that so=
me nitwit is going to come along as instantiate it with `T&`. I should =
not have to guard this function with `enable_if` or `requires` just to be a=
ble to ensure sane behavior.<br></div></div></blockquote><div><br></div><di=
v>If you indiscriminately take an <span style=3D"font-family:monospace,mono=
space">`optional<T>`</span> for all <span style=3D"font-family:monosp=
ace,monospace">`T`</span> then you are likely to run into problems regardle=
ss of whether <span style=3D"font-family:monospace,monospace">`T`</span> ca=
n be a reference type, just as if you indiscriminately take a <span style=
=3D"font-family:monospace,monospace">`T`</span>.</div></div></div></div></b=
lockquote></span><div><br>Nonsense. As previously stated, there are many op=
erations on `optional` that don't care about the characteristics of `T`=
.. You remove several of them, which transforms the object into something el=
se. It becomes immutable, when before it was a mutable type.<br></div></div=
></blockquote><div><br></div></span><div>The copy/move operations of <span =
style=3D"font-family:monospace,monospace">`optional<T>`</span> <i>do<=
/i> care about the characteristics of <span style=3D"font-family:monospace,=
monospace">`T`</span>. Copy construction requires <span style=3D"font-famil=
y:monospace,monospace">`is_copy_constructible_v<T>`</span>. Move cons=
truction requires <span style=3D"font-family:monospace,monospace">`is_move_=
constructible_v<T>`</span>. Copy assignment requires <span style=3D"f=
ont-family:monospace,monospace">`is_copy_constructible_v<T> &&=
; is_copy_assignable_v<T>`</span>. Move assignment requires <span sty=
le=3D"font-family:monospace,monospace">`is_move_constructible_v<T> &a=
mp;& is_move_assignable_v<T>`</span>.<br></div><span class=3D"gma=
il-"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><di=
v dir=3D"ltr"><div>Just like `vector<bool>` stops being a contiguous =
array of `T`s.<br>=C2=A0</div><span class=3D"gmail-m_607101740440477199gmai=
l-"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div=
><div class=3D"gmail_quote"><div>Concepts will make this problem easier to =
manage. Even so, if my code expects <span style=3D"font-family:monospace,mo=
nospace">`optional<T>`</span> to be copy assignable, then you will ge=
t a compile-time error if <span style=3D"font-family:monospace,monospace">`=
T`</span> is a reference type (you would get a run-time bug if <span style=
=3D"font-family:monospace,monospace">`optional<T&>`</span> had re=
ference copy assignment semantics).<br></div></div></div></div></blockquote=
></span><div><br>So, why should I clutter up my code with needless `enable_=
if/requires` clauses just to stop you from passing me something I don't=
want to deal with? Wouldn't it make sense to make this a new type with=
its own name, so that users who want to pass optional references can do so=
?<span class=3D"gmail-m_607101740440477199gmail-"></span></div></div></bloc=
kquote></span><div><br>As I've just shown, if you indiscriminately acce=
pt an <span style=3D"font-family:monospace,monospace">`optional<T>`</=
span> parameter for any type <span style=3D"font-family:monospace,monospace=
">`T`</span>, I can pass you any number of types that will disable the vari=
ous copy/move operations. Do you have a use case where <span style=3D"font-=
family:monospace,monospace">`optional<T&>`</span> specifically wo=
uld cause a problem?<br></div></div></div></div>
</blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHocnE-ayi0j7gNYzwX8-yQ%2B83byAagGOe=
TB_hKGNEpfAZB8iQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHocnE-ayi0j7g=
NYzwX8-yQ%2B83byAagGOeTB_hKGNEpfAZB8iQ%40mail.gmail.com</a>.<br />
--f403043c49483a49090549c9f153--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 2 Mar 2017 22:31:14 -0500
Raw View
--001a11469ea69343560549cb2df0
Content-Type: text/plain; charset=UTF-8
On Thu, Mar 2, 2017 at 3:11 AM, Joseph Thomson <joseph.thomson@gmail.com>
wrote:
> On Thu, Mar 2, 2017 at 1:19 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>>
>>
>> You want to put a non-value type into a type that is meant to contain
>> values.
>>
>
> `optional` is *currently* only defined for value types. I want to define
> its behaviour for reference types. It is possible to define `optional<T&>`
> to be consistent with the behaviour of `optional<T>`. If this weren't the
> case, I would agree with you that it should be a different type.
>
It may be only _meant_ for values, but it is currently defined for value
types, AND non-value types:
template <typename T> class RefLike {
T * ref;
public:
RefLike(T & r) : ref(&r) { }
RefLike & operator=(T const & val) {
*ref = val;
return *this;
}
};
int main()
{
int x = 17;
std::optional<RefLike<int>> ori = x;
int y = 22;
ori = y;
std::cout << x;
return x;
}
--
Be seeing you,
Tony
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivtvM3FZAyej9uJvdyf_Z_5%2BaHLfX0WrVWwADPJsU7D3Q%40mail.gmail.com.
--001a11469ea69343560549cb2df0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Mar 2, 2017 at 3:11 AM, Joseph Thomson <span dir=3D"ltr"><<a=
href=3D"mailto:joseph.thomson@gmail.com" target=3D"_blank">joseph.thomson@=
gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_=
quote"><span class=3D"gmail-">On Thu, Mar 2, 2017 at 1:19 PM, Nicol Bolas <=
span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blan=
k">jmckesson@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex"><br><div dir=3D"ltr"><br><div>You want to put a non-=
value type into a type that is meant to contain values.<br></div></div></bl=
ockquote><div><br></div></span><div><span style=3D"font-family:monospace,mo=
nospace">`optional`</span> is <i>currently</i> only defined for value types=
.. I want to define its behaviour for reference types. It is possible to def=
ine <span style=3D"font-family:monospace,monospace">`optional<T&>=
`</span> to be consistent with the behaviour of <span style=3D"font-family:=
monospace,monospace">`optional<T>`</span>. If this weren't the ca=
se, I would agree with you that it should be a different type.<br></div></d=
iv></div></div></blockquote><div><br><br></div><div>It may be only _meant_ =
for values, but it is currently defined for value types, AND non-value type=
s:<br><br><pre><code>template <typename T> class RefLike {
T * ref;
public:
RefLike(T & r) : ref(&r) { }
RefLike & operator=3D(T const & val) {
*ref =3D val; <br> return *this;<br>=C2=A0 }
};<br></code></pre><code>int main()<br>{<br>=C2=A0=C2=A0 int x =3D 17;<br>=
=C2=A0=C2=A0 std::optional<RefLike<int>> ori =3D x;<br>=C2=A0=
=C2=A0 int y =3D 22;<br>=C2=A0=C2=A0 ori =3D y;<br><br>=C2=A0=C2=A0 std::co=
ut << x;<br>=C2=A0=C2=A0 =C2=A0<br>=C2=A0=C2=A0 return x;<br>}</code>=
</div></div><br clear=3D"all"><br>-- <br><div class=3D"gmail_signature"><di=
v dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br></div></div>
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbivtvM3FZAyej9uJvdyf_Z_5%2BaHLfX=
0WrVWwADPJsU7D3Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivtvM3FZA=
yej9uJvdyf_Z_5%2BaHLfX0WrVWwADPJsU7D3Q%40mail.gmail.com</a>.<br />
--001a11469ea69343560549cb2df0--
.
Author: Joseph Thomson <joseph.thomson@gmail.com>
Date: Fri, 3 Mar 2017 11:47:07 +0800
Raw View
--001a113c1bec5eb8520549cb66a3
Content-Type: text/plain; charset=UTF-8
On Fri, Mar 3, 2017 at 11:31 AM, Tony V E <tvaneerd@gmail.com> wrote:
>
>
> On Thu, Mar 2, 2017 at 3:11 AM, Joseph Thomson <joseph.thomson@gmail.com>
> wrote:
>
>> On Thu, Mar 2, 2017 at 1:19 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>>
>>>
>>>
>>> You want to put a non-value type into a type that is meant to contain
>>> values.
>>>
>>
>> `optional` is *currently* only defined for value types. I want to define
>> its behaviour for reference types. It is possible to define
>> `optional<T&>` to be consistent with the behaviour of `optional<T>`. If
>> this weren't the case, I would agree with you that it should be a different
>> type.
>>
>
>
> It may be only _meant_ for values, but it is currently defined for value
> types, AND non-value types:
>
Okay, I meant *object* types :-)
> template <typename T> class RefLike {
> T * ref;
> public:
> RefLike(T & r) : ref(&r) { }
> RefLike & operator=(T const & val) {
> *ref = val;
> return *this;
> }
> };
>
> int main()
> {
> int x = 17;
> std::optional<RefLike<int>> ori = x;
> int y = 22;
> ori = y;
>
> std::cout << x;
>
> return x;
> }
>
>
> --
> Be seeing you,
> Tony
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/lPHskm8mFCo/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAOHCbivtvM3FZAyej9uJvdyf_Z_5%
> 2BaHLfX0WrVWwADPJsU7D3Q%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivtvM3FZAyej9uJvdyf_Z_5%2BaHLfX0WrVWwADPJsU7D3Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHocnE8djMBo_GPJJdTfjFti%2BZFrdyxFLgVqWCaEzh-uzdre%2BA%40mail.gmail.com.
--001a113c1bec5eb8520549cb66a3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Mar 3, 2017 at 11:31 AM, Tony V E <span dir=3D"ltr"><<a href=3D"mail=
to:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>></span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D=
"gmail_extra"><br><div class=3D"gmail_quote"><span class=3D"">On Thu, Mar 2=
, 2017 at 3:11 AM, Joseph Thomson <span dir=3D"ltr"><<a href=3D"mailto:j=
oseph.thomson@gmail.com" target=3D"_blank">joseph.thomson@gmail.com</a>>=
</span> wrote:<br></span><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><spa=
n class=3D"m_2723378381341562925gmail-"><span class=3D"">On Thu, Mar 2, 201=
7 at 1:19 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson=
@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></span> wrote:<br>=
</span><span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
br><div dir=3D"ltr"><br><div>You want to put a non-value type into a type t=
hat is meant to contain values.<br></div></div></blockquote><div><br></div>=
</span></span><span class=3D""><div><span style=3D"font-family:monospace,mo=
nospace">`optional`</span> is <i>currently</i> only defined for value types=
.. I want to define its behaviour for reference types. It is possible to def=
ine <span style=3D"font-family:monospace,monospace">`optional<T&>=
`</span> to be consistent with the behaviour of <span style=3D"font-family:=
monospace,monospace">`optional<T>`</span>. If this weren't the ca=
se, I would agree with you that it should be a different type.<br></div></s=
pan></div></div></div></blockquote><div><br><br></div><div>It may be only _=
meant_ for values, but it is currently defined for value types, AND non-val=
ue types:<br></div></div></div></div></blockquote><div><br></div><div>Okay,=
I meant <i>object</i> types :-) <br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>=
<pre><code>template <typename T> class RefLike {
T * ref;
public:
RefLike(T & r) : ref(&r) { }
RefLike & operator=3D(T const & val) {
*ref =3D val; <br> return *this;<br>=C2=A0 }
};<br></code></pre><code>int main()<br>{<br>=C2=A0=C2=A0 int x =3D 17;<br>=
=C2=A0=C2=A0 std::optional<RefLike<int>> ori =3D x;<br>=C2=A0=
=C2=A0 int y =3D 22;<br>=C2=A0=C2=A0 ori =3D y;<br><br>=C2=A0=C2=A0 std::co=
ut << x;<br>=C2=A0=C2=A0 =C2=A0<br>=C2=A0=C2=A0 return x;<br>}</code>=
</div></div><br clear=3D"all"><br>-- <br><div class=3D"m_272337838134156292=
5gmail_signature"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br></d=
iv></div>
</div></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/lPHskm8mFCo/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/l=
PHskm8mFCo/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbivtvM3FZAyej9uJvdyf_Z_5%2BaHLfX=
0WrVWwADPJsU7D3Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/<wbr>CAOHCbivtvM3FZAyej9uJvdyf_Z_5%<wbr>2BaHLfX0WrVWwADPJs=
U7D3Q%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHocnE8djMBo_GPJJdTfjFti%2BZFrdyxFLg=
VqWCaEzh-uzdre%2BA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHocnE8djMBo=
_GPJJdTfjFti%2BZFrdyxFLgVqWCaEzh-uzdre%2BA%40mail.gmail.com</a>.<br />
--001a113c1bec5eb8520549cb66a3--
.