Topic: std::optional, revision 3 -- request for feedback
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Tue, 22 Jan 2013 13:18:49 -0800 (PST)
Raw View
------=_Part_2472_24147677.1358889529784
Content-Type: multipart/alternative;
boundary="----=_Part_2473_9154063.1358889529784"
------=_Part_2473_9154063.1358889529784
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Hi Everyone,
We are ready with the 3rd revision of std::optional proposal. The main=20
changes:
- optional<T> is hashable for hashable T=92s.
- Removed optional references =97 they will be proposed separately.
- get_value_or is now optional-specific member function.
- optional<T> is a literal type.
- Removed reference implementation. We now only provide the=20
implementation of the parts that we consider non-trivial.
We would appreciate your feedback and suggestions.
Regards,
&rzej
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_2473_9154063.1358889529784
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Hi Everyone,<br>We are ready with the 3rd revision of std::optional proposa=
l. The main changes:<br><ul><li><code>optional<T></code> is hashable =
for hashable <code>T</code>=92s.</li><li>Removed optional references =97 th=
ey will be proposed separately.</li><li><code>get_value_or</code> is now <c=
ode>optional</code>-specific member function.</li><li><code>optional<T&g=
t;</code> is a literal type.</li><li>Removed reference implementation. We n=
ow only provide the implementation of the parts that we consider non-trivia=
l.</li></ul>We would appreciate your feedback and suggestions.<br><br>Regar=
ds,<br>&rzej<br>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_2473_9154063.1358889529784--
------=_Part_2472_24147677.1358889529784
Content-Type: text/html; charset=US-ASCII; name=tr2.optional.proposal.html
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename=tr2.optional.proposal.html
X-Attachment-Id: 671d0f5d-1a45-44ce-aafb-a093a35c83af
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/htm=
l4/strict.dtd">
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html;charset=3DUS-ASCII">
<style type=3D"text/css">
pre {margin-left:20pt; }
pre > i {
font-family: "OCR A Extended", "Consolas", "Lucida Console", monospace;
font-style:italic;
}
code > i {
font-family: "OCR A Extended", "Consolas", "Lucida Console", monospace;
font-style:italic;
}
pre > em {
font-family: "OCR A Extended", "Consolas", "Lucida Console", monospace;
font-style:italic;
}
code > em {
font-family: "OCR A Extended", "Consolas", "Lucida Console", monospace;
font-style:italic;
}
body { color: #000000; background-color: #FFFFFF; }
del { text-decoration: line-through; color: #8B0040; }
ins { text-decoration: underline; color: #005100; }
p.example { margin-left: 2em; }
pre.example { margin-left: 2em; }
div.example { margin-left: 2em; }
code.extract { background-color: #F5F6A2; }
pre.extract { margin-left: 2em; background-color: #F5F6A2;
border: 1px solid #E1E28E; }
p.function { }
..attribute { margin-left: 2em; }
..attribute dt { float: left; font-style: italic;
padding-right: 1ex; }
..attribute dd { margin-left: 0em; }
blockquote.std { color: #000000; background-color: #F1F1F1;
border: 1px solid #D1D1D1;
padding-left: 0.5em; padding-right: 0.5em; }
blockquote.stddel { text-decoration: line-through;
color: #000000; background-color: #FFEBFF;
border: 1px solid #ECD7EC;
padding-left: 0.5empadding-right: 0.5em; ; }
blockquote.stdins { text-decoration: underline;
color: #000000; background-color: #C8FFC8;
border: 1px solid #B3EBB3; padding: 0.5em; }
table { border: 1px solid black; border-spacing: 0px;
margin-left: auto; margin-right: auto; }
th { text-align: left; vertical-align: top;
padding-left: 0.4em; border: none;=20
padding-right: 0.4em; border: none; }
td { text-align: left; vertical-align: top;
padding-left: 0.4em; border: none;
padding-right: 0.4em; border: none; }
</style>
<title>A proposal to add a utility class to represent optional objects (Rev=
ision 2)</title>
<script src=3D"https://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.mi=
n.js" type=3D"text/javascript"> </script>
<script type=3D"text/javascript">$(function() {
var next_id =3D 0
function find_id(node) {
// Look down the first children of 'node' until we find one
// with an id. If we don't find one, give 'node' an id and
// return that.
var cur =3D node[0];
while (cur) {
if (cur.id) return curid;
if (cur.tagName =3D=3D 'A' && cur.name)
return cur.name;
cur =3D cur.firstChild;
};
// No id.
node.attr('id', 'gensection-' + next_id++);
return node.attr('id');
};
// Put a table of contents in the #toc nav.
// This is a list of <ol> elements, where toc[N] is the list for
// the current sequence of <h(N+2)> tags. When a header of an
// existing level is encountered, all higher levels are popped,
// and an <li> is appended to the level
var toc =3D [$("<ol/>")];
$(':header').not('h1').each(function() {
var header =3D $(this);
// For each <hN> tag, add a link to the toc at the appropriate
// level. When toc is one element too short, start a new list
var levels =3D {H2: 0, H3: 1, H4: 2, H5: 3, H6: 4};
var level =3D levels[this.tagName];
if (typeof level =3D=3D 'undefined') {
throw 'Unexpected tag: ' + this.tagName;
}
// Truncate to the new level.
toc.splice(level + 1, toc.length);
if (toc.length < level) {
// Omit TOC entries for skipped header levels.
return;
}
if (toc.length =3D=3D level) {
// Add a <ol> to the previous level's last <li> and push
// it into the array.
var ol =3D $('<ol/>')
toc[toc.length - 1].children().last().append(ol);
toc.push(ol);
}
var header_text =3D header.text();
toc[toc.length - 1].append(
$('<li/>').append($('<a href=3D"#' + find_id(header) + '"/>')
.text(header_text)));
});
$('#toc').append(toc[0]);
})
</script>
</head>
<body>
<!--<table>
<tr><td>Doc. no.</td><td>NXXXX=3DXX-XXXX</td></tr>
<tr><td>Date</td><td>YYYY-MM-DD</td></tr>
<tr><td valign=3D'top'>Authors</td><td>Fernando Cacciola<br>Andrzej Krzemie=
ński</td></tr>
<tr><td valign=3D'top'>Contact</td><td><a href=3D"mailto:fernando.cacciola@=
gmail.com">fernando.cacciola@gmail.com</a><br><a href=3D'mailto:akrzemi1@gm=
ail.com'>akrzemi1@gmail.com</a></td></tr>
<tr><td>Addresses</td><td>LWG</td></tr>
</table>-->
<h1><a name=3D'title'>A proposal to add a utility class to represent option=
al objects (Revision 3)</a></h1>
<p>
ISO/IEC JTC1 SC22 WG21 D3527
</p>
<address>
Fernando Cacciola, fernando.cacciola@gmail.com
</address>
<address>
Andrzej Krzemieński, akrzemi1@gmail.com
</address>
<h2><a name=3D'intro'>Introduction</a></h2>
<p>Class template <code>optional<T></code> proposed here is a <em>nul=
lable</em> type <code>T</code> that can store in its storage space either a=
value of type <code>T</code> or a special value <code>nullopt</code>. Its =
interface allows to query whether a value of <code>T</code> or <code>nullop=
t</code> is currently stored. The interface is based on Fernando Cacciola'=
s
Boost.Optional library<sup>[2]</sup>, shipping since March, 2003, and widel=
y used. It requires no changes to core language, and breaks no existing cod=
e. </p>
<h2><a name=3D'toc'>Table of contents</a></h2>
<p id=3D'toc'></p>
<h2><a name=3D'revision'>Revision history</a></h2>
<p>Changes since <a href=3D'http://www.open-std.org/jtc1/sc22/wg21/docs/pap=
ers/2012/n3406.html'>N3406=3D12-0096</a>:</p>
<ul>
<li><code>optional<T></code> is hashable for hashable <code>T</code=
>’s.</li>
<li>Removed optional references — they will be proposed separately.=
</li>
<li><code>get_value_or</code> is now <code>optional</code>-specific membe=
r function.</li>
<li><code>optional<T></code> is a literal type.</li>
<li>Removed reference implementation. We now only provide the implementat=
ion of the parts that we consider non-trivial.</li>
</ul>
<p>Changes since <a href=3D'http://www.open-std.org/jtc1/sc22/wg21/docs/pap=
ers/2005/n1878.htm'>N1878=3D05-0138</a>:</p>
<ul>
<li>Revised wording; the changes are now relative to <a href=3D'http://ww=
w.open-std.org/jtc1/sc22/wg21/prot/14882fdis/n3290.pdf'>N3290</a>.</li>
<li>Removed any form of assignment for optional references.</li>
<li>Removed duplicate interface for accessing the value stored by the opt=
ional.</li>
<li>Added in-place construction and assignment.</li>
<li>Now using different tag <code>nullopt</code> instead of <code>nullptr=
</code> to indicate the 'disengaged' (uninitialized) optional.</li>
<li>Included C++11 features: move semantics, <code>noexcept</code>, varia=
dic templates, perfect forwarding, static initialization.</li>
<li>Changed the motivation section.</li>
<li>Changed the design rationale section.</li>
<li>Added reference implementation</li>
</ul>
<h2><a name=3D'motivation'>Motivation and scope</a></h2>
<h3><a name=3D'motivation.missingval'>Missing return values</a></h3>
<p>It sometimes happens that a function that is declared to return values o=
f type <code>T</code> may not have a value to return. For one instance, con=
sider function <code>double sqrt(double)</code>. It is not defined for nega=
tive numbers. <em>The only way</em> function <b>sqrt</b> can find itself in=
the situation where it cannot produce a value is when it is passed an inva=
lid argument, and it is possible for the caller to check if the argument is=
valid. Therefore, such cases are dealt with by stating a function <em>prec=
ondition</em>. Violating the precondition may either result in undefined be=
havior, or (as it is the case for <code>std::vector::at</code>) may be defi=
ned to throw an exception. However, there are cases where we cannot know wh=
ether a function is able to return a value before we call it. For instance:=
=20
</p>
<pre>char c =3D stream.getNextChar();
int x =3D DB.execute("select x_coord from coordinates where point_id =3D 11=
2209");
</pre>
<p>In the first case, one could argue that <code>stream</code> could provid=
e another function for checking if the end of stream has been reached. But =
for the latter there is no easy way to make sure that the requested informa=
tion exists in the database before we request for it. Also, throwing an exc=
eption is not a good solution, because there is nothing unusual or erroneou=
s about not having found a record in the DB.
</p>
<h3><a name=3D'motivation.optargs'>Optional function arguments</a></h3>
<p>Sometimes it is useful to indicate that we are unable or do not want to =
provide one of the function arguments:</p>
<pre>void execute( function<void(int)> fa, function<void(int)> =
fb )
{
int i =3D computeI();
fa(i); <em>// implicit assumption that fa !=3D nullptr</em>
if (fb) {
fb(i);
}
}
</pre>
<p>
Here, <code>fb</code> is an optional argument, and it typically requires an=
if-statement in function body. It is often argued that such design can be =
replaced by providing two function overloads, however this also is problema=
tic: it adds certain duplication; may make the code less clear; the number =
of overloads increases expotentially with the number of optional parameters=
..
</p>
<h3><a name=3D'motivation.trackinit'>Indicating a <em>null-state</em></a></=
h3>
<p>Some types are capable of storing a special <em>null-state</em> or <em>n=
ull-value</em>. It indicates that no 'meaningful' value has been assigned t=
o the object yet. It is then possible to query the object whether it contai=
ns a null-state, typically by invoking a contextual conversion to type <cod=
e>bool</code> or by checking for equality with <code>nullptr</code>. Exampl=
es of such types include: <code>std::unique_ptr</code> or <code>std::functi=
on</code>. This is convenient for instance when implementing a <q>lazy init=
ialization</q> optimization:
</p>
<pre>class Car=20
{
mutable unique_ptr<const Engine> engine_;
=20
public:
const Engine& engine() const
{
if (engine_ =3D=3D nullptr) {
engine_.reset( new engine{engineParams()} );
}
return *engine_;
}
};</pre>
<p>Other types, on the other hand, do not provide this capability. For inst=
ance, type <code>int</code> does not have a special value that would signal=
the null-state. Any value of <code>int</code> is a valid value. The same g=
oes for user defined types: e.g., <code>Rational<int></code> that imp=
lements a rational number by holding two <code>int</code>’s represent=
ing a numerator and a denumerator.</p>
<p>For a similar example, consider this function for finding biggest <code>=
int</code>.</p>
<pre>
int find_biggest( const vector<int>& vec )
{
int biggest; <em>// =3D what initial value??</em>
for (int val : vec) {
if (biggest < val) {
biggest =3D val;
}
}
return biggest;
}=20
</pre>
<p>
What initial value should we assign to <code>biggest</code>? Not 0, because=
the vector may hold negative values. We can use <code>std::numeric_limits&=
lt;int>::min</code>. But what if we want to make our function generic? <=
code>std::numeric_limits</code> will not be specialized for any possible ty=
pe. And what if the vector contains no elements? Shall we return minimum po=
ssible value? But how will the caller know if the size of the vector was ze=
ro, or if it was one with the minimum possible value?
</p>
<h3><a name=3D'motivation.guards'>Manually controlling the lifetime of scop=
e guards</a></h3>
<p>
Consider that you have to run three actions in the fixed order:
</p>
<pre>
void runAction1( Resource1 & );
void runAction2( Resource1 &, Resource2 & );
void runAction3( Resource2 & );
</pre>
<p>Of course, the two resources need to be acquired before using them and r=
eleased once we are done. This is how we would write it conceptually, if we=
could assume that none of the operations ever fails or throws exceptions:<=
/p>
<pre>
Result run3Actions( Parameter param ) <i>// BAD!!</i>
{
Resource1 res1;
Resource2 res2;
res1.acquire(param); <i>// res1 scope</i>
runAction1( res1 ); <i>//</i>
res2.acquire(param); <i>// // res2 scope</i>
runAction2( res1, res2 ); <i>// //</i>
res1.release(); <i>// //</i>
runAction3( res2 ); <i> //</i>
res2.release(); <i> //</i>
}
</pre>
<p>Note that the scopes of the two resources <em>overlap.</em> we cannot cl=
early divide our function into nested scopes that correspond to lifetimes o=
f the resources. This example represents a real-life situation if you imagi=
ne that <tt>runAction2</tt> is a critical operation, and <tt>runAction3</t=
t> (and perhaps <tt>runAction1</tt>) is logging, which we can even skip if =
it fails. </p>
<p>Of course, this code is unacceptable, because it does not take into acco=
unt that acquire operations, and the three actions may fail. So, we want t=
o rewrite <tt>run3Actions</tt> using RAII idiom. Especially, that the libra=
ry author that provides the interface to the two resources also knows that =
RAII is probably always what we want and the only interface he provides are=
scope guards:=20
</p>
<pre>
Result run3Actions( Parameter param ) <i>// selfish</i>
{
Resource1Guard res1{param};
Resource2Guard res2{param};
runAction1( res1 );
runAction2( res1, res2 ); =20
runAction3( res2 );
}
</pre>
<p>This solution is somewhat elegant: you first acquire all resources that =
you will need, and once you are sure you have them all, you just run the ac=
tions. But it has one problem. Someone else will also need to use resources=
we are acquiring. If they need it at the moment, but we own the resource r=
ight now, they will be locked, or thrown a refusal exception — they w=
ill be disturbed and delayed. Using a resource is a critical part of the pr=
ogram, and we should be only acquiring them for as short a period as possib=
le, for the sake of efficiency: not only our program's but of the entire op=
erating system. In our example above, we hold the ownership of <tt>res2</tt=
> while executing <tt>runAction1</tt>, which does not require the resource.=
Similarly, we unnecessarily hold <tt>res1</tt> when calling <tt>runAction3=
</tt>. </p>
<p>So, how about this?</p>
<pre>
Result run3Actions( Parameter param ) <i>// slow and risky</i>
{
{
Resource1Guard res1{param};
runAction1( res1 );
}
{
Resource1Guard res1{param};
Resource2Guard res2{param};
runAction2( res1, res2 ); =20
} =20
{
Resource2Guard res2{param};
runAction3( res2 );
}=20
}
</pre>
<p>It does not have the above-mentioned problem, but it introduces a differ=
ent one. Now we have to acquire the same resource two times in a row for tw=
o subsequent actions. Resource acquisition is critical, may lock us, may sl=
ow us down, may fail; calling it four times rather than two is wrong, espec=
ially that acquiring the same resource twice may give us different resource=
properties in each acquisition, and it may not work for our actions.</p>=
=20
<h3><a name=3D'motivation.skipinit'>Skipping the expensive initialization</=
a></h3>
<p>Not all types provide a cheap default construction, even if they are sma=
ll in size. If we want to put such types in certain containers, we are risk=
ing paying the price of expensive default construction even if we want to a=
ssign a different value a second later.
</p>
<pre>ExpensiveCtor array[100]; <em>// 100 default constructions</em>
std::array<ExpensiveCtor, 100> arr; <em>// 100 default constructions<=
/em>
std::vector<ExpensiveCtor> vec(100); <em>// 100 default constructions=
</em>
</pre>
<h3><a name=3D'motivation.practise'>Current techniques for solving the prob=
lems</a></h3>
<p>The above mentioned problems are usually dealt with in C++ in three ways=
:</p>
<ol>
<li>Using ad-hoc special values, like <code>EOF</code>, -1, 0, <code>nume=
ric_limits<T>::min</code>.</li>
<li>Using additional flags, like <code>pair<T, bool></code>.</li>
<li>Using pointers even if the object would have been passed or returned =
by value if it wouldn't be possibly absent.</li>
</ol>
<p>Technique (1) suffers from the lack of uniformity. Special value, like <=
code>EOF</code> is not something characteristic of the type (<code>int</cod=
e>), but of the particular function. Other function may need to use a diffe=
rent special value. The notable example is the standard function <code>atoi=
</code>, where 0 may indicate either an unsuccessful conversion, or a succe=
ssful conversion to value 0. And again, sometimes it is not even possible t=
o designate a value with a special meaning, because all values of a given t=
ype are equally likely to appear; for instance:
</p>
<pre>bool accepted =3D DB.execute("select accepted from invitations where i=
nvitation_id =3D 132208");</pre>
<p>Technique (2) is problematic because it requires both members of <code>p=
air</code> to be initialized. But one of the reasons we are not returning a=
'normal' value from a function or do not want to initialize the object jus=
t yet, is because we did not know how to initialize it. In case of optional=
<code>int</code> we could give it a rubbish value or leave it uninitialize=
d, but user defined types, including resources, may not provide a default c=
onstructor, and require some effort to perform initialization.</p>
<p>Technique (3) is general. It uses value <code>nullptr</code> to indicate=
the special value. Users can unequivocally test if the value is indeed abs=
ent and being formally undefined behavior to access an object pointed to by=
a null pointer. It also does not require initializing the object unnecessa=
rily. But it comes with different problems. Automatic objects created insid=
e functions cannot be returned by pointer. Thus it often requires creating =
objects in free store which may be more expensive than the expensive initia=
lization itself. It also requires manual memory management problems. The la=
tter problem can be dealt with by using <code>std::unique_ptr</code>, but t=
his is still a pointer, and we must abandon value semantics. Now we return =
a smart pointer: we have shallow copy and shallow comparison.</p>
<h2><a name=3D'impact'>Impact on the Standard</a></h2>
<p>This proposal depends on library proposal <a href=3D"http://www.open-std=
..org/jtc1/sc22/wg21/docs/papers/2012/n3471.html">N3471</a>: it requires tha=
t Standard Library components <code>move</code>, <code>forward</code> and m=
ember functions of <code>initializer_list</code> are <code>constexpr</code>=
.. The paper has already been incorporated into the Working Draft of the Sta=
ndard <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3=
485.pdf">N3485</a>. This proposal also depends on language proposal <a href=
=3D"www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2439.htm">N2439</a> (=
Rvalue references for <code>*this</code>). While the latter feature proposa=
l has been incorporated into C++0x, we are not aware of any compiler implem=
entation. There is a risk that if compiler vendors do not implement it, the=
y will also not be able to fully implement this proposal. In that case, the=
signature of member function <code>optional<T>::get_value_or</code> =
from this proposal will need to be modified.</p>
<h2><a name=3D'overview'>Overview of <code>optional</code></a></h2>
<p>The utility presented here is not a smart pointer. Even though it provid=
es operators <code>-></code> and <code>*</code>, it has full value semantic=
s: deep copy construction, deep copy assignmet, deep equality and less-than=
comparison, and constness propagation (from optional object to the contain=
ed value).</p>
<p>Conceptually, <code>optional</code> can be illustrated by the following =
structure.</p>
<pre>template <typename T>
struct optional
{
bool is_initialized_;
typename aligned_storage<sizeof(T), alignof(T)>::type storage_;
};</pre>
<p>Flag <code>is_initialized_</code> stores the information if <code>option=
al</code> has been assigned a value of type <code>T</code>. <code>storage_<=
/code> is a raw fragment of memory (allocated within <code>optional</code> =
object) capable of storing an object of type <code>T</code>. Objects in thi=
s storage are created and destroyed using placement <code>new</code> and ps=
eudo destructor call as member functions of <code>optional</code> are execu=
ted and based on the value of flag <code>is_initialized_</code>.</p>=20
<p>Alternatively, one can think of <code>optional<T></code> as <code>=
pair<bool, T></code> with one important difference: if <code>first</c=
ode> is <code>false</code>, member <code>second</code> has never been even =
initialized, even with default constructor or value-initialization.</p>
<p>Default construction of <code>optional<T></code> creates an an obj=
ect that stores no value of type <code>T</code>. No default constructor of =
<code>T</code> is called. <code>T</code> doesn't even need to be <code>Defa=
ultConstructible</code>. We say that thus created optional object is <em>di=
sengaged</em>. We need the pair of artificial names, 'engaged' and 'disenga=
ged', in order not to overload the regular meaning of terms 'initialized' a=
nd 'uninitialized'. The optional object is initialized (the lifetime of <co=
de>optional<T></code> has started), but it is disengaged (the lifetim=
e of the contained object has not yet started). Trying to access the value =
of <code>T</code> in this state causes undefined behavior. The only thing w=
e can do with a disengaged optional object is to query whether it is engage=
d, copy it, compare it with another <code>optional<T></code>, or <em>=
engage</em> it.</p>
<pre>optional<int> oi; <em>// create disengaged objec=
t</em>
optional<int> oj =3D nullopt; <em>// alternative syntax</em>
oi =3D oj; <em>// assign disengaged object</em>
optional<int> ok =3D oj; <em>// ok is disengaged</em>
if (oi) assert(false); <em>// 'if oi is engaged...'</em>
if (!oi) assert(true); <em>// 'if oi is disengaged...'</em>
if (oi !=3D nullopt) assert(false); <em>// 'if oi is engaged...'</em>
if (oi =3D=3D nullopt) assert(true); <em>// 'if oi is disengaged...'</em>
assert(oi =3D=3D ok); <em>// two disengaged optionals compa=
re equal</em>
</pre>
<p>We can create engaged optional objects or engage existing optional objec=
ts by using converting constructor (from type <code>T</code>) or by assigni=
ng a value of type <code>T</code>.
<pre>optional<int> ol{1}; <em>// ol is engaged; its cont=
ained value is 1</em>
ok =3D 2; <em>// ok becomes engaged; its containe=
d value is 2</em>
oj =3D ol; <em>// oj becomes engaged; its containe=
d value is 1</em>
assert(oi !=3D ol); <em>// disengaged !=3D engaged</em>
assert(ok !=3D ol); <em>// different contained values</em>
assert(oj =3D=3D ol); <em>// same contained value</em>
assert(oi < ol); <em>// disengaged < engaged</em>
assert(ol < ok); <em>// less by contained value</em>
</pre>
<p>We access the contained value using the indirection operator.</p>
<pre>int i =3D *ol; <em>// i obtains the value contain=
ed in ol</em>
assert(i =3D=3D 1);
*ol =3D 9; <em>// the object contained in ol becom=
es 9</em>
assert(*ol =3D=3D 9);
</pre>
<p>We also provide consistent <code>operator-></code>. The typical usage=
of <code>optional</code> requires an if-statement.</p>
<pre>if (ol) =20
process(*ol); <em>// use contained value if present</em=
>
else
processNil(); <em>// proceed without contained value</e=
m>
</pre>
=20
<p>If the action to be taken for disengaged <code>optional</code> is to pro=
ceed with the default value, we provide a convenient idiom: </p>=20
<pre>process(ol.get_value_or(0)); <em>// use 0 if ol is disengaged</em=
>
</pre>
<p>Sometimes the initialization from <code>T</code> may not do. If we want =
to skip the copy/move construction for <code>T</code> because it is too exp=
ensive or simply not available, we can call an 'emplacing' constructor, or =
function <code>emplace</code>.</p>
<pre>optional<Guard> oga; <em>// Guard is non-cop=
yable (and non-moveable)</em> =20
optional<Guard> ogb(emplace, "res1"); <em>// initialzes the contai=
ned value with "res1" </em> =20
optional<Guard> ogc(emplace); <em>// default-constructs th=
e contained value</em>
oga.emplace("res1"); <em>// initialzes the contained va=
lue with "res1" </em>=20
oga.emplace(); <em>// destroys the contained valu=
e and </em>
<em>// default-constructs the new =
one</em>
</pre>
<p>There are two ways to <em>disengage</em> a perhaps engaged optional obje=
ct:</p>
<pre>ok =3D nullopt; <em>// if ok was engaged calls T'=
s dtor</em>
oj =3D {}; <em>// assigns a temporary disengaged =
optional</em>
oga =3D nullopt; <em>// OK: disengage the optional Guar=
d</em>
ogb =3D {}; <em>// ERROR: Guard is not Moveable</e=
m>
</pre>
<p>Optional propagates constness to its contained value:</p>
<pre>const optional<int> c =3D 4;=20
int i =3D *c; <em>// i becomes 4</em>
*c =3D i; <em>// ERROR: cannot assign to const i=
nt&</em>
</pre>
<h3><a name=3D'overview.except.safety'>Exception safety</a></h3>
<p>Type <code>optional<T></code> is a wrapper over <code>T</code>, th=
us its exception safety guarantees depend on exception safety guarantees of=
<code>T</code>. We expect (as is the case for the entire C++ Standard Libr=
ary) that destructor of <code>T</code> does not throw exceptions. Copy assi=
gnment of <code>optional<T></code> provides the same exception guaran=
tee as copy assignment of <code>T</code> and copy constructor of <code>T</c=
ode> (i.e., the weakest of the two). Move assignment of <code>optional<T=
></code> provides the same exception guarantee as move assignment of <co=
de>T</code> and move constructor of <code>T</code>. Member function <code>e=
mplace</code> provides basic guarantee: if exception is thrown, <code>optio=
nal<T></code> becomes disengaged, regardless of its prior state. </p>
<h3><a name=3D'overview.usecases'>Advanced use cases</a></h3>
<p>With <code>optional<T></code> problems described in Motivation sec=
tion can be solved as follows. For lazy initialization:</p>
<pre>class Car=20
{
mutable optional<const Engine> engine_;
mutable optional<const int> mileage_
=20
public:
const Engine& engine() const
{
if (engine_ =3D=3D nullopt) engine_.emplace( engineParams() );
return *engine_;
}
=20
const int& mileage() const
{
if (!mileage_) mileage_ =3D initMileage();
return *mileage_;
}
};</pre>
<p>The algorithm for finding the greatest element in vector can be written =
as: </p>
<pre>
optional<int> find_biggest( const vector<int>& vec )
{
optional<int> biggest; <em>// initialized to not-an-int</em>
for (int val : vec) {
if (!biggest || *biggest < val) {
biggest =3D val;
<em>// or: biggest.emplace(val);</em>
}
}
return biggest;
}=20
</pre>
<p>Missing return values are naturally modelled by optional values:</p>
<pre>optional<char> c =3D stream.getNextChar();
optional<int> x =3D DB.execute("select ...");
storeChar( c.get_value_or('\0') );
storeCount( x.get_value_or(-1) );
</pre>
<p>Optional arguments can be implemented as follows:<p>
<pre>template <typename T>
T getValue( optional<T> newVal =3D nullopt )
{
if (newVal) {
cached =3D *newVal; =20
}
return cached; =20
}
</pre>
<p>Manually controlling the life-time of guard-like objects can be achieved=
by emplacement operations and <code>nullopt</code> assignment:</p>
<pre>{
optional<Guard> grd1{emplace, "res1", 1}; <em>// guard 1 initiali=
zed</em>
optional<Guard> grd2;
grd2.emplace("res2", 2); <em>// guard 2 initialized</=
em>
grd1 =3D nullopt; <em>// guard 1 released</e=
m>
} <em>// guard 2 released (in =
dtor)</em>
</pre>
<p>It is possible to use <code>tuple</code> and <code>optional</code> to em=
ulate multiple return valuse for types without default constructor:</p>
<pre>tuple<Date, Date, Date> getStartMidEnd();
void run(Date const&, Date const&, Date const&);
<em>// ...</em>
optional<Date> start, mid, end; <em>// Date doesn't have de=
fault ctor (no good default date)</em>
tie(start, mid, end) =3D getStartMidEnd();
run(*start, *mid, *end);=20
</pre>
<h3><a name=3D'overview.value_ptr_compartson'>Comparison with <code>value_p=
tr</code></a></h3>
<p><a href=3D'http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3339=
..pdf'>N3339</a><sup>[7]</sup> proposes a smart pointer template <code>value=
_ptr</code>. In short, it is a smart pointer with deep copy semantics. It h=
as a couple of features in common with <code>optional</code>: both contain =
the notion of optionality, both are deep-copyable. Below we list the most i=
mportant differences. </p>
<p><code>value_ptr</code> requires that the pointed-to object is allocated =
in the free store. This means that the <code>sizeof(value_ptr<T>)</co=
de> is fixed irrespective of <code>T</code>. <code>value_ptr</code> is 'pol=
ymorphic': object of type <code>value_ptr<T></code> can point to an o=
bject of type <code>DT</code>, derived from <code>T</code>. The deep copy p=
reserves the dynamic type. <code>optional</code> requires no free store all=
ocation: its creation is more efficient; it is not "polymorphic".</p>
<p>Relational operations on <code>value_ptr</code> are shallow: only addres=
ses are compared. Relational operations on <code>optional</code> are deep, =
based on object's value. In general, <code>optional</code> has a well defin=
ed value: being disengaged and the value of contained value (if it exists);=
this value is expressed in the semantics of equality operator. This makes =
<code>optional</code> a full value-semantic type. Comparison of <code>value=
_ptr</code> does not have this property: copy semantics are incompatible wi=
th equality comparison semantics: a copy-constructed <code>value_ptr</code>=
does not compare equal to the original. <code>value_ptr</code> is not a va=
lue semantic type.=20
</p>
<h2><a name=3D'rationale'>Design rationale</a></h2>
<p>Nearly every function in the interface of <code>optional</code> has rise=
n some controversies. Different people have different expectations and diff=
erent concerns and it is not possible to satisfy all conflicting requiremen=
ts. Yet, we believe that <code>optional</code> is so universally useful, th=
at it is worth standardizing it even at the expense of introducing a contor=
versial interface. The current proposal reflects our arbitrary choice of ba=
lance between unambiguousity, genericity and flexibility of the interface. =
The interface is based on Fernanndo Cacciola's <a href=3D'http://www.boost.=
org/doc/libs/1_48_0/libs/optional/doc/html/index.html'>Boost.Optional</a> l=
ibrary,<sup>[2]</sup> and the users' feedback. The library has been widely =
accepted, used and even occasionally recommended ever since.=20
</p>
<h3><a name=3D'rationale.model'>Conceptual model for <code>optional<T>=
;</code></a></h3>
<p>Optional objects serve a number of purposes and a couple of conceptual m=
odels can be provided to answer the question what <code>optional<T></=
code> really is and what interface it should provide. The three most common=
models are:</p>
<ol>
<li>Just a <code>T</code> with deferred initialization (and additional in=
terface to check if the object has already been initialized).</li>
<li>A discriminated union of types <code>nullopt_t</code> and <code>T</co=
de>.</li>
<li>A container of <code>T</code>'s with the maximum size of 1.</li>
</ol>
<p>While (1) was the first motivation for <code>optional</code>, we do not =
choose to apply this model, because type <code>optional<T></code> wou=
ld not be a value semantic type: it would not model concept <code>Regular</=
code> (if C++ had concepts). In particular, it would be not clear whather b=
eing engaged or disengaged is part of the object's state. Programmers who w=
ish to adapt this view, and don't mind the mentioned difficulties, can stil=
l use <code>optional</code> this way:</p>
<pre>optional<int> oi;
initializeSomehow(oi);
int i =3D (*oi);
use(*oi);
(*oi) =3D 2;
cout << (*oi);
</pre>
<p>Note that this usage does not even require to check for engaged state, i=
f one is sure it has been performed. One just needs to use indirection oper=
ator consistently anywhere one means to use the initialized value. </p>
<p>Model (2) treats <code>optional<T></code> as etier a value of type=
<code>T</code> or value <code>nullopt</code>, allocated in the same storag=
e, along with the way of determining which of the two it is. The interface =
in this model requires operations such as comparison to <code>T</code>, com=
parison to <code>nullopt</code>, assignment and creation from either. It is=
easy to determine what the value of the optional object is in this model: =
the type it stores (<code>T</code> or <code>nullopt_t</code>) and possibly =
the value of <code>T</code>. This is the model that we propose.</p>
<p>Model (3) treats <code>optional<T></code> as a special case contai=
ner. This begs for a container-like interface: <code>empty</code> to check =
if the object is disengaged, <code>emplace</code> to engage the object, and=
<code>clear</code> to disengage it. Also, the value of optional object in =
this model is well defined: the size of the container (0 or 1) and the valu=
e of the element if the size is 1. This model would serve our pupose equall=
y well. The choice between models (2) and (3) is to a certain degree arbitr=
ary. One argument in favour of (2) is that it has been used in practise for=
a while in Boost.Optional.</p>
<h3><a name=3D'rationale.initialization_variants'>Initialization of <code>o=
ptional<T></code></a></h3>
<p>In cases <code>T</code> is a value semantic type capable of storing <em>=
n</em> distinct values, <code>optional<T></code> can be seen as an ex=
tended <code>T</code> capable of storing <em>n</em> + 1 values: these that =
<code>T</code> stores and <code>nullopt</code>. Any valid initialization sc=
heme must provide a way to put an optional objects to any of these states. =
In addition, some <code>T</code>s (like scope guards) are not <code>MoveCon=
structible</code> and their optional variants still should constructible wi=
th any set of arguments that work for <code>T</code>. Two models have been =
identified as feasible.</p>
<p>The first requires that you initialize either by providing an already co=
nstructed <code>T</code> on the tag <code>nullopt</code>.</p>
<pre>string s{"STR"};
optional<string> os{s}; <em> // requires Copyable&l=
t;T></em>
optional<string> ot =3D s; <em> // requires Copyable=
<T></em>
optional<string> ou{"STR"}; <em> // requires Movable<=
;T></em>
optional<string> ov =3D string{"STR"}; <em> // requires Movable&=
lt;T></em>
optional<string> ow; <em> // disengaged</em>
optional<string> ox{}; <em> // disengaged</em>
optional<string> oy =3D {}; <em> // disengaged</em>
optional<string> oz =3D optional<string>{}; <em> // disengaged<=
/em>
optional<string> op{nullopt}; <em> // disengaged</em>
optional<string> oq =3D {nullopt}; <em> // disengaged</em>
</pre>
<p>In order to avoid calling move/copy constructor of <code>T</code>, we us=
e a 'tagged' placement constructor: </p>
<pre>optional<Guard> og; <em> // disengaged</em=
>
optional<Guard> oh{}; <em> // disengaged</em>
optional<Guard> oi{emplace}; <em> // calls Guard{} in pl=
ace</em>
optional<Guard> oj{emplace, "arg"}; <em> // calls Guard{"arg"} =
in place</em>
</pre>
<p>The in-place constructor is not strictly necessary. It could be dropped =
because one can always achieve the same effect with a two-liner:</p>
<pre>optional<Guard> oj; <em> // start disengag=
ed</em>
oj.emplace("arg"); <em> // now engage</em>
</pre>
<p>Notably, there are two ways to create a disengaged optional object: eith=
er by using the default constructor or by calling the 'tagged constructor' =
that takes <code>nullopt</code>. One of these could be safely removed and <=
code>optional<T></code> could still be initialized to any state. </p>
<p>An alternative and also comprehensive initialization scheme is to have a=
variadic perfect forwarding constructor that just forwards any set of argu=
ments to the constructor of the contained object of type <code>T</code>:
<pre><em>// not proposed</em>
optional<string> os{"STR"}; <em> // calls string{"STR"}=
in place </em>
optional<string> ot{2, 'a'}; <em> // calls string{2, 'a'=
} in place</em>
optional<string> ou{}; <em> // calls string{} in p=
lace</em>
optional<string> or; <em> // calls string{} in p=
lace</em>
optional<Guard> og; <em> // calls Guard{} in pl=
ace</em>
optional<Guard> oh{}; <em> // calls Guard{} in pl=
ace</em>
optional<Guard> ok{"arg"}; <em> // calls Guard{"arg"} =
in place</em>
optional<vector<int>> ov; <em> // creates 0-ele=
ment vector</em>
optional<vector<int>> ow{}; <em> // creates 0-ele=
ment vector</em>
optional<vector<int>> ox{5, 6}; <em> // creates 5-ele=
ment vector</em>
optional<vector<int>> oy{{5, 6}}; <em> // creates 2-ele=
ment vector</em>
</pre>
<p>In order to create a disengaged optional object a special tag needs to b=
e used: either <code>nullopt</code> or <code>T</code>-based:</p>
<pre>optional<int> oi =3D nullopt; <em> // disengaged <=
/em>
optional<int> oj =3D optional<int>::nullopt;<em> // disengaged<=
/em>
</pre>
<p>The latter, perfect forwarding variant, has an obvious advantage: whatev=
er you can initialize <code>T</code> with, you can also use it to initializ=
e <code>optional<T></code> with the same semantics. It becomes even o=
re useful in copy-initialization contextx like returning values from functi=
ons or passing arguments to functions:</p>
<pre>void putch(optional<char> oc);
putch('c');
putch({}); // char '\0'
putch(nullopt); // no char
</pre>
<p> However, there are also certain problems with this model. First, there =
are exceptions to perfect forwarding: the tag <code>nullopt</code> is not f=
orwarded. Also, arguments of type <code>optional<T></code> are not. T=
his becomes visible if <code>T</code> has such constructor:</p>
<pre>struct MyType
{
MyType(optional<MyType>, int =3D 0);
<em>// ... </em>
};
</pre>
<p>Also, in general, it is impossible to perfect-forward <code>initializer_=
list</code> as the special deduction rules are involved. Second problem is =
that <code>optional</code>'s default constructor creates an engaged object =
and therby triggers the value-initialization of <code>T</code>. It can be a=
rgued that this is only a psychological argument resulting from the fact th=
at other <code>std</code> components behave this way: containers, smart poi=
nters, <code>function</code>, and only because perfect forwarding was not a=
vailable at the time they were designed. However we anticipate that this ex=
pectation (valid or not) could cause bugs in programs. Consider the followi=
ng example:</p>
<pre>optional<char> readChar(Stream str)
{
optional<char> ans;
if (str.buffered()) {
ans =3D str.readBuffered();
clearBuffer();
}
else if (!str.end()) {
ans =3D str.readChar();
}
return ans;
}=20
</pre>
<p>This is so natural to expect that <code>ans</code> is not engaged until =
we decide how we wan to engage it, that people will write this code. And in=
the effect, if they cannod read the character, they will return an engaged=
optional object with value <code>'\0'</code>. For these reasons we choose =
to propose the former model.</p>
<h3><a name=3D'rationale.default_ctor'>The default constructor</a></h3>
<p>This proposal provides a default constructor for <code>optional<T>=
</code> that creates a disengaged optional. We find this feature convenient=
for a couple of reasons. First, it is because this behaviour is intuitive =
as shown in the above example of function <code>readChar</code>. It avoids =
a certain kind of bugs. Also it satisfies other expectations. If I declare =
<code>optional<T></code> as a non-static member, without any initial=
izer, I may expect it is already initialized to the most natural, disengage=
d, state regardless of whether <code>T</code> is <code>DefaultConstructible=
</code> or not. Also when declaring a global object, one could expect that =
default constructor would be initialized during static-initialization (this=
proposal guarantees that). One could argue that the tagged constructor cou=
ld be used for that puropse: </p>
<pre>
int global =3D nullopt;
struct X
{
optional<M> m =3D nullopt;
};
</pre>
<p>However, sometimes not providing the tag may be the result of an inadver=
tent omission rather than concious decision. Because of our default constru=
ctor semantics we have to reject the initialization scheme that yses a perf=
ect forwarding constructor. Even if this is fine, one could argue that we d=
o not need a default constructor if we have a tagged constructor. We find t=
his redundancy convenient. For instance, how do you resize a <code>vector&l=
t;optional<T>></code> if you do not have the default constructor? =
You could type:</p>
<pre>vec.resize(size, nullopt);</pre>
<p>However, that causes first the creation od disengaged optional, and then=
copying it multiple times. The use of copy constructor may incur run-time =
overhead and not be available for non-copyable <code>T</code>s. Also, it wo=
uld be not possible to use subscript operator in maps that hold opitonal ob=
jects.</p>
<p>Also, owing to this constructor, <code>optional</code> has a nice side-e=
ffect feature: it can make "almost <code>Regular</code>" types fully <code>=
Regular</code> if the lack od default constructor is the only thing they ar=
e missing. For instance consider type <code>Date</code> for representing ca=
lendar days: it is copyable movable, comparable, but is not <code>DefaultCo=
nstructible</code> because there is no meaningful default date. However, <c=
ode>optional<Date></code> is <code>Regular</code> with a meaningful n=
ot-a-date state created by default.</p>
<h3><a name=3D'rationale.converting_ctor'>Converting constructor (from <cod=
e>T</code>)</a></h3>
<p>An object of type <code>T</code> is convertible to an engaged opbject of=
type <code>optional<T></code>:</p>
<pre>optional<int> oi =3D 1; <em>// works</em></pre>
<p>This convenience feature is not strictly necessary because you can achie=
ve the same effect by using tagged forwarding constructor:</p>
<pre>optional<int> oi{emplace, 1};</pre>
<p>If the latter appears too inconvenient, one can always use funciotn <cod=
e>make_optional</code> described below:</p>
=20
<pre>optional<int> oi =3D make_optional(1);=20
auto oj =3D make_optional(1);=20
</pre>
<p>If the above still appears inconvenient, one could argue that <code>opti=
onal</code>'s constructor from <code>T</code> could still be provided but m=
ade explicit. We decided to enable implicit conversion, because it is in ac=
cord with the view of optional as an extended type <code>T</code> capable o=
f storing all 'normal' values of <code>T</code> + one additional value: <co=
de>nullopt</code> this is reflected in object construction and assignment:<=
/p>
<pre>optional<unsigned> oi =3D 1;
optional<unsigned> oj =3D 0;
optional<unsigned> ok =3D nullopt;
oi =3D nullopt;
oj =3D 0;
ok =3D 1;
</pre>
<p>For the same reason, also construction from <code>nullopt</code> is non-=
explicit. Although, in this picture name 'none' for the tag (rather than 'n=
ullopt') would better serve the purpose. In contrast, accessor functions (i=
ncluding comparison operators) do not expose such symmetric interface. Such=
implicit conversions impose some risk of introducing bugs, and in fact in =
order to avoid one such possible bug we had to 'poison' comparisons between=
<code>optional<T></code> and <code>T</code>. (This is explained in d=
etail in section on relational operators.)</p>
<h3><a name=3D'rationale.bool_conversion'>Contextual conversion to <code>bo=
ol</code> for checking engaged state</a></h3>
<p>Objections have been risen to this decision. When using <code>optional&l=
t;bool></code>, contextual conversion to <code>bool</code> (used for che=
cking the engaged state) might be confused with accessing the stored value.=
while such mistake is possible, it is not precedent in the standard: types=
<code>bool*</code>, <code>unique_ptr<bool></code>, <code>shared_ptr&=
lt;bool></code> suffer from the same potential problem, and it was never=
considered a show-stopper. Some have suggested that a special case in the =
interface should be made for <code>optional<bool></code> specializati=
on. This was however rejected because it would break the generic use of <co=
de>optional</code>. </p>
<p>Some have also suggested that a member function like <code>is_initialize=
d</code> would more clearly indicate the intent than explicit conversion to=
<code>bool</code>. However, we believe that the latter is a well establish=
ed idiom in C++ comunity as well as in the C++ Standard Library, and <code>=
optional</code> appears so fundamental a type that a short and familiar not=
ation appears more appropriate. It also allows us to combine the constructi=
on and checking for being engaged in a condition:
=09</p>
<pre>if (optional<char> ch =3D readNextChar()) {
// ...
}
</pre>
<h3><a name=3D'rationale.nullopt'>Using tag <code>nullopt</code> for indica=
ting disengaged state</a></h3>
<p>The proposed interface uses special tag <code>nullopt</code> to indicate=
disengaged <code>optional</code> state. It is used for construction, assig=
nment and relational operations. This might rise a couple of objections. Fi=
rst, it introduces redundancy into the interface:</p>
<pre>optional<int> opt1 =3D nullopt;=20
optional<int> opt2 =3D {};=20
opt1 =3D nullopt;
opt2 =3D {};
if (opt1 =3D=3D nullopt) ...
if (!opt2) ...
if (opt2 =3D=3D optional<int>{}) ...
</pre>
<p>On the other hand, there are usages where the usage of <code>nullopt</co=
de> cannot be replaced with any other convenient notation:</p>
<pre>void run(complex<double> v);
void run(optional<string> v);
run(nullopt); <em>// pick the second overload</em>
run({}); <em>// ambiguous</em>
if (opt1 =3D=3D nullopt) ... <em>// fine</em>
if (opt2 =3D=3D {}) ... <em>// ilegal</em>
</pre>
<p>While some situations would work with <code>{}</code> syntax, using <cod=
e>nullopt</code> makes the programmer's intention more clear. Compare these=
:</p>
<pre>optional<vector<int>> get1() {
return {};
}
optional<vector<int>> get2() {
return nullopt;
}
optional<vector<int>> get3() {
return optional<vector<int>>{};
}
</pre>
<p>The usage of <code>nullopt</code> is also a consequence of the adapted m=
odel for optional: a discriminated union of <code>T</code> and <code>nullop=
t_t</code>. Also, a similar redundancy in the interface already exists in a=
number of components in the standard library: <code>unique_ptr</code>, <co=
de>shared_ptr</code>, <code>function</code> (which use literal <code>nullpt=
r</code> for the same purpose); in fact, type requirements <code>NullablePo=
inter</code> require of types this redundancy. </p>
<p>Name "nullopt" has been chosen because it clearly indicates that we are =
interested in creating a null (disengaged) <code>optional<T></code> (=
of unspecified type <code>T</code>). Other short names like "null", "naught=
", "nothing" or "none" (used in Boost.Optional library) were rejected becau=
se they were too generic: they did not indicate unambiguously that it was <=
code>optional<T></code> that we intend to create. Such a generic tag =
<code>nothing</code> could be useful in many places (e.g., in types like <c=
ode>variant<nothing_t, T, U></code>), but is outside the scope of thi=
s proposal.</p>
=20
<p>Note also that the definition of tag struct <code>nullopt</code> is more=
complicated than that of other, similar, tags: it has explicitly deleted d=
efault constructor. This is in order to enable the reset idiom (<code>opt2 =
=3D {};</code>), which would otherwise not work because of ambiguuity when =
deducing the right-hand side argument.</p>
<h3><a name=3D'rationale.no_nullptr'>Why not <code>nullptr</code></a></h3>
<p>One could argue that since we have keyword <code>nullptr</code>, which a=
lready indicates a 'null-state' for a number of Standard Library types, not=
necessarily pointers (class template <code>function</code>), it could be e=
qually well used for <code>optional</code>. In fact, the previous revision =
of this proposal did propose <code>nullptr</code>, however there are certai=
n difficulties that arise when the null-pointer literal is used.</p>
<p>First, the interface of <code>optional</code> is already criticized for =
resembling too much the interface of a (raw or smart) pointer, which incorr=
ectly suggests external heap storage and shallow copy and comparison semant=
ics. The "ptr" in "nullptr" would only increase this confusion. While <code=
>std::function</code> is not a pointer either, it also does not provide a c=
onfusing <code>operator-></code>, or equality comparison, and in case it=
stores a function pointer it does shallow copying.</p>
<p>Second, using literal <code>nullptr</code> in <code>optional</code> woul=
d make it impossible to provide some of the natural and expected initializa=
tion and assignment semantics for types that themselves are nullable:</p>
<ul>
<li><code>optional<int*></code>, </li>
<li><code>optional<const char*></code>, </li>
<li><code>optional<M C::*></code>, </li>
<li><code>optional<function<void(int)>></code>, </li>
<li><code>optional<NullableInteger></code>,</li>
<li><code>optional<nullptr_t></code>.</li>
</ul>
<p>Should the following initialization render an engaged or a disengaged op=
tional?</p>
<pre>optional<int*> op =3D nullptr;</pre>
<p>One could argue that if we want to initialize an engaged optional we sho=
uld indicate that explicitly: </p>
<pre>optional<int*> op{emplace, nullptr};</pre>
<p>But this argument would not work in general. One of the goals of the des=
ign of <code>optional</code> is to allow a seamless "optionalization" of fu=
nction arguments. That is, given the folowing function signature:</p>
<pre>void fun(T v) {
process(v);
}
</pre>
<p>It should be possible to change the signature and the implementation to:=
</p>
<pre>void fun(optional<T> v) {
if (v) process(*v);
else doSthElse();
}
</pre>
<p>and expect that all the places that call function <code>fun</code> are n=
ot affected. But if <code>T</code> happens to be <code>int*</code> and we o=
ccasionally pass value <code>nullptr</code> to it, we will silently change =
the intended behavior of the refactoring: because it will not be the pointe=
r that we null-initialize anymore but a disengaged optional.</p>
<p>Note that this still does not save us from the above problem with refact=
oring function <code>fun</code> in case where <code>T</code> happens to be =
<code>optional<U></code>, but we definately limit the amount of surpr=
ises.</p>
<p>In order to avoid similar problems with tag <code>nullopt</code>, instan=
tiating template <code>optional</code> with types <code>nullopt_t</code> an=
d <code>emplace_t</code> is prohibitted.</p>
<p>There exist, on the other hand, downsides of introducing a special token=
in place of <code>nullptr</code>. The number of ways to indicate the 'null=
-state' for different library components will grow: you will have <code>NUL=
L</code>, <code>nullptr</code>, <code>nullopt</code>. New C++ programmers w=
ill ask "which of these should I use now?" What guidelines should be provid=
ed? Use only <code>nullptr</code> for pointers? But does it mean that we sh=
ould use <code>nullopt</code> for <code>std::function</code>? Having only o=
ne way of denoting null-state, would make the things easier, even if "ptr" =
suggests a pointer. </p>
<h3><a name=3D'rationale.t_based_none'>Why not a tag dependent on <code>T</=
code>? </a></h3>
<p>It has been suggested that instead of 'typeless' <code>nullopt</code> a =
tag nested in class <code>optional</code> be used instead:</p>
<pre>optional<int> oi =3D optional<int>::nullopt;
</pre>
<p>This has several advanages. Namespace <code>std</code> is not polluted w=
ith an additional <code>optional</code>-specific name. Also, it resolves ce=
rtain ambiguities when types like <code>optional<<code>optional<T>=
</code>></code> are involved:</p>
<pre>optional<optional<int>> ooi =3D optional<int>::nullo=
pt; <em>// engaged</em>
optional<optional<int>> ooj =3D optional<optional<int>=
>::nullopt; <em>// disengaged</em>
</pre>
<pre>void fun(optional<string>);
void fun(optional<int>);
fun(optional<string>::nullopt); <em>// unambiguous: a typeless nullop=
t would not do</em>=20
</pre>
<p>Yet, we choose to propose a typeless tag because we consider the above p=
roblems rare and a typeless tag offers a very short notation in other cases=
:</p>
<pre>optional<string> fun()
{
optional<int> oi =3D nullopt; <em>// no ambiguity</em>
oi =3D nullopt; <em>// no ambiguity</em>
<em>// ...</em>
return nullopt; <em>// no ambiguity</em>
}
</pre>
<p>If the typeless tag does not work for you, you can always use the follow=
ing construct, although at the expense of invoking a (possibly elided) move=
constructor:</p>=20
<pre>optional<optional<int>> ooi =3D optional<int>{}; =
<em>// engaged</em>
optional<optional<int>> ooj =3D optional<optional<int>=
>{}; <em>// disengaged</em>
</pre>
<pre>void fun(optional<string>);
void fun(optional<int>);
fun(optional<string>{}); <em>// unambiguous</em>=20
</pre>
<h3><a name=3D'rationale.access'>Accessing the contained value</a></h3>
<p>It was chosen to use indirection operator because, along with explicit c=
onversion to <code>bool</code>, it is a very common pattern for accessing a=
value that might not be there: </p>
<pre>if (p) use(*p);</pre>
<p>This pattern is used for all sort of pointers (smart or dumb), and it cl=
early indicates the fact that the value may be missing and that we return a=
reference rather than a value. The indirection operator has risen some ob=
jections because it may incorrectly imply that <code>optional</code> is a (=
possibly smart) pointer, and thus provides shallow copy and comparison sema=
ntics. We believe that the cost of potential confusion is overweighed by th=
e benefit of an easy to grasp and intuitive interface for accessing the con=
tained value. </p>
<p>We do not think that providing an implicit conversion to <code>T</code> =
would be a good choice. First, it would require different way of checking f=
or the epty state; and second, such implicit conversion is not perfect and =
still requires other means of accessing the contained value if we want to c=
all a member function on it.</p>
<h3><a name=3D'rationale.relops'>Relational operators</a></h3>
<p>One of the design goals of <code>optional</code> is that objects of type=
<code>optional<T></code> should be valid elements in STL containers =
and usable with STL algorithms (at least if objects of type <code>T</code>=
are). Equality comparison is essential for <code>optional<T></code> =
to model concept <code>Regular</code>. C++ does not have concepts, but bein=
g regular is still essential for the type to be effectively used with STL. =
Ordering is essential if we want to store optional values in associative co=
ntainers. A number of ways of including the disengaged state in comparisons=
have been suggested. The ones proposed, have been crafted such that the ax=
ioms of equivalence and strict weak ordering are preserved: disengaged <cod=
e>optional<T></code> is simply treated as an additional and unique va=
lue of <code>T</code> equal only to itself; this value is always compared a=
s less than any value of <code>T</code>:</p>
<pre>
assert (optional<unsigned>{} < optional<unsigned>{0});
assert (optional<unsigned>{0} < optional<unsigned>{1});
assert (!(optional<unsigned>{} < optional<unsigned>{}) );
assert (!(optional<unsigned>{1} < optional<unsigned>{1}));
assert (optional<unsigned>{} !=3D optional<unsigned>{0});
assert (optional<unsigned>{0} !=3D optional<unsigned>{1});
assert (optional<unsigned>{} =3D=3D optional<unsigned>{} );
assert (optional<unsigned>{0} =3D=3D optional<unsigned>{0});
</pre>
<p>One could also expect comparisons between <code>T</code> and <code>optio=
nal<T></code>. The natural semantics of such comparison would be:</p>
<pre>
template <class T>
bool operator=3D=3D(const optional<T>& a, const T& b)
{
return a =3D=3D make_optional(b);
}
</pre>
<p>We do not propose it because there is no strong motivation for such comp=
arisons. On the contrary, the inadvertent invocation o such comparisons mig=
ht be disastrous. Consider the following scenario. We have a class that sto=
res the number of passengers:
</p>
<pre>class MyPlan
{
unsigned passengerCount;
<em>// ...</em>
};</pre>
<p>At some point we realize that sometimes we will not know the number of p=
assengers: either because we use lazy initialization techniques or because =
we failed to compute the number. We change the type of the variable:</p>
<pre>class MyPlan
{
optional<unsigned> passengerCount;
<em>// ...</em>
};</pre>
<p>And we might expect that compiler will warn us in every place where we t=
ry to access the value of <code>passengerCount</code>. However the followin=
g comparison will continue to compile although the run-time behaviour will =
be different than the one expected:</p>
<pre>bool MyPlan::exceedsCapacity() const
{
return passengerCount > availableSeats;
<em>// availableSeats is of type unsigned int</em>
}
</pre>
<p>Since disengaged optional never compares greater than anything, the effe=
ct we have is that if we do not know how many passengers there are we repor=
t with certainty that their number does not exceed the capacity. For this r=
eason comparison between <code>optional<T></code> and <code>T</code> =
are required to be reported as errors at compile-time</p>
<h3><a name=3D'rationale.resetting'>Resetting the optional value</a></h3>
<p>This proposal offers three ways of assigning a new contained value to an=
optional object:</p>
<pre>optional<int> o;
o =3D make_optional(1); <em>// copy/move assignment</em>
o =3D 1; <em>// assignment from T</em>
o.emplace(1); <em>// emplacement</em>=20
</pre>
<p>The first form of assignment is required to make <code>optional</code> a=
regular object, useable in STL. We need the second form in order to reflec=
t the fact that <code>optional<T></code> is a wrapper for <code>T</co=
de> and hence it should behave as <code>T</code> as much as possible. Also,=
when <code>optional<T></code> is viewed as <code>T</code> with one a=
dditional value, we want the values of <code>T</code> to be directly assign=
able to <code>optional<T></code>. In addition, we need the second for=
m to allow the interoperability with function <code>std::tie</code> as show=
n above. The two forms differ only by syntax. Their semantics are practical=
ly the same: if <code>o</code> is disengaged, call <code>T</code>'s copy/mo=
ve constructor to initialize the contained value; otherwise use <code>T</co=
de>'s copy/move assignment to modify the contained value (here, we skip the=
cases where the right-hand side optional object is disengaged). The third =
option, using function <code>emplace</code> is different in semantics, whic=
h is: destroy the contained value (if engaged) and create anew. It does not=
require that the contained value is even a moveable type, and guarantees n=
o copying/moving.
</p>
=20
<h3><a name=3D'rationale.emplace'>Tag <code>emplace</code></a></h3>
<p>This proposal provides an 'in-place' constructor that forwards (perfectl=
y) the arguments provided to <code>optional</code>'s constructor into the c=
onstructor of <code>T</code>. In order to trigger this constructor one has =
to use the tag struct <code>emplace</code>. We need the extra tag to disamb=
iguate certain situations, like calling <code>optional</code>'s default con=
structor and requesting <code>T</code>'s default construction:</p>
<pre>optional<Big> ob{emplace, "1"}; <em>// calls Big{"1"} in place (=
no moving)</em>
optional<Big> oc{emplace}; <em>// calls Big{} in place (no movin=
g)</em>
optional<Big> od{}; <em>// creates a disengaged optional<=
/em>
</pre>
<p>The name, suggested by Alberto Ganesh Barbati, is consistent with member=
functions of containers (and <code>optional</code> itself), which also ind=
icate similar purpose. On the other hand, it may appear uncomfortable that =
<code>emplace</code> becomes overloaded in <code>std</code>: it is now a me=
mber funciton in many container type as well as a tag. If this is considere=
d a serious issue, the tag could be renamed to <code>in_place</code>.</p>
=20
<h3><a name=3D'rationale.requirements'>Requirements on <code>T</code></a></=
h3>
<p>Class template <code>optional</code> imposes little requirements on <cod=
e>T</code>: it has to be either an lvalue reference type, or a complete obj=
ect type satisfying the requirements of <code>Destructible</code>. It is th=
e particular operations on <code>optional<T></code> that impose requi=
rements on <code>T</code>: <code>optional<T></code>'s move constructo=
r requires that <code>T</code> is <code>MoveConstructible</code>, <code>opt=
ional<T></code>'s copy constructor requires that <code>T</code> is <c=
ode>CopyConstructible</code>, and so on. This is because <code>optional<=
T></code> is a wrapper for <code>T</code>: it should resemble <code>T</c=
ode> as much as possible. If <code>T</code> is <code>EqualityComparable</co=
de> then (and only then) we expect <code>optional<T></code> to be <co=
de>EqualityComparable</code>. </p>
<h3><a name=3D'rationale.refs'>No optional references</a></h3>
<p>In this revision we propose no optional references. Defining type <code>=
optional<T&></code> is illegal. While optional references add cer=
tain value, we decided to remove them from this proposal as their existence=
appeared controversial. Optional references will be proposed in a separate=
paper.</p>
<p>Users that in generic contexts require to also store optional lvalue ref=
erences can achieve this effect with a bit of meta-programming. </p>
<pre>
template <class T>
struct generic
{
typedef T type;
};
template <class U>
struct generic<U&>
{
typename std::reference_wrapper<U> type;
};
template <class T>
using Generic =3D typename generic<T>::type;
template <class X>
void generic_fun()
{
std::optional<Generic<X>> op;
<em>// ...</em>
}
</pre>
<h3><a name=3D'rationale.noexcept'>Exception specifications</a></h3>
<p>First draft of this revision required an aggressive usage of conditional=
<code>noexcept</code> specifications for nearly every, member- or non-memb=
er-, function in the interface. For instance equality comparison was to be =
declared as:</p>
<pre>template <class T>
bool operator=3D=3D(const optional<T>& lhs, const optional<T=
>& rhs)
noexcept(noexcept(*lhs =3D=3D *rhs));
</pre>
<p>This was based on one of our goals: that we want <code>optional<T>=
</code> to be applicable wherever <code>T</code> is applicable in as many s=
ituations as reasonably possible. One such situation occurs where no-throw =
operations of objects of type <code>T</code> are used to implement a strong=
exception safety guarantee of some operations. We would like objects of ty=
pe <code>optional<T></code> to be also useable in such cases. However=
, we do not propose this aggressive conditional no-throw guarantees at this=
time in order for the proposed library component to adhere to the current =
Library guidlines for conditional <code>noexcept</code>: it is currently on=
ly used in move constructor, move assignment and <code>swap</code>. One exc=
eption to this rule, we think could be made for optional's move constructor=
and assignment from type <code>T&&</code>, however we still do not=
propose this at this time in order to avoid controversy.</p>
<p>Constructors and mutating functions that disengage an optional object ar=
e required to be <code>noexcept(true)</code>: they only call <code>T</code>=
's destructor and impose no precondition on optional object's or contained =
value's state. The same applies to the observers that check the disengaged/=
engaged state.</p>
<p>The observers that access the contained value, following the guidelines =
from N3248<sup>[6]</sup>, are declared as <code>noexcept(false)</code> beca=
use they impose a precondition that optional object shall be engaged. These=
operations are still required not to throw exceptions.</p>
<p>In general, operations on optional objects only throw, when operations d=
elegated to the contained value throw.</p>
<h3><a name=3D'rationale.constexpr'>Constexpr constructors</a></h3>
<p>We propose that <code>optional<T></code> be a literal type for tri=
vially destructible <code>T</code>'s.</p>
<pre>constexpr optional<int> oi{5};
static_assert(oi, ""); <em>// ok</em>
static_assert(oi !=3D nullopt, ""); <em>// ok</em>
static_assert(oi =3D=3D oi, ""); <em>// ok</em>
int array[*oi]; <em>// ok: array of size 5 </em>
</pre>
<p>Making <code>optional<T></code> a literal-type in general is impos=
sible: the destructor cannot be trivial because it has to execute an operat=
ion that can be conceptually described as:</p>
<pre>
~optional() {
if (is_engaged()) destroy_contained_value();
}
</pre>
<p>It is still possible to make the destructor trivial for <code>T</code>'s=
which provide a trivial destructor themselves, and we know an efficient im=
plementation of such <code>optional<T></code> with compile-time inter=
face — except for copy constructor and move constructor — is po=
ssible. Therefore we propose that for trivially destructible <code>T</code>=
's all <code>optional<T></code>'s constructors, except for move and c=
opy constructors, as well as observer functions are <code>constexpr</code>.=
The sketch of reference implementation is provided in this proposal.</p>=
=20
<h3><a name=3D'rationale.moved_from'>Moved-from state</a></h3>
<p>When a disengaged optional object is moved from (i.e., when it is the so=
urce object of move constructor or move assignment) its state does not chan=
ge. When an engaged object is moved from, we move the contained value, but =
leave the optional object engaged. A moved-from contained value is still va=
lid (although possibly not specified), so it is fine to consider such optio=
nal object engaged. An alternative approach would be to destroy the contain=
ed value and make the moved-from optional object disengaged. However, we do=
not propose this for performance reasons.</p>
<p>In contexts, like returning by value, where you need to call the destruc=
tor the second after the move, it does not matter, but in cases where you r=
equest the move explicitly and intend to assign a new value in the next ste=
p, and if <code>T</code> does not provide an efficient move, the chosen app=
roach saves an unnecessary destructor and constructor call:</p>
<pre>optional<array<Big, 1000>> oo =3D ... <em>// array doesn't=
have efficient move</em>
op =3D std::move(oo);
oo =3D std::move(tmp);
</pre>
<p>The following is even more compelling reason. In this proposal <code>std=
::optional<int></code> is allowed to be implemented as a <code>Trivia=
llyCopyable</code> type. Therefore, the copy constructor of type <code>std:=
:array<std::optional<int>, 1000></code> can be implemented usin=
g <code>memcpy</code>. With additional requirement that <code>optional</cod=
e>'s move constructor should not be trivial, we would be preventing the des=
cribed optimization. </p>
<p>The fact that the moved-from optional is not disengaged may look "uncomf=
ortable" at first, but this is an invalid expectation. The only thing that =
can be legitimately expected of a moved from object (optional object, in pa=
rticular) is that it can be assigned to or destroyed without causing any re=
source leak or undefined behavior.</p>
<h3><a name=3D'rationale.io'>IO operations</a></h3>
<p>The proposed interface for optional values does not contain IO operation=
s: <code>operator<<</code> and <code>operator>></code>. While w=
e believe that they would be a useful addition to the interface of optional=
objects, we also observe that there are some technical obstacles in provid=
ing them, and we choose not to propose them at this time.</p>
<p>One can imagine a couple of ways in which IO-operations for any streamab=
le type <code>T</code> could be expected to work. The differences are mostl=
y the consequence of different conceptual models of optional types, as well=
as different use cases that programmers may face. Below we list the possib=
le ways of outputting the value of optional object.</p>
<ol>
<li>Output the contained value if engaged; otherwise enter an undefined beh=
aviour (as programmer error).</li>
<li>Output the contained value if engaged; otherwise output nothing.</li>
<li>Output the contained value if engaged; otherwise output some special se=
quence of characters.</li>
<li>Output something like <code>"OPT[<var>v</var>]"</code>, where <code><va=
r>v</var></code> represents the contained value, if engaged; otherwise outp=
ut something like <code>"OPT[]"</code>.</li>
</ol>
<p>The first option is a consequence of the model where <code>optional<T=
></code> is a <code>T</code> with deferred initialization, but which is =
still initialized before first usage. This is not the model that we advocat=
e, so this behavior of <code>operator<<</code> is rejected. However t=
his behavior can be achieved by accessing the contained value of optional o=
bject on each usage:</p>
<pre>optional<int> oi;
initialize(oi);
cin >> (*oi);
cout << (*oi);
</pre>
<p>The second option appears useful in certain contexts, where we want opti=
onal objects to indicate some supplementary, often missing, information:</p=
>
<pre>struct FlatNumber {
unsigned number_;
optional<char> letter_;
};
ostream& operator<<( ostream& out, FlatNumber n ) {
return out << n.number_ << n.letter_;
}
<em>// outputs "10", "11", "11A", ...</em>=20
</pre>
<p>However, in general the results would be ambiguous. Does output <code>"1=
0"</code> indicate two engaged <code>optional<int></code>s, or =
three, one of which (which one?) is disengaged, or 77 <code>optional<int=
></code>s? Or are these perhaps two <code>int</code>s? Also, It is not p=
ossible to implement a consistent <code>operator>></code> in this cas=
e. It may not be a problem itself, and providing only one operator is not a=
precedent in the standard (consider <code>std::thread::id</code>); alterna=
tively, <code>operator>></code> could be implemented inconsistently: =
by simply calling <code>T</code>'s <code>operator>></code>. =20
</p> =20
<p>The third choice appears attractive at first glance, but there is no goo=
d representation for the special sequence that would produce no ambiguities=
.. Whatever sequence we choose, it is also a valid representtion of <code>st=
d::string</code>; thus if we need to interpret the special sequence, say <c=
ode>"~~~"</code> as <code>optional<string></code>, we do not know if =
it is a disengaged object, or engaged one with contained value of <code>"~~=
~"</code>. On the other hand, some people have argued that this ambiguity i=
s worth the usefulness of a simple tool for logging.
</p>
<p>While the fourth choice presented above still comes with some similar am=
biguities, it is posssible to implement a variant thereof that is not ambig=
uous. Such solution has been implemented in Boost.Tuple library<sup>[5]</su=
p>: user has to register a sequence of letters that represent "an opening b=
racket" of the optional object's contained value, and similarly register an=
another sequence for representing a "closing bracket." This would be the u=
ser's responsibility to make sure that the chosen sequences are unambiguous=
, if default sequences (e.g., <code>"["</code> and <code>"]"</code>) do not=
suffice. However, this solution is not without certain controversy.</p>
<p>Currently all streamable types in the library have a nice property that =
string representation that is streamed out or read in is similar to the for=
mat of literals in C++ used to initialize variables. Thus, whatever you typ=
e into the console that you intend your program to read, could be equally w=
ell typed directly in the C++ code as a literal — of course, to certa=
in extent. The text that the program requires of users to read and type is =
simply nice.</p>
<p>This controversy is charachteristic not only of <code>optional</code>. L=
ibrary components like containers, pairs, tuples face the same issue. At pr=
esent IO operations are not provided for these types. Our preference for <c=
ode>optional</code> is to provide an IO solution compatible with this for c=
ontainers, pairs and tuples, therefore at tis point we refrain from proposi=
ng a solution for <code>optional</code> alone.</p>
<h3>Type requirements <code>NullableProxy</code></h3>
<p>Along with the developement of this proposal, we observe that certain ab=
straction is common to optional objects, as well as to raw and smart pointe=
rs, and is useful enough to provide type requirements for certain class of =
algorithms. We call this concept <code>NullableProxy</code>. Basically the =
concept indicates that a type is a 'proxy' for another type. The operations=
allowed are: checking if there exists an object that our proxy can indirec=
t us to and the indirection operation. The operations can be summarized by =
the following use-case:</p>
<pre>
temmplate <class NullableProxy>
void test(NullableProxy&& np)
{
if (np) <em>// 'has-object' check</em>
auto&& obj =3D *np; <em>// object access</em>
if (!np) {} <em>// 'doesn't have object'</em>
}
</pre>
<p>These requirements are sufficient to specify a couple of algorithms (not=
proposed), like the one below: </p>
<pre>template <typename NullableProxy>
<em>// enable_if: decltype(*declval<NullableProxy>()) is EqualityComp=
arable</em>
bool equal_pointees( const NullableProxy& x, const NullableProxy& y=
)
{
return bool(x) !=3D bool(y) ? false : ( x ? *x =3D=3D *y : true );
}
</pre>
<p>This is exactly the logic for the equality comparison of optional values=
, and could be used as an implementation of <code>optional<T>::operat=
or=3D=3D</code>. A similar algorithm for less-than comparison can be specif=
ied. The third example is function <code>get_value_or</code> discussed belo=
w.</p>
<p>Requirements <code>NullableProxy</code> overlap with requirements <code>=
NullablePointer</code>. Their common part could be extracted to separate re=
quirements, say <code>Nullable</code>, but these requirements are to small =
to be useful alone for anything.</p>
<p>We do not propose to add <code>NullableProxy</code> to Library at this t=
ime, but we consider it a useful future addition.</p>
<h3><a name=3D'rationale.get_value_or'>Function <code>get_value_or</code></=
a></h3>
<p>This function template returns a value stored by the <code>optional</cod=
e> object if it is engaged, and if not, it falls back to the default value =
specified in the second argument. This method for specifying default values=
on the fly rather than tying the default values to the type is based on th=
e observation that different contexts or usages require different default v=
alues for the same type. For instance the default value for <code>int</code=
> can be 0 or -1. The callee might not know what value the caller considers=
special, so it returns the lack of the requested value explicitly. The cal=
ler may be better suited to make the choice what special value to use.</p>
<pre>
optional<int> queryDB(std::string);
void setPieceCount(int);
void setMaxCount(int);
setPieceCount( queryDB("select piece_count from ...").get_value_or(0) );
setMaxCount( queryDB("select max_count from ...").get_value_or(numeric_limi=
ts<int>::max()) );
</pre>
<p>The decision to provide this function is controversial itself. As pointe=
d out by Robert Ramey, the goal of the <code>optional</code> is to make the=
lack of the value explicit. Its syntax forces two control paths; therefore=
we will typically see an <code>if</code>-statement (or similar branching i=
nstruction) wherever <code>optional</code> is used. This is considered an i=
mprovement in correctness. On the other hand, using the default value appea=
rs to conflict with the above idea. One other argument against providing it=
is that in many cases you can use a ternary conditional operator instead:<=
/p>
<pre>auto&& cnt =3D queryDB("select piece_count from ...");
setPieceCount(cnt ? *cnt : 0);
auto&& max =3D queryDB("select max_count from ...");
setMaxCount(max ? std::move(*max) : numeric_limits<int>::max());
</pre>
<p>However, in case optional objects are returned by value and immediately =
consumed, the ternary operator syntax requires introducing an lvalue. This =
requires more typing and explicit <code>move</code>. This in turn makes the=
code less safe because a moved-from lvalue is still accessible and open fo=
r inadvertent misuse.</p>
<p>There are reasons to make it a free-standing function. (1) It can be imp=
lemented by using only the public interface of <code>optional</code>. (2) T=
his function template could be equally well be applied to any type satisfyi=
ng the requirements of <code>NullableProxy</code>. In this proposal, functi=
on <code>get_value_or</code> is defined as a member function and only for <=
code>optional</code>s. We leave a possible generalization for the future.
</p>
<p>The second argument in the function template's signature is not <code>T<=
/code> but any type convertible to <code>T</code>:</p>
<pre>
template <class T, class V>=20
typename decay<T>::type optional<T>::get_value_or(V&&=
<var>v</var>) const&;
template <class T, class V>=20
typename decay<T>::type optional<T>::get_value_or(V&&=
<var>v</var>) &&;
</pre>
<p>This allows for a certain run-time optimization. In the following exampl=
e:</p>
<pre>optional<string> op{"cat"};
string ans =3D op.get_value_or("dog");
</pre>
<p>Because the optional object is engaged, we do not need the fallback valu=
e and therefore to convert the string literal <code>"dog"</code> into type =
<code>string</code>.</p>
<p>It has been argued that the function should return by constant reference=
rather than value, which would avoid copy overhead in certain situations:<=
/p>
<pre>void observe(const X& x);
optional<X> ox { <em>/* ... */</em> };
observe( ox.get_value_or(X{args}) ); <em>// unnecessary copy</em>
</pre>
<p>However, the benefit of the function <code>get_value_or</code> is only v=
isible when the optional object is provided as a temporary (without the nam=
e); otherwise, a ternary operator is equally useful:</p>
<pre>optional<X> ox { <em>/* ... */</em> };
observe(ox ? *ok : X{args}); <em>// no copy</em>
</pre>
<p>Also, returning by reference would be likely to render a dangling refere=
nce, in case the optional object is disengaged, because the second argument=
is typically a temporary:</p>
<pre>
optional<X> ox {nullopt};
auto&& x =3D ox.get_value_or(X{args});
cout << x; <em> // x is dangling!</em>
</pre>
<p>There is also one practical problem with returning a reference. The func=
tion takes two arguments by reference: the optional object and the default =
value. It can happen that one is deduced as lvalue reference and the other =
as rvalue reference. In such case we would not know what kind of reference =
to return. Returning lvalue reference might prevent move optimizationreturn=
ing an rvalue reference might cause an unsafe move from lvalue. By returnin=
g by value we avoid these problems by requiring one unnecessary move in som=
e cases.</p>
<p>We also do not want to return a constant lvalue reference because that w=
ould prevent a copy elision in cases where optional object is returned by v=
alue.</p>
<p>It has also been suggested (by Luc Danton) that function <code>optional&=
lt;T>::get_value_or<V></code> should return type <code>decay<co=
mmon_type<T, V>::type>::type</code> rather than <code>decay<T&g=
t;::type</code>. This would avoid certain problems, such as loss of accurac=
y on arithmetic types:</p>
<pre><em>// not proposed</em>
std::optional<int> op =3D <em>/* ... */</em>;
long gl =3D <em>/* ... */</em>;
auto lossless =3D op.get_value_or(gl); <em>// lossless deduced as long ra=
ther than int</em>
</pre>
<p>However, we did not find many practical use cases for this extension, so=
we do not propose is at this time.</p>
<h3><a name=3D'rationale.make_optional'>Function <code>make_optional</code>=
</a></h3>
<p>We also propose a helper function <code>make_optional</code>. Its semant=
ics is closer to that of <code>make_pair</code> or <code>make_tuple</code> =
than that of <code>make_shared</code>. You can use it in order for the type=
of the optional to be deduced:</p>
<pre>int i =3D 1;
auto oi =3D make_optional(i); <em>// decltype(oi) =3D=3D optional&=
lt;int></em>
</pre>
<p>This may occasionally be useful when you need to pick the right overload=
and not type the type of the optional by hand: </p>
<pre>void fun(optional<complex<double>>);
void fun(Current); <em>// complex is convertible to Curre=
nt</em>
complex<double> c{0.0, 0.1};
fun(c); <em>// ambiguous</em>
fun({c}); <em>// ambiguous</em>
fun(make_optional(c)); <em>// picks first overload</em>
</pre>
<p>This is not very useful in return statements, as long as the converting =
constructor from <code>T</code> is implicit, because you can always use the=
brace syntax:</p>
<pre>optional<complex<double>> findC()
{
complex<double> c{0.0, 0.1};
return {c};
}
</pre>
<p><code>make_shared</code>-like function does not appear to be useful at a=
ll: it is no different than manually creating a temporary optional object:<=
/p>
<pre><em>// not proposed</em>
fun( make_optional<Rational>(1, 2) );
fun( optional<Rational>{1, 2} ); <em>// same as above</em>
</pre>
<p>It would also not be a good alternative for tagged placement constructor=
, because using it would require type <code>T</code> to be <code>MoveConstr=
uctible</code>:</p>
<pre><em>// not proposed</em>
auto og =3D make_optional<Guard>("arg1"); <em>// ERROR: Guard is not =
MoveConstructible</em>
</pre>
<p>Such solution works for <code>shared_ptr</code> only because its copy co=
nstructor is shallow. One useful variant of <code>shared_ptr</code>-like <c=
ode>make_optional</code> would be a function that either creates an engaged=
or a disengaged optional based on some boolean condition:</p>
<pre><em>// not proposed</em>
return make_optional_if<Rational>(good(i) && not_bad(j), i, j=
);
<em>// same as:</em>
if (good(i) && not_bad(j)) {
return {i, j};
}
else {
return nullopt;
}
<em>// same as:</em>
optional<Rational> or =3D nullopt;
if (good(i) && not_bad(j)) or.emplace(i, j);
return or; <em>// move-construct on return</em>
</pre>
<p>Since this use case is rare, and the function call not that elegant, and=
a two-liner alternative exists, we do not propose it.</p>
<h3><a name=3D'rationale.conversion'>"Copy initialization forwarding"</a></=
h3>
<p>At some point the following goal was considered for <code>optional</code=
>; it is the property that could informally be called "copy initialization =
forwarding". It is somewhat similar to the one-argument version of perfect =
forwarding constructor; i.e., if a given initializer can be used to copy-in=
itialize objects of type <code>T</code>, it should also be possible to to u=
se it to copy-initialize objects of type <code>optional<T></code> wit=
h the same samantics as initializing object of type <code>T</code>. This go=
al cannot be achieved in 100% without severely compromising other design go=
als. For instance, we cannot guarantee the following: </p>
<pre>T x =3D {}; <em>// "{}" is the initializer; x is value-ini=
tialized</em>
optional<T> ox =3D {}; <em>// same initializer; contained value not =
initialized</em>
assert (x =3D=3D *ox); <em>// not guaranteed!</em>
</pre>
<p>Apart from this default initialization case, and a couple of others (coc=
ncerning initializer-list), "copy initialization forwarding" could be provi=
ded for <code>optional</code>.</p>
<p>Since <code>optional<T></code> can be thought of as an "almost <co=
de>T</code>", one could expect that if the following works:</p>
<pre>void fun(std::string s);
fun("text");
</pre>
<p>the following should also work:</p>
<pre>void gun(optional<std::string> s);
gun("text");
</pre>
<p>However, naively implementing a converting constructor would also enable=
a non-explicit converting constructor from any type <code>U</code> to type=
<code>optional<T></code> for any type <code>T</code>. This would tur=
n some types that are explicitly constructible into optional types that are=
implicitly constructible. Consider:
</p>
<pre>void explicit_conv( int * ptr ) {
unique_ptr<int> v =3D ptr; <em>// ILLEGAL</em>=20
}
void implicit_conv( int * ptr ) {
optional<unique_ptr<int>> v =3D ptr; <em>// LEGAL</em>
}</pre>
<p>In order to make the former example work on the one hand and to prevent =
the problem with the latter example on the other, we considered a solution =
that could be informally called a conditionally-explicit converting constru=
ctor. We could achieve this by specifying two constructor templates with id=
entical template and function parameters, one explicit and one non-explicit=
, and make them mutually exclusive by means of SFINAE:</p>
<pre>
template <class U>=20
<em>// enable_if: Constructible<T, U&&> && !Convert=
ible<U&&, T></em>
explicit optional<T>::optional(U&&);
=20
template <class U>=20
<em>// enable_if: Convertible<U&&, T></em>
optional<T>::optional(U&&);
</pre>
<p>Such concept-like behaviour as used above can be implemented in C++ with=
type traits and <code>enable_if</code>. It was noted, however, that the ex=
istence of such converting constructor would cause unexpected ambiguities i=
n overload resolution. Consider the following scenario. We start from a wor=
king program:</p>
<pre><em>// library</em>
void fun(string const& s);
<em>// usage</em>
fun("hello");
</pre>
<p>At some point we decide to add a second overload that accepts an optiona=
l string:</p>
<pre><em>// library</em>
void fun(string const& s);
void fun(optional<string> const& s); <em>// new overload</em>
<em>// usage</em>
fun("hello"); <em>// ERROR: ambiguity </em>
</pre>
<p>Does it make sense to add an overload for optional rather than substitut=
ing it for the original? It might be useful for performance reasons: if you=
already have <code>string</code> it is cheaper to bind it directly to <cod=
e>string const&</code> than to create a temporary optional object and t=
rigger the copy constructor of <code>string</code>:</p>
<pre><em>// library</em>
void fun(optional<string> const& s); <em>// only this fun</em>
<em>// usage</em>
string s =3D "hello";
fun(s); <em>// copy ctor invoked!</em>
</pre>
<p>This example shows how an implicit conversion can cause an inadvertent a=
nd unexpected (potentially expensive) copy constructor. For this reason we =
do not propose a converting constructor from arbitrary type <code>U</code>.=
(Although we do propose a converting constructor from <code>T</code>.)</p>
<h3><a name=3D'rationale.initializer_list'>Handling <code>initializer_list<=
/code></a></h3>
<p>Another feature worth considering is a "sequence constructor" (one that =
takes <code>initializer_list</code> as its argument). It would be enabled (=
in <code>enable_if</code> sense) only for these <code>T</code>s that themse=
lf provide a sequence constructor. This would be usefult to fully support t=
wo features we already mentioned above (but chose not to propose).</p>
<p>First, our goal of "copy initialization forwarding" for <code>optional</=
code> also needs to address the following usages of <code>initializer_list<=
/code>:
</p>
<pre>vector<int> v =3D {1, 2, 4, 8};
optional<vector<int>> ov =3D {1, 2, 4, 8};
assert (v =3D=3D *ov);
</pre>
<p>This is not only a syntactical convenience. It also avoids subtle bugs. =
When perfect forwarding constructor is implemented naively with one variadi=
c constructor, optional vector initialization may render surprising result:=
</p>
<pre>optional<vector<int>> ov =3D {3, 1};
assert (*ov =3D=3D vector{3, 1}); // FAILS!
assert (*ov =3D=3D vector{1, 1, 1}); // TRUE!
</pre>
<p>However this sequence constructor feature is incompatible with another o=
ne: default constructor creating a disengaged optional. This is because, as=
outlined in the former example, initializer <code>{}</code>, that looks li=
ke 0-element list, is in fact interpretted as the request for value-initial=
ization (default constructor call). This may hit programmers that use initi=
alizer list in "generic" context:</p>
<pre>
template <class ...A> <em>// enable_if: every A is int</em>
void fwd(const A&&... a)
{
optional<vector<int>> o =3D {a...};
assert (bool(o)); <em>// not true for empty a</em>
}
</pre>
<p>If this feature were to be added, we would need to provide an assignment=
from initializer list and variadic 'emplacement' constructor with the firs=
t forwarded argument being <code>initializer_list</code>:</p>
<pre>ov =3D {1, 2, 4, 8};
allocator<int> a;
optional<vector<int>> ou { emplace, {1, 2, 4, 8}, a };
assert (ou =3D=3D ov);
</pre>
<p>Since we are not proposing neither perfect forwarding constructor, nor t=
he "copy initialization forwarding", we are also not proposing the sequence=
constructor. However, in this proposal, the following constructs work:</p>
<pre>optional<vector<int>> ov{emplace, {3, 1}};
assert (*ov =3D=3D vector{3, 1});
ov.emplace({3, 1});
assert (*ov =3D=3D vector{3, 1});
</pre>
<h3><a name=3D'rationale.optional_optional'><code>optional<optional<T=
>></code></a></h3>
<p>The necessity to create a "double" optional explicitly does not occur of=
ten. Such type may appear though in generic contexts where we create <code>=
optional<V></code> and <code>V</code> only happens to be <code>option=
al<T></code>. Some special behavior to be observed in this situation =
is the following. When copy-initializing with <code>nullopt</code>, the "ou=
termost" optional is initialized to disengaged state. Thus, changing functi=
on argument from <code>optional<T></code> to <code>optional<option=
al<T>></code> will silently break the code in places where the arg=
ument passed to function happens to be of type <code>nullopt_t</code>:</p>
<pre><em>// before change</em>
void fun(optional<T> v) {
process(v);
}
fun(nullopt); <em>// process() called</em>
<em>// after change</em>
void fun(optional<optional<T>> v) {
if (v) process(*v);
else doSthElse();
}
fun(nullopt); <em>// process() not called!</em>
</pre>
<p>This issue would not arise if <code>nullopt</code> were <code>T</code>-s=
pecific:</p>=20
<pre>
fun(optional<T>::nullopt); <em>// process() called</em>
fun(optional<optional<T>>::nullopt); <em>// process() not call=
ed</em>
</pre>
<p>Since <code>T</code>-dependent <code>nullopt</code> is not proposed, in =
order to creae an engaged optional containing a disengaged optional, one ne=
eds to use one of the following constructs:</p>
<pre>
optional<optional<T>> ot {emplace};
optional<optional<T>> ou {emplace, nullopt};
optional<optional<T>> ov {optional<T>{}};
</pre>
<p>Also note that <code>make_optional</code> will create a "double" optiona=
l when called with optional argument:</p>
<pre>optional<int> oi;
auto ooi =3D make_optional(oi);
static_assert( is_same<optional<optional<int>>, decltype(ooi=
)>::value, "");
</pre>
<h3><a name=3D'rationale.conditional.init'>Conditional initialization to en=
gaged state</a></h3>
<p>It has been suggested, and in fact implemented in Boost.Optional, that <=
code>optional</code> shall have an another constructor with the first argum=
ent of type <code>bool</code>. The value of this argument should be used to=
determine whether the object should be disengaged, or engaged using the re=
maining arguments. If we wanted to provide it in <code>optional</code> and =
disampiguate the situations where the contained value is also initialized w=
ith the first argument of type <code>bool</code>, it could be easily done b=
y providing a yet another tag (similar to <code>emplace_t</code>):</p>
<pre>bool doIt =3D false;
tr2::optional<string> opstr1{ tr2::only_if(doIt), 3, 'x' };=20
<em>// disengaged</em>
doIt =3D true;
tr2::optional<string> opstr2{ tr2::only_if(doIt), 3, 'x' };=20
<em>// contained value is "xxx"</em>
</pre>
<p>However, we do not see a practical use case for this usage. Undoubtadly,=
it spares you from an explicit if-statement and a two-phase initialization=
of the optional object, but then it appears obvious that at some time you =
need to check the value of <code>doIt</code> anyway, because you do not eve=
n know the state of the optional object. It is at that time that you may as=
well decide to initialize the contained value:</p>
<pre>optional<string> process( bool doIt )
{
fun1(doIt);
optional<string> optstr;
=20
if (doIt) { <em> // we ned an if to conditionally call fun2()</em>
fun2();
optstr.emplace(3, 'x');
}
=20
return optstr;
}</pre>
<p>Also, even if you create optional as disengaged in the conditional const=
ructor, you still have to compute the values of the arguments that you coul=
d potentially use to initialize the contained value, so the two-phase initi=
alization may look more attractive.
</p>
<p>For these reasons we do not propose such conditional constructor at this=
point. However, there appears to be no difficulty in adding it if we find =
convincing use cases.</p>
<h2><a name=3D'wording'>Proposed wording</a></h2>
<p>Add new header in Table 14 (C++ library headers).</p>
<blockquote class=3D"std">
<table>
<caption>Table 14 — C++ library headers</caption>
<tbody>
<tr>
<td><code><algorithm></code></td> <td><code><fstream></code></t=
d> <td><code><list></code></td> <td><code><ratio></code></td> <=
td><code><tuple></code></td>
</tr>
<tr>
<td><code><array></code></td> <td><code><functional></code></td=
> <td><code><locale></code></td> <td><code><regex></code></td> =
<td><code><typeindex></code></td>
</tr>
<tr>
<td><code><atomic></code></td> <td><code><future></code></td> <=
td><code><map></code></td> <td><code><set></code></td> <td><cod=
e><typeinfo></code></td>
</tr>
<tr>
<td><code><bitset></code></td> <td><code><initializer_list></co=
de></td> <td><code><memory></code></td> <td><code><sstream></co=
de></td> <td><code><type_traits></code></td>
</tr>
<tr>
<td><code><chrono></code></td> <td><code><iomanip></code></td> =
<td><code><mutex></code></td> <td><code><stack></code></td> <td=
><code><unordered_map></code></td>
</tr>
<tr>
<td><code><codecvt></code></td> <td><code><ios></code></td> <td=
><code><new></code></td> <td><code><stdexcept></code></td> <td>=
<code><unordered_set></code></td>
</tr>
<tr>
<td><code><complex></code></td> <td><code><iosfwd></code></td> =
<td><code><numeric></code></td> <td><code><streambuf></code></t=
d> <td><code><utility></code></td>
</tr>
<tr>
<td><code><condition_variable></code></td> <td><code><iostream>=
</code></td> <td><ins><code><optional></code></ins></td> <td><code>&l=
t;string></code></td> <td><code><valarray></code></td>
</tr>
<tr>
<td><code><dequeue></code></td> <td><code><istream></code></td>=
<td><code><ostream></code></td> <td><code><strstream></code></=
td> <td><code><vector></code></td>
</tr>
<tr>
<td><code><exception></code></td> <td><code><iterator></code></=
td> <td><code><queue></code></td> <td><code><system_error></cod=
e></td> <td><code> </code></td>
</tr>
<tr>
<td><code><forward_list></code></td> <td><code><limits></code><=
/td> <td><code><random></code></td> <td><code><thread></code></=
td> <td><code> </code></td>
</tr>
</tbody>
</table>
</blockquote>
<p>After chapter 20.4 Tuples [tuple], insert a new paragraph. (Chapter [tem=
plate.bitset] (Class template <code>bitset</code>) becomes 20.6.)</p>
=20
<blockquote class=3D"std">=20
<h3><a name=3D"optional">20.5 Optional objects <span style=3D"float:right">=
[optional]</span></a></h3>
<h4><a name=3D"optional.general">20.5.1 In general <span style=3D"float:rig=
ht">[optional.general]</span></a></h4>
<p>This subclause describes class template <code>optional</code> that repre=
sents <em>optional objects</em>. An <em>optional object for object types</e=
m> is an object that contains the storage for another object and manages th=
e lifetime of this contained object. The contained object may be initialize=
d after the optional object has been initialized, and may be destroyed befo=
re the optional object has been destroyed. The initialization state of the =
contained object is tracked by the optional object. An <em>optional object =
for lvalue reference types</em> is an object capable of storing the address=
of another object. The address stored by the optional object can be canged=
or set to a value that does not represent a valid address. </p>
=20
<h4><a name=3D"optional.synop">20.5.2 Header <kbd><optional></kbd> sy=
nopsis <span style=3D"float:right">[optional.synop]</span></a></h4>
<pre>
namespace std {
namespace experimental {
// <em><a href=3D"#optional.object">20.5.4</a>, <code>optional</code> for=
object types</em>
template <class T> class optional;
// <em><a href=3D"#optional.inplace">20.5.5</a>, In-place construction</e=
m>
struct emplace_t{};
constexpr emplace_t emplace{};
// <em><a href=3D"#optional.nullopt">20.5.6</a>, Disengaged state indicat=
or</em>
struct nullopt_t{<em>see below</em>};
constexpr nullopt_t nullopt(<em>unspecified</em>);
// <em><a href=3D"#optional.relops">20.5.7</a>, Relational operators</em>
template <class T>
constexpr bool operator=3D=3D(const optional<T>&, const optio=
nal<T>&);
template <class T>
constexpr bool operator!=3D(const optional<T>&, const optiona=
l<T>&);
template <class T>
constexpr bool operator<(const optional<T>&, const optiona=
l<T>&);
template <class T>
constexpr bool operator>(const optional<T>&, const optiona=
l<T>&);
template <class T>
constexpr bool operator<=3D(const optional<T>&, const opti=
onal<T>&);
template <class T>
constexpr bool operator>=3D(const optional<T>&, const opti=
onal<T>&);
// <em><a href=3D"#optional.nullops">20.5.8</a>, Comparison with <code>nu=
llopt</code></em>
template <class T> constexpr bool operator=3D=3D(const optional<=
T>&, nullopt_t) noexcept;
template <class T> constexpr bool operator=3D=3D(nullopt_t, const o=
ptional<T>&) noexcept;
template <class T> constexpr bool operator!=3D(const optional<T&=
gt;&, nullopt_t) noexcept;
template <class T> constexpr bool operator!=3D(nullopt_t, const opt=
ional<T>&) noexcept;
template <class T> constexpr bool operator<(const optional<T&=
gt;&, nullopt_t) noexcept;
template <class T> constexpr bool operator<(nullopt_t, const opt=
ional<T>&) noexcept;
template <class T> constexpr bool operator<=3D(const optional<=
;T>&, nullopt_t) noexcept;
template <class T> constexpr bool operator<=3D(nullopt_t, const =
optional<T>&) noexcept;
template <class T> constexpr bool operator>(const optional<T&=
gt;&, nullopt_t) noexcept;
template <class T> constexpr bool operator>(nullopt_t, const opt=
ional<T>&) noexcept;
template <class T> constexpr bool operator>=3D(const optional<=
;T>&, nullopt_t) noexcept;
template <class T> constexpr bool operator>=3D(nullopt_t, const =
optional<T>&) noexcept;
// <em><a href=3D"#optional.specalg">20.5.9</a>, Poisoned comparison with=
T</em>
template <class T> bool operator=3D=3D(const optional<T>&=
, const T&) noexcept;
template <class T> bool operator=3D=3D(const T&, const optional=
<T>&) noexcept;
template <class T> bool operator!=3D(const optional<T>&, =
const T&) noexcept;
template <class T> bool operator!=3D(const T&, const optional&l=
t;T>&) noexcept;
template <class T> bool operator<(const optional<T>&, =
const T&) noexcept;
template <class T> bool operator<(const T&, const optional&l=
t;T>&) noexcept;
template <class T> bool operator<=3D(const optional<T>&=
;, const T&) noexcept;
template <class T> bool operator<=3D(const T&, const optiona=
l<T>&) noexcept;
template <class T> bool operator>(const optional<T>&, =
const T&) noexcept;
template <class T> bool operator>(const T&, const optional&l=
t;T>&) noexcept;
template <class T> bool operator>=3D(const optional<T>&=
;, const T&) noexcept;
template <class T> bool operator>=3D(const T&, const optiona=
l<T>&) noexcept;
// <em><a href=3D"#optional.specalg">20.5.10</a>, Specialized algorithms<=
/em>
template <class T> void swap(optional<T>&, optional<T&=
gt;&) noexcept(<em>see below</em>);<!--
template <class T, class V>=20
constexpr typename decay<T>::type get_value_or(const optional<=
T>&, V&&);
template <class T, class V>=20
constexpr typename decay<T>::type get_value_or(optional<T>&=
amp;&, V&&);-->
template <class T> constexpr optional<<em>see below</em>> mak=
e_optional(T&&);
// <em><a href=3D"#optional.hash">20.5.11</a>, hash support</em>
template <class T> struct hash;
template <class T> struct hash<optional<T>>;
} <em>// namespace experimental</em>
} <em>// namespace std</em>
</pre>
=20
<p>A program that necessitates the instantiation of template <code>option=
al</code> for an lvalue reference or rvalue reference type, or for types <c=
ode>emplace_t</code> or <code>nullopt_t</code>, or a possibli cv-qualified =
reference to types <code>emplace_t</code> or <code>nullopt_t</code> is ill-=
formed.</p>
<h4><a name=3D"optional.defs">20.5.3 Definitions <span style=3D"float:right=
">[optional.defs]</span></a></h4>
=20
<p>An instance of <code>optional<T></code> is said to be <em>diseng=
aged</em> if it has been default constructed, constructed or assigned with =
a value of type <code>nullopt_t</code>, constructed or assigned with a dise=
ngaged optional object of type <code>optional<U></code>, with <code>U=
</code> being equal or not to <code>T</code>.
</p>
<p>An instance of <code>optional<T></code> is said to be <em>engage=
d</em> if it has=20
been modified with member function <code>emplace</code>, constructed with=
a value of type <code>U</code>, assigned a value of type <code>U</code>, c=
opy-constructed from or assigned with an engaged optional object of type <c=
ode>optional<U></code>, where <code>U</code> is same as or convertibl=
e to <code>T</code>.=20
</p>
<p>Being engaged or disengaged is part of the state optional object's sta=
te.</p>
=20
<!-- <p>An <em>optional object for object type</em> is an instance of cla=
ss <code>optional<T></code> where <code>T</code> is of object type (3=
..9).</p>
=20
<p>An <em>optional object for lvalue reference type</em> is an instance o=
f class <code>optional<T></code> where <code>T</code> is of lvalue re=
ference type.</p>-->
=20
=20
<p>In several places in this Clause the expression <code>OnlyExplicitlyC=
onstructible(T, V)</code> is used. All such cases mean the evaluation of th=
e expression:</p>
=20
<pre>std::is_constructible<T, V>::value && !std::is_conver=
tible<V, T>::value</pre>
=20
=20
<h4><a name=3D"optional.object">20.5.4 <code>optional</code> for object typ=
es <span style=3D"float:right">[optional.object]</span></a></h4>
=20
<pre>
namespace std {
namespace experimental {
template <class T>
class optional
{
public:
typedef T value_type;
// <em><a href=3D"#optional.object.ctor">20.5.4.1</a>, constructors</em=
>
constexpr optional() noexcept;
constexpr optional(nullopt_t) noexcept;
optional(const optional&);
optional(optional&&) noexcept(<em>see below</em>);
constexpr optional(const T&);
constexpr optional(T&&);<!--
template <class U> explicit optional(U&&);
template <class U> optional(U&&);
template <class U> explicit optional(const optional<U>&=
);
template <class U> optional(const optional<U>&);
template <class U> explicit optional(optional<U>&&)=
;
template <class U> optional(optional<U>&&);
template <class U> explicit optional(initializer_list<U>);
template <class U> optional(initializer_list<U>);-->
template <class... Args> constexpr explicit optional(emplace_t, A=
rgs&&...);
template <class U, class... Args>
constexpr explicit optional(emplace_t, initializer_list<U>, Arg=
s&&...);
// <em><a href=3D"#optional.object.dtor">20.5.4.2</a>, destructor</em>
~optional();
// <em><a href=3D"#optional.object.assign">20.5.4.3</a>, assignment</em=
>
optional& operator=3D(nullopt_t) noexcept;<!--
optional& operator=3D(const T&);
optional& operator=3D(T&&);-->
optional& operator=3D(const optional&);
optional& operator=3D(optional&&) noexcept(<em>see below</e=
m>);
template <class U> optional& operator=3D(U&&);<!--
template <class U> optional& operator=3D(const optional<U&=
gt;&);
template <class U> optional& operator=3D(optional<U>&am=
p;&);
template <class U> optional& operator=3D(initializer_list<=
U>);-->
template <class... Args> optional& emplace(Args&&...)=
;
template <class U, class... Args>
optional& emplace(initializer_list<U>, Args&&...);
// <em><a href=3D"#optional.object.swap">20.5.4.4</a>, swap</em>
void swap(optional&) noexcept(<em>see below</em>);
// <em><a href=3D"#optional.object.observe">20.5.4.5</a>, observers</em=
>
constexpr T const* operator ->() const;
T* operator ->();
constexpr T const& operator *() const;
T& operator *();
constexpr explicit operator bool() const noexcept;
template <class U> constexpr T get_value_or(U&&) const&am=
p;;
template <class U> T get_value_or(U&&) &&;
<var>private:</var>
<var>bool init; //</var> <em>exposition only</em>
<var>T* val; //</var> <em>exposition only</em>
};
} // <em>namespace experimental</em>
} // <em>namespace std</em></pre>
<p>Engaged instances of <code>optional<T></code> where <code>T</code>=
is of object type shall contain a value of type <code>T</code> within its =
own storage. This value is referred to as the <em>contained value</em> of t=
he optional object. Implementations are not permitted to use additional sto=
rage, such as dynamic memory, to allocate its contained value. The contain=
ed value shall be allocated in a region of the <code>optional<T></cod=
e> storage suitably aligned for the type <code>T</code>. Initializing the c=
ontained value shall put the optional object into engaged state. Destroying=
the contained value shall put the optional object into disengaged state.</=
p>
<p>Members <code><var>init</var></code> and <code><var>val</var></code> are=
provided for exposition only. Implementations need not provide those membe=
rs. <code><var>init</var></code> indicates whether the <code>optional</code=
> object's contained value has been initialized (and not yet destroyed); <c=
ode><var>val</var></code> points to (a possibly uninitialized) contained va=
lue.
</p>
<p><code>T</code> shall be an object type and shall satisfy the requirement=
s of <code>Destructible</code> (Table 24).</p>
<p>Throughout this subclause term <em>direct-non-list-initialization</em> i=
s used to denote a direct-initialization that is not list-initialization.</=
p>
<h5><a name=3D"optional.object.ctor">20.5.4.1 Constructors <span style=3D"f=
loat:right">[optional.object.ctor]</span></a></h5>
=20
<p class=3D"function">
<code>constexpr optional<T>::optional() noexcept;</code><br>
<code>constexpr optional<T>::optional(nullopt_t) noexcept;</code>
</p>
<dl class=3D"attribute">
<dt>Effects:</dt> <dd><p>Constructs a disengaged <code>optional</code> ob=
ject.</p></dd>
<dt>Postconditions:</dt> <dd><p><code>bool(*this) =3D=3D false</code>.</p=
></dd>
<dt>Remarks:</dt> <dd><p>No <code>T</code> object referenced is initializ=
ed. For every object type <code>T</code> these constructors shall be <code>=
constexpr</code> constructors (7.1.5).</p></dd>
</dl>
=20
<p class=3D"function">
<code>optional<T>::optional(const optional<T>& <var>rhs</=
var>);</code>
</p>
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>is_copy_constructible<T>::value</=
code> is <code>true</code>.</p></dd>
<dt>Effects:</dt> <dd><p>Constructs an <code>optional</code> object. If=
<code>bool(<var>rhs</var>) =3D=3D true</code> initializes the contained va=
lue as if direct-non-list-initializing an object of type <code>T</code> wit=
h the expression <code>*<var>rhs</var></code>.</p></dd>
<dt>Postconditions:</dt> <dd><p>If <code>bool(<var>rhs</var>) =3D=3D fa=
lse</code> then <code>bool(*this) =3D=3D false</code>; otherwise <code>bool=
(*this) =3D=3D true</code> and <code>*(*this)</code> is equivalent to <code=
>*<var>rhs</var></code>.</p></dd>
<dt>Throws:</dt> <dd><p>Whatever the execution of <code>T</code>'s cons=
tructor selected for the copy throws.</p></dd>
</dl>
=20
=20
<p class=3D"function">
<code>optional<T>::optional(optional<T> && <var>rhs</=
var>) noexcept(<em>see below</em>);</code>
</p>
=20
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>is_move_constructible<T>::value</=
code> is <code>true</code>.</p></dd>
<dt>Effects:</dt> <dd><p>Constructs an <code>optional</code> object. If=
<code>bool(<var>rhs</var>) =3D=3D true</code> initializes the contained va=
lue as if direct-non-list-initializing an object of type <code>T</code> wit=
h the expression <code>std::move(*<var>rhs</var>)</code>.</p></dd>
<dt>Postconditions:</dt> <dd><p>If initially <code>bool(<var>rhs</var>)=
=3D=3D false</code> then <code>bool(*this) =3D=3D false</code> and <code>b=
ool(<var>rhs</var>) =3D=3D false</code>; otherwise <code>bool(*this) =3D=3D=
true</code> and <code>*(*this)</code> is equivalent to the value <code>*<v=
ar>rhs</var></code> had initially and <code>bool(<var>rhs</var>) =3D=3D tru=
e</code>.</p></dd>
<dt>Throws:</dt> <dd><p>Whatever the execution of <code>T</code>'s cons=
tructor selected for the copy throws.</p></dd>
<dt>Remarks:</dt> <dd><p>The expression inside <code>noexcept</code> is=
equivalent to:</p> <pre>is_nothrow_move_constructible<T>::value</pre=
></dd>
</dl>
=20
<p class=3D"function">
<code>optional<T>::optional(const T& <var>v</var>);</code>
</p>
=20
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>is_copy_constructible<T>::value</=
code> is <code>true</code>.</p></dd>
<dt>Effects:</dt> <dd><p>Constructs an <code>optional</code> object by =
direct-non-list-initializing the contained value with the expression <code>=
<var>v</var></code>.</p></dd>
<dt>Postconditions:</dt> <dd><p><code>bool(*this) =3D=3D true</code> an=
d <code>*(*this)</code> is equivalent to <code><var>v</var></code>.</p></dd=
>
<dt>Throws:</dt> <dd><p>Whatever the execution of <code>T</code>'s cons=
tructor selected for the copy throws.</p></dd>
<dt>Remarks:</dt> <dd><p>If <code>T</code>'s constructor selected for t=
he copy is a <code>constexpr</code> constructor, this constructor shall be =
a <code>constexpr</code> constructor.</p></dd>
</dl>
=20
=20
<p class=3D"function">
<code>optional<T>::optional(T&& <var>v</var>);</code>
</p>
=20
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>is_move_constructible<T>::value</=
code> is <code>true</code>.</p></dd>
<dt>Effects:</dt> <dd><p>Constructs an <code>optional</code> object by =
direct-non-list-initializing the contained value with the expression <code>=
std::move(<var>v</var>)</code>.</p></dd>
<dt>Postconditions:</dt> <dd><p><code>bool(*this) =3D=3D true</code> an=
d <code>*(*this)</code> is equivalent to value that <code><var>v</var></cod=
e> had initially.</p></dd>
<dt>Throws:</dt> <dd><p>Whatever the execution of <code>T</code>'s cons=
tructor selected for the move throws.</p></dd>
<dt>Remarks:</dt> <dd><p>If <code>T</code>'s constructor selected for t=
he move is a <code>constexpr</code> constructor, this constructor shall be =
a <code>constexpr</code> constructor.</p></dd>
</dl>
=20
<!-- =20
<p class=3D"function">
<code>template <class U> explicit optional<T>::optional(U&=
;& <var>v</var>);<br>template <class U> optional<T>::option=
al(U&& <var>v</var>);</code>
</p>
=20
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>is_constructible<T, U&&>:=
:value</code> is true.</p></dd>
<dt>Effects:</dt> <dd><p>Constructs an engaged <code>optional</code> ob=
ject; initializes the contained value as if constructing an object of type =
<code>T</code> with argument <code>std::forward<U>(<var>v</var>)</cod=
e>.</p></dd>
<dt>Postconditions:</dt> <dd><p><code>bool(*this) =3D=3D true</code> an=
d <code>*(*this)</code> is equivalent to <code><var>v</var></code> if conve=
rted to <code>T</code>.</p></dd>
<dt>Throws:</dt> <dd><p>Whatever the execution of <code>T</code>'s cons=
tructor selected for the initialization throws.</p></dd>
<dt>Remarks:</dt> <dd><p>The first function shall not participate in ov=
erload resolution unless <code>OnlyExplicitlyConstructible(T, U&&)<=
/code> is <code>true</code>. The second function shall not participate in t=
he overload resolution unless <code>is_convertible<U&&, T>::v=
alue</code> is <code>true</code>. The expression inside <code>noexcept</cod=
e> is equivalent to:</p> <pre>noexcept(T(std::declval<U&&>())=
)</pre></dd>
</dl>
=20
=20
<p class=3D"function">
<code>template <class U> explicit optional<T>::optional(const=
optional<U>& <var>rhs</var>);<br>template <class U> optio=
nal<T>::optional(const optional<U>& <var>rhs</var>);</code>
</p>
=20
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>is_constructible<T, const U&>=
::value</code> is <code>true</code>.</p></dd>
<dt>Effects:</dt> <dd><p>Constructs an <code>optional</code> object. If=
<code>bool(<var>rhs</var>) =3D=3D true</code> initializes the contained va=
lue as if constructing an object of type <code>T</code> with argument <code=
>*<var>rhs</var></code></p></dd>
<dt>Postconditions:</dt> <dd><p>If <code>bool(<var>rhs</var>) =3D=3D fa=
lse</code> then <code>bool(*this) =3D=3D false</code>; otherwise <code>bool=
(*this) =3D=3D true</code> and <code>*(*this)</code> is equivalent to <code=
>*<var>rhs</var></code> if converted to <code>T</code>.</p></dd>
<dt>Throws:</dt> <dd><p>Whatever the execution of <code>T</code>'s cons=
tructor selected for the initialization throws.</p></dd>
<dt>Remarks:</dt> <dd><p>The first function shall not participate in ov=
erload resolution unless <code>OnlyExplicitlyConstructible(T, const U&)=
</code> is <code>true</code>. The second function shall not participate in =
the overload resolution unless <code>is_convertible<const U&, T>:=
:value</code> is <code>true</code>.</dd>
</dl>
=20
=20
<p class=3D"function">
<code>template <class U> explicit optional<T>::optional(optio=
nal<U>&& <var>rhs</var>);<br>template <class U> option=
al<T>::optional(optional<U>&& <var>rhs</var>);</code>
</p>
=20
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>is_constructible<T, U&&>:=
:value</code> is <code>true</code>.</p></dd>
<dt>Effects:</dt> <dd><p>Constructs an <code>optional</code> object. If=
<code>bool(<var>rhs</var>) =3D=3D true</code> initializes the contained va=
lue as if constructing an object of type <code>T</code> with argument <code=
>std::move(*<var>rhs</var>)</code></p></dd>
<dt>Throws:</dt> <dd><p>Whatever the execution of <code>T</code>'s cons=
tructor selected for the initialization throws.</p></dd>
<dt>Remarks:</dt> <dd><p>The first function shall not participate in ov=
erload resolution unless <code>OnlyExplicitlyConstructible(T, U&&)<=
/code> is <code>true</code>. The second function shall not participate in t=
he overload resolution unless <code>is_convertible<U&&, T>::v=
alue</code> is <code>true</code>.</dd>
</dl>
=20
<p class=3D"function">
<code>template <class U> explicit optional<T>::optional(initi=
alizer_list<U> <var>il</var>);<br>template <class U> optional&=
lt;T>::optional(initializer_list<U><var>il</var>);</code>
</p>
=20
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>is_constructible<T, initializer_list=
<U>>::value</code> is <code>true</code>.</p></dd>
<dt>Effects:</dt> <dd><p>Constructs an <code>optional</code> object. If=
<code>bool(<var>rhs</var>) =3D=3D true</code> initializes the contained va=
lue as if constructing an object of type <code>T</code> with argument <code=
><var>il</var></code></p></dd>
<dt>Throws:</dt> <dd><p>Whatever the execution of <code>T</code>'s cons=
tructor selected for the initialization throws.</p></dd>
<dt>Remarks:</dt> <dd><p>The first function shall not participate in ov=
erload resolution unless <code>OnlyExplicitlyConstructible(T, initializer_l=
ist<U>)</code> is <code>true</code>. The second function shall not pa=
rticipate in the overload resolution unless <code>is_convertible<initial=
izer_list<U>, T>::value</code> is <code>true</code>.</dd>
</dl>
-->
=20
<p class=3D"function">
<code>template <class... Args> constexpr explicit optional(emplace_=
t, Args&&... <var>args</var>);</code>
</p>
=20
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>is_constructible<T, Args&&..=
..>::value</code> is <code>true</code>.</p></dd>
<dt>Effects:</dt> <dd><p>Constructs an engaged <code>optional</code> ob=
ject. Initializes the contained value as if constructing an object of type =
T with the arguments <code>std::forward<Args>(<var>args</var>)...</co=
de>.</p></dd>
<dt>Postconditions:</dt> <dd><p><code>bool(*this) =3D=3D true</code>.</=
p></dd>
<dt>Throws:</dt> <dd><p>Whatever the execution of <code>T</code>'s cons=
tructor selected for the initialization throws.</p></dd>
<dt>Remarks:</dt> <dd><p>If <code>T</code>'s constructor selected for t=
he initialization is a <code>constexpr</code> constructor, this constructor=
shall be a <code>constexpr</code> constructor.</p></dd>
</dl>
<p class=3D"function">
<code>template <class U, class... Args><br>
explicit optional(emplace_t, initializer_list<U> <var>il</var>, Arg=
s&&... <var>args</var>);</code>
</p>
=20
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>is_constructible<T, initializer_list=
<U>, Args&&...>::value</code> is <code>true</code>.</p></d=
d>
<dt>Effects:</dt> <dd><p>Constructs an engaged <code>optional</code> ob=
ject. Initializes the contained value as if constructing an object of type =
T with the arguments <code><var>il</var>, std::forward<Args>(<var>arg=
s</var>)...</code>.</p></dd>
<dt>Postconditions:</dt> <dd><p><code>bool(*this) =3D=3D true</code>.</=
p></dd>
<dt>Throws:</dt> <dd><p>Whatever the execution of <code>T</code>'s cons=
tructor selected for the initialization throws.</p></dd>
<dt>Remarks:</dt> <dd><p>The function shall not participate in overload=
resolution unless <code>is_constructible<T, initializer_list<U>, =
Args&&...>::value</code> is <code>true</code>.</p></dd>
<dt>Remarks:</dt> <dd><p>If <code>T</code>'s constructor selected for t=
he initialization is a <code>constexpr</code> constructor, this constructor=
shall be a <code>constexpr</code> constructor.</p></dd>
</dl>
<h5><a name=3D"optional.object.dtor">20.5.4.2 Destructor <span style=3D"fl=
oat:right">[optional.object.dtor]</span></a></h5>
=20
<p class=3D"function">=20
<code>optional<T>::~optional();</code>
</p>
=20
<dl class=3D"attribute">
<dt>Effects:</dt> <dd><p>If <code>is_trivially_destructible<T>::v=
alue !=3D true</code> and <code>bool(*this) =3D=3D true</code>, calls <code=
><var>val</var>->T::~T()</code>.</p></dd>
<dt>Remarks:</dt> <dd><p>If <code>is_trivially_destructible<T>::v=
alue =3D=3D true</code> then this destructor shall be a trivial destructor.=
</p></dd>
</dl>
=20
=20
=20
<h5><a name=3D"optional.object.assign">20.5.4.3 Assignment <span style=3D"=
float:right">[optional.object.assign]</span></a></h5>
=20
=20
<p class=3D"function">
<code>optional<T>& optional<T>::operator=3D(nullopt_t) no=
except;</code>
</p>
<dl class=3D"attribute">
<dt>Effects:</dt> <dd><p>If <code>bool(*this) =3D=3D true</code> calls =
<code><var>val</var>->T::~T()</code> to destroy the <em>contained value<=
/em>; otherwise no effect.</p></dd>
<dt>Returns:</dt> <dd><p><code>*this</code></p></dd>
<dt>Postconditions:</dt> <dd><p><code>bool(*this) =3D=3D false</code>.<=
/p></dd>
</dl>
=20
<!--
<p class=3D"function">
<code>optional<T>& optional<T>::operator=3D(const T& =
<var>rhs</var>);</code>
</p>
=20
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>is_copy_constructible<T>::value</=
code> is <code>true</code> and <code>is_copy_assignable<T>::value</co=
de> is <code>true</code>.</p></dd>
<dt>Effects:</dt> <dd><p>If <code>bool(*this) =3D=3D true</code> assign=
s <code><var>rhs</var></code> to the contained value; otherwise constructs =
the contained value as if direct-non-list-initializing object of type <code=
>T</code> with <code><var>rhs</var></code>.</p></dd>
<dt>Returns:</dt> <dd><p><code>*this</code></p></dd>
<dt>Postconditions:</dt> <dd><p><code>bool(*this) =3D=3D true</code> an=
d <code>*(*this)</code> is equivalent to <code><var>rhs</var></code>.</p></=
dd>
<dt>Exception Safety:</dt> <dd><p>If any exception is thrown value of <=
code><var>init</var></code> remains unchanged. If an exception is thrown du=
ring the call to <code>T</code>'s copy constructor, no effect. If an except=
ion is thrown during the call to <code>T</code>'s copy assignment, the stat=
e of its contained value is as defined by the exception safety guarantee of=
<code>T</code>'s copy assignment.</p></dd>
</dl>
=20
<p class=3D"function">
<code>optional<T>& optional<T>::operator=3D(T&& <=
var>rhs</var>);</code>
</p>
=20
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>is_move_constructible<T>::value</=
code> is <code>true</code> and <code>is_move_assignable<T>::value</co=
de> is <code>true</code>.</p></dd>
<dt>Effects:</dt> <dd><p>If <code>bool(*this) =3D=3D true</code> assign=
s <code>std::move(<var>rhs</var>)</code> to the contained value; otherwise =
constructs the contained value as if direct-non-list-initializing object of=
type <code>T</code> with <code>std::move(<var>rhs</var>)</code>.</p></dd>
<dt>Returns:</dt> <dd><p><code>*this</code></p></dd>
<dt>Postconditions:</dt> <dd><p><code>bool(*this) =3D=3D true</code> an=
d <code>*(*this)</code> is equivalent to the value that <code><var>rhs</var=
></code> had initially.</p></dd>
<dt>Exception Safety:</dt> <dd><p>If any exception is thrown value of <=
code><var>init</var></code> remains unchanged. If an exception is thrown du=
ring the call to <code>T</code>'s move constructor, the state of <code><var=
>rhs</var></code> is determined by exception safety guarantee of <code>T</c=
ode>'s move constructor. If an exception is thrown during the call to <code=
>T</code>'s move assignment, the state of <code><var>*val</var></code> and =
<code><var>rhs</var></code> is determined by exception safety guarantee of =
<code>T</code>'s move assignment.</p></dd>
</dl>
=20
-->
<p class=3D"function">
<code>optional<T>& optional<T>::operator=3D(const optiona=
l<T>& <var>rhs</var>);</code>
</p>
=20
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>is_copy_constructible<T>::value</=
code> is <code>true</code> and <code>is_copy_assignable<T>::value</co=
de> is <code>true</code>.</p></dd>
<dt>Effects:</dt> <dd><p>If <code><var>init</var> =3D=3D false &&am=
p; <var>rhs.init</var> =3D=3D false</code>, no effect. If <code><var>init</=
var> =3D=3D true && <var>rhs.init</var> =3D=3D false</code>, destroys the c=
ontained value by calling <code><var>val</var>->T::~T()</code>. If <code=
><var>init</var> =3D=3D false && <var>rhs.init</var> =3D=3D true</c=
ode>, constructs the contained value as if direct-non-list-initializing an =
object of type <code>T</code> with <code>*<var>rhs</var></code>. If <code><=
var>init</var> =3D=3D true && <var>rhs.init</var> =3D=3D true</code=
>, assigns <code>*<var>rhs</var></code> to the contained value.</p></dd>
<dt>Returns:</dt> <dd><p><code>*this</code></p></dd>
<dt>Postconditions:</dt> <dd><p>If <code>bool(<var>rhs</var>) =3D=3D fa=
lse</code> then <code>bool(*this) =3D=3D false</code>; otherwise <code>bool=
(*this) =3D=3D true</code> and <code>*(*this)</code> is equivalent to <code=
>*<var>rhs</var></code>.</p></dd>
<dt>Exception Safety:</dt> <dd><p>If any exception is thrown values of =
<code><var>init</var></code> and <code><var>rhs.init</var></code> remain un=
changed. If an exception is thrown during the call to <code>T</code>'s copy=
constructor, no effect. If an exception is thrown during the call to <code=
>T</code>'s copy assignment, the state of its contained value is as defined=
by the exception safety guarantee of <code>T</code>'s copy constructor.</p=
></dd>
</dl>
=20
=20
<p class=3D"function">
<code>optional<T>& optional<T>::operator=3D(optional<T=
>&& <var>rhs</var>) noexcept(<em>see below</em>);</code>
</p>
=20
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>is_move_constructible<T>::value</=
code> is <code>true</code> and <code>is_move_assignable<T>::value</co=
de> is <code>true</code>.</p></dd>
<dt>Effects:</dt> <dd><p>If <code><var>init</var> =3D=3D false &&am=
p; <var>rhs.init</var> =3D=3D false</code>, no effect. If <code><var>init</=
var> =3D=3D true && <var>rhs.init</var> =3D=3D false</code>, destroys the c=
ontained value by calling <code><var>val</var>->T::~T()</code>. If <code=
><var>init</var> =3D=3D false && <var>rhs.init</var> =3D=3D true</c=
ode>, constructs the contained value as if direct-non-list-initializing an =
object of type <code>T</code> with <code>std::move(*<var>rhs</var>)</code>.=
If <code><var>init</var> =3D=3D true && <var>rhs.init</var> =3D=3D=
true</code>, assigns <code>std::move(*<var>rhs</var>)</code> to the contai=
ned value.</p></dd>
<dt>Returns:</dt> <dd><p><code>*this</code></p></dd>
<dt>Postconditions:</dt> <dd><p><p>If initially <code>bool(<var>rhs</va=
r>) =3D=3D false</code> then <code>bool(*this) =3D=3D false</code> and <cod=
e>bool(<var>rhs</var>) =3D=3D false</code>; otherwise <code>bool(*this) =3D=
=3D true</code> and <code>*(*this)</code> is equivalent to the value that <=
code>*<var>rhs</var></code> had initially and <code>bool(<var>rhs</var>) =
=3D=3D true</code>.</p></dd>
<dt>Remarks:</dt> <dd><p>The expression inside <code>noexcept</code> is=
equivalent to:</p> <pre>is_nothrow_move_assignable<T>::value && is_n=
othrow_move_constructible<T>::value</pre></dd>
<dt>Exception Safety:</dt> <dd><p>If any exception is thrown values of =
<code><var>init</var></code> and <code><var>rhs.init</var></code> remain un=
changed. If an exception is thrown during the call to <code>T</code>'s move=
constructor, the state of <code>*rhs.val</code> is determined by exception=
safety guarantee of <code>T</code>'s move constructor. If an exception is =
thrown during the call to <code>T</code>'s move assignment, the state of <c=
ode><var>*val</var></code> and <code>*rhs.val</code> is determined by excep=
tion safety guarantee of <code>T</code>'s move assignment.</p></dd>
</dl>
=20
=20
<p class=3D"function">
<code>template <class U> optional<T>& optional<T>::=
operator=3D(U&& <var>v</var>);</code>
</p>
=20
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>is_constructible<T, U>::value</co=
de> is <code>true</code> and <code>is_assignable<U, T>::value</code> =
is <code>true</code>.</p></dd>
<dt>Effects:</dt> <dd><p>If <code>bool(*this) =3D=3D true</code> assign=
s <code>std::forward<U>(<var>v</var>)</code> to the contained value; =
otherwise constructs the contained value as if direct-non-list-initializing=
object of type <code>T</code> with <code>std::forward<U>(<var>v</var=
>)</code>.</p></dd>
<dt>Returns:</dt> <dd><p><code>*this</code></p></dd>
<dt>Postconditions:</dt> <dd><p><code>bool(*this) =3D=3D true</code> an=
d <code>*(*this)</code> is equivalent to the value that <code><var>v</var><=
/code> had initially.</p></dd>
<dt>Exception Safety:</dt> <dd><p>If any exception is thrown value of <=
code><var>init</var></code> remains unchanged. If an exception is thrown du=
ring the call to <code>T</code>'s constructor, the state of <code><var>v</v=
ar></code> is determined by exception safety guarantee of <code>T</code>'s =
constructor. If an exception is thrown during the call to <code>T</code>'s =
assignment, the state of <code><var>*val</var></code> and <code><var>v</var=
></code> is determined by exception safety guarantee of <code>T</code>'s as=
signment.</p></dd>
<dt>Remarks:</dt> <dd><p>The function shall not participate in overload=
resolution unless <code>is_same<typename remove_reference<U>::ty=
pe, T>::value</code> is <code>true</code>.</dd>
</dl>
<p>[<i>Note:</i> The reson to provide such genereic assignment and then c=
onstraining it so that effectively <code>T</code> =3D=3D <code>U</code> is =
to guarantee that assignment of the form <code>o =3D {}</code> is unambiguo=
us. —<i>end note</i>]</p>
<!--
<p class=3D"function">
<code>template <class U> optional<T>& optional<T>::=
operator=3D(U&& <var>v</var>);</code>
</p>
=20
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>is_constructible<T, U>::value</co=
de> is <code>true</code> and <code>is_assignable<U, T>::value</code> =
is <code>true</code>.</p></dd>
<dt>Effects:</dt> <dd><p>If <code>bool(*this) =3D=3D true</code> assign=
s <code>std::forward<U>(<var>v</var>)</code> to the contained value; =
otherwise constructs the contained value as if direct-non-list-initializing=
object of type <code>T</code> with <code>std::forward<U>(<var>v</var=
>)</code>.</p></dd>
<dt>Returns:</dt> <dd><p><code>*this</code></p></dd>
<dt>Postconditions:</dt> <dd><p><code>bool(*this) =3D=3D true</code> an=
d <code>*(*this)</code> is equivalent to the value that <code><var>v</var><=
/code> had initially.</p></dd>
<dt>Exception Safety:</dt> <dd><p>If any exception is thrown value of <=
code><var>init</var></code> remains unchanged. If an exception is thrown du=
ring the call to <code>T</code>'s constructor, the state of <code><var>v</v=
ar></code> is determined by exception safety guarantee of <code>T</code>'s =
constructor. If an exception is thrown during the call to <code>T</code>'s =
assignment, the state of <code><var>*val</var></code> and <code><var>v</var=
></code> is determined by exception safety guarantee of <code>T</code>'s as=
signment.</p></dd>
<dt>Remarks:</dt> <dd><p>The function shall not participate in overload=
resolution if type <code>decay<U>::type</code> is an instantiation o=
f class template <code>optional</code>.</dd>
</dl>
=20
=20
<p class=3D"function">
<code>template <class U> optional<T>& optional<T>::=
operator=3D(const optional<U>& <var>rhs</var>);</code>
</p>
=20
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>is_constructible<T, const U&>=
::value</code> is <code>true</code> and <code>is_assignable<T, const U&a=
mp;>::value</code> is <code>true</code>.</p></dd>
<dt>Effects:</dt> <dd><p>If <code><var>init</var> =3D=3D false &&am=
p; <var>rhs.init</var> =3D=3D false</code>, no effect. If <code><var>init</=
var> =3D=3D true && <var>rhs.init</var> =3D=3D false</code>, destroys the c=
ontained value by calling <code><var>val</var>->T::~T()</code>. If <code=
><var>init</var> =3D=3D false && <var>rhs.init</var> =3D=3D true</c=
ode>, constructs the contained value as if direct-non-list-initializing an =
object of type <code>T</code> with <code>*<var>rhs</var></code>. If <code><=
var>init</var> =3D=3D true && <var>rhs.init</var> =3D=3D true</code=
>, assigns <code>*<var>rhs</var></code> to the contained value.</p></dd>
<dt>Returns:</dt> <dd><p><code>*this</code></p></dd>
<dt>Postconditions:</dt> <dd><p>If <code>bool(<var>rhs</var>) =3D=3D fa=
lse</code> then <code>bool(*this) =3D=3D false</code>; otherwise <code>bool=
(*this) =3D=3D true</code> and <code>*(*this)</code> is equivalent to <code=
>*<var>rhs</var></code> converted to <code>T</code>.</p></dd>
<dt>Exception Safety:</dt> <dd><p>If any exception is thrown values of =
<code><var>init</var></code> and <code><var>rhs.init</var></code> remain un=
changed. If an exception is thrown during the call to <code>T</code>'s cons=
tructor, no effect. If an exception is thrown during the call to <code>T</c=
ode>'s assignment, the state of i<code><var>*val</var></code> is defined b=
y the exception safety guarantee of <code>T</code>'s assignment.</p></dd>
</dl>
=20
=20
<p class=3D"function">
<code>template <class U> optional<T>& optional<T>::=
operator=3D(optional<U>&& <var>rhs</var>);</code>
</p>
=20
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>is_constructible<T, U&&>:=
:value</code> is <code>true</code> and <code>is_assignable<T, U&&=
;>::value</code> is <code>true</code>.</p></dd>
<dt>Effects:</dt> <dd><p>If <code><var>init</var> =3D=3D false &&am=
p; <var>rhs.init</var> =3D=3D false</code>, no effect. If <code><var>init</=
var> =3D=3D true && <var>rhs.init</var> =3D=3D false</code>, destroys the c=
ontained value by calling <code><var>val</var>->T::~T()</code>. If <code=
><var>init</var> =3D=3D false && <var>rhs.init</var> =3D=3D true</c=
ode>, constructs the contained value as if direct-non-list-initializing an =
object of type <code>T</code> with <code>std::move(*<var>rhs</var>)</code>.=
If <code><var>init</var> =3D=3D true && <var>rhs.init</var> =3D=3D=
true</code>, assigns <code>std::move(*<var>rhs</var>)</code> to the contai=
ned value.</p></dd>
<dt>Returns:</dt> <dd><p><code>*this</code></p></dd>
<dt>Postconditions:</dt> <dd><p>If <code>bool(<var>rhs</var>) =3D=3D fa=
lse</code> then <code>bool(*this) =3D=3D false</code>; otherwise <code>bool=
(*this) =3D=3D true</code> and <code>*(*this)</code> is equivalent to the v=
alue <code>*<var>rhs</var></code> had initially if converted to <code>T</co=
de>.</p></dd>
<dt>Exception Safety:</dt> <dd><p>If any exception is thrown values of =
<code><var>init</var></code> and <code><var>rhs.init</var></code> remain un=
changed. If an exception is thrown during the call to <code>T</code>'s cons=
tructor, no effect. If an exception is thrown during the call to <code>T</c=
ode>'s assignment, the state of <code><var>*val</var></code> is defined by =
the exception safety guarantee of <code>T</code>'s assignment.</p></dd>
</dl>
=20
<p class=3D"function">
<code>template <class U> optional<T>& optional<T>::=
operator=3D(initializer_list<U> <var>il</var>);</code>
</p>
=20
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>is_constructible<T, initializer_list=
<U>>::value</code> is <code>true</code> and <code>is_assignable<=
;T, initializer_list<U>>::value</code> is <code>true</code>.</p></=
dd>
<dt>Effects:</dt> <dd><p>If <code>bool(*this) =3D=3D true</code> assig=
ns <code><var>il</var></code> to the contained value; otherwise constructs =
the contained value as if direct-non-list-initializing object of type <code=
>T</code> with <code><var>il</var></code>.</p></dd>
<dt>Returns:</dt> <dd><p><code>*this</code></p></dd>
<dt>Postconditions:</dt> <dd><p><code>bool(*this) =3D=3D true</code>.</=
p></dd>
<dt>Throws:</dt> <dd><p>Whatever <code>T::T(initializer_list<U>)<=
/code> or <code>T::operator=3D(initializer_list<U>)</code> throws.</p=
></dd>
<dt>Exception Safety:</dt> <dd><p>If any exception is thrown, value of =
<code><var>init</var></code> remains unchanged. If an exception is thrown d=
uring the call to <code>T</code>'s constructor, no effect. If an exception =
is thrown during the call to <code>T</code>'s assignment, the state of its =
contained value is as defined by the exception safety guarantee of <code>T<=
/code>'s assignemnt.</p></dd>
<dt>Remarks:</dt> <dd><p>The function shall not participate in overload=
resolution unless <code>is_constructible<T, initializer_list<U>&g=
t;::value</code> is <code>true</code> and <code>is_assignable<T, initial=
izer_list<U>>::value</code> is <code>true</code>.</dd>
</dl>
-->
=20
<p class=3D"function">
<code>template <class... Args> optional<T>& optional<T=
>::emplace(Args&&... <var>args</var>);</code>
</p>
=20
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>is_constructible<T, Args&&..=
..>::value</code> is <code>true</code>.</p></dd>
<dt>Effects:</dt> <dd><p>Calls <code>*this =3D nullopt</code>. Then ini=
tializes the contained value as if constructing an object of type <code>T</=
code> with the arguments <code>std::forward<Args>(<var>args</var>)...=
</code>.</p></dd>
<dt>Returns:</dt> <dd><p><code>*this</code></p></dd>
<dt>Postconditions:</dt> <dd><p><code>bool(*this) =3D=3D true</code>.</=
p></dd>
<dt>Throws:</dt> <dd><p>Whatever expression <code>T(std::forward<Arg=
s>(<var>args</var>)...)</code> throws.</p></dd>
<dt>Exception Safety:</dt> <dd><p>If an exception is thrown during the =
call to <code>T</code>'s constructor, <code>*this</code> is disengaged, and=
the previous <code><var>*val</var></code> (if any) has been destroyed.</p>=
</dd>
</dl>
=20
=20
<p class=3D"function">
<code>template <class U, class... Args> optional<T>& opti=
onal<T>::emplace(initializer_list<U> <var>il</var>, Args&&a=
mp;... <var>args</var>);</code>
</p>
=20
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>is_constructible<T, initializer_list=
<U>, Args&&...>::value</code> is <code>true</code>.</p></d=
d>
<dt>Effects:</dt> <dd><p>Calls <code>*this =3D nullopt</code>. Then ini=
tializes the contained value as if constructing an object of type <code>T</=
code> with the arguments <code><var>il</var>, std::forward<Args>(<var=
>args</var>)...</code>.</p></dd>
<dt>Returns:</dt> <dd><p><code>*this</code></p></dd>
<dt>Postconditions:</dt> <dd><p><code>bool(*this) =3D=3D true</code>.</=
p></dd>
<dt>Throws:</dt> <dd><p>Whatever expression <code>T(<var>il</var>, std:=
:forward<Args>(<var>args</var>)...)</code> throws.</p></dd>
<dt>Exception Safety:</dt> <dd><p>If an exception is thrown during the =
call to <code>T</code>'s constructor, <code>*this</code> is disengaged, and=
the previous <code><var>*val</var></code> (if any) has been destroyed.</p>=
</dd>
<dt>Remarks:</dt> <dd><p>The function shall not participate in overload=
resolution unless <code>is_constructible<T, initializer_list<U>, =
Args&&...>::value</code> is <code>true</code>.</p></dd>
</dl>
=20
<h5><a name=3D"optional.object.swap">20.5.4.4 Swap <span style=3D"float:rig=
ht">[optional.object.swap]</span></a></h5>
<p class=3D"function">
<code>void optional<T>::swap(optional<T>& rhs) noexcept(<em>s=
ee below</em>);</code>
</p>
=20
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>T</code> shall be swappable for lvalues=
and <code>is_move_constructible<T>::value</code> is <code>true</code=
>.</p></dd>
<dt>Effects:</dt> <dd><p>If <code><var>init</var> =3D=3D false && <var>=
rhs.init</var> =3D=3D false</code>, no effect. If <code><var>init</var> =3D=
=3D true && <var>rhs.init</var> =3D=3D false</code>, constructs the contain=
ed value of <code><var>rhs</var></code> by direct-initialization with <code=
>std::move(*(*this))</code>, followed by <code>val->T::~T(), swap(<var>i=
nit</var>, <var>rhs.init</var>)</code>. If <code><var>init</var> =3D=3D fal=
se && <var>rhs.init</var> =3D=3D true</code>, constructs the contained valu=
e of <code>*this</code> by direct-initialization with <code>std::move(*<var=
>rhs</var>)</code>, followed by <code>rhs.val->T::~T(), swap(<var>init</=
var>, <var>rhs.init</var>)</code>. If <code><var>init</var> =3D=3D true && =
<var>rhs.init</var> =3D=3D true</code>, calls <code>swap(*(*this), *<var>rh=
s</var>)</code>.</p></dd>
<dt>Throws:</dt> <dd><p>Whatever expressions <code>swap(declval<T&am=
p;>(), declval<T&>())</code> and <code>T{move(declval<T&=
;&>())}</code> throw.</p></dd>
<dt>Remarks:</dt> <dd><p>The expression inside <code>noexcept</code> is=
equivalent to: <pre>is_nothrow_move_constructible<T>::value && noexc=
ept(swap(declval<T&>(), declval<T&>()))</pre></dd>
<dt>Exception Safety:</dt> <dd><p>If any exception is thrown values of =
<code><var>init</var></code> and <code><var>rhs.init</var></code> remain un=
changed. If an exception is thrown during the call to function <code>swap</=
code> the state of <code><var>*val</var></code> and <code>*rhs.val</code> i=
s determined by the exception safety quarantee of <code>swap</code> for lva=
lues of <code>T</code>. If an exception is thrown durning the call to <code=
>T</code>'s move constructor, the state of <code><var>*val</var></code> and=
<code>*rhs.val</code> is determined by the exception safety quarantee of <=
code>T</code>'s move constructor.</p></dd>
</dl>
=20
=20
<h5><a name=3D"optional.object.observe">20.5.4.5 Observers <span style=3D"=
float:right">[optional.object.observe]</span></a></h5>
<p class=3D"function">
<code>constexpr T const* optional<T>::operator->() const;<br>T* =
optional<T>::operator->();</code>
</p>
=20
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>bool(*this) =3D=3D true</code>.</p></dd=
>
<dt>Returns:</dt> <dd><p><code>val</code></p></dd>
<dt>Throws:</dt> <dd><p>nothing.</p></dd>
<dt>Remarks:</dt> <dd><p>The first function shall be a <code>constexpr<=
/code> function.</p></dd>
</dl>
=20
=20
<p class=3D"function">
<code>constexpr T const& optional<T>::operator*() const;<br>T&a=
mp; optional<T>::operator*();</code>
</p>
=20
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>bool(*this) =3D=3D true</code>.</p></dd=
>
<dt>Returns:</dt> <dd><p><code><var>*val</var></code></p></dd>
<dt>Throws:</dt> <dd><p>nothing.</p></dd>
<dt>Remarks:</dt> <dd><p>The first function shall be a <code>constexpr<=
/code> function.</p></dd>
</dl>
=20
=20
<p class=3D"function">
<code>constexpr explicit optional<T>::operator bool() noexcept;</co=
de>
</p>
=20
<dl class=3D"attribute">
<dt>Returns:</dt> <dd><p><code><var>init</var></code></p></dd>
<dt>Remarks:</dt> <dd><p>this function shall be a <code>constexpr</code=
> function.</p></dd>
</dl>
=20
<p class=3D"function">
<code>template <class U> constexpr T optional<T>::get_value_o=
r(U&& <var>v</var>) const&;</code>
</p>
=20
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>is_copy_constructible<T>::value</=
code> is <code>true</code> and <code>is_convertible<U&&, T>::=
value</code> is <code>true</code>.</p></dd>
<dt>Returns:</dt> <dd><p><code>bool(*this) ? **this : static_cast<T&=
gt;(std::forward<U>(<var>v</var>))</code>.</p></dd>
<dt>Throws:</dt> <dd><p>Whatever the execution of <code>T</code>'s cons=
tructor selected for the initialization of the return value throws.</p></dd=
>
<dt>Exception Safety:</dt> <dd><p>If <code><var>init</var> =3D=3D true<=
/code> and exception is thrown durning the call to <code>T</code>'s constru=
ctor, the value of <code><var>init</var></code> and <code><var>v</var></cod=
e> remains unchanged and the state of <code><var>*val</var></code> is deter=
mined by the exception safety quarantee of the selected <code>T</code>'s co=
nstructor. Otherwise, when exception is thrown durning the call to <code>T<=
/code>'s constructor, the value of <code><var>*this</var></code> remains un=
changed and the state of <code><var>v</var></code> is determined by the exc=
eption safety quarantee of the selected <code>T</code>'s constructor</p></d=
d>
<dt>Remarks:</dt> <dd><p>If the selected <code>T</code>'s constructor i=
s a <code>constexpr</code> constructor, this function shall be a <code>cons=
texpr</code> function.</p></dd>
</dl>
=20
=20
<p class=3D"function">
<code>template <class U> T optional<T>::get_value_or(U&&a=
mp; <var>v</var>) &&;</code>
</p>
=20
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>is_move_constructible<T>::value</=
code> is <code>true</code> and <code>is_convertible<U&&, T>::=
value</code> is <code>true</code>.</p></dd>
<dt>Returns:</dt> <dd><p><code>bool(*this) ? std::move(**this) : static=
_cast<T>(std::forward<U>(<var>v</var>))</code>.</p></dd>
<dt>Throws:</dt> <dd><p>Whatever the execution of the selected <code>T<=
/code>'s constructor selected for the initialization of the return value th=
rows.</p></dd>
<dt>Exception Safety:</dt> <dd><p>If <code><var>init</var> =3D=3D true<=
/code> and exception is thrown durning the call to <code>T</code>'s constru=
ctor, the value of <code><var>init</var></code> and <code><var>v</var></cod=
e> remains unchanged and the state of <code><var>*val</var></code> is deter=
mined by the exception safety quarantee of the <code>T</code>'s constructor=
.. Otherwise, when exception is thrown durning the call to <code>T</code>'s =
constructor, the value of <code><var>*this</var></code> remains unchanged a=
nd the state of <code><var>v</var></code> is determined by the exception sa=
fety quarantee of the selected <code>T</code>'s constructor</p></dd>
</dl>
=20
<h4><a name=3D"optional.inplace">20.5.5 In-place construction <span style=
=3D"float:right">[optional.inplace]</span></a></h4>
<p class=3D"function">
<code>struct emplace_t{}; <br>constexpr emplace_t emplace{};</code>
</p>
<p>The struct <code>emplace_t</code> is a disengaged structure type used =
as a unique type to disambiguate constructor and function overloading. Spec=
ifically, <code>optional<T></code> has a constructor with <code>empla=
ce_t</code> as the first argument followed by an argument pack; this indica=
tes that <code>T</code> should be constructed in-place (as if by a call to =
placement new expression) with forwarded argument pack as parameters.
</p>
=20
<h4><a name=3D"optional.nullopt">20.5.6 Disengaged state indicator <span s=
tyle=3D"float:right">[optional.nullopt]</span></a></h4>
<p class=3D"function">
<code>struct nullopt_t{<em>see below</em>}; <br>constexpr nullopt_t nullo=
pt(<em>unspecified</em>);</code>
</p>
<p>The struct <code>nullopt_t</code> is an empty structure type used as a=
unique type to indicate a disengaged state for <code>optional</code> objec=
ts. In particular, <code>optional<T></code> has a constructor with <c=
ode>nullopt_t</code> as single argument; this indicates that a disengaged o=
ptional object shall be constructed.
</p>
=20
<p>Type <code>nullopt_t</code> shall not have a default constructor. It s=
hall be a literal type. Constant <code>nullopt</code> shall be initialized =
with argument of literal type.</p>
=20
=20
=20
<h4><a name=3D"optional.relops">20.5.7 Relational operators <span style=3D=
"float:right">[optional.relops]</span></a></h4>
=20
<p class=3D"function">=20
<code>template <class T> constexpr bool operator=3D=3D(const option=
al<T>& x, const optional<T>& y);</code>
</p>
=20
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>T</code> shall meet the requirements of <=
code>EqualityComparable</code>.</p></dd>
<dt>Returns:</dt> <dd><p>If <code>bool(x) !=3D bool(y)</code>, <code>fals=
e</code>; otherwise if <code>bool(x) =3D=3D false</code>, <code>true</code>=
; otherwise <code>*x =3D=3D *y</code>.</p></dd>
<dt>Remarks:</dt> <dd><p>Instantiations of this function template for whi=
ch <code>*x =3D=3D *y</code> is a core constant expression, shall be <code>=
constexpr</code> functions.</p></dd>
</dl>
=20
=20
<p class=3D"function">
<code>template <class T> constexpr bool operator!=3D(const optional=
<T>& x, const optional<T>& y);</code>
</p>
=20
<dl class=3D"attribute">
<dt>Returns:</dt> <dd><p><code>!(x =3D=3D y)</code>.</p></dd>
</dl>
=20
=20
<p class=3D"function">
<code>template <class T> constexpr bool operator<(const optional=
<T>& x, const optional<T>& y);</code>=20
</p>
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>T</code> shall meet the requirements of <=
code>LessThanComparable</code>.</p></dd>
<dt>Returns:</dt> <dd><p>If <code>(!y)</code>, <code>false</code>; otherw=
ise, if <code>(!x)</code>, <code>true</code>; otherwise <code>*x < *y</c=
ode>.</p></dd>
<dt>Remarks:</dt> <dd><p>Instantiations of this function template for whi=
ch <code>*x < *y</code> is a core constant expression, shall be <code>co=
nstexpr</code> functions.</p></dd>
</dl>
=20
<p class=3D"function">
<code>template <class T> constexpr bool operator>(const optional=
<T>& x, const optional<T>& y);</code>=20
</p>
<dl class=3D"attribute">
<dt>Returns:</dt> <dd><p><code>(y < x)</code>.</p></dd>
</dl>
=20
=20
<p class=3D"function">=20
<code>template <class T> constexpr bool operator<=3D(const optio=
nal<T>& x, const optional<T>& y);</code>=20
</p>
<dl class=3D"attribute">
<dt>Returns:</dt> <dd><p><code>!(y < x)</code>.</p></dd>
</dl>
=20
=20
<p class=3D"function">
<code>template <class T> constexpr bool operator>=3D(const optio=
nal<T>& x, const optional<T>& y);</code>=20
</p>
<dl class=3D"attribute">
<dt>Returns:</dt> <dd><p><code>!(x < y)</code>.</p></dd>
</dl>
=20
=20
<h4><a name=3D"optional.nullops">20.5.8 Comparison with <code>nullopt</code=
> <span style=3D"float:right">[optional.nullops]</span></a></h4>
=20
=20
<p class=3D"function">
<code>template <class T> constexpr bool operator=3D=3D(const option=
al<T>& <var>x</var>, nullopt_t) noexcept;<br>template <class T=
> constexpr bool operator=3D=3D(nullopt_t, const optional<T>& =
x) noexcept;</code>
</p>
=20
<dl class=3D"attribute">
<dt>Returns:</dt> <dd><p><code>(!<var>x</var>)</code>.</p></dd>
</dl>
<p class=3D"function">
<code>template <class T> constexpr bool operator!=3D(const optional=
<T>& <var>x</var>, nullopt_t) noexcept;<br>template <class T&g=
t; constexpr bool operator!=3D(nullopt_t, const optional<T>& x) n=
oexcept;</code>
</p>
=20
<dl class=3D"attribute">
<dt>Returns:</dt> <dd><p><code>bool(<var>x</var>)</code>.</p></dd>
</dl>=20
<p class=3D"function">
<code>template <class T> constexpr bool operator<(const optional=
<T>& <var>x</var>, nullopt_t) noexcept;</code>
</p>
=20
<dl class=3D"attribute">
<dt>Returns:</dt> <dd><p><code>false</code>.</p></dd>
</dl>
<p class=3D"function">
<code>template <class T> constexpr bool operator<(nullopt_t, con=
st optional<T>& <var>x</var>) noexcept;</code>
</p>
=20
<dl class=3D"attribute">
<dt>Returns:</dt> <dd><p><code>bool(<var>x</var>)</code>.</p></dd>
</dl>
=20
<p class=3D"function">
<code>template <class T> constexpr bool operator<=3D(const optio=
nal<T>& <var>x</var>, nullopt_t) noexcept;</code>
</p>
=20
<dl class=3D"attribute">
<dt>Returns:</dt> <dd><p><code>(!<var>x</var>)</code>.</p></dd>
</dl>
<p class=3D"function">
<code>template <class T> constexpr bool operator<=3D(nullopt_t, =
const optional<T>& <var>x</var>) noexcept;</code>
</p>
=20
<dl class=3D"attribute">
<dt>Returns:</dt> <dd><p><code>true</code>.</p></dd>
</dl>
=20
=20
<p class=3D"function">
<code>template <class T> constexpr bool operator>(const optional=
<T>& <var>x</var>, nullopt_t) noexcept;</code>
</p>
=20
<dl class=3D"attribute">
<dt>Returns:</dt> <dd><p><code>bool(<var>x</var>)</code>.</p></dd>
</dl>
<p class=3D"function">
<code>template <class T> constexpr bool operator>(nullopt_t, con=
st optional<T>& <var>x</var>) noexcept;</code>
</p>
=20
<dl class=3D"attribute">
<dt>Returns:</dt> <dd><p><code>false</code>.</p></dd>
</dl>
=20
<p class=3D"function">
<code>template <class T> constexpr bool operator>=3D(const optio=
nal<T>& <var>x</var>, nullopt_t) noexcept;</code>
</p>
=20
<dl class=3D"attribute">
<dt>Returns:</dt> <dd><p><code>true</code>.</p></dd>
</dl>
<p class=3D"function">
<code>template <class T> constexpr bool operator>=3D(nullopt_t, =
const optional<T>& <var>x</var>) noexcept;</code>
</p>
=20
<dl class=3D"attribute">
<dt>Returns:</dt> <dd><p><code>(!<var>x</var>)</code>.</p></dd>
</dl>
=20
=20
<h4><a name=3D"optional.poisoned_comp">20.5.9 Poisoned comparison with <cod=
e>T</code> <span style=3D"float:right">[optional.poisoned_comp]</span></a><=
/h4>
<p class=3D"function">
<code>template <class T> bool operator=3D=3D(const optional<T>=
;&, const T&) noexcept;<br>
template <class T> bool operator=3D=3D(const T&, const optional=
<T>&) noexcept;<br>
template <class T> bool operator!=3D(const optional<T>&, =
const T&) noexcept;<br>
template <class T> bool operator!=3D(const T&, const optional&l=
t;T>&) noexcept;<br>
template <class T> bool operator<(const optional<T>&, =
const T&) noexcept;<br>
template <class T> bool operator<(const T&, const optional&l=
t;T>&) noexcept;<br>
template <class T> bool operator<=3D(const optional<T>&=
;, const T&) noexcept;<br>
template <class T> bool operator<=3D(const T&, const optiona=
l<T>&) noexcept;<br>
template <class T> bool operator>(const optional<T>&, =
const T&) noexcept;<br>
template <class T> bool operator>(const T&, const optional&l=
t;T>&) noexcept;<br>
template <class T> bool operator>=3D(const optional<T>&=
;, const T&) noexcept;<br>
template <class T> bool operator>=3D(const T&, const optiona=
l<T>&) noexcept;</code>
</p>
=20
<dl class=3D"attribute">
<dt>Remarks:</dt> <dd><p>Program that causes the instantiation of one of =
the above templates is ill-formed.</p></dd>
</dl>
=20
=20
<h4><a name=3D"optional.specalg">20.5.10 Specialized algorithms <span style=
=3D"float:right">[optional.specalg]</span></a></h4>
<p class=3D"function">
<code>template <class T> void swap(optional<T>& x, option=
al<T>& y) noexcept(noexcept(x.swap(y)));</code>
</p>
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>is_reference<T>::value =3D=3D fal=
se</code>.</p></dd>
<dt>Effects:</dt> <dd><p>calls <code>x.swap(y)</code>.</p> =20
</dl><!--
<p class=3D"function">
<code>template <class T, class V><br>
typename decay<T>::type get_value_or(const optional&l=
t;T>& <var>op</var>, V&& <var>v</var>);</code>
</p>
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>is_copy_constructible<T>::value</=
code> is <code>true</code> and <code>is_convertible<V&&, T>::=
value</code> is <code>true</code>.</p></dd>
<dt>Returns:</dt> <dd><p><code><var>op</var> ? *<var>op</var> : static_=
cast<T>(std::forward<V>(<var>v</var>))</code>.</p></dd>
</dl>
=20
=20
<p class=3D"function">
<code>template <class T, class V><br>
typename decay<T>::type get_value_or(optional<T>=
;&& <var>op</var>, V&& <var>v</var>);</code>
</p>
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p><code>is_move_constructible<T>::value</=
code> is <code>true</code> and <code>is_convertible<V&&, T>::=
value</code> is <code>true</code>.</p></dd>
<dt>Returns:</dt> <dd><p><code><var>op</var> ? std::move(*<var>op</var>=
) : static_cast<T>(std::forward<V>(<var>v</var>))</code>.</p></=
dd>
<dt>Remarks:</dt> <dd><p>This function provides the same exception safe=
ty as <code>T</code>'s move-constructor.</p></dd>
</dl>-->
=20
=20
<p class=3D"function">
<code>template <class T><br>
constexpr optional<typename decay<T>::type> mak=
e_optional(T&& <var>v</var>);</code>
</p>
=20
<dl class=3D"attribute">
<dt>Returns:</dt> <dd><p><code>optional<typename decay<T>::typ=
e>(std::forward<T>(<var>v</var>))</code>.</p></dd>
</dl>
=20
=20
<h4><a name=3D"optional.hash">20.5.11 Hash support <span style=3D"float:rig=
ht">[optional.hash]</span></a></h4>
<p class=3D"function">
<code>template <class T> struct hash<optional<T>>;</cod=
e>
</p>
<dl class=3D"attribute">
<dt>Requires:</dt> <dd><p>the template specilaization <code>hash<T&g=
t;</code> shall meet the requirements of class template hash (20.9.12).
The template specilaization <code>hash<optional<T>></code=
> shall meet the requirements of class template hash.=20
For an object <code>o</code> of type <code>optional<T></code>, =
if <code>bool(o) =3D=3D true</code>,=20
<code>hash<optional<T>>()(o)</code> shall evaluate to the=
same value as <code>hash<T>()(*o)</code>.</p></dd>=20
</dl>
=20
=20
</blockquote>
<h2><a name=3D'implementability'>Implementability</a></h2>
<p>This proposal can be implemented as pure library extension, without any =
compiler magic support, in C++11. An almost full rerefence implementation o=
f this proposal can be found at <a href=3D"https://github.com/akrzemi1/Opti=
onal/">https://github.com/akrzemi1/Optional/</a>. Below we demonstrate how =
one can implement <code>optional</code>'s <code>constexpr</code> constructo=
rs to engaged and disengaged state as well as <code>constexpr</code> <code>=
operator*</code> for <code>TriviallyDestructible</code> <code>T</code>'s. <=
/p>
<pre>namespace std {
namespace experimental {
struct dummy_t{};
template <class T>
union optional_storage
{
static_assert( is_trivially_destructible<T>::value, "" );
dummy_t dummy_;
T value_;
constexpr optional_storage() <em>// null-state ctor</em>
: dummy_{} {}
constexpr optional_storage(T const& v) <em>// value ctor</em>
: value_{v} {}
~optional_storage() =3D default; <em>// trivial dtor</em>
};
template <class T>
<em>// requires: is_trivially_destructible<T>::value</em>
class optional
{
bool initialized_;
optional_storage<T> storage_;
public:
constexpr optional(nullopt_t) : initialized_{false}, storage_{} {}
constexpr optional(T const& v) : initialized_{true}, storage_{v} {}
constexpr T const& operator*()=20
{
return assert(bool(*this)), storage_.value_;
}
<em>// ...</em>
};
} <em>// namespace experimental</em>
} <em>// namespace std</em>
</pre>
<!--END-->
<h2><a name=3D'acknowledgements'>Acknowledgements</a></h2>
<p>Many people from the Boost community, participated in the developement o=
f the Boost.Optional library. Sebastian Redl suggested the usage of functio=
n <code>emplace</code>. </p>
<p>Daniel Krügler provided numerous helpful suggestions, corrections a=
nd comments on this paper; in particular he suggested the addition of and r=
eference implementation for "perfect initialization" operations.</p>
<p>People in discussion group "ISO C++ Standard - Future Proposals" provide=
d numerous insightful suggestions: Vladimir Batov (who described and suppor=
ted the perfect forwarding constructor), Nevin Liber, Ville Voutilainen, Ri=
chard Smiths, Dave Abrahams, Chris Jefferson, Jeffrey Yasskin, Nikolay Ivch=
enkov, and many more. </p>
<p>Joe Gottman suggested the support for hashing some optional objects.</p>
<h2><a name=3D'literature'>References</a></h2>
<ol>
<li>John J. Barton, Lee R. Nackman, "Scientific and Engineering C++: An Int=
roduction with Advanced Techniques and Examples".</li>
<li>Fernando Cacciola, Boost.Optional library (<a href=3D'http://www.boost.=
org/doc/libs/1_49_0/libs/optional/doc/html/index.html'>http://www.boost.org=
/doc/libs/1_49_0/libs/optional/doc/html/index.html</a>)</li>
<li>MSDN Library, "Nullable Types (C# Programming Guide)", (<a href=3D'http=
://msdn.microsoft.com/en-us/library/1t3y8s4s.aspx'>http://msdn.microsoft.co=
m/en-us/library/1t3y8s4s.aspx</a></li>
<li>Code Synthesis Tools, "C++ Object Persistence with ODB", (<a href=3D'ht=
tp://www.codesynthesis.com/products/odb/doc/manual.xhtml#7.3'>http://www.co=
desynthesis.com/products/odb/doc/manual.xhtml#7.3</a>)</li>
<li>Jaakko Järvi, Boost Tuple Library (<a href=3D"http://www.boost.org=
/doc/libs/1_49_0/libs/tuple/doc/tuple_users_guide.html">http://www.boost.or=
g/doc/libs/1_49_0/libs/tuple/doc/tuple_users_guide.html</a>) </li>
<li>Alisdair Meredith, John Lakos, "<code>noexcept</code> Prevents Library =
Validation" (N3248, <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/=
papers/2011/n3248.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2=
011/n3248.pdf</a>)</li>
<li>Walter E. Brown, "A Preliminary Proposal for a Deep-Copying Smart Point=
er" (N3339, <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2=
012/n3339.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n333=
9.pdf</a>)</li>
<li>Andrzej Krzemieński, Optional library implementation in C++11 (<a=
href=3D"https://github.com/akrzemi1/Optional/">https://github.com/akrzemi1=
/Optional/</a>)</li>
</ol>
=20
</body>
</html>
------=_Part_2472_24147677.1358889529784--
.
Author: Akira Takahashi <faithandbrave@gmail.com>
Date: Wed, 23 Jan 2013 11:41:41 +0900
Raw View
--bcaec53aedb46333b304d3eba291
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
Hi Andrzej,
2013/1/23 Andrzej Krzemie=F1ski <akrzemi1@gmail.com>
> Hi Everyone,
> We are ready with the 3rd revision of std::optional proposal. The main
> changes:
>
> - optional<T> is hashable for hashable T's.
> - Removed optional references -- they will be proposed separately.
> - get_value_or is now optional-specific member function.
> - optional<T> is a literal type.
> - Removed reference implementation. We now only provide the
> implementation of the parts that we consider non-trivial.
>
> We would appreciate your feedback and suggestions.
>
>
I want `optional::get()` member function. (the member exist in
`boost::optional`)
Why only pointer interface?
Regards,
Akira
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Akira Takahashi
mailto:faithandbrave@gmail.com
https://sites.google.com/site/faithandbrave/about/en
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
--bcaec53aedb46333b304d3eba291
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Andrzej,<div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">2013/1/23 Andrzej Krzemie=F1ski <span dir=3D"ltr"><<a h=
ref=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">akrzemi1@gmail.com</a>&=
gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex">
Hi Everyone,<br>We are ready with the 3rd revision of std::optional proposa=
l. The main changes:<br><ul><li><code>optional<T></code> is hashable =
for hashable <code>T</code>’s.</li><li>Removed optional references &m=
dash; they will be proposed separately.</li>
<li><code>get_value_or</code> is now <code>optional</code>-specific member =
function.</li><li><code>optional<T></code> is a literal type.</li><li=
>Removed reference implementation. We now only provide the implementation o=
f the parts that we consider non-trivial.</li>
</ul>We would appreciate your feedback and suggestions.<br><br></blockquote=
></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra" styl=
e>I want `optional::get()` member function. (the member exist in `boost::op=
tional`)</div>
<div class=3D"gmail_extra" style>Why only pointer interface?</div><div clas=
s=3D"gmail_extra"><br></div><div class=3D"gmail_extra" style>Regards,</div>=
<div class=3D"gmail_extra" style>Akira</div><br>>>=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
Akira Takahashi<br>mailto:<a href=3D"mailto:faithandbrave@gmail.com">faitha=
ndbrave@gmail.com</a><br><a href=3D"https://sites.google.com/site/faithandb=
rave/about/en">https://sites.google.com/site/faithandbrave/about/en</a><br>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--bcaec53aedb46333b304d3eba291--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Wed, 23 Jan 2013 00:56:16 -0800 (PST)
Raw View
------=_Part_3116_16755246.1358931376385
Content-Type: text/plain; charset=ISO-8859-1
>
> Why only pointer interface?
>
By "non-pointer" interface do you mean member functions like:
bool is_initialized() const;
T const& get_value() const;
?
I want `optional::get()` member function. (the member exist in
> `boost::optional`)
>
One of the goals for the design was not to introduce any redundancy in the
interface. This is the answer to the former question, and also partially to
the latter. This is the second time, the observer function get is
requested. I am personally a bit uneasy about introducing this, mostly
because of the overlap in functionality with other members and little
offered benefit on the other hand.
Do you have a practical use case for it?
Does everyone agree on adding get observer?
Regards,
&rzej
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_3116_16755246.1358931376385
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Why only=
pointer interface?</div></div></blockquote><div><br>By "non-pointer" inter=
face do you mean member functions like:<br><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"><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">bool</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> is_initialized</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">const</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>T <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">const</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">&</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> get_value</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">const</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><br>?<br><br><blockqu=
ote 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>I want `opt=
ional::get()` member function. (the member exist in `boost::optional`)</div=
></div></div></blockquote><div><br>One of the goals for the design was not =
to introduce any redundancy in the interface. This is the answer to the for=
mer question, and also partially to the latter. This is the second time, th=
e observer function <span style=3D"font-family: courier new,monospace;">get=
</span>is requested. I am personally a bit uneasy about introducing this, =
mostly because of the overlap in functionality with other members and littl=
e offered benefit on the other hand.<br> <br>Do you have a practical u=
se case for it?<br>Does everyone agree on adding <span style=3D"font-family=
: courier new,monospace;">get </span>observer?<br><br>Regards,<br>&rzej=
<br></div><div> </div> </div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_3116_16755246.1358931376385--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 23 Jan 2013 01:02:26 -0800 (PST)
Raw View
------=_Part_247_8122812.1358931746067
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
On Wednesday, January 23, 2013 12:56:16 AM UTC-8, Andrzej Krzemie=F1ski wro=
te:
>
> Why only pointer interface?
>>
>
> By "non-pointer" interface do you mean member functions like:
>
> bool is_initialized() const;
> T const& get_value() const;
>
> ?
>
> I want `optional::get()` member function. (the member exist in=20
>> `boost::optional`)
>>
>
> One of the goals for the design was not to introduce any redundancy in th=
e=20
> interface. This is the answer to the former question, and also partially =
to=20
> the latter. This is the second time, the observer function get is=20
> requested. I am personally a bit uneasy about introducing this, mostly=20
> because of the overlap in functionality with other members and little=20
> offered benefit on the other hand.
> =20
> Do you have a practical use case for it?
> Does everyone agree on adding get observer?
>
> Regards,
> &rzej
>
Well, reference_wrapper has a `get` method even though it has an `operator=
=20
T&` that does the same thing. So there is precident for always having a=20
`get` method for objects which contain other objects.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_247_8122812.1358931746067
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>On Wednesday, January 23, 2013 12:56:16 AM UTC-8, Andrzej Krzemie=
=F1ski wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div>Why only pointer interface?</d=
iv></div></blockquote><div><br>By "non-pointer" interface do you mean membe=
r functions like:<br><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><span style=3D"color:#000"><br></span><span style=3D"colo=
r:#008">bool</span><span style=3D"color:#000"> is_initialized</span><span s=
tyle=3D"color:#660">()</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">const</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"><br>T </span><span style=3D"color:#008">const</span><span s=
tyle=3D"color:#660">&</span><span style=3D"color:#000"> get_value</span=
><span style=3D"color:#660">()</span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#008">const</span><span style=3D"color:#660">;</span><spa=
n style=3D"color:#000"><br></span></div></code></div><br>?<br><br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>I want `optional:=
:get()` member function. (the member exist in `boost::optional`)</div></div=
></div></blockquote><div><br>One of the goals for the design was not to int=
roduce any redundancy in the interface. This is the answer to the former qu=
estion, and also partially to the latter. This is the second time, the obse=
rver function <span style=3D"font-family:courier new,monospace">get </span>=
is requested. I am personally a bit uneasy about introducing this, mostly b=
ecause of the overlap in functionality with other members and little offere=
d benefit on the other hand.<br> <br>Do you have a practical use case =
for it?<br>Does everyone agree on adding <span style=3D"font-family:courier=
new,monospace">get </span>observer?<br><br>Regards,<br>&rzej</div></di=
v></blockquote><div><br>Well, reference_wrapper has a `get` method even tho=
ugh it has an `operator T&` that does the same thing. So there is preci=
dent for always having a `get` method for objects which contain other objec=
ts.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_247_8122812.1358931746067--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Wed, 23 Jan 2013 10:05:05 +0100
Raw View
2013/1/23 Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com>:
>> Why only pointer interface?
>
>
> By "non-pointer" interface do you mean member functions like:
>
> bool is_initialized() const;
> T const& get_value() const;
>
> ?
>
>> I want `optional::get()` member function. (the member exist in
>> `boost::optional`)
>
>
> One of the goals for the design was not to introduce any redundancy in th=
e
> interface. This is the answer to the former question, and also partially =
to
> the latter. This is the second time, the observer function get is request=
ed.
> I am personally a bit uneasy about introducing this, mostly because of th=
e
> overlap in functionality with other members and little offered benefit on
> the other hand.
>
> Do you have a practical use case for it?
> Does everyone agree on adding get observer?
I have a similar but also slightly different suggestion: When
comparing with std::function (which also is nullable) there is one
notable difference: There is no way to have a runtime-checked
observer. I'm *not* suggesting that operator* should be required to
throw an exception when disengaged, but I'm suggesting to add the
correspondence of the "at()" function of some containers which throws
a well-defined exception (e.g. std::bad_optional). The name "at()" is
probably not a good idea (I'm only referring to it for comparison),
but get_value() or something else would seem appropriate.
- Daniel
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 23 Jan 2013 11:07:24 +0200
Raw View
On 23 January 2013 11:02, Nicol Bolas <jmckesson@gmail.com> wrote:
>> Do you have a practical use case for it?
>> Does everyone agree on adding get observer?
> Well, reference_wrapper has a `get` method even though it has an `operator
> T&` that does the same thing. So there is precident for always having a
> `get` method for objects which contain other objects.
Smart pointers have both operator-> and get(). You don't _need_ the get
if you want a minimal interface with no redundancy, just say
Foo* p = smartptr.operator->();
and watch your soul leave your body. I think it's a style issue whether
there's an operator* or a get(), and it's possibly reasonable to support
both. Do note that optional::get() and unique/shared_ptr::get() don't
have the same
semantics, which can be seen as confusing...
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Wed, 23 Jan 2013 01:13:23 -0800 (PST)
Raw View
------=_Part_3057_11096606.1358932403214
Content-Type: text/plain; charset=ISO-8859-1
> Do note that optional::get() and unique/shared_ptr::get() don't have the
> same
> semantics, which can be seen as confusing...
>
In hat sense? Do you mean the propagation of const-ness?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_3057_11096606.1358932403214
Content-Type: text/html; charset=ISO-8859-1
<br><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Do note that optional::get() and unique/shared_ptr::get() don't
have the same
<br>semantics, which can be seen as confusing...
<br></blockquote><div><br>In hat sense? Do you mean the propagation of const-ness?<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
------=_Part_3057_11096606.1358932403214--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 23 Jan 2013 11:17:46 +0200
Raw View
On 23 January 2013 11:13, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> wro=
te:
>> Do note that optional::get() and unique/shared_ptr::get() don't have the
>> same
>> semantics, which can be seen as confusing...
> In hat sense? Do you mean the propagation of const-ness?
I thought the get() for optional wouldn't return a pointer (unless
it's optional<T*>)?
Well, ok, in that sense, it just returns the underlying type, so in
language-lawyer
sense they are the same, but for the common uses probably not. I'm not sure
whether that's a problem. I have no strong opinion either way whether to ad=
d or
not to add a get(). It has downsides, too.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Wed, 23 Jan 2013 01:35:31 -0800 (PST)
Raw View
------=_Part_3015_14302503.1358933731729
Content-Type: text/plain; charset=ISO-8859-1
>
> I thought the get() for optional wouldn't return a pointer (unless
> it's optional<T*>)?
>
Ok, I guess I misunderstood Akira's sugestion. Boost.Optional provides the
following function:
T const& optional<T>::get() const
{
assert (is_initialized_)
return contained_value_;
}
In that case, it is obviously different than unique_ptr's get.
On the other hand, I received the following note from LWG discussion:
Jeffrey said that there's a "natural" .get() for optional that returns a
> pointer (or NULL if disengaged).
>
This implies a somewhat different semantics (compatible with unique_ptr's
get):
T const* optional<T>::get() const
{
return is_initialized_? addresof(contained_value_) : nullptr;
}
I somehow assumed the latter semantics. I see Daniel's suggestion as yet
another function, separate of this get.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_3015_14302503.1358933731729
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-l=
eft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: s=
olid;" class=3D"gmail_quote">
I thought the get() for optional wouldn't return a pointer (unless
<br>it's optional<T*>)?
<br></blockquote><div><br>Ok, I guess I misunderstood Akira's sugestion. Bo=
ost.Optional provides the following function:<br><div style=3D"border: 1px =
solid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250,=
250, 250);" class=3D"prettyprint"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by=
-prettify">T </span><span style=3D"color: rgb(0, 0, 136);" class=3D"styled-=
by-prettify">const</span><span style=3D"color: rgb(102, 102, 0);" class=3D"=
styled-by-prettify">&</span><span style=3D"color: rgb(0, 0, 0);" class=
=3D"styled-by-prettify"> optional</span><span style=3D"color: rgb(102, 102,=
0);" class=3D"styled-by-prettify"><</span><span style=3D"color: rgb(0, =
0, 0);" class=3D"styled-by-prettify">T</span><span style=3D"color: rgb(102,=
102, 0);" class=3D"styled-by-prettify">>::</span><span style=3D"color: =
rgb(0, 0, 136);" class=3D"styled-by-prettify">get</span><span style=3D"colo=
r: rgb(102, 102, 0);" class=3D"styled-by-prettify">()</span><span style=3D"=
color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: rgb(0, 0, 136);" class=3D"styled-by-prettify">const</span><span style=
=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> <br></span><span st=
yle=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">{</span><span=
style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br> </s=
pan><span style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify">ass=
ert</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"=
> </span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettif=
y">is_initialized_</span><span style=3D"color: rgb(102, 102, 0);" class=3D"=
styled-by-prettify">)</span><span style=3D"color: rgb(0, 0, 0);" class=3D"s=
tyled-by-prettify"><br> </span><span style=3D"color: rgb(0, 0, 136);"=
class=3D"styled-by-prettify">return</span><span style=3D"color: rgb(0, 0, =
0);" class=3D"styled-by-prettify"> contained_value_</span><span style=3D"co=
lor: rgb(102, 102, 0);" class=3D"styled-by-prettify">;</span><span style=3D=
"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">}</span><span st=
yle=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br></span></div>=
</code></div>In that case, it is obviously different than unique_ptr's get.=
<br><br>On the other hand, I received the following note from LWG discussio=
n: <br><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-le=
ft: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bor=
der-left-style: solid;" class=3D"gmail_quote">Jeffrey said that there's a "=
natural" .get() for optional that returns a pointer (or NULL if disengaged)=
..<br></blockquote><div><br>This implies a somewhat different semantics (com=
patible with unique_ptr's get):<br><div style=3D"border: 1px solid rgb(187,=
187, 187); word-wrap: break-word; background-color: rgb(250, 250, 250);" c=
lass=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettypri=
nt"><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">T </s=
pan><span style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify">con=
st</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-pretti=
fy">*</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettif=
y"> optional</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled=
-by-prettify"><</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styl=
ed-by-prettify">T</span><span style=3D"color: rgb(102, 102, 0);" class=3D"s=
tyled-by-prettify">>::</span><span style=3D"color: rgb(0, 0, 136);" clas=
s=3D"styled-by-prettify">get</span><span style=3D"color: rgb(102, 102, 0);"=
class=3D"styled-by-prettify">()</span><span style=3D"color: rgb(0, 0, 0);"=
class=3D"styled-by-prettify"> </span><span style=3D"color: rgb(0, 0, 136);=
" class=3D"styled-by-prettify">const</span><span style=3D"color: rgb(0, 0, =
0);" class=3D"styled-by-prettify"> <br></span><span style=3D"color: rgb(102=
, 102, 0);" class=3D"styled-by-prettify">{</span><span style=3D"color: rgb(=
0, 0, 0);" class=3D"styled-by-prettify"><br> </span><span style=3D"co=
lor: rgb(0, 0, 136);" class=3D"styled-by-prettify">return</span><span style=
=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> is_initialized_</sp=
an><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">?<=
/span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> ad=
dresof</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-pre=
ttify"><code class=3D"prettyprint"><span style=3D"color: rgb(0, 0, 0);" cla=
ss=3D"styled-by-prettify">contained_value_</span><span style=3D"color: rgb(=
102, 102, 0);" class=3D"styled-by-prettify">) : nullptr;</span></code></spa=
n><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify"></s=
pan><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br><=
/span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify"=
>}</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">=
<br></span></div></code></div><br>I somehow assumed the latter semantics. I=
see Daniel's suggestion as yet another function, separate of this <span st=
yle=3D"font-family: courier new,monospace;">get</span>.<br><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_3015_14302503.1358933731729--
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Wed, 23 Jan 2013 02:57:42 -0800 (PST)
Raw View
------=_Part_386_8675392.1358938662285
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, January 23, 2013 8:18:49 AM UTC+11, Andrzej Krzemie=C5=84ski =
wrote:
>
> Hi Everyone,
> We are ready with the 3rd revision of std::optional proposal. The main=20
> changes:
>
> - optional<T> is hashable for hashable T=E2=80=99s.
> - Removed optional references =E2=80=94 they will be proposed separate=
ly.
> - get_value_or is now optional-specific member function.
> - optional<T> is a literal type.
> - Removed reference implementation. We now only provide the=20
> implementation of the parts that we consider non-trivial.
>
> We would appreciate your feedback and suggestions.
>
optional<Guard> ogb(emplace, "res1");
optional<Guard> ogc(emplace); =20
oga.emplace("res1"); =20
oga.emplace(); =20
I most likely missed when the function emplace has been introduced. Could=
=20
someone remind me why the following interface was not accepted:
optional<Guard> ogb(emplace, "res1"); // as above
optional<Guard> ogc(emplace); // as above
oga(emplace, "res1"); =20
oga(emplace); =20
The 2 lines above do what the function=20
emplace does but without extending api's vocabulary and consistently with=
=20
the previous 2 lines. API consistency (i.e. predictability) and minimalism=
=20
quite important. Just my 2c... We probably discussed it already.=20
V.
=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_386_8675392.1358938662285
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, January 23, 2013 8:18:49 AM UTC+11, Andrzej Krzemie=C5=84ski =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi Everyone,<br>We are r=
eady with the 3rd revision of std::optional proposal. The main changes:<br>=
<ul><li><code>optional<T></code> is hashable for hashable <code>T</co=
de>=E2=80=99s.</li><li>Removed optional references =E2=80=94 they will be p=
roposed separately.</li><li><code>get_value_or</code> is now <code>optional=
</code>-specific member function.</li><li><code>optional<T></code> is=
a literal type.</li><li>Removed reference implementation. We now only prov=
ide the implementation of the parts that we consider non-trivial.</li></ul>=
We would appreciate your feedback and suggestions.<br></blockquote><div><br=
><pre>optional<Guard> ogb(emplace, "res1");
optional<Guard> ogc(emplace); =20
oga.emplace("res1"); =20
oga.emplace(); =20
</pre><p></p><p>I most likely missed when the function <code>emplace</code>=
has been introduced. Could someone remind me why the following interface w=
as not accepted:<br></p>
<pre>optional<Guard> ogb(emplace, "res1"); // as above
optional<Guard> ogc(emplace); // as above
oga(emplace, "res1"); =20
oga(emplace); <br><br> =20
</pre>The 2 lines above do what the function <code>emplace</code> does but =
without extending api's vocabulary and consistently with the previous 2 lin=
es. API consistency (i.e. predictability) and minimalism quite important. J=
ust my 2c... We probably discussed it already. <br><br>V.<br> </div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_386_8675392.1358938662285--
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Wed, 23 Jan 2013 03:04:57 -0800 (PST)
Raw View
------=_Part_732_23861050.1358939097075
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, January 23, 2013 8:07:24 PM UTC+11, Ville Voutilainen wrote:
...
> Smart pointers have both operator-> and get(). You don't _need_ the get
> if you want a minimal interface with no redundancy, just say
> Foo* p = smartptr.operator->();
> and watch your soul leave your body.
Or Foo* p = &*smartptr;
Given anyone knows what & and * operators do, it's quite readable -- get
the address of dereferenced smart ptr which is, obviously, the underlying
object. So, no need (as it seems) for get(). IMO the more I can do wit the
standard set of operators (like op&, op*, op(), etc)the better.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_732_23861050.1358939097075
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Wednesday, January 23, 2013 8:07:24 PM UTC+11, Ville Voutilainen wrote:<=
div> ...</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Smart point=
ers have both operator-> and get(). You don't _need_ the get
<br>if you want a minimal interface with no redundancy, just say
<br>Foo* p =3D smartptr.operator->();
<br>and watch your soul leave your body. </blockquote><div><br>Or Foo* p =
=3D &*smartptr;<br><br>Given anyone knows what & and * operators do=
, it's quite readable -- get the address of dereferenced smart ptr which is=
, obviously, the underlying object. So, no need (as it seems) for get(). IM=
O the more I can do wit the standard set of operators (like op&, op*, o=
p(), etc)the better.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_732_23861050.1358939097075--
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Wed, 23 Jan 2013 03:24:36 -0800 (PST)
Raw View
------=_Part_39_21097630.1358940276505
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, January 23, 2013 8:35:31 PM UTC+11, Andrzej Krzemie=C5=84ski =
wrote:
>
> I thought the get() for optional wouldn't return a pointer (unless=20
>> it's optional<T*>)?=20
>>
>
> Ok, I guess I misunderstood Akira's sugestion. Boost.Optional provides th=
e=20
> following function:
> T const& optional<T>::get() const=20
> {
> assert (is_initialized_)
> return contained_value_;
> }
> In that case, it is obviously different than unique_ptr's get.
>
> On the other hand, I received the following note from LWG discussion: =20
>
> Jeffrey said that there's a "natural" .get() for optional that returns a=
=20
>> pointer (or NULL if disengaged).
>>
>
> This implies a somewhat different semantics (compatible with unique_ptr's=
=20
> get):
> T const* optional<T>::get() const=20
> {
> return is_initialized_? addresof(contained_value_) : nullptr;
> }
>
> I somehow assumed the latter semantics. I see Daniel's suggestion as yet=
=20
> another function, separate of this get.
>
I am personally far from convinced that get() is necessary and "natural"=20
for optional. Providing get() legitimizes getting the address of the=20
underlying object which is IMO is conceptually wrong and error-prone. =20
=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_39_21097630.1358940276505
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, January 23, 2013 8:35:31 PM UTC+11, Andrzej Krzemie=C5=84ski =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><blockquote style=3D"mar=
gin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);b=
order-left-width:1px;border-left-style:solid" class=3D"gmail_quote">
I thought the get() for optional wouldn't return a pointer (unless
<br>it's optional<T*>)?
<br></blockquote><div><br>Ok, I guess I misunderstood Akira's sugestion. Bo=
ost.Optional provides the following function:<br><div style=3D"border:1px s=
olid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,250,250=
)"><code><div><span style=3D"color:rgb(0,0,0)">T </span><span style=3D"colo=
r:rgb(0,0,136)">const</span><span style=3D"color:rgb(102,102,0)">&</spa=
n><span style=3D"color:rgb(0,0,0)"> optional</span><span style=3D"color:rgb=
(102,102,0)"><</span><span style=3D"color:rgb(0,0,0)">T</span><span styl=
e=3D"color:rgb(102,102,0)">>::</span><span style=3D"color:rgb(0,0,136)">=
get</span><span style=3D"color:rgb(102,102,0)">()</span><span style=3D"colo=
r:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">const</span><span =
style=3D"color:rgb(0,0,0)"> <br></span><span style=3D"color:rgb(102,102,0)"=
>{</span><span style=3D"color:rgb(0,0,0)"><br> </span><span style=3D"=
color:rgb(0,0,136)">assert</span><span style=3D"color:rgb(0,0,0)"> </span><=
span style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,0)=
">is_initialized_</span><span style=3D"color:rgb(102,102,0)">)</span><span =
style=3D"color:rgb(0,0,0)"><br> </span><span style=3D"color:rgb(0,0,1=
36)">return</span><span style=3D"color:rgb(0,0,0)"> contained_value_</span>=
<span style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0=
)"><br></span><span style=3D"color:rgb(102,102,0)">}</span><span style=3D"c=
olor:rgb(0,0,0)"><br></span></div></code></div>In that case, it is obviousl=
y different than unique_ptr's get.<br><br>On the other hand, I received the=
following note from LWG discussion: <br><br><blockquote style=3D"mar=
gin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);b=
order-left-width:1px;border-left-style:solid" class=3D"gmail_quote">Jeffrey=
said that there's a "natural" .get() for optional that returns a pointer (=
or NULL if disengaged).<br></blockquote><div><br>This implies a somewhat di=
fferent semantics (compatible with unique_ptr's get):<br><div style=3D"bord=
er:1px solid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250=
,250,250)"><code><div><span style=3D"color:rgb(0,0,0)">T </span><span style=
=3D"color:rgb(0,0,136)">const</span><span style=3D"color:rgb(102,102,0)">*<=
/span><span style=3D"color:rgb(0,0,0)"> optional</span><span style=3D"color=
:rgb(102,102,0)"><</span><span style=3D"color:rgb(0,0,0)">T</span><span =
style=3D"color:rgb(102,102,0)">>::</span><span style=3D"color:rgb(0,0,13=
6)">get</span><span style=3D"color:rgb(102,102,0)">()</span><span style=3D"=
color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">const</span><s=
pan style=3D"color:rgb(0,0,0)"> <br></span><span style=3D"color:rgb(102,102=
,0)">{</span><span style=3D"color:rgb(0,0,0)"><br> </span><span style=
=3D"color:rgb(0,0,136)">return</span><span style=3D"color:rgb(0,0,0)"> is_i=
nitialized_</span><span style=3D"color:rgb(102,102,0)">?</span><span style=
=3D"color:rgb(0,0,0)"> addresof</span><span style=3D"color:rgb(102,102,0)">=
(</span><span style=3D"color:rgb(0,0,0)"><code><span style=3D"color:rgb(0,0=
,0)">contained_value_</span><span style=3D"color:rgb(102,102,0)">) : nullpt=
r;</span></code></span><span style=3D"color:rgb(102,102,0)"></span><span st=
yle=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(102,102,0)">}<=
/span><span style=3D"color:rgb(0,0,0)"><br></span></div></code></div><br>I =
somehow assumed the latter semantics. I see Daniel's suggestion as yet anot=
her function, separate of this <span style=3D"font-family:courier new,monos=
pace">get</span>.<br></div></div></blockquote><div><br>I am personally far =
from convinced that get() is necessary and "natural" for optional. Providin=
g get() legitimizes getting the address of the underlying object which is I=
MO is conceptually wrong and error-prone. <br></div><div><br> </=
div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_39_21097630.1358940276505--
.
Author: =?UTF-8?Q?R=C3=B3bert_D=C3=A1vid?= <lrdxgm@gmail.com>
Date: Wed, 23 Jan 2013 03:43:35 -0800 (PST)
Raw View
------=_Part_654_6962416.1358941415288
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
Hello,
I don't see the get_value_or variant (last name was something like=20
get_value_or_call) that calls the parameter / parameter's operator() (only)=
=20
if the optional does not contain value. I thought you liked the idea, any=
=20
reason why is it missing? I'd guess the details are missing - I'll figure=
=20
out them. I would still like that feature.
I love code so example:
void doCalc() {
const std::optional<Foo>& fooOpt =3D getOptions().getFoo();
const Foo foo =3D fooOpt.get_value_or_call([]{ returnlengthyCalculation=
OfFooFromOtherOptions
(); });
/* do lots of stuff with foo */
}
While possible, it is messy and/or verbose to make foo const without this=
=20
function if I want to avoid calling lengthyCalculationOfFooFromOtherOptions=
all the time..
Regards,
Robert
2013. janu=E1r 22., kedd 22:18:49 UTC+1 id=F5pontban Andrzej Krzemie=F1ski =
a=20
k=F6vetkez=F5t =EDrta:
>
> Hi Everyone,
> We are ready with the 3rd revision of std::optional proposal. The main=20
> changes:
>
> - optional<T> is hashable for hashable T's.
> - Removed optional references -- they will be proposed separately.
> - get_value_or is now optional-specific member function.
> - optional<T> is a literal type.
> - Removed reference implementation. We now only provide the=20
> implementation of the parts that we consider non-trivial.
>
> We would appreciate your feedback and suggestions.
>
> Regards,
> &rzej
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_654_6962416.1358941415288
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hello,<br><br>I don't see the get_value_or variant (last name was something=
like get_value_or_call) that calls the parameter / parameter's operator() =
(only) if the optional does not contain value. I thought you liked the idea=
, any reason why is it missing? I'd guess the details are missing - I'll fi=
gure out them. I would still like that feature.<br><br>I love code so examp=
le:<br><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"prettyprint"><div class=3D"subp=
rettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">void<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> doCalc</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br> </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">const</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">::</span><span 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: #606;" class=3D"st=
yled-by-prettify">Foo</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">>&</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> fooOpt </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> getOptions</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">().</span><span style=3D"color: #000;" class=3D"styled-by-prettify">getFo=
o</span><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>  =
; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">const</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #606;" class=3D"styled-by-prettify">Foo</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> foo </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> fooOpt</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">get_value_or_call</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">([]{</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> lengthyCalculationOfFooFromOtherOptions</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">();</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">});</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br> </span><span style=3D"color: #800;" cl=
ass=3D"styled-by-prettify">/* do lots of stuff with foo */</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span></div></code></div>While possib=
le, it is messy and/or verbose to make <span style=3D"font-family: cou=
rier new,monospace;">foo const</span> without this function if I want to av=
oid calling <span style=3D"font-family: courier new,monospace;"><code class=
=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">=
lengthyCalculationOfFooFromOtherOptions</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify"></span></code></span><code class=3D"prettyprin=
t"><span style=3D"color: #660;" class=3D"styled-by-prettify"> all the time.=
..</span></code><br><br>Regards,<br>Robert<br><br>2013. janu=C3=A1r 22., ked=
d 22:18:49 UTC+1 id=C5=91pontban Andrzej Krzemie=C5=84ski a k=C3=B6vetkez=
=C5=91t =C3=ADrta:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi Everyone,=
<br>We are ready with the 3rd revision of std::optional proposal. The main =
changes:<br><ul><li><code>optional<T></code> is hashable for hashable=
<code>T</code>=E2=80=99s.</li><li>Removed optional references =E2=80=94 th=
ey will be proposed separately.</li><li><code>get_value_or</code> is now <c=
ode>optional</code>-specific member function.</li><li><code>optional<T&g=
t;</code> is a literal type.</li><li>Removed reference implementation. We n=
ow only provide the implementation of the parts that we consider non-trivia=
l.</li></ul>We would appreciate your feedback and suggestions.<br><br>Regar=
ds,<br>&rzej<br></blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_654_6962416.1358941415288--
.
Author: Chris Jefferson <chris@bubblescope.net>
Date: Wed, 23 Jan 2013 11:57:40 +0000
Raw View
This is a multi-part message in MIME format.
--------------050606010508000705070008
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: quoted-printable
On 23/01/13 11:43, R=F3bert D=E1vid wrote:
> Hello,
>
> I don't see the get_value_or variant (last name was something like=20
> get_value_or_call) that calls the parameter / parameter's operator()=20
> (only) if the optional does not contain value. I thought you liked the=20
> idea, any reason why is it missing? I'd guess the details are missing=20
> - I'll figure out them. I would still like that feature.
I think the problem was that get_value_or_call either has to return by=20
value (which involves possibly expensive copying) or by reference (which=20
involves possibly hanging references to the 'or' value).
Your get_value_or_call function avoids constructing the 'or' object=20
which it is not required, but still involves copying. There is no good=20
reason for this not to be a free function, so I wonder if this is one=20
area where we should see what people end up using, and standardise later?
Chris
>
> I love code so example:
> |
> voiddoCalc(){
> conststd::optional<Foo>&fooOpt =3DgetOptions().getFoo();
> constFoofoo=20
> =3DfooOpt.get_value_or_call([]{returnlengthyCalculationOfFooFromOtherOpti=
ons();});
> /* do lots of stuff with foo */
> }
> |
> While possible, it is messy and/or verbose to make foo const without=20
> this function if I want to avoid calling=20
> |lengthyCalculationOfFooFromOtherOptions||all the time..|
>
> Regards,
> Robert
>
> 2013. janu=E1r 22., kedd 22:18:49 UTC+1 id=F5pontban Andrzej Krzemie=F1sk=
i a=20
> k=F6vetkez=F5t =EDrta:
>
> Hi Everyone,
> We are ready with the 3rd revision of std::optional proposal. The
> main changes:
>
> * |optional<T>| is hashable for hashable |T|'s.
> * Removed optional references -- they will be proposed separately.
> * |get_value_or| is now |optional|-specific member function.
> * |optional<T>| is a literal type.
> * Removed reference implementation. We now only provide the
> implementation of the parts that we consider non-trivial.
>
> We would appreciate your feedback and suggestions.
>
> Regards,
> &rzej
>
> --=20
>
> ---
> You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> To post to this group, send email to std-proposals@isocpp.org.
> To unsubscribe from this group, send email to=20
> std-proposals+unsubscribe@isocpp.org.
> Visit this group at=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=3Den.
>
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
--------------050606010508000705070008
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"moz-cite-prefix">On 23/01/13 11:43, R=F3bert D=E1vid wrot=
e:<br>
</div>
<blockquote
cite=3D"mid:8baecb97-a0dc-466e-8b7c-ef0d72d1fc83@isocpp.org"
type=3D"cite">Hello,<br>
<br>
I don't see the get_value_or variant (last name was something like
get_value_or_call) that calls the parameter / parameter's
operator() (only) if the optional does not contain value. I
thought you liked the idea, any reason why is it missing? I'd
guess the details are missing - I'll figure out them. I would
still like that feature.<br>
</blockquote>
<br>
I think the problem was that get_value_or_call either has to return
by value (which involves possibly expensive copying) or by reference
(which involves possibly hanging references to the 'or' value).<br>
<br>
Your get_value_or_call function avoids constructing the 'or' object
which it is not required, but still involves copying. There is no
good reason for this not to be a free function, so I wonder if this
is one area where we should see what people end up using, and
standardise later?<br>
<br>
Chris<br>
<br>
<blockquote
cite=3D"mid:8baecb97-a0dc-466e-8b7c-ef0d72d1fc83@isocpp.org"
type=3D"cite"><br>
I love code so example:<br>
<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"prettyprint">
<div class=3D"subprettyprint"><span style=3D"color: #008;"
class=3D"styled-by-prettify">void</span><span style=3D"color:
#000;" class=3D"styled-by-prettify"> doCalc</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">()</span>=
<span
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span
style=3D"color: #660;" class=3D"styled-by-prettify">{</span><=
span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
</span><span style=3D"color: #008;"
class=3D"styled-by-prettify">const</span><span style=3D"color=
:
#000;" class=3D"styled-by-prettify"> std</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">::</span>=
<span
style=3D"color: #000;" class=3D"styled-by-prettify">optional<=
/span><span
style=3D"color: #660;" class=3D"styled-by-prettify"><</spa=
n><span
style=3D"color: #606;" class=3D"styled-by-prettify">Foo</span=
><span
style=3D"color: #660;" class=3D"styled-by-prettify">>&=
</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> fooOpt <=
/span><span
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span=
><span
style=3D"color: #000;" class=3D"styled-by-prettify">
getOptions</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">().</span><span style=3D"color:
#000;" class=3D"styled-by-prettify">getFoo</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">();</span=
><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
</span><span style=3D"color: #008;"
class=3D"styled-by-prettify">const</span><span style=3D"color=
:
#000;" class=3D"styled-by-prettify"> </span><span
style=3D"color: #606;" class=3D"styled-by-prettify">Foo</span=
><span
style=3D"color: #000;" class=3D"styled-by-prettify"> foo </sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span=
><span
style=3D"color: #000;" class=3D"styled-by-prettify"> fooOpt</=
span><span
style=3D"color: #660;" class=3D"styled-by-prettify">.</span><=
span
style=3D"color: #000;" class=3D"styled-by-prettify">get_value=
_or_call</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">([]{</spa=
n><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span
style=3D"color: #008;" class=3D"styled-by-prettify">return</s=
pan><span
style=3D"color: #000;" class=3D"styled-by-prettify">
lengthyCalculationOfFooFromOtherOptions</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">();</span=
><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span
style=3D"color: #660;" class=3D"styled-by-prettify">});</span=
><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
</span><span style=3D"color: #800;"
class=3D"styled-by-prettify">/* do lots of stuff with foo */<=
/span><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">}</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
</span></div>
</code></div>
While possible, it is messy and/or verbose to make <span
style=3D"font-family: courier new,monospace;">foo const</span>
without this function if I want to avoid calling <span
style=3D"font-family: courier new,monospace;"><code
class=3D"prettyprint"><span style=3D"color: #000;"
class=3D"styled-by-prettify">lengthyCalculationOfFooFromOtherOp=
tions</span><span
style=3D"color: #660;" class=3D"styled-by-prettify"></span></co=
de></span><code
class=3D"prettyprint"><span style=3D"color: #660;"
class=3D"styled-by-prettify"> all the time..</span></code><br>
<br>
Regards,<br>
Robert<br>
<br>
2013. janu=E1r 22., kedd 22:18:49 UTC+1 id=F5pontban Andrzej
Krzemie=F1ski a k=F6vetkez=F5t =EDrta:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi
Everyone,<br>
We are ready with the 3rd revision of std::optional proposal.
The main changes:<br>
<ul>
<li><code>optional<T></code> is hashable for hashable <code=
>T</code>’s.</li>
<li>Removed optional references — they will be proposed
separately.</li>
<li><code>get_value_or</code> is now <code>optional</code>-specif=
ic
member function.</li>
<li><code>optional<T></code> is a literal type.</li>
<li>Removed reference implementation. We now only provide the
implementation of the parts that we consider non-trivial.</li>
</ul>
We would appreciate your feedback and suggestions.<br>
<br>
Regards,<br>
&rzej<br>
</blockquote>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.<br>
To post to this group, send email to <a class=3D"moz-txt-link-abbrevi=
ated" href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>=
..<br>
To unsubscribe from this group, send email to
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:std-proposals+un=
subscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br>
Visit this group at <a moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/?=
hl=3Den">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=3Den=
</a>.<br>
<br>
<br>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--------------050606010508000705070008--
.
Author: Nikolay Ivchenkov <tsoae@mail.ru>
Date: Wed, 23 Jan 2013 04:12:04 -0800 (PST)
Raw View
------=_Part_295_21409658.1358943124636
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, January 23, 2013 12:56:16 PM UTC+4, Andrzej Krzemie=C5=84ski =
wrote:
>
> I want `optional::get()` member function. (the member exist in=20
> `boost::optional`)
>
> One of the goals for the design was not to introduce any redundancy in th=
e=20
> interface. This is the answer to the former question, and also partially =
to=20
> the latter. This is the second time, the observer function get is=20
> requested. I am personally a bit uneasy about introducing this, mostly=20
> because of the overlap in functionality with other members and little=20
> offered benefit on the other hand.
>
There are people who find calls to get() more readable than the dereference=
=20
notation.
optional<map_iterator> *p;
....
if (p && p->get())
{
auto &&value =3D p->get()->second;
//auto &&value =3D (***p).second;
....
}
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_295_21409658.1358943124636
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, January 23, 2013 12:56:16 PM UTC+4, Andrzej Krzemie=C5=84ski =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><d=
iv>I want `optional::get()` member function. (the member exist in `boost::o=
ptional`)</div></div></div><div><div><br>One of the goals for the design wa=
s not to introduce any redundancy in the interface. This is the answer to t=
he former question, and also partially to the latter. This is the second ti=
me, the observer function <span style=3D"font-family:courier new,monospace"=
>get </span>is requested. I am personally a bit uneasy about introducing th=
is, mostly because of the overlap in functionality with other members and l=
ittle offered benefit on the other hand.<br></div></div></blockquote><div><=
br>There are people who find calls to get() more readable than the derefere=
nce notation.<br><br> optional<map_iterator> *p;<br=
> ....<br> if (p && p->get()=
)<br> {<br> aut=
o &&value =3D p->get()->second;<br> &n=
bsp; //auto &&value =3D (***p).second;<br> &=
nbsp; ....<br> }</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_295_21409658.1358943124636--
.
Author: Nikolay Ivchenkov <tsoae@mail.ru>
Date: Wed, 23 Jan 2013 04:22:27 -0800 (PST)
Raw View
------=_Part_237_28948668.1358943747250
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, January 23, 2013 12:56:16 PM UTC+4, Andrzej Krzemie=C5=84ski =
wrote:
>
>
> I want `optional::get()` member function. (the member exist in=20
>> `boost::optional`)
>>
>
> One of the goals for the design was not to introduce any redundancy in th=
e=20
> interface. This is the answer to the former question, and also partially =
to=20
> the latter. This is the second time, the observer function get is=20
> requested. I am personally a bit uneasy about introducing this, mostly=20
> because of the overlap in functionality with other members and little=20
> offered benefit on the other hand.
>
There are people who find calls to get() more readable than the dereference=
=20
notation.
optional<map_iterator> *p;
....
if (p && *p)
{
auto &&value =3D p->get()->second;
//auto &&value =3D (***p).second;
....
}=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_237_28948668.1358943747250
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, January 23, 2013 12:56:16 PM UTC+4, Andrzej Krzemie=C5=84ski =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br><div><blockquote cla=
ss=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>I want `optional::get()=
` member function. (the member exist in `boost::optional`)</div></div></div=
></blockquote><div><br>One of the goals for the design was not to introduce=
any redundancy in the interface. This is the answer to the former question=
, and also partially to the latter. This is the second time, the observer f=
unction <span style=3D"font-family:courier new,monospace">get </span>is req=
uested. I am personally a bit uneasy about introducing this, mostly because=
of the overlap in functionality with other members and little offered bene=
fit on the other hand.</div></div></blockquote><div><br>There are people wh=
o find calls to get() more readable than the dereference notation.<br><br>&=
nbsp; optional<map_iterator> *p;<br> ..=
...<br> if (p && *p)<br> {<br>&n=
bsp; auto &&value =3D p->get=
()->second;<br> //auto &&a=
mp;value =3D (***p).second;<br> .=
....<br> } <br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_237_28948668.1358943747250--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 23 Jan 2013 15:06:30 +0200
Raw View
On 23 January 2013 13:24, Vladimir Batov <vb.mail.247@gmail.com> wrote:
> I am personally far from convinced that get() is necessary and "natural" for
> optional. Providing get() legitimizes getting the address of the underlying
> object which is IMO is conceptually wrong and error-prone.
Perhaps get() should return a reference to the underlying object
rather than a pointer.
At any rate, for people who want the address of the underlying object, I find
foo.operator->() or &*foo very unfortunate solutions. Even &foo.get() would be
better, or if we go for the address, just foo.get(). I don't consider
it conceptually
wrong, and I certainly don't find foo.get() or &foo.get() more error prone than
&*foo, quite the opposite.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Wed, 23 Jan 2013 05:08:09 -0800 (PST)
Raw View
------=_Part_2954_605300.1358946489800
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu =B6roda, 23 stycznia 2013 13:22:27 UTC+1 u=BFytkownik Nikolay Ivchen=
kov=20
napisa=B3:
>
> On Wednesday, January 23, 2013 12:56:16 PM UTC+4, Andrzej Krzemie=F1ski=
=20
> wrote:
>>
>>
>> I want `optional::get()` member function. (the member exist in=20
>>> `boost::optional`)
>>>
>>
>> One of the goals for the design was not to introduce any redundancy in=
=20
>> the interface. This is the answer to the former question, and also=20
>> partially to the latter. This is the second time, the observer function =
get=20
>> is requested. I am personally a bit uneasy about introducing this, mostl=
y=20
>> because of the overlap in functionality with other members and little=20
>> offered benefit on the other hand.
>>
>
> There are people who find calls to get() more readable than the=20
> dereference notation.
>
> optional<map_iterator> *p;
> ....
> if (p && *p)
> {
> auto &&value =3D p->get()->second;
> //auto &&value =3D (***p).second;
> ....
> }=20
>
Would it work for you, if we forget the name get (it may imply that we are=
=20
returning a pointer), and provide function value instead with the semantics=
=20
suggested by Daniel:
T const& optional<T>::value() const
{
if (is_initialized)=20
rerurn contained_value_;
else=20
throw invalid_optional_value_access{};=20
}
The semantics are different than operator* (the extra performance penalty),=
=20
but we do not have to provide yet another function.=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_2954_605300.1358946489800
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu =B6roda, 23 stycznia 2013 13:22:27 UTC+1 u=BFytkownik Nikola=
y Ivchenkov napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wedne=
sday, January 23, 2013 12:56:16 PM UTC+4, Andrzej Krzemie=F1ski wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><br><div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div><div>I want `optional::get()` member functio=
n. (the member exist in `boost::optional`)</div></div></div></blockquote><d=
iv><br>One of the goals for the design was not to introduce any redundancy =
in the interface. This is the answer to the former question, and also parti=
ally to the latter. This is the second time, the observer function <span st=
yle=3D"font-family:courier new,monospace">get </span>is requested. I am per=
sonally a bit uneasy about introducing this, mostly because of the overlap =
in functionality with other members and little offered benefit on the other=
hand.</div></div></blockquote><div><br>There are people who find calls to =
get() more readable than the dereference notation.<br><br>  =
; optional<map_iterator> *p;<br> ....<br> &nbs=
p; if (p && *p)<br> {<br> =
auto &&value =3D p->get()->second;<b=
r> //auto &&value =3D (**=
*p).second;<br> ....<br> &nb=
sp; } <br></div></blockquote><div><br>Would it work for you, if we fo=
rget the name <span style=3D"font-family: courier new,monospace;">get </spa=
n>(it may imply that we are returning a pointer), and provide function <spa=
n style=3D"font-family: courier new,monospace;">value</span> instead with t=
he semantics suggested by Daniel:<br><br><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"><span style=3D"color: #000;=
" class=3D"styled-by-prettify">T </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">const</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">&</span><span 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: #000;" class=3D"styled-by-pre=
ttify">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&g=
t;::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">value<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br> </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">if</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">is_initialized</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <b=
r> rerurn contained_value_</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">else</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> <br> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">throw</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> invalid_optional_value_access</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">{}</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> <br></span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span></div></code></div><br>The semantics are different tha=
n operator* (the extra performance penalty), but we do not have to provide =
yet another function. <br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_2954_605300.1358946489800--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 23 Jan 2013 15:10:28 +0200
Raw View
On 23 January 2013 15:08, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> wro=
te:
> Would it work for you, if we forget the name get (it may imply that we ar=
e
> returning a pointer), and provide function value instead with the semanti=
cs
> suggested by Daniel:
> T const& optional<T>::value() const
> {
> if (is_initialized)
> rerurn contained_value_;
> else
> throw invalid_optional_value_access{};
> }
> The semantics are different than operator* (the extra performance penalty=
),
> but we do not have to provide yet another function.
Works for me, I quite like this idea.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Wed, 23 Jan 2013 05:48:41 -0800 (PST)
Raw View
------=_Part_65_33235283.1358948921466
Content-Type: text/plain; charset=ISO-8859-1
>
> optional<Guard> ogb(emplace, "res1");
> optional<Guard> ogc(emplace);
>
> oga.emplace("res1");
> oga.emplace();
>
> I most likely missed when the function emplace has been introduced. Could
> someone remind me why the following interface was not accepted:
>
> optional<Guard> ogb(emplace, "res1"); // as above
> optional<Guard> ogc(emplace); // as above
>
> oga(emplace, "res1");
> oga(emplace);
>
> The 2 lines above do what the function
> emplace does but without extending api's vocabulary and consistently with
> the previous 2 lines. API consistency (i.e. predictability) and minimalism
> quite important. Just my 2c... We probably discussed it already.
>
Indeed, you already suggested it before:
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/cXneqUj-5oo/AivbM3GggfUJ
..
Now that I think of it, I have some reservations for it, although I cannot
provide objective arguments against it. This feels like an overuse of
function-call operator. It also looks less uniform if people start using
the new initialization syntax.
optional<Guard> og{emplace, "res1"};
og(emplace, "res1"); // still looks similar?
Apart from this, the suggestion is implementable and unambiguous. I would
like to hear what others think.
&rzej
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_65_33235283.1358948921466
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div><pre>optional<Guard>=
; ogb(emplace, "res1");
optional<Guard> ogc(emplace); =20
oga.emplace("res1"); =20
oga.emplace(); =20
</pre><p></p><p>I most likely missed when the function <code>emplace</code>=
has been introduced. Could someone remind me why the following interface w=
as not accepted:<br></p>
<pre>optional<Guard> ogb(emplace, "res1"); // as above
optional<Guard> ogc(emplace); // as above
oga(emplace, "res1"); =20
oga(emplace); <br><br> =20
</pre>The 2 lines above do what the function <code>emplace</code> does but =
without extending api's vocabulary and consistently with the previous 2 lin=
es. API consistency (i.e. predictability) and minimalism quite important. J=
ust my 2c... We probably discussed it already. <br></div></blockquote><div>=
<br>Indeed, you already suggested it before: <a href=3D"https://groups.goog=
le.com/a/isocpp.org/d/msg/std-proposals/cXneqUj-5oo/AivbM3GggfUJ">https://g=
roups.google.com/a/isocpp.org/d/msg/std-proposals/cXneqUj-5oo/AivbM3GggfUJ<=
/a>.<br><br>Now that I think of it, I have some reservations for it, althou=
gh I cannot provide objective arguments against it. This feels like an over=
use of function-call operator. It also looks less uniform if people start u=
sing the new initialization syntax.<br><br><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"><pre><span style=3D"color: =
#000;" class=3D"styled-by-prettify">optional</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify"><</span><span style=3D"color: #606;" c=
lass=3D"styled-by-prettify">Guard</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> og</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">emplace</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #080;" class=3D"styled-by-prettify">"res1"</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>og</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">emplace</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-=
prettify">"res1"</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #800;" class=3D"styled-by-prettify">// still lo=
oks similar? </span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span></pre></div><=
/code></div><br>Apart from this, the suggestion is implementable and unambi=
guous. I would like to hear what others think.<br><br>&rzej<br><br></di=
v><div> </div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_65_33235283.1358948921466--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Wed, 23 Jan 2013 14:58:49 +0100
Raw View
2013/1/23 Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com>:
>> optional<Guard> ogb(emplace, "res1");
>> optional<Guard> ogc(emplace);
>>
>> oga.emplace("res1");
>> oga.emplace();
>>
>> I most likely missed when the function emplace has been introduced. Coul=
d
>> someone remind me why the following interface was not accepted:
>>
>> optional<Guard> ogb(emplace, "res1"); // as above
>> optional<Guard> ogc(emplace); // as above
>>
>> oga(emplace, "res1");
>> oga(emplace);
>>
>>
>>
>> The 2 lines above do what the function emplace does but without extendin=
g
>> api's vocabulary and consistently with the previous 2 lines. API consist=
ency
>> (i.e. predictability) and minimalism quite important. Just my 2c... We
>> probably discussed it already.
>
> Indeed, you already suggested it before:
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/cXneqUj-5oo/Ai=
vbM3GggfUJ.
>
> Now that I think of it, I have some reservations for it, although I canno=
t
> provide objective arguments against it. This feels like an overuse of
> function-call operator. It also looks less uniform if people start using =
the
> new initialization syntax.
>
> optional<Guard> og{emplace, "res1"};
> og(emplace, "res1"); // still looks similar?
>
> Apart from this, the suggestion is implementable and unambiguous. I would
> like to hear what others think.
IMO this is abusing the intend of the operator() overload. Usually we
typically provide it to provide a notational convenience that matches
the concept characteristics of the actual type, such as that of a
function in std::function or std::reference_wrapper. The existence of
the emplace member function and the (necessary) emplace tag provided
for the constructor looks like a sufficient solution to me that is
also easy to teach.
- Daniel
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 23 Jan 2013 16:00:48 +0200
Raw View
On 23 January 2013 15:58, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wrot=
e:
> IMO this is abusing the intend of the operator() overload. Usually we
> typically provide it to provide a notational convenience that matches
> the concept characteristics of the actual type, such as that of a
> function in std::function or std::reference_wrapper. The existence of
> the emplace member function and the (necessary) emplace tag provided
> for the constructor looks like a sufficient solution to me that is
> also easy to teach.
+1. Using a function call operator for what is effectively assignment gener=
ated
a WTF in my brain when I saw it.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 23 Jan 2013 10:54:48 -0500
Raw View
On Wed, Jan 23, 2013 at 9:00 AM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 23 January 2013 15:58, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wr=
ote:
>> IMO this is abusing the intend of the operator() overload. Usually we
>> typically provide it to provide a notational convenience that matches
>> the concept characteristics of the actual type, such as that of a
>> function in std::function or std::reference_wrapper. The existence of
>> the emplace member function and the (necessary) emplace tag provided
>> for the constructor looks like a sufficient solution to me that is
>> also easy to teach.
>
> +1. Using a function call operator for what is effectively assignment gen=
erated
> a WTF in my brain when I saw it.
>
> --
And if you had
optional<functionlike> fn;
fn(some, params);
I might think it was calling operator() on the contained value.
ie
fn(emplace, foo)
vs
(*fn)(emplace, foo)
Who would recognize those as completely different?
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Wed, 23 Jan 2013 12:06:07 -0600
Raw View
On Wed, Jan 23, 2013 at 9:54 AM, Tony V E <tvaneerd@gmail.com> wrote:
> optional<functionlike> fn;
Please consider to treat a std::optional<callable> callable, like
std::ref, by defining typedefs and an operator(); throw an exception
when the underlay callable is not initialized.
Besides, the _naming_ of get_value_or is somewhat misleading.
People tend to read it like "get value, or doing something", which
result in a request of `get_value_or([]{...})`. Since .value() with an
exception is a nice naming, maybe we can rename `get_value_or`
into just `value_or`.
So
opt.value() + exception
opt() + exception
opt.value_or(fallback);
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Wed, 23 Jan 2013 11:10:16 -0800 (PST)
Raw View
------=_Part_204_12928097.1358968216676
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu =B6roda, 23 stycznia 2013 19:06:07 UTC+1 u=BFytkownik Zhihao Yuan=20
napisa=B3:
>
> On Wed, Jan 23, 2013 at 9:54 AM, Tony V E <tvan...@gmail.com <javascript:=
>>=20
> wrote:=20
> > optional<functionlike> fn;=20
>
> Please consider to treat a std::optional<callable> callable, like=20
> std::ref, by defining typedefs and an operator(); throw an exception=20
> when the underlay callable is not initialized.=20
>
> Besides, the _naming_ of get_value_or is somewhat misleading.=20
> People tend to read it like "get value, or doing something", which=20
> result in a request of `get_value_or([]{...})`. Since .value() with an=
=20
> exception is a nice naming, maybe we can rename `get_value_or`=20
> into just `value_or`.=20
>
> So=20
> opt.value() + exception=20
> opt() + exception=20
> opt.value_or(fallback);=20
>
I understand that you propose two different things.
(1) rename get_value_or to value_or. If we introduce a throwing function=20
value, name value_or looks natural, so I am in favor of doing so. Does=20
anyone disagree?
(2) adding operator()(Args&&...) for T's callable with Args&&... I am not=
=20
convinced that this is a good idea. Do you have any particular use case for=
=20
it?
Regards,
&rzej
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_204_12928097.1358968216676
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu =B6roda, 23 stycznia 2013 19:06:07 UTC+1 u=BFytkownik Zhihao=
Yuan napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wed, Jan 23=
, 2013 at 9:54 AM, Tony V E <<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"KxIo_v_tHSgJ">tvan...@gmail.com</a>> wrote:
<br>> optional<functionlike> fn;
<br>
<br>Please consider to treat a std::optional<callable> callable, like
<br>std::ref, by defining typedefs and an operator(); throw an exception
<br>when the underlay callable is not initialized.
<br>
<br>Besides, the _naming_ of get_value_or is somewhat misleading.
<br>People tend to read it like "get value, or doing something", which
<br>result in a request of `get_value_or([]{...})`. Since .value() wi=
th an
<br>exception is a nice naming, maybe we can rename `get_value_or`
<br>into just `value_or`.
<br>
<br>So
<br>opt.value() + exception
<br>opt() + exception
<br>opt.value_or(fallback);
<br></blockquote><div><br>I understand that you propose two different thing=
s.<br><br>(1) rename <span style=3D"font-family: courier new,monospace;">ge=
t_value_or</span> to <span style=3D"font-family: courier new,monospace;">va=
lue_or</span>. If we introduce a throwing function <span style=3D"font-fami=
ly: courier new,monospace;">value</span>, name <span style=3D"font-family: =
courier new,monospace;">value_or </span>looks natural, so I am in favor of =
doing so. Does anyone disagree?<br><br>(2) adding operator()(Args&&=
....) for T's callable with Args&&... I am not convinced that this i=
s a good idea. Do you have any particular use case for it?<br><br>Regards,<=
br>&rzej<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_204_12928097.1358968216676--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 23 Jan 2013 21:17:59 +0200
Raw View
On 23 January 2013 21:10, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> wro=
te:
> (2) adding operator()(Args&&...) for T's callable with Args&&... I am not
> convinced that this is a good idea. Do you have any particular use case f=
or
> it?
And are such use cases not covered by std::function?
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?ISO-8859-2?Q?Mikael_Kilpel=E4inen?=
Date: Wed, 23 Jan 2013 20:34:15 +0100
Raw View
This is a multi-part message in MIME format.
--------------040103090804040504000205
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> So
> opt.value() + exception
> opt() + exception
> opt.value_or(fallback);
>
>
> I understand that you propose two different things.
>
> (1) rename get_value_or to value_or. If we introduce a throwing
> function value, name value_or looks natural, so I am in favor of doing
> so. Does anyone disagree?
>
I like the naming value and value_or .. my only concern is that atm it
seems one returns reference and the other by value which might be
confusing. Then again, if we
have only const ref value-function, it is probably just fine.
Mikael
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--------------040103090804040504000205
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-2"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<blockquote
cite="mid:dc6c5344-1c82-4d83-9617-2bec2a4cb4d7@isocpp.org"
type="cite">
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">So
<br>
opt.value() + exception
<br>
opt() + exception
<br>
opt.value_or(fallback);
<br>
</blockquote>
<div><br>
I understand that you propose two different things.<br>
<br>
(1) rename <span style="font-family: courier new,monospace;">get_value_or</span>
to <span style="font-family: courier new,monospace;">value_or</span>.
If we introduce a throwing function <span style="font-family:
courier new,monospace;">value</span>, name <span
style="font-family: courier new,monospace;">value_or </span>looks
natural, so I am in favor of doing so. Does anyone disagree?<br>
</div>
<br>
</blockquote>
I like the naming value and value_or .. my only concern is that atm
it seems one returns reference and the other by value which might be
confusing. Then again, if we<br>
have only const ref value-function, it is probably just fine.<br>
<br>
<br>
Mikael<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
--------------040103090804040504000205--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Wed, 23 Jan 2013 13:55:17 -0600
Raw View
On Wed, Jan 23, 2013 at 1:10 PM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
> (2) adding operator()(Args&&...) for T's callable with Args&&... I am not
> convinced that this is a good idea. Do you have any particular use case f=
or
> it?
Oh, I see. Calling a std::function with a nullptr result in a
bad_function_call.
It's indeed covered.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Wed, 23 Jan 2013 14:34:13 -0600
Raw View
On Wed, Jan 23, 2013 at 1:34 PM, Mikael Kilpel=E4inen
<mikael.kilpelainen@gmail.com> wrote:
> .. my only concern is that atm it seems one returns reference and the oth=
er
> by value which might be confusing.
Maybe we can modify .value_or(fallback)'s semantics into:
if (!is_initialized)
initialize storage with fallback;
return storage;
With this semantics, the read side user can no longer pick a
different fallback value with this API; the rights to pick one
belongs to the writer, which makes the API less possible to
be misused.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Wed, 23 Jan 2013 21:36:28 +0100
Raw View
2013/1/23 Zhihao Yuan <lichray@gmail.com>:
> On Wed, Jan 23, 2013 at 1:34 PM, Mikael Kilpel=E4inen
> <mikael.kilpelainen@gmail.com> wrote:
>> .. my only concern is that atm it seems one returns reference and the ot=
her
>> by value which might be confusing.
>
> Maybe we can modify .value_or(fallback)'s semantics into:
>
> if (!is_initialized)
> initialize storage with fallback;
> return storage;
>
> With this semantics, the read side user can no longer pick a
> different fallback value with this API; the rights to pick one
> belongs to the writer, which makes the API less possible to
> be misused.
I have worked with .get_value_or functions in different languages and
different occasions but I never met this case: I really would find it
surprising if it would potentially mutate the queried optional.
- Daniel
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Wed, 23 Jan 2013 14:43:04 -0600
Raw View
On Wed, Jan 23, 2013 at 2:36 PM, Daniel Kr=FCgler
<daniel.kruegler@gmail.com> wrote:
> I really would find it
> surprising if it would potentially mutate the queried optional.
My suggest is, actually, to drop the fallback practice. So that
the .value_or() becomes a function *to mutate* the value,
like `basic_ios.flags()`.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?ISO-8859-1?Q?Mikael_Kilpel=E4inen?=
Date: Wed, 23 Jan 2013 21:47:26 +0100
Raw View
>> I really would find it
>> surprising if it would potentially mutate the queried optional.
> My suggest is, actually, to drop the fallback practice. So that
> the .value_or() becomes a function *to mutate* the value,
> like `basic_ios.flags()`.
>
I find that not only surprising but inconsistent, many parameters will
be const ref to optional and i want to call the value_or for those.
Mikael
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Wed, 23 Jan 2013 21:48:27 +0100
Raw View
2013/1/23 Zhihao Yuan <lichray@gmail.com>:
> On Wed, Jan 23, 2013 at 2:36 PM, Daniel Kr=FCgler
> <daniel.kruegler@gmail.com> wrote:
>> I really would find it
>> surprising if it would potentially mutate the queried optional.
>
> My suggest is, actually, to drop the fallback practice. So that
> the .value_or() becomes a function *to mutate* the value,
> like `basic_ios.flags()`.
I would consider a function with the semantics of get_value_or (not
necessarily with that name) as a well known idiom in regard to
nullable types and I think it is often handy to have. I have not found
yet the need for a mutating value_or() function. I especially would
warn to add controversial or less important functions with the initial
proposal. It is much simpler to get a short and simple proposal
accepted and add further functionality in the future. This also gives
implementations the time to get feedback from a large number of users.
This is much moire valuable than to discuss potential function x and y
in a smaller group like this one.
- Daniel
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Thu, 24 Jan 2013 07:49:43 +1100
Raw View
On Thu, Jan 24, 2013 at 2:54 AM, Tony V E <tvaneerd@gmail.com> wrote:
> On Wed, Jan 23, 2013 at 9:00 AM, Ville Voutilainen
> ...
> And if you had
> optional<functionlike> fn;
> fn(some, params);
> I might think it was calling operator() on the contained value.
> ie
> fn(emplace, foo)
> vs
> (*fn)(emplace, foo)
> Who would recognize those as completely different?
Uhm, everyone?... They look different and they do different things...
as fn() clearly applies op() to the 'fn' object and (*fn)() applies
op() to the dereferenced 'fn' object which is the underlying object.
That perceived "subtlety" is not due to op() but due to dereferencing
op*... which is idiomatic in C++. Extending your example one might say
"it's difficult to recognize the following as completely different":
optional<T> o1 = v;
T& o2 = *v;
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Wed, 23 Jan 2013 14:57:18 -0600
Raw View
On Wed, Jan 23, 2013 at 2:48 PM, Daniel Kr=FCgler
<daniel.kruegler@gmail.com> wrote:
> I would consider a function with the semantics of get_value_or (not
> necessarily with that name) as a well known idiom in regard to
> nullable types and I think it is often handy to have. I have not found
> yet the need for a mutating value_or() function.
With this change, in many cases, the idiom like:
queryDB("select piece_count from ...").value_or(0);
continues to work. The only difference is that, the functions to take
`optional<T> const&` can no longer use `.value_or`. This is actually
a good thing -- To have a safe nullable type is the purpose; the
really controversial thing is the `get_value_or` itself, as shown in the
proposal.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?ISO-8859-1?Q?Mikael_Kilpel=E4inen?=
Date: Wed, 23 Jan 2013 21:57:55 +0100
Raw View
> On Thu, Jan 24, 2013 at 2:54 AM, Tony V E <tvaneerd@gmail.com> wrote:
>> On Wed, Jan 23, 2013 at 9:00 AM, Ville Voutilainen
>> ...
>> And if you had
>> optional<functionlike> fn;
>> fn(some, params);
>> I might think it was calling operator() on the contained value.
>> ie
>> fn(emplace, foo)
>> vs
>> (*fn)(emplace, foo)
>> Who would recognize those as completely different?
> Uhm, everyone?... They look different and they do different things...
>
They look (=are) different for sure, but to what extend.. One issue
mudding this water is function pointers where you don't care about
dereferencing.
Anyhow, i think the usage of operator() is just too surprising in this
case, no matter what.
Mikael
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Wed, 23 Jan 2013 12:59:21 -0800 (PST)
Raw View
------=_Part_556_19131982.1358974761127
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu =B6roda, 23 stycznia 2013 21:49:43 UTC+1 u=BFytkownik Vladimir Batov=
=20
napisa=B3:
>
> On Thu, Jan 24, 2013 at 2:54 AM, Tony V E <tvan...@gmail.com <javascript:=
>>=20
> wrote:=20
> > On Wed, Jan 23, 2013 at 9:00 AM, Ville Voutilainen=20
> > ...=20
> > And if you had=20
> > optional<functionlike> fn;=20
> > fn(some, params);=20
> > I might think it was calling operator() on the contained value.=20
> > ie=20
> > fn(emplace, foo)=20
> > vs=20
> > (*fn)(emplace, foo)=20
> > Who would recognize those as completely different?=20
>
> Uhm, everyone?... They look different and they do different things...=20
>
This particular argument does not convince me. However, I find the=20
arguments about abusing function call operator strong.=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_556_19131982.1358974761127
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu =B6roda, 23 stycznia 2013 21:49:43 UTC+1 u=BFytkownik Vladim=
ir Batov napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thu, Jan=
24, 2013 at 2:54 AM, Tony V E <<a href=3D"javascript:" target=3D"_blank=
" gdf-obfuscated-mailto=3D"uzbR9j7cBzwJ">tvan...@gmail.com</a>> wrote:
<br>> On Wed, Jan 23, 2013 at 9:00 AM, Ville Voutilainen
<br>> ...
<br>> And if you had
<br>> optional<functionlike> fn;
<br>> fn(some, params);
<br>> I might think it was calling operator() on the contained value.
<br>> ie
<br>> fn(emplace, foo)
<br>> vs
<br>> (*fn)(emplace, foo)
<br>> Who would recognize those as completely different?
<br>
<br>Uhm, everyone?... They look different and they do different things...
<br></blockquote><div><br>This particular argument does not convince me. Ho=
wever, I find the arguments about abusing function call operator strong. <b=
r></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_556_19131982.1358974761127--
.
Author: =?ISO-8859-1?Q?Mikael_Kilpel=E4inen?=
Date: Wed, 23 Jan 2013 22:00:16 +0100
Raw View
> With this change, in many cases, the idiom like:
>
> queryDB("select piece_count from ...").value_or(0);
>
> continues to work. The only difference is that, the functions to take
> `optional<T> const&` can no longer use `.value_or`. This is actually
> a good thing -- To have a safe nullable type is the purpose; the
> really controversial thing is the `get_value_or` itself, as shown in the
> proposal.
>
>
You lost me there, what makes it safe here?
Mikael
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Thu, 24 Jan 2013 08:07:20 +1100
Raw View
On Thu, Jan 24, 2013 at 7:48 AM, Daniel Kr=FCgler
<daniel.kruegler@gmail.com> wrote:
> ...
> I would consider a function with the semantics of get_value_or (not
> necessarily with that name) as a well known idiom in regard to
> nullable types and I think it is often handy to have. I have not found
> yet the need for a mutating value_or() function. I especially would
> warn to add controversial or less important functions with the initial
> proposal. It is much simpler to get a short and simple proposal
> accepted and add further functionality in the future. This also gives
> implementations the time to get feedback from a large number of users.
> This is much moire valuable than to discuss potential function x and y
> in a smaller group like this one.
If I understood the message above correctly, it warns against
light-hearted (frivolous IMO) extension of the core api. If it is so,
then I whole-heartedly agree. I am watching with great concern how
easily new api and new member functions (get, value_this, value_that)
are suggested and debated. It's a std proposal. Inflating it with
non-essential api (implementable outside the class) seems quite
reckless. In this situation IMO the rule of
not-making-a-member-something-that
can-be-implemented-as-a-free-function (was it Scott Meyers'?) is
highly appropriate. And for me that seems to include get_value_or
which seems to relate to all nullable classes and should probably be
implemented as such.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Wed, 23 Jan 2013 15:10:13 -0600
Raw View
On Wed, Jan 23, 2013 at 3:00 PM, Mikael Kilpel=E4inen
<mikael.kilpelainen@gmail.com> wrote:
> You lost me there, what makes it safe here?
Think it as a "privilege separation". The API (like query) who
provides (returns) the optional<T> decide whether the nullable
state can be safely ignored with a fallback, and the users of the
API can not ignore it with a fallback if the provider says no. And
all other users (optional<T> const&) should use .value(), because
the first API user decide the error handling policy -- no error, or
exception.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Wed, 23 Jan 2013 22:15:28 +0100
Raw View
2013/1/23 Vladimir Batov <vb.mail.247@gmail.com>:
> On Thu, Jan 24, 2013 at 7:48 AM, Daniel Kr=FCgler
> <daniel.kruegler@gmail.com> wrote:
>> ...
>> I would consider a function with the semantics of get_value_or (not
>> necessarily with that name) as a well known idiom in regard to
>> nullable types and I think it is often handy to have. I have not found
>> yet the need for a mutating value_or() function. I especially would
>> warn to add controversial or less important functions with the initial
>> proposal. It is much simpler to get a short and simple proposal
>> accepted and add further functionality in the future. This also gives
>> implementations the time to get feedback from a large number of users.
>> This is much moire valuable than to discuss potential function x and y
>> in a smaller group like this one.
>
> If I understood the message above correctly, it warns against
> light-hearted (frivolous IMO) extension of the core api.
Yes, this was the intention.
- Daniel
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Wed, 23 Jan 2013 13:16:58 -0800 (PST)
Raw View
------=_Part_315_24014683.1358975818885
Content-Type: text/plain; charset=ISO-8859-1
Op woensdag 23 januari 2013 12:04:57 UTC+1 schreef Vladimir Batov het
volgende:
> On Wednesday, January 23, 2013 8:07:24 PM UTC+11, Ville Voutilainen wrote:
> ...
>
>> Smart pointers have both operator-> and get(). You don't _need_ the get
>> if you want a minimal interface with no redundancy, just say
>> Foo* p = smartptr.operator->();
>> and watch your soul leave your body.
>
>
> Or Foo* p = &*smartptr;
>
> Given anyone knows what & and * operators do, it's quite readable -- get
> the address of dereferenced smart ptr which is, obviously, the underlying
> object. So, no need (as it seems) for get(). IMO the more I can do wit the
> standard set of operators (like op&, op*, op(), etc)the better.
>
Is this defined behaviour if the pointer is null?
Dereferencing a null pointer doesn't seem right.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_315_24014683.1358975818885
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Op woensdag 23 januari 2013 12:04:57 UTC+1 schreef Vladimir Batov het volge=
nde:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wednesday, January =
23, 2013 8:07:24 PM UTC+11, Ville Voutilainen wrote:<div> ...</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">Smart pointers have both operator->=
and get(). You don't _need_ the get
<br>if you want a minimal interface with no redundancy, just say
<br>Foo* p =3D smartptr.operator->();
<br>and watch your soul leave your body. </blockquote><div><br>Or Foo* p =
=3D &*smartptr;<br><br>Given anyone knows what & and * operators do=
, it's quite readable -- get the address of dereferenced smart ptr which is=
, obviously, the underlying object. So, no need (as it seems) for get(). IM=
O the more I can do wit the standard set of operators (like op&, op*, o=
p(), etc)the better.<br></div></blockquote><div><br></div><div>Is this defi=
ned behaviour if the pointer is null?</div><div>Dereferencing a null pointe=
r doesn't seem right.</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_315_24014683.1358975818885--
.
Author: =?ISO-8859-1?Q?Mikael_Kilpel=E4inen?=
Date: Wed, 23 Jan 2013 22:22:11 +0100
Raw View
> Think it as a "privilege separation". The API (like query) who
> provides (returns) the optional<T> decide whether the nullable
> state can be safely ignored with a fallback, and the users of the
> API can not ignore it with a fallback if the provider says no. And
> all other users (optional<T> const&) should use .value(), because
> the first API user decide the error handling policy -- no error, or
> exception.
>
Okey, I see what you mean. But i don't think it is quite that black and
white. The safeness here is in the eye of the beholder.
Just as well many people think that parameters you have by value ought
not to be altered, as it might be confusing.
I still think the const ref params would be big concern as for me it
most likely is the most likely case.
Also in most function i would need the value once and not care about it
afterwards, i try to keep my functions as
small as possible.
Something related though..
The proposal explicitly bans relational operators with the contained
type. Fair enough, and the explanation and example
are good. I agree, however the rationale only applies to < and <=
functions. I have really liked to use the == and != with
boost::optional. I agree that on consistency reasons we might want to
ban those as well and i certainly can live with the
alternatives.. but.. :)
Mikael
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Wed, 23 Jan 2013 22:22:15 +0100
Raw View
2013/1/23 Olaf van der Spek <olafvdspek@gmail.com>:
> Op woensdag 23 januari 2013 12:04:57 UTC+1 schreef Vladimir Batov het
> volgende:
>
>> On Wednesday, January 23, 2013 8:07:24 PM UTC+11, Ville Voutilainen wrote:
>> ...
>>>
>>> Smart pointers have both operator-> and get(). You don't _need_ the get
>>> if you want a minimal interface with no redundancy, just say
>>> Foo* p = smartptr.operator->();
>>> and watch your soul leave your body.
>>
>>
>> Or Foo* p = &*smartptr;
>>
>> Given anyone knows what & and * operators do, it's quite readable -- get
>> the address of dereferenced smart ptr which is, obviously, the underlying
>> object. So, no need (as it seems) for get(). IMO the more I can do wit the
>> standard set of operators (like op&, op*, op(), etc)the better.
>
>
> Is this defined behaviour if the pointer is null?
Yes, it is, because both these expressions invoke member functions
that impose the precondition that the underlying pointer is not null.
> Dereferencing a null pointer doesn't seem right.
Not for these library functions, correct. The core language is
currently considering to extend some cases where this would be fine,
though, see
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#232
- Daniel
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Wed, 23 Jan 2013 22:27:54 +0100
Raw View
On Wed, Jan 23, 2013 at 10:22 PM, Daniel Kr=FCgler
<daniel.kruegler@gmail.com> wrote:
>>> Or Foo* p =3D &*smartptr;
>> Is this defined behaviour if the pointer is null?
>
> Yes, it is, because both these expressions invoke member functions
> that impose the precondition that the underlying pointer is not null.
The precondition is violated, so the behaviour is *undefined*, isn't it?
So &* is not a suitable replacement for a T* get() member.
--=20
Olaf
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Wed, 23 Jan 2013 22:29:25 +0100
Raw View
2013/1/23 Olaf van der Spek <olafvdspek@gmail.com>:
> On Wed, Jan 23, 2013 at 10:22 PM, Daniel Kr=FCgler
> <daniel.kruegler@gmail.com> wrote:
>>>> Or Foo* p =3D &*smartptr;
>
>>> Is this defined behaviour if the pointer is null?
>>
>> Yes, it is, because both these expressions invoke member functions
>> that impose the precondition that the underlying pointer is not null.
>
> The precondition is violated, so the behaviour is *undefined*, isn't it?
Yes, sorry I misread what you wrote as "undefined behaviour".
> So &* is not a suitable replacement for a T* get() member.
Correct.
- Daniel
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Jeffrey Yasskin <jyasskin@googlers.com>
Date: Wed, 23 Jan 2013 13:33:19 -0800
Raw View
On Wed, Jan 23, 2013 at 5:08 AM, Andrzej Krzemie=F1ski <akrzemi1@gmail.com>=
wrote:
>
>
> W dniu =B6roda, 23 stycznia 2013 13:22:27 UTC+1 u=BFytkownik Nikolay Ivch=
enkov
> napisa=B3:
>>
>> On Wednesday, January 23, 2013 12:56:16 PM UTC+4, Andrzej Krzemie=F1ski
>> wrote:
>>>
>>>
>>>> I want `optional::get()` member function. (the member exist in
>>>> `boost::optional`)
>>>
>>>
>>> One of the goals for the design was not to introduce any redundancy in
>>> the interface. This is the answer to the former question, and also part=
ially
>>> to the latter. This is the second time, the observer function get is
>>> requested. I am personally a bit uneasy about introducing this, mostly
>>> because of the overlap in functionality with other members and little
>>> offered benefit on the other hand.
>>
>>
>> There are people who find calls to get() more readable than the
>> dereference notation.
>>
>> optional<map_iterator> *p;
>> ....
>> if (p && *p)
>> {
>> auto &&value =3D p->get()->second;
>> //auto &&value =3D (***p).second;
>> ....
>> }
>
>
> Would it work for you, if we forget the name get (it may imply that we ar=
e
> returning a pointer), and provide function value instead with the semanti=
cs
> suggested by Daniel:
>
> T const& optional<T>::value() const
> {
> if (is_initialized)
> rerurn contained_value_;
> else
> throw invalid_optional_value_access{};
> }
>
> The semantics are different than operator* (the extra performance penalty=
),
> but we do not have to provide yet another function.
+1.
I suggested .get() to return a pointer because there are other types
(e.g. unique_ptr) that follow this convention, and there are functions
that take a nullable pointer, meaning an optional argument, and it's
convenient to have a short way to pass an optional<> to them. I
certainly won't be heartbroken if .get() isn't included in the
C++14/17 optional<> interface. I would be a bit sad if there were a
..get() that didn't work (or threw) on empty optionals. .value() seems
like a good name that's clear it doesn't return a pointer.
Regarding .get_value_or() (possibly renamed to .value_or()):
1) This is a very useful operation, but I won't be heartbroken if this
isn't in the standardized version either.
2) I do worry about both extra copies and dangling references.
3) Compilers ought to be trying to warn about this sort of dangling
reference, and it seems doable, but nobody's done it yet AFAIK.
4) In the absence of compiler support, what if get_value_or insists
that both of its arguments are either rvalues or lvalues? A mix causes
a compile error. If both arguments are rvalues, it returns moved
versions. If both are lvalues, it returns a reference, of appropriate
const-ness.
Reiterating (1), like with optional<T&>, I'd rather drop get_value_or
from the proposal than have it jeopardize consensus about the whole
proposal.
Thanks for working on this!
Jeffrey
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?UTF-8?Q?R=C3=B3bert_D=C3=A1vid?= <lrdxgm@gmail.com>
Date: Wed, 23 Jan 2013 13:35:42 -0800 (PST)
Raw View
------=_Part_1045_12116467.1358976942590
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
2013. janu=E1r 23., szerda 12:57:40 UTC+1 id=F5pontban Chris Jefferson a=20
k=F6vetkez=F5t =EDrta:
>
>
> I think the problem was that get_value_or_call either has to return by=20
> value (which involves possibly expensive copying) or by reference (which=
=20
> involves possibly hanging references to the 'or' value).
>
> Your get_value_or_call function avoids constructing the 'or' object which=
=20
> it is not required, but still involves copying. There is no good reason f=
or=20
> this not to be a free function, so I wonder if this is one area where we=
=20
> should see what people end up using, and standardise later?
>
> Chris
>
I would like avoid the "standardize later" case, as that would mean not=20
having this anywhere, and I'll need to implement it myself :)
Anyway, the exact problem is handled by the language already within the=20
ternary operator, using that I think the solution is quite easy:
template<typename fn>
auto get_value_or_call(fn&& fun) const & -> decltype(this ? get() : fun()){
return this ? get() : fun();
}
template<typename fn>
auto get_value_or_call(fn&& fun) && -> decltype(this ? get() : fun()){
return this ? get() : fun();
}
Or in C++1y style, if the corresponding proposal is accepted then without=
=20
the -> decltype part.
Sure, it still involves copying if the function returns a value, but you=20
have the same with x=3Dopt.get_value_or(fun()); as well (plus you are calli=
ng=20
a function you might not need). I don't think that can be avoided, besides=
=20
compilers can do copy elision, so probably not an issue in release.
Regards, Robert
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_1045_12116467.1358976942590
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>2013. janu=E1r 23., szerda 12:57:40 UTC+1 id=F5pontban Chris Jeffer=
son a k=F6vetkez=F5t =EDrta:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF"><br>
I think the problem was that get_value_or_call either has to return
by value (which involves possibly expensive copying) or by reference
(which involves possibly hanging references to the 'or' value).<br>
<br>
Your get_value_or_call function avoids constructing the 'or' object
which it is not required, but still involves copying. There is no
good reason for this not to be a free function, so I wonder if this
is one area where we should see what people end up using, and
standardise later?<br>
<br>
Chris<br></div></blockquote><div><br>I would like avoid the "standardiz=
e later" case, as that would mean not having this anywhere, and I'll need t=
o implement it myself :)<br><br>Anyway, the exact problem is handled by the=
language already within the ternary operator, using that I think the solut=
ion is quite easy:<br><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"prettyprint"><di=
v class=3D"subprettyprint"><code class=3D"prettyprint"><span style=3D"color=
: #008;" class=3D"styled-by-prettify">template</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #008;"=
class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> fn</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">></span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> get_value_or_call</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">fn</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&&=
amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> fun</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">-></span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">decltype</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">this</=
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"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">get</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> fun</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
()){</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&n=
bsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">this</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">?</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">get</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> f=
un</span><span style=3D"color: #660;" class=3D"styled-by-prettify">();</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">template</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> fn</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><code class=3D"prettyprint">auto get_value_or_call(fn&&=
fun) && -> decltype(this ? get() : fun()){<br> ret=
urn this ? get() : fun();<br>}</code></span></code><span style=3D"color: #6=
60;" class=3D"styled-by-prettify"></span></div></code></div>Or in C++1y sty=
le, if the corresponding proposal is accepted then without the -> declty=
pe part.<br><br>Sure, it still involves copying if the function returns a v=
alue, but you have the same with <span style=3D"font-family: courier new,mo=
nospace;">x=3Dopt.get_value_or(fun())</span>; as well (plus you are calling=
a function you might not need). I don't think that can be avoided, besides=
compilers can do copy elision, so probably not an issue in release.<br><br=
>Regards, Robert<br><br><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1045_12116467.1358976942590--
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Thu, 24 Jan 2013 08:38:09 +1100
Raw View
On Thu, Jan 24, 2013 at 7:59 AM, Andrzej Krzemie=F1ski <akrzemi1@gmail.com>=
wrote:
> W dniu =B6roda, 23 stycznia 2013 21:49:43 UTC+1 u=BFytkownik Vladimir Bat=
ov
> napisa=B3:
>> On Thu, Jan 24, 2013 at 2:54 AM, Tony V E <tvan...@gmail.com> wrote:
>> > On Wed, Jan 23, 2013 at 9:00 AM, Ville Voutilainen
>> > ...
>> > And if you had
>> > optional<functionlike> fn;
>> > fn(some, params);
>> > I might think it was calling operator() on the contained value.
>> > ie
>> > fn(emplace, foo)
>> > vs
>> > (*fn)(emplace, foo)
>> > Who would recognize those as completely different?
>>
>> Uhm, everyone?... They look different and they do different things...
>
> This particular argument does not convince me. However, I find the argume=
nts
> about abusing function call operator strong.
Well, for starters it was not an argument as such. All I tried was to
highlight the fact that the perceived insufficient visual difference
as actually caused by the op* which somehow no one objects to even
though 'v' and '*v' (with or without following functions) look quite
similar. That's C++ terse syntax. Some love it, some hate it.
As for "abuse", then it's quite subjective and, therefore,
endlessly/fruitlessly debatable. I for one consider highly unfortunate
(abusive? ;-)) how quickly (needlessly?) an api is stuffed with new
keywords when op+, op*, op(), etc. would do. If, say, 3 new keywords
added to such a "basic building block" class as optional, jmagine how
many more one needs to remember to be able to deploy 100s of classes
everyday.
As for op() in particular, one could write an api like
foo.set_some_string(some_string);
foo.set_some_bool(true);
I personally do not see anything wrong with simply
foo(some_string);
foo(true);
as long as the signature is unique. I find it a direct (non-abusive)
deployment of op() -- apply something to the object. As long the
applied type uniquely/unequivocally interpreted. That said, I
understand that these rumblings (and in this limited format) can
achieve much. :-)
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Wed, 23 Jan 2013 22:46:40 +0100
Raw View
On Wed, Jan 23, 2013 at 10:33 PM, Jeffrey Yasskin <jyasskin@googlers.com> wrote:
> Regarding .get_value_or() (possibly renamed to .value_or()):
>
> 1) This is a very useful operation, but I won't be heartbroken if this
> isn't in the standardized version either.
> 2) I do worry about both extra copies and dangling references.
> 3) Compilers ought to be trying to warn about this sort of dangling
> reference, and it seems doable, but nobody's done it yet AFAIK.
> 4) In the absence of compiler support, what if get_value_or insists
> that both of its arguments are either rvalues or lvalues? A mix causes
> a compile error. If both arguments are rvalues, it returns moved
> versions. If both are lvalues, it returns a reference, of appropriate
> const-ness.
This has been suggested before. It's not so simple, there's also the
case where the types don't match exactly.
Long-term a new operator might be best, something like a ?: b which
returns a ? *a : b
> Reiterating (1), like with optional<T&>, I'd rather drop get_value_or
> from the proposal than have it jeopardize consensus about the whole
> proposal.
Can't it (no pun intended) be included as an optional feature in the
optional proposal?
--
Olaf
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Nikolay Ivchenkov <tsoae@mail.ru>
Date: Wed, 23 Jan 2013 13:47:16 -0800 (PST)
Raw View
------=_Part_467_10673590.1358977636475
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, January 23, 2013 5:08:09 PM UTC+4, Andrzej Krzemie=C5=84ski w=
rote:
>
>
>> There are people who find calls to get() more readable than the=20
>> dereference notation.
>>
>> optional<map_iterator> *p;
>> ....
>> if (p && *p)
>> {
>> auto &&value =3D p->get()->second;
>> //auto &&value =3D (***p).second;
>> ....
>> }=20
>>
>
> Would it work for you, if we forget the name get (it may imply that we=20
> are returning a pointer),
>
I prefer to think that get() returns an underlying entity, which is not=20
necessarily a pointer, while operations * and -> are usually associated=20
with pointer-like entities.
=20
> and provide function value instead
>
Name 'value' seems to be good enough for me.
=20
> with the semantics suggested by Daniel:
>
> T const& optional<T>::value() const
> {
> if (is_initialized)=20
> rerurn contained_value_;
> else=20
> throw invalid_optional_value_access{};=20
> }
>
=20
I don't think that stack unwinding is an appropriate way to handle logic=20
errors and I would prefer a call to std::terminate instead:
http://liveworkspace.org/code/G6txS$1
But others may have different preferences.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_467_10673590.1358977636475
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, January 23, 2013 5:08:09 PM UTC+4, Andrzej Krzemie=C5=84ski w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div><br>There are people who find calls to get() more reada=
ble than the dereference notation.<br><br> optional<ma=
p_iterator> *p;<br> ....<br> if (p &=
amp;& *p)<br> {<br> &nbs=
p; auto &&value =3D p->get()->second;<br> &n=
bsp; //auto &&value =3D (***p).second;<br>&=
nbsp; ....<br> } <br>=
</div></blockquote><div><br>Would it work for you, if we forget the name <s=
pan style=3D"font-family:courier new,monospace">get </span>(it may imply th=
at we are returning a pointer),</div></blockquote><div><br>I prefer to thin=
k that get() returns an underlying entity, which is not necessarily a point=
er, while operations * and -> are usually associated with pointer-like e=
ntities.<br> </div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div> =
and provide function <span style=3D"font-family:courier new,monospace">valu=
e</span> instead</div></blockquote><div><br>Name 'value' seems to be good e=
nough for me.<br> </div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div> with the semantics suggested by Daniel:<br><br><div style=3D"backgroun=
d-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;b=
order-width:1px;word-wrap:break-word"><code><div><span style=3D"color:#000"=
>T </span><span style=3D"color:#008">const</span><span style=3D"color:#660"=
>&</span><span style=3D"color:#000"> optional</span><span style=3D"colo=
r:#660"><</span><span style=3D"color:#000">T</span><span style=3D"color:=
#660">>::</span><span style=3D"color:#000">value</span><span style=3D"co=
lor:#660">()</span><span style=3D"color:#000"> </span><span style=3D"color:=
#008">const</span><span style=3D"color:#000"><br></span><span style=3D"colo=
r:#660">{</span><span style=3D"color:#000"><br> </span><span style=3D=
"color:#008">if</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#660">(</span><span style=3D"color:#000">is_initialized</span><span styl=
e=3D"color:#660">)</span><span style=3D"color:#000"> <br> reru=
rn contained_value_</span><span style=3D"color:#660">;</span><span style=3D=
"color:#000"><br> </span><span style=3D"color:#008">else</span><span =
style=3D"color:#000"> <br> </span><span style=3D"color:#008">t=
hrow</span><span style=3D"color:#000"> invalid_optional_value_access</span>=
<span style=3D"color:#660">{<wbr>}</span><span style=3D"color:#660">;</span=
><span style=3D"color:#000"> <br></span><span style=3D"color:#660">}</span>=
<span style=3D"color:#000"><br></span></div></code></div></div></blockquote=
><div> <br>I don't think that stack unwinding is an appropriate way to=
handle logic errors and I would prefer a call to std::terminate instead:<b=
r>http://liveworkspace.org/code/G6txS$1<br><br>But others may have differen=
t preferences.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_467_10673590.1358977636475--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Wed, 23 Jan 2013 22:50:26 +0100
Raw View
On Wed, Jan 23, 2013 at 10:47 PM, Nikolay Ivchenkov <tsoae@mail.ru> wrote:
> I don't think that stack unwinding is an appropriate way to handle logic
> errors and I would prefer a call to std::terminate instead:
> http://liveworkspace.org/code/G6txS$1
>
> But others may have different preferences.
They certainly do...
https://groups.google.com/a/isocpp.org/forum/#!searchin/std-discussion/abort/std-discussion/ChznW6ipyEw/4xeVU20aUuoJ
--
Olaf
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 23 Jan 2013 23:50:35 +0200
Raw View
On 23 January 2013 23:47, Nikolay Ivchenkov <tsoae@mail.ru> wrote:
>> with the semantics suggested by Daniel:
>> T const& optional<T>::value() const
>> {
>> if (is_initialized)
>> rerurn contained_value_;
>> else
>> throw invalid_optional_value_access{};
>> }
> I don't think that stack unwinding is an appropriate way to handle logic
> errors and I would prefer a call to std::terminate instead:
The standard library is moving into a different direction, if we look
at what std::function
does when the operator() is invoked for an empty function, or what
promise does if
you try to retrieve its future twice or if it has no shared state.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Wed, 23 Jan 2013 22:53:03 +0100
Raw View
2013/1/23 Vladimir Batov <vb.mail.247@gmail.com>:
> On Thu, Jan 24, 2013 at 7:59 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail=
..com> wrote:
>> This particular argument does not convince me. However, I find the argum=
ents
>> about abusing function call operator strong.
>
> Well, for starters it was not an argument as such. All I tried was to
> highlight the fact that the perceived insufficient visual difference
> as actually caused by the op* which somehow no one objects to even
> though 'v' and '*v' (with or without following functions) look quite
> similar. That's C++ terse syntax. Some love it, some hate it.
This is - I think - essentially the root of the problem here: There is
(in a fundamental way) nothing wrong with your proposal, but I think
we have at least two arguments that speak against it at *this point of
time*:
a) There does not exist a considerable consensus to add it.
b) There is no comparable design of an existing library feature so
that we could provide some consistency argument (except if we would
stretch the term consistency here).
> As for "abuse", then it's quite subjective and, therefore,
> endlessly/fruitlessly debatable.
I agree, it was a bit emotionally expressed. I withdraw the "abuse"
argument but would stick with "misleading" in the context of existing
standard components.
- Daniel
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Wed, 23 Jan 2013 13:53:58 -0800 (PST)
Raw View
------=_Part_223_15262800.1358978038557
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu =B6roda, 23 stycznia 2013 22:38:09 UTC+1 u=BFytkownik Vladimir Batov=
=20
napisa=B3:
>
> On Thu, Jan 24, 2013 at 7:59 AM, Andrzej Krzemie=F1ski <akrz...@gmail.com=
<javascript:>>=20
> wrote:=20
> > W dniu =B6roda, 23 stycznia 2013 21:49:43 UTC+1 u=BFytkownik Vladimir B=
atov=20
> > napisa=B3:=20
> >> On Thu, Jan 24, 2013 at 2:54 AM, Tony V E <tvan...@gmail.com> wrote:=
=20
> >> > On Wed, Jan 23, 2013 at 9:00 AM, Ville Voutilainen=20
> >> > ...=20
> >> > And if you had=20
> >> > optional<functionlike> fn;=20
> >> > fn(some, params);=20
> >> > I might think it was calling operator() on the contained value.=20
> >> > ie=20
> >> > fn(emplace, foo)=20
> >> > vs=20
> >> > (*fn)(emplace, foo)=20
> >> > Who would recognize those as completely different?=20
> >>=20
> >> Uhm, everyone?... They look different and they do different things...=
=20
> >=20
> > This particular argument does not convince me. However, I find the=20
> arguments=20
> > about abusing function call operator strong.=20
>
> Well, for starters it was not an argument as such. All I tried was to=20
> highlight the fact that the perceived insufficient visual difference=20
> as actually caused by the op* which somehow no one objects to even=20
> though 'v' and '*v' (with or without following functions) look quite=20
> similar. That's C++ terse syntax. Some love it, some hate it.=20
>
I agree with you here. I meant to say that I do not find the potential=20
confusion of fn(emplace, foo) with (*fn)(emplace, foo) a convincing=20
argument.
=20
> As for "abuse", then it's quite subjective and, therefore,=20
> endlessly/fruitlessly debatable. I for one consider highly unfortunate=20
> (abusive? ;-)) how quickly (needlessly?) an api is stuffed with new=20
> keywords when op+, op*, op(), etc. would do. If, say, 3 new keywords=20
> added to such a "basic building block" class as optional, jmagine how=20
> many more one needs to remember to be able to deploy 100s of classes=20
> everyday.=20
>
> As for op() in particular, one could write an api like=20
>
> foo.set_some_string(some_string);=20
> foo.set_some_bool(true);=20
>
> I personally do not see anything wrong with simply=20
>
> foo(some_string);=20
> foo(true);=20
>
> as long as the signature is unique. I find it a direct (non-abusive)=20
> deployment of op() -- apply something to the object. As long the=20
> applied type uniquely/unequivocally interpreted. That said, I=20
> understand that these rumblings (and in this limited format) can=20
> achieve much. :-)=20
>
I agree here that we are discussing something highly "arbitrary" :)
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_223_15262800.1358978038557
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu =B6roda, 23 stycznia 2013 22:38:09 UTC+1 u=BFytkownik Vladim=
ir Batov napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thu, Jan=
24, 2013 at 7:59 AM, Andrzej Krzemie=F1ski <<a href=3D"javascript:" tar=
get=3D"_blank" gdf-obfuscated-mailto=3D"O9-NgKBPPHEJ">akrz...@gmail.com</a>=
> wrote:
<br>> W dniu =B6roda, 23 stycznia 2013 21:49:43 UTC+1 u=BFytkownik Vladi=
mir Batov
<br>> napisa=B3:
<br>>> On Thu, Jan 24, 2013 at 2:54 AM, Tony V E <<a>tvan...@gmail=
..com</a>> wrote:
<br>>> > On Wed, Jan 23, 2013 at 9:00 AM, Ville Voutilainen
<br>>> > ...
<br>>> > And if you had
<br>>> > optional<functionlike> fn;
<br>>> > fn(some, params);
<br>>> > I might think it was calling operator() on the contained =
value.
<br>>> > ie
<br>>> > fn(emplace, foo)
<br>>> > vs
<br>>> > (*fn)(emplace, foo)
<br>>> > Who would recognize those as completely different?
<br>>>
<br>>> Uhm, everyone?... They look different and they do different th=
ings...
<br>>
<br>> This particular argument does not convince me. However, I find the=
arguments
<br>> about abusing function call operator strong.
<br>
<br>Well, for starters it was not an argument as such. All I tried was to
<br>highlight the fact that the perceived insufficient visual difference
<br>as actually caused by the op* which somehow no one objects to even
<br>though 'v' and '*v' (with or without following functions) look quite
<br>similar. That's C++ terse syntax. Some love it, some hate it.
<br></blockquote><div><br>I agree with you here. I meant to say that I do n=
ot find the potential confusion of <span style=3D"font-family: courier new,=
monospace;">fn(emplace, foo)</span>
with <span style=3D"font-family: courier new,monospace;">(*fn)(emplace, foo=
)</span>
a convincing argument.<br> <br></div><blockquote class=3D"gmail_quote"=
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;">As for "abuse", then it's quite subjective and, therefore,
<br>endlessly/fruitlessly debatable. I for one consider highly unfortunate
<br>(abusive? ;-)) how quickly (needlessly?) an api is stuffed with new
<br>keywords when op+, op*, op(), etc. would do. If, say, 3 new keywords
<br>added to such a "basic building block" class as optional, jmagine how
<br>many more one needs to remember to be able to deploy 100s of classes
<br>everyday.
<br>
<br>As for op() in particular, one could write an api like
<br>
<br>foo.set_some_string(some_<wbr>string);
<br>foo.set_some_bool(true);
<br>
<br>I personally do not see anything wrong with simply
<br>
<br>foo(some_string);
<br>foo(true);
<br>
<br>as long as the signature is unique. I find it a direct (non-abusive)
<br>deployment of op() -- apply something to the object. As long the
<br>applied type uniquely/unequivocally interpreted. That said, I
<br>understand that these rumblings (and in this limited format) can
<br>achieve much. :-)
<br></blockquote><div><br>I agree here that we are discussing something hig=
hly "arbitrary" :)<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_223_15262800.1358978038557--
.
Author: =?UTF-8?Q?R=C3=B3bert_D=C3=A1vid?= <lrdxgm@gmail.com>
Date: Wed, 23 Jan 2013 13:54:01 -0800 (PST)
Raw View
------=_Part_2959_31701150.1358978041774
Content-Type: text/plain; charset=ISO-8859-1
>
>
> with the semantics suggested by Daniel:
>>
>> T const& optional<T>::value() const
>> {
>> if (is_initialized)
>> rerurn contained_value_;
>> else
>> throw invalid_optional_value_access{};
>> }
>>
>
> I don't think that stack unwinding is an appropriate way to handle logic
> errors and I would prefer a call to std::terminate instead:
> http://liveworkspace.org/code/G6txS$1
>
> But others may have different preferences.
>
I'd go with undefined behaviour, so I can skip the testing -> more
performance. The debug-mode standard library is free to throw an exception,
call terminate, or whatever. Also static analyser tools can detect misuse
easier.
Regards, Robert
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_2959_31701150.1358978041774
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><br><blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div> with the semantics suggested by Daniel:<br><br><div sty=
le=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);borde=
r-style:solid;border-width:1px;word-wrap:break-word"><code><div><span style=
=3D"color:#000">T </span><span style=3D"color:#008">const</span><span style=
=3D"color:#660">&</span><span style=3D"color:#000"> optional</span><spa=
n style=3D"color:#660"><</span><span style=3D"color:#000">T</span><span =
style=3D"color:#660">>::</span><span style=3D"color:#000">value</span><s=
pan style=3D"color:#660">()</span><span style=3D"color:#000"> </span><span =
style=3D"color:#008">const</span><span style=3D"color:#000"><br></span><spa=
n style=3D"color:#660">{</span><span style=3D"color:#000"><br> </span=
><span style=3D"color:#008">if</span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#660">(</span><span style=3D"color:#000">is_initialized</=
span><span style=3D"color:#660">)</span><span style=3D"color:#000"> <br>&nb=
sp; rerurn contained_value_</span><span style=3D"color:#660">;</span=
><span style=3D"color:#000"><br> </span><span style=3D"color:#008">el=
se</span><span style=3D"color:#000"> <br> </span><span style=
=3D"color:#008">throw</span><span style=3D"color:#000"> invalid_optional_va=
lue_access</span><span style=3D"color:#660">{<wbr>}</span><span style=3D"co=
lor:#660">;</span><span style=3D"color:#000"> <br></span><span style=3D"col=
or:#660">}</span><span style=3D"color:#000"><br></span></div></code></div><=
/div></blockquote><div> <br>I don't think that stack unwinding is an a=
ppropriate way to handle logic errors and I would prefer a call to std::ter=
minate instead:<br><a href=3D"http://liveworkspace.org/code/G6txS$1" target=
=3D"_blank">http://liveworkspace.org/code/<wbr>G6txS$1</a><br><br>But other=
s may have different preferences.<br></div></blockquote><div><br>I'd go wit=
h undefined behaviour, so I can skip the testing -> more performance. Th=
e debug-mode standard library is free to throw an exception, call terminate=
, or whatever. Also static analyser tools can detect misuse easier.<br><br>=
Regards, Robert<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_2959_31701150.1358978041774--
.
Author: Jeffrey Yasskin <jyasskin@googlers.com>
Date: Wed, 23 Jan 2013 13:54:08 -0800
Raw View
On Wed, Jan 23, 2013 at 1:35 PM, R=C3=B3bert D=C3=A1vid <lrdxgm@gmail.com> =
wrote:
>
>
> 2013. janu=C3=A1r 23., szerda 12:57:40 UTC+1 id=C5=91pontban Chris Jeffer=
son a
> k=C3=B6vetkez=C5=91t =C3=ADrta:
>>
>>
>> I think the problem was that get_value_or_call either has to return by
>> value (which involves possibly expensive copying) or by reference (which
>> involves possibly hanging references to the 'or' value).
>>
>> Your get_value_or_call function avoids constructing the 'or' object whic=
h
>> it is not required, but still involves copying. There is no good reason =
for
>> this not to be a free function, so I wonder if this is one area where we
>> should see what people end up using, and standardise later?
>>
>> Chris
>
>
> I would like avoid the "standardize later" case, as that would mean not
> having this anywhere, and I'll need to implement it myself :)
That's kind of the point of "standardize later". :) You'll need to
implement it yourself, as will I and lots of other people, and then we
get to see what you all do and how it bit you, and standardize the
best option given that information.
Jeffrey
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Wed, 23 Jan 2013 22:56:34 +0100
Raw View
2013/1/23 R=F3bert D=E1vid <lrdxgm@gmail.com>:
>>
>>> with the semantics suggested by Daniel:
>>>
>>> T const& optional<T>::value() const
>>> {
>>> if (is_initialized)
>>> rerurn contained_value_;
>>> else
>>> throw invalid_optional_value_access{};
>>> }
>>
>>
>> I don't think that stack unwinding is an appropriate way to handle logic
>> errors and I would prefer a call to std::terminate instead:
>> http://liveworkspace.org/code/G6txS$1
>>
>> But others may have different preferences.
>
>
> I'd go with undefined behaviour, so I can skip the testing -> more
> performance. The debug-mode standard library is free to throw an exceptio=
n,
> call terminate, or whatever. Also static analyser tools can detect misuse
> easier.
If you want performance, call operator* directly. This is the primary
access point for the value. The explicit function is intended to
provide a checked variant, this is "existing practice" for a lot of
library components, such as the classic "at()" functions for
containers.
- Daniel
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Wed, 23 Jan 2013 22:57:52 +0100
Raw View
On Wed, Jan 23, 2013 at 10:56 PM, Daniel Kr=FCgler
<daniel.kruegler@gmail.com> wrote:
> If you want performance, call operator* directly. This is the primary
> access point for the value. The explicit function is intended to
> provide a checked variant, this is "existing practice" for a lot of
> library components, such as the classic "at()" functions for
> containers.
Are these used in existing practice? That question came up on the
Boost list recently too.
I've never used them myself.
--=20
Olaf
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?UTF-8?Q?R=C3=B3bert_D=C3=A1vid?= <lrdxgm@gmail.com>
Date: Wed, 23 Jan 2013 14:07:23 -0800 (PST)
Raw View
------=_Part_201_16662610.1358978843221
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
2013. janu=E1r 23., szerda 22:57:52 UTC+1 id=F5pontban Olaf van der Spek a=
=20
k=F6vetkez=F5t =EDrta:
>
> On Wed, Jan 23, 2013 at 10:56 PM, Daniel Kr=FCgler=20
> <daniel....@gmail.com <javascript:>> wrote:=20
> > If you want performance, call operator* directly. This is the primary=
=20
> > access point for the value. The explicit function is intended to=20
> > provide a checked variant, this is "existing practice" for a lot of=20
> > library components, such as the classic "at()" functions for=20
> > containers.=20
>
> Are these used in existing practice? That question came up on the=20
> Boost list recently too.=20
> I've never used them myself.=20
>
> Yes, they are useful sometimes. You are right Daniel, I didn't think of=
=20
the operator.
Regards, Robert
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_201_16662610.1358978843221
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>2013. janu=E1r 23., szerda 22:57:52 UTC+1 id=F5pontban Olaf van der=
Spek a k=F6vetkez=F5t =EDrta:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
On Wed, Jan 23, 2013 at 10:56 PM, Daniel Kr=FCgler
<br><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
UQrD7lAopjYJ">daniel....@gmail.com</a>> wrote:
<br>> If you want performance, call operator* directly. This is the prim=
ary
<br>> access point for the value. The explicit function is intended to
<br>> provide a checked variant, this is "existing practice" for a lot o=
f
<br>> library components, such as the classic "at()" functions for
<br>> containers.
<br>
<br>Are these used in existing practice? That question came up on the
<br>Boost list recently too.
<br>I've never used them myself.
<br>
<br></blockquote><div>Yes, they are useful sometimes. You are right Daniel,=
I didn't think of the operator.<br><br>Regards, Robert<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_201_16662610.1358978843221--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Wed, 23 Jan 2013 14:18:26 -0800 (PST)
Raw View
------=_Part_419_22928095.1358979506594
Content-Type: text/plain; charset=ISO-8859-1
> 4) In the absence of compiler support, what if get_value_or insists
> that both of its arguments are either rvalues or lvalues? A mix causes
> a compile error. If both arguments are rvalues, it returns moved
> versions. If both are lvalues, it returns a reference, of appropriate
> const-ness.
>
This would render the following, IMO typical, examples ill-formed:
return getPosition().get_value_or(std::string::npos); // npos is an lvalue
constexpr int LEAST = ~0;
return getBiggestInt().get_value_or(LEAST); // rvalue-lvalue mismatch
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_419_22928095.1358979506594
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">4) In the absence of compi=
ler support, what if get_value_or insists
<br>that both of its arguments are either rvalues or lvalues? A mix causes
<br>a compile error. If both arguments are rvalues, it returns moved
<br>versions. If both are lvalues, it returns a reference, of appropriate
<br>const-ness.
<br></blockquote><div><br>This would render the following, IMO typical, exa=
mples ill-formed:<br><br><div class=3D"prettyprint" style=3D"background-col=
or: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: sol=
id; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint">=
<div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-=
by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> getPosition</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">().</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">get_value_or</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">std=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">string</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">npos</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// npos is an lvalue </span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">constexpr</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> LEAST </span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">~<=
/span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> getBiggestInt</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">().</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">get_value_or</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">LEAST</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify">// rvalue-lvalue mismatch</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><br><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_419_22928095.1358979506594--
.
Author: Jeffrey Yasskin <jyasskin@googlers.com>
Date: Wed, 23 Jan 2013 14:23:38 -0800
Raw View
On Wed, Jan 23, 2013 at 2:18 PM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
>
>> 4) In the absence of compiler support, what if get_value_or insists
>> that both of its arguments are either rvalues or lvalues? A mix causes
>> a compile error. If both arguments are rvalues, it returns moved
>> versions. If both are lvalues, it returns a reference, of appropriate
>> const-ness.
>
>
> This would render the following, IMO typical, examples ill-formed:
>
> return getPosition().get_value_or(std::string::npos); // npos is an lvalu=
e
>
> constexpr int LEAST =3D ~0;
> return getBiggestInt().get_value_or(LEAST); // rvalue-lvalue mismatch
Yes it would. I still don't have a strong feeling for which of the
options is least-bad, which is why leaving it out and waiting for user
feedback is attractive.
Jeffrey
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Wed, 23 Jan 2013 14:28:22 -0800 (PST)
Raw View
------=_Part_111_29388769.1358980102585
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu =B6roda, 23 stycznia 2013 23:23:38 UTC+1 u=BFytkownik Jeffrey Yasski=
n=20
napisa=B3:
>
> On Wed, Jan 23, 2013 at 2:18 PM, Andrzej Krzemie=F1ski <akrz...@gmail.com=
<javascript:>>=20
> wrote:=20
> >=20
> >> 4) In the absence of compiler support, what if get_value_or insists=20
> >> that both of its arguments are either rvalues or lvalues? A mix causes=
=20
> >> a compile error. If both arguments are rvalues, it returns moved=20
> >> versions. If both are lvalues, it returns a reference, of appropriate=
=20
> >> const-ness.=20
> >=20
> >=20
> > This would render the following, IMO typical, examples ill-formed:=20
> >=20
> > return getPosition().get_value_or(std::string::npos); // npos is an=20
> lvalue=20
> >=20
> > constexpr int LEAST =3D ~0;=20
> > return getBiggestInt().get_value_or(LEAST); // rvalue-lvalue mismatch=
=20
>
> Yes it would. I still don't have a strong feeling for which of the=20
> options is least-bad, which is why leaving it out and waiting for user=20
> feedback is attractive.=20
>
What do others feel about dropping get_value_or altogether? (at least for=
=20
C++17)=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_111_29388769.1358980102585
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu =B6roda, 23 stycznia 2013 23:23:38 UTC+1 u=BFytkownik Jeffre=
y Yasskin napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wed, Ja=
n 23, 2013 at 2:18 PM, Andrzej Krzemie=F1ski <<a href=3D"javascript:" ta=
rget=3D"_blank" gdf-obfuscated-mailto=3D"MRxyEbJGJ0cJ">akrz...@gmail.com</a=
>> wrote:
<br>>
<br>>> 4) In the absence of compiler support, what if get_value_or in=
sists
<br>>> that both of its arguments are either rvalues or lvalues? A mi=
x causes
<br>>> a compile error. If both arguments are rvalues, it returns mov=
ed
<br>>> versions. If both are lvalues, it returns a reference, of appr=
opriate
<br>>> const-ness.
<br>>
<br>>
<br>> This would render the following, IMO typical, examples ill-formed:
<br>>
<br>> return getPosition().get_value_or(<wbr>std::string::npos); // npos=
is an lvalue
<br>>
<br>> constexpr int LEAST =3D ~0;
<br>> return getBiggestInt().get_value_or(<wbr>LEAST); // rvalue-lvalue =
mismatch
<br>
<br>Yes it would. I still don't have a strong feeling for which of the
<br>options is least-bad, which is why leaving it out and waiting for user
<br>feedback is attractive.
<br></blockquote><div><br>What do others feel about dropping <span style=3D=
"font-family: courier new,monospace;">get_value_or</span> altogether? (at l=
east for C++17) <br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_111_29388769.1358980102585--
.
Author: =?ISO-8859-2?Q?Mikael_Kilpel=E4inen?=
Date: Wed, 23 Jan 2013 23:31:08 +0100
Raw View
This is a multi-part message in MIME format.
--------------090405050305040105000507
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> What do others feel about dropping get_value_or altogether? (at least
> for C++17)
>
I would find that very unfortunate, from my point of view it is one of
the main use cases.
Mikael
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--------------090405050305040105000507
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-2"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<blockquote
cite="mid:3c2e094b-36f4-40e6-a9ff-48c18363f7a0@isocpp.org"
type="cite">
<div>What do others feel about dropping <span style="font-family:
courier new,monospace;">get_value_or</span> altogether? (at
least for C++17) <br>
</div>
<br>
</blockquote>
I would find that very unfortunate, from my point of view it is one
of the main use cases.<br>
<br>
<br>
Mikael<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
--------------090405050305040105000507--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 24 Jan 2013 00:37:26 +0200
Raw View
On 24 January 2013 00:31, Mikael Kilpel=E4inen
<mikael.kilpelainen@gmail.com> wrote:
> What do others feel about dropping get_value_or altogether? (at least for
> C++17)
> I would find that very unfortunate, from my point of view it is one of th=
e
> main use cases.
I won't cry bloody murder if you drop it from the proposal. I won't
cry bloody murder
if it's in the proposal and the LWG chooses to axe it.
However, I'm 100% certain that its returning a value is the right
choice, and I don't need
to wait for years of experiments to prove that. ;) Therefore I'd
recommend keeping it
in the proposal as it's currently specified.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Wed, 23 Jan 2013 16:38:46 -0600
Raw View
On Wed, Jan 23, 2013 at 4:28 PM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
> What do others feel about dropping get_value_or altogether? (at least for
> C++17)
`.get_value_or` has too much use cases, but itself makes std::optional
less meaningful. I also feel sad, but you have to decide...
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Thu, 24 Jan 2013 09:38:45 +1100
Raw View
On Thu, Jan 24, 2013 at 8:27 AM, Olaf van der Spek <olafvdspek@gmail.com> w=
rote:
> On Wed, Jan 23, 2013 at 10:22 PM, Daniel Kr=FCgler
> <daniel.kruegler@gmail.com> wrote:
>>>> Or Foo* p =3D &*smartptr;
>
>>> Is this defined behaviour if the pointer is null?
>>
>> Yes, it is, because both these expressions invoke member functions
>> that impose the precondition that the underlying pointer is not null.
>
> The precondition is violated, so the behaviour is *undefined*, isn't it?
>
> So &* is not a suitable replacement for a T* get() member.
My point was not that &* was a replacement for get()... especially
given the fact that get() is a function and, therefore, its behavior
very much depend on its actual implementation rather than on one's
expectations what get() might do. My point was against 1) adding (as I
perceive) non-essential api and 2) legitimizing getting a pointer to
the underlying (likely on the stack) object.
For something like get() to be used successfully, one needs to learn
1) it exists; 2) what it actually does; 3) what its limitations are.
All that inevitably pushes the entry level higher and higher. None of
these issues seem to exist when the standard (!) facilities are
used... like & -- getting the address of. It's part of the language.
So, anyone claiming to be a C++ programmer must already (!) know its
application and limitations. For example,
int a;
int* ap =3D &a;
Yes, I got the address of 'a'. The onus is on me to make sure 'a'
existed in the first place and won't be released from under my feet.
optional<int> a;
int* ap1 =3D &*a;
int* ap2 =3D a ? &*a : 0;
int* ap3 =3D a.get();
For 'ap1' and 'ap2' one applies the same language knowledge (and
awareness) as for 'ap'. For 'ap3' though it's far from clear as it
applied the learning requirement. That learning requirement multiplied
by the number of new methods and the number of deployed classes deeply
affects productivity, readability, reliability.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 24 Jan 2013 00:40:50 +0200
Raw View
On 24 January 2013 00:38, Vladimir Batov <vb.mail.247@gmail.com> wrote:
> optional<int> a;
> int* ap1 = &*a;
> int* ap2 = a ? &*a : 0;
> int* ap3 = a.get();
> For 'ap1' and 'ap2' one applies the same language knowledge (and
> awareness) as for 'ap'. For 'ap3' though it's far from clear as it
> applied the learning requirement. That learning requirement multiplied
> by the number of new methods and the number of deployed classes deeply
> affects productivity, readability, reliability.
I happen to find ap3 massively more readable and reliable than ap2.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Wed, 23 Jan 2013 14:43:03 -0800 (PST)
Raw View
------=_Part_482_9493576.1358980983719
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu =B6roda, 23 stycznia 2013 22:22:11 UTC+1 u=BFytkownik Mikael Kilpel=
=E4inen=20
napisa=B3:
>
> > Think it as a "privilege separation". The API (like query) who=20
> > provides (returns) the optional<T> decide whether the nullable=20
> > state can be safely ignored with a fallback, and the users of the=20
> > API can not ignore it with a fallback if the provider says no. And=20
> > all other users (optional<T> const&) should use .value(), because=20
> > the first API user decide the error handling policy -- no error, or=20
> > exception.=20
> >=20
> Okey, I see what you mean. But i don't think it is quite that black and=
=20
> white. The safeness here is in the eye of the beholder.=20
> Just as well many people think that parameters you have by value ought=20
> not to be altered, as it might be confusing.=20
>
> I still think the const ref params would be big concern as for me it=20
> most likely is the most likely case.=20
> Also in most function i would need the value once and not care about it=
=20
> afterwards, i try to keep my functions as=20
> small as possible.=20
>
>
> Something related though..=20
>
> The proposal explicitly bans relational operators with the contained=20
> type. Fair enough, and the explanation and example=20
> are good. I agree, however the rationale only applies to < and <=3D=20
> functions. I have really liked to use the =3D=3D and !=3D with=20
> boost::optional. I agree that on consistency reasons we might want to=20
> ban those as well and i certainly can live with the=20
> alternatives.. but.. :)=20
>
=20
This is our feeling of safety. My personal experience is that I was once=20
bitten by the unfortunate consequences of the "mixed" comparison on the one=
=20
hand, and on the other never needed to do such mixed comparison=20
consciously. What would you use such mixed comparisons for?
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_482_9493576.1358980983719
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu =B6roda, 23 stycznia 2013 22:22:11 UTC+1 u=BFytkownik Mikael=
Kilpel=E4inen napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">> =
Think it as a "privilege separation". The API (like query) who
<br>> provides (returns) the optional<T> decide whether the nullab=
le
<br>> state can be safely ignored with a fallback, and the users of the
<br>> API can not ignore it with a fallback if the provider says no. &nb=
sp;And
<br>> all other users (optional<T> const&) should use .value()=
, because
<br>> the first API user decide the error handling policy -- no error, o=
r
<br>> exception.
<br>>
<br>Okey, I see what you mean. But i don't think it is quite that black and=
=20
<br>white. The safeness here is in the eye of the beholder.
<br>Just as well many people think that parameters you have by value ought=
=20
<br>not to be altered, as it might be confusing.
<br>
<br>I still think the const ref params would be big concern as for me it=20
<br>most likely is the most likely case.
<br>Also in most function i would need the value once and not care about it=
=20
<br>afterwards, i try to keep my functions as
<br>small as possible.
<br>
<br>
<br>Something related though..
<br>
<br>The proposal explicitly bans relational operators with the contained=20
<br>type. Fair enough, and the explanation and example
<br>are good. I agree, however the rationale only applies to < and <=
=3D=20
<br>functions. I have really liked to use the =3D=3D and !=3D with
<br>boost::optional. I agree that on consistency reasons we might want to=
=20
<br>ban those as well and i certainly can live with the
<br>alternatives.. but.. :)
<br></blockquote><div> </div><div>This is our feeling of safety. My pe=
rsonal experience is that I was once bitten by the unfortunate consequences=
of the "mixed" comparison on the one hand, and on the other never needed t=
o do such mixed comparison consciously. What would you use such mixed compa=
risons for?<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_482_9493576.1358980983719--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 23 Jan 2013 16:43:30 -0600
Raw View
--f46d043be240dc64d104d3fc6ecb
Content-Type: text/plain; charset=ISO-8859-1
On 23 January 2013 16:37, Ville Voutilainen <ville.voutilainen@gmail.com>wrote:
> I won't cry bloody murder if you drop it from the proposal. I won't
> cry bloody murder
> if it's in the proposal and the LWG chooses to axe it.
>
> However, I'm 100% certain that its returning a value is the right
> choice, and I don't need
> to wait for years of experiments to prove that. ;) Therefore I'd
> recommend keeping it
> in the proposal as it's currently specified.
>
+1 to both of these.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--f46d043be240dc64d104d3fc6ecb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 23 January 2013 16:37, Ville Voutilainen <span dir=3D"ltr"><<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@gmail.com</a>></span> wrote:<br><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">
I won't cry bloody murder if you drop it from the proposal. I won't=
<br>
cry bloody murder<br>
if it's in the proposal and the LWG chooses to axe it.<br>
<br>
However, I'm 100% certain that its returning a value is the right<br>
choice, and I don't need<br>
to wait for years of experiments to prove that. ;) Therefore I'd<br>
recommend keeping it<br>
in the proposal as it's currently specified.<br clear=3D"all"></blockqu=
ote><div><br>+1 to both of these. <br></div></div>-- <br>=A0Nevin ":-)=
" Liber=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=
=3D"_blank">nevin@eviloverlord.com</a>>=A0 (847) 691-1404
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--f46d043be240dc64d104d3fc6ecb--
.
Author: Jeffrey Yasskin <jyasskin@googlers.com>
Date: Wed, 23 Jan 2013 14:44:24 -0800
Raw View
On Wed, Jan 23, 2013 at 2:38 PM, Vladimir Batov <vb.mail.247@gmail.com> wro=
te:
> On Thu, Jan 24, 2013 at 8:27 AM, Olaf van der Spek <olafvdspek@gmail.com>=
wrote:
>> On Wed, Jan 23, 2013 at 10:22 PM, Daniel Kr=FCgler
>> <daniel.kruegler@gmail.com> wrote:
>>>>> Or Foo* p =3D &*smartptr;
>>
>>>> Is this defined behaviour if the pointer is null?
>>>
>>> Yes, it is, because both these expressions invoke member functions
>>> that impose the precondition that the underlying pointer is not null.
>>
>> The precondition is violated, so the behaviour is *undefined*, isn't it?
>>
>> So &* is not a suitable replacement for a T* get() member.
>
> My point was not that &* was a replacement for get()... especially
> given the fact that get() is a function and, therefore, its behavior
> very much depend on its actual implementation rather than on one's
> expectations what get() might do. My point was against 1) adding (as I
> perceive) non-essential api and 2) legitimizing getting a pointer to
> the underlying (likely on the stack) object.
I do agree that get() isn't essential, but argument (2) doesn't
convince me that it's bad. C++ programmers always have to deal with
object lifetimes and pointers to values owned by other objects. For
example, operator* also returns the address of the underlying object,
and unique_ptr<T>::get() also returns a pointer to a value that will
be destroyed (by default) when the unique_ptr goes out of scope.
Jeffrey
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?ISO-8859-1?Q?Mikael_Kilpel=E4inen?=
Date: Wed, 23 Jan 2013 23:46:27 +0100
Raw View
23.1.2013 23:40, Ville Voutilainen kirjoitti:
> On 24 January 2013 00:38, Vladimir Batov <vb.mail.247@gmail.com> wrote:
>> optional<int> a;
>> int* ap1 = &*a;
>> int* ap2 = a ? &*a : 0;
>> int* ap3 = a.get();
>> For 'ap1' and 'ap2' one applies the same language knowledge (and
>> awareness) as for 'ap'. For 'ap3' though it's far from clear as it
>> applied the learning requirement. That learning requirement multiplied
>> by the number of new methods and the number of deployed classes deeply
>> affects productivity, readability, reliability.
> I happen to find ap3 massively more readable and reliable than ap2.
>
I can only agree with this!
Mikael
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Thu, 24 Jan 2013 09:46:55 +1100
Raw View
On Thu, Jan 24, 2013 at 9:28 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
> ...
> What do others feel about dropping get_value_or altogether? (at least for
> C++17)
I'd personally think it's be the right thing to do. To begin with I
feel that functionality is not a property of optional but rather all
nullable classes. So, IMO it needs to be implemented that way.
Secondly, it seems to be a convenience feature which again raises the
question if that belongs *with* the class. Thirdly, the amount of
discussion generated about the function speaks volumes -- there is no
clear-cut agreement on its behavior, applicability, etc.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?ISO-8859-2?Q?Mikael_Kilpel=E4inen?=
Date: Wed, 23 Jan 2013 23:52:01 +0100
Raw View
> This is our feeling of safety. My personal experience is that I was
> once bitten by the unfortunate consequences of the "mixed" comparison
> on the one hand, and on the other never needed to do such mixed
> comparison consciously. What would you use such mixed comparisons for?
>
For me it was about checking the optional..
void func( optional<int> const& o ) {
if( o == 1 ) { //instead of o && *o == 1 or similar
whatever..
}
}
That is, i don't need to check if the optional is engaged or not, so i
cannot forget it either and i don't need to type the name twice..
(okey, you can always do the comparison by constructing the optional
from the value and comparing)
I never even thought of using < though .. so it was purely == and != always.
Mikael
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Thu, 24 Jan 2013 09:56:45 +1100
Raw View
On Thu, Jan 24, 2013 at 9:46 AM, Mikael Kilpel=E4inen
<mikael.kilpelainen@gmail.com> wrote:
> 23.1.2013 23:40, Ville Voutilainen kirjoitti:
>
>> On 24 January 2013 00:38, Vladimir Batov <vb.mail.247@gmail.com> wrote:
>>>
>>> optional<int> a;
>>> int* ap1 =3D &*a;
>>> int* ap2 =3D a ? &*a : 0;
>>> int* ap3 =3D a.get();
>>> For 'ap1' and 'ap2' one applies the same language knowledge (and
>>> awareness) as for 'ap'. For 'ap3' though it's far from clear as it
>>> applied the learning requirement. That learning requirement multiplied
>>> by the number of new methods and the number of deployed classes deeply
>>> affects productivity, readability, reliability.
>>
>> I happen to find ap3 massively more readable and reliable than ap2.
>>
> I can only agree with this!
Not so fast! :-) The problem here is that your sensation of "massively
more readable and reliable" is purely subjective and only based on
your *interpretation* what get() *might* do. In reality, get() might
do something altogether different (which obviously depends on how it's
implemented). Have you noticed the confusion previously over get's
implementation/behavior? So, for *true* "massively more readable and
reliable" sensation one has to read the documentation and *remember*
all the subtleties. One does not have such issues with, say, 'ap2'...
as it deploys the basic (well-known?) language constructs.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 23 Jan 2013 16:51:45 -0600
Raw View
--f46d0444029a28b57a04d3fca06e
Content-Type: text/plain; charset=ISO-8859-1
On 23 January 2013 16:40, Ville Voutilainen <ville.voutilainen@gmail.com>wrote:
> On 24 January 2013 00:38, Vladimir Batov <vb.mail.247@gmail.com> wrote:
> > optional<int> a;
> > int* ap1 = &*a;
> > int* ap2 = a ? &*a : 0;
> > int* ap3 = a.get();
>
>
> I happen to find ap3 massively more readable and reliable than ap2.
>
What happens when it is written as:
auto a1 = &*a;
auto a2 = a ? &*a : 0;
auto a3 = a.get();
I don't find a3 to be as readable, as I expect it to return a reference,
not a pointer.
Nothing else about optional interface to pointers, and we have a hard
enough time telling people that optional has pointer syntax but does not
model pointer semantics. get() returning a pointer is surprising
semantics. This differs from smart pointers in that they hold pointers,
not values.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--f46d0444029a28b57a04d3fca06e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 23 January 2013 16:40, Ville Voutilainen <span dir=3D"ltr"><<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@gmail.com</a>></span> wrote:<br><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">
<div class=3D"im">On 24 January 2013 00:38, Vladimir Batov <<a href=3D"m=
ailto:vb.mail.247@gmail.com">vb.mail.247@gmail.com</a>> wrote:<br>
> optional<int> a;<br>
> int* ap1 =3D &*a;<br>
> int* ap2 =3D a ? &*a : 0;<br>
> int* ap3 =3D a.get();<br><br>
<br>
</div>I happen to find ap3 massively more readable and reliable than ap2.<b=
r></blockquote><div><br>What happens when it is written as:<br><br>auto a1 =
=3D &*a;<br>auto a2 =3D a ? &*a : 0;<br>auto a3 =3D a.get();<br><br=
>
I don't find a3 to be as readable, as I expect it to return a reference=
, not a pointer.<br><br>Nothing else about optional interface to pointers, =
and we have a hard enough time telling people that optional has pointer syn=
tax but does not model pointer semantics.=A0 get() returning a pointer is s=
urprising semantics.=A0 This differs from smart pointers in that they hold =
pointers, not values.<br>
</div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
>=A0 (847) 691-1404
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--f46d0444029a28b57a04d3fca06e--
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Thu, 24 Jan 2013 10:03:25 +1100
Raw View
On Thu, Jan 24, 2013 at 9:51 AM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 23 January 2013 16:40, Ville Voutilainen <ville.voutilainen@gmail.com>
> wrote:
>>
>> On 24 January 2013 00:38, Vladimir Batov <vb.mail.247@gmail.com> wrote:
>> > optional<int> a;
>> > int* ap1 = &*a;
>> > int* ap2 = a ? &*a : 0;
>> > int* ap3 = a.get();
>>
>> I happen to find ap3 massively more readable and reliable than ap2.
>
> What happens when it is written as:
>
> auto a1 = &*a;
> auto a2 = a ? &*a : 0;
> auto a3 = a.get();
>
> I don't find a3 to be as readable, as I expect it to return a reference, not
> a pointer.
>
> Nothing else about optional interface to pointers, and we have a hard enough
> time telling people that optional has pointer syntax but does not model
> pointer semantics. get() returning a pointer is surprising semantics. This
> differs from smart pointers in that they hold pointers, not values.
Yep, If get() was so obvious/natural, how comes that some expect a
pointer returned, some a reference? Does it check 'engage-ness'? Does
it throw? What is the lifetime of the returned pointer (if that *is a
pointer)?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: =?ISO-8859-1?Q?Mikael_Kilpel=E4inen?=
Date: Thu, 24 Jan 2013 00:06:31 +0100
Raw View
23.1.2013 23:56, Vladimir Batov kirjoitti:
> On Thu, Jan 24, 2013 at 9:46 AM, Mikael Kilpel=E4inen
> <mikael.kilpelainen@gmail.com> wrote:
>> 23.1.2013 23:40, Ville Voutilainen kirjoitti:
>>
>>> On 24 January 2013 00:38, Vladimir Batov <vb.mail.247@gmail.com> wrote:
>>>> optional<int> a;
>>>> int* ap1 =3D &*a;
>>>> int* ap2 =3D a ? &*a : 0;
>>>> int* ap3 =3D a.get();
>>>> For 'ap1' and 'ap2' one applies the same language knowledge (and
>>>> awareness) as for 'ap'. For 'ap3' though it's far from clear as it
>>>> applied the learning requirement. That learning requirement multiplied
>>>> by the number of new methods and the number of deployed classes deeply
>>>> affects productivity, readability, reliability.
>>> I happen to find ap3 massively more readable and reliable than ap2.
>>>
>> I can only agree with this!
> Not so fast! :-) The problem here is that your sensation of "massively
> more readable and reliable" is purely subjective and only based on
> your *interpretation* what get() *might* do.
Indeed, is that not what we said? We find it to be more..
> In reality, get() might
> do something altogether different (which obviously depends on how it's
> implemented). Have you noticed the confusion previously over get's
> implementation/behavior? So, for *true* "massively more readable and
> reliable" sensation one has to read the documentation and *remember*
> all the subtleties. One does not have such issues with, say, 'ap2'...
> as it deploys the basic (well-known?) language constructs.
>
Indeed, I can only talk for myself and my experience... Like we all.
That said, i would really go with the _value_ name for the _get_ like=20
function and the semantics discussed earlier. Makes it more clear.
Mikael
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Thu, 24 Jan 2013 00:07:58 +0100
Raw View
On Wed, Jan 23, 2013 at 11:51 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
>> I happen to find ap3 massively more readable and reliable than ap2.
>
>
> What happens when it is written as:
>
> auto a1 = &*a;
> auto a2 = a ? &*a : 0;
> auto a3 = a.get();
>
> I don't find a3 to be as readable, as I expect it to return a reference, not
> a pointer.
Why?
*a returns a reference already
What would you call a function returning a (possibly null) pointer?
--
Olaf
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Thu, 24 Jan 2013 10:12:39 +1100
Raw View
On Thu, Jan 24, 2013 at 10:07 AM, Olaf van der Spek
<olafvdspek@gmail.com> wrote:
> On Wed, Jan 23, 2013 at 11:51 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
>>> I happen to find ap3 massively more readable and reliable than ap2.
>>
>> What happens when it is written as:
>>
>> auto a1 = &*a;
>> auto a2 = a ? &*a : 0;
>> auto a3 = a.get();
>>
>> I don't find a3 to be as readable, as I expect it to return a reference, not
>> a pointer.
>
> Why?
> *a returns a reference already
.... and 'a2' returns a pointer.
> What would you call a function returning a (possibly null) pointer?
Oh, c'mon. Surely you are not arguing that 'get' is the most
descriptive of all names for a function returning a (possibly null)
pointer?.. Especially in the context of a value class.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Thu, 24 Jan 2013 00:14:51 +0100
Raw View
On Thu, Jan 24, 2013 at 12:12 AM, Vladimir Batov <vb.mail.247@gmail.com> wrote:
>> Why?
>> *a returns a reference already
>
> ... and 'a2' returns a pointer.
a2 can't be used with rvalues, is longer and complexer.
>> What would you call a function returning a (possibly null) pointer?
>
> Oh, c'mon. Surely you are not arguing that 'get' is the most
> descriptive of all names for a function returning a (possibly null)
> pointer?.. Especially in the context of a value class.
You forgot to answer the question. ;)
Yes, I'm voting for get.
--
Olaf
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Jeffrey Yasskin <jyasskin@googlers.com>
Date: Wed, 23 Jan 2013 15:17:33 -0800
Raw View
On Wed, Jan 23, 2013 at 2:43 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 23 January 2013 16:37, Ville Voutilainen <ville.voutilainen@gmail.com>
> wrote:
>>
>> I won't cry bloody murder if you drop it from the proposal. I won't
>> cry bloody murder
>> if it's in the proposal and the LWG chooses to axe it.
>>
>> However, I'm 100% certain that its returning a value is the right
>> choice, and I don't need
>> to wait for years of experiments to prove that. ;) Therefore I'd
>> recommend keeping it
>> in the proposal as it's currently specified.
>
>
> +1 to both of these.
Of the people commenting here, Ville and Nevin (and Daniel) have the
most experience with the LWG, so I'm happy to bow to their preference.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: =?ISO-8859-2?Q?Mikael_Kilpel=E4inen?=
Date: Thu, 24 Jan 2013 00:20:24 +0100
Raw View
> void func( optional<int> const& o ) {
> if( o == 1 ) { //instead of o && *o == 1 or similar
> whatever..
> }
> }
>
> That is, i don't need to check if the optional is engaged or not, so i
> cannot forget it either and i don't need to type the name twice..
> (okey, you can always do the comparison by constructing the optional
> from the value and comparing)
>
Just wanted to add here that actually the one of most convient cases being..
BOOST_CHECK( my_func_returning_optional() == my_value );
Again, i could construct optional of the right hand side, good enough,
would work, might have performance implications though.
One con i didn't mention yet is that you might confuse assigment with
the comparison .. then again you can do the same with the full type
including optional.
Mikael
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 23 Jan 2013 17:22:16 -0600
Raw View
--e89a8f3bae49833f2c04d3fcf98d
Content-Type: text/plain; charset=ISO-8859-1
On 23 January 2013 17:07, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>
> Why?
> *a returns a reference already
>
Why should I expect anything in optional to return a pointer?
>
> What would you call a function returning a (possibly null) pointer?
>
to_pointer?
My position:
I am strongly against calling this feature get().
I am weakly for this feature with a better name, such as to_pointer()
(either as a free function or a member function).
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--e89a8f3bae49833f2c04d3fcf98d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 23 January 2013 17:07, Olaf van der Spek <span dir=3D"ltr"><<a href=
=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</a>=
></span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">
<div class=3D"im"><br>
</div>Why?<br>
*a returns a reference already<br></blockquote><div><br>Why should I expect=
anything in optional to return a pointer?<br>=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">
<br>
What would you call a function returning a (possibly null) pointer?<br></bl=
ockquote><div><br>to_pointer?<br clear=3D"all"></div></div><br>My position:=
<br><br>I am strongly against calling this feature get().<br><br>I am weakl=
y for this feature with a better name, such as to_pointer() (either as a fr=
ee function or a member function).<br>
-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"mailto:nevin=
@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=A0 (847=
) 691-1404
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--e89a8f3bae49833f2c04d3fcf98d--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Thu, 24 Jan 2013 00:31:21 +0100
Raw View
On Thu, Jan 24, 2013 at 12:22 AM, Nevin Liber <nevin@eviloverlord.com> wrote:
> Why should I expect anything in optional to return a pointer?
Why not?
There's demand for the feature.
shared_ptr and unique_ptr get() return pointers to the content.
While those two are pointers and optional isn't, both point to /
contain something or are empty.
>> What would you call a function returning a (possibly null) pointer?
> to_pointer?
Reasonable
--
Olaf
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 23 Jan 2013 18:02:49 -0600
Raw View
--f46d0444029a86844004d3fd8ae3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 23 January 2013 16:28, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> wro=
te:
> (at least for C++17)
>
I' d rather get optional in earlier if possible (either C++14 or as a TS).
--=20
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
--f46d0444029a86844004d3fd8ae3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_quote">On 23 January 2013 16:28, Andrzej Krzemie=C5=84s=
ki <span dir=3D"ltr"><<a href=3D"mailto:akrzemi1@gmail.com" target=3D"_b=
lank">akrzemi1@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">
<div>(at least for <span class=3D"il">C</span>++<span class=3D"il">17</span=
>) <div class=3D"yj6qo ajU"><div id=3D":2tk" class=3D"ajR" tabindex=3D"0"><=
/div></div></div></blockquote></div><br>I' d rather get optional in ear=
lier if possible (either C++14 or as a TS).<br>
-- <br>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=
=C2=A0 (847) 691-1404
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--f46d0444029a86844004d3fd8ae3--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 23 Jan 2013 23:48:08 -0600
Raw View
--20cf303b40fb63e8c504d4025d89
Content-Type: text/plain; charset=ISO-8859-1
On 23 January 2013 17:31, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Thu, Jan 24, 2013 at 12:22 AM, Nevin Liber <nevin@eviloverlord.com>
> wrote:
> > Why should I expect anything in optional to return a pointer?
>
I'm not arguing against the feature, I'm arguing against naming it get(),
because nothing about pointers is implied by it. Even something as short
as ptr() would be fine.
The practical lifetime for a non-null pointer returned is that it is valid
while the optional is engaged. If an engaged optional is disengaged and
then engaged, is the pointer still valid?
This discussion also begs the question: should we be able to construct
and/or assign an optional<T> from a T*?
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--20cf303b40fb63e8c504d4025d89
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 23 January 2013 17:31, Olaf van der Spek <span dir=3D"ltr"><<a href=
=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</a>=
></span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">
<div class=3D"im">On Thu, Jan 24, 2013 at 12:22 AM, Nevin Liber <<a href=
=3D"mailto:nevin@eviloverlord.com">nevin@eviloverlord.com</a>> wrote:<br=
>
> Why should I expect anything in optional to return a pointer?<br></div=
></blockquote><div><br></div><div>I'm not arguing against the feature, =
I'm arguing against naming it get(), because nothing about pointers is =
implied by it. =A0Even something as short as ptr() would be fine.</div>
<div><br></div><div>The practical lifetime for a non-null pointer returned =
is that it is valid while the optional is engaged. =A0If an engaged optiona=
l is disengaged and then engaged, is the pointer still valid?</div><div>
<br>
</div><div>This discussion also begs the question: =A0should we be able to =
construct and/or assign an optional<T> from a T*?</div></div>-- <br>=
=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"mailto:nevin@evilov=
erlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=A0 (847) 691-1=
404
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--20cf303b40fb63e8c504d4025d89--
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Thu, 24 Jan 2013 17:16:02 +1100
Raw View
--14dae9340fafc7662904d402bea5
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Jan 24, 2013 at 4:48 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 23 January 2013 17:31, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>
>> On Thu, Jan 24, 2013 at 12:22 AM, Nevin Liber <nevin@eviloverlord.com>
>> wrote:
>> > Why should I expect anything in optional to return a pointer?
>>
>
> I'm not arguing against the feature, I'm arguing against naming it get(),
> because nothing about pointers is implied by it. Even something as short
> as ptr() would be fine.
>
> The practical lifetime for a non-null pointer returned is that it is valid
> while the optional is engaged. If an engaged optional is disengaged and
> then engaged, is the pointer still valid?
>
There is no misunderstanding when one uses the std language facilities to
retrieve a pointer:
Foo foo1;
Foo* ptr = &foo1; // #1
That deployment is idiomatic in C/C++. The user knows that the onus is on
him to make sure ptrs are valid. I am hoping no one is arguing that (liking
or not is another matter). Then, if getting access to the underlying object
optional<Foo> foo2;
Foo& ref = *foo2; // #2
does not cause any issues, then, I do not see the next step of marrying #1
and #2 together as too hard to read for a C/C++ programmer:
optional<Foo> foo2;
Foo* ptr = &*foo2;
That also requires very little :-) from the Foo developer to "support" the
feature. It's an entirely another matter when's done like
Foo foo1;
Foo* ptr = foo.ptr(); // or get()
optional<Foo> foo2;
Foo* ptr2 = foo2.ptr();
as without learning/understanding what ptr() *actually* does the user
cannot rely on ptr2. Obviously that adds a hassle to the developer.
This discussion also begs the question: should we be able to construct
> and/or assign an optional<T> from a T*?
>
Isn't it achieved with
optional<T> foo = *foo_ptr;
again with onus on the user to ensure code safety and correctness? If the
purpose of all that extra complexity (ptr(), assignment from a ptr, etc.)
is to save a few key strokes, then IMO it is misguided as it results in
obfuscated code where the user *assumes* the behavior (unless he has an
intimate knowledge of all apis in use) rather than simply reads what is
*actually* there.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--14dae9340fafc7662904d402bea5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_quote">On Thu, Jan 24, 2013 at 4:48 PM, Nevin Liber <sp=
an dir=3D"ltr"><<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_bla=
nk">nevin@eviloverlord.com</a>></span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
<div class=3D"im">On 23 January 2013 17:31, Olaf van der Spek <span dir=3D"=
ltr"><<a href=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdsp=
ek@gmail.com</a>></span> wrote:<br></div><div class=3D"gmail_quote"><div=
class=3D"im">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div>On Thu, Jan 24, 2013 at 12:22 AM, Nevin Liber <<a href=3D"mailto:ne=
vin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>> wrot=
e:<br>
> Why should I expect anything in optional to return a pointer?<br></div=
></blockquote><div><br></div></div><div>I'm not arguing against the fea=
ture, I'm arguing against naming it get(), because nothing about pointe=
rs is implied by it. =A0Even something as short as ptr() would be fine.</di=
v>
<div><br></div><div>The practical lifetime for a non-null pointer returned =
is that it is valid while the optional is engaged. =A0If an engaged optiona=
l is disengaged and then engaged, is the pointer still valid?</div></div>
</blockquote><div><br>There is no misunderstanding when one uses the std la=
nguage facilities to retrieve a pointer:<br><br>Foo foo1;<br>Foo* ptr =3D &=
amp;foo1; // #1<br><br>That deployment is idiomatic in C/C++. The user know=
s that the onus is on him to make sure ptrs are valid. I am hoping no one i=
s arguing that (liking or not is another matter). Then, if getting access t=
o the underlying object <br>
<br>optional<Foo> foo2;<br>Foo& ref =3D *foo2; // #2<br><br>does =
not cause any issues, then, I do not see the next step of marrying #1 and #=
2 together as too hard to read for a C/C++ programmer:<br><br>optional<F=
oo> foo2;<br>
Foo* ptr =3D &*foo2;<br><br>That also requires very little :-) from the=
Foo developer to "support" the feature. It's an entirely ano=
ther matter when's done like <br><br>Foo foo1;<br>Foo* ptr =3D foo.ptr(=
); // or get()<br>
optional<Foo> foo2;<br>Foo* ptr2 =3D foo2.ptr();<br><br>as without le=
arning/understanding what ptr() *actually* does the user cannot rely on ptr=
2. Obviously that adds a hassle to the developer.<br></div><div><br></div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"gmail_quote"><div>This discuss=
ion also begs the question: =A0should we be able to construct and/or assign=
an optional<T> from a T*?</div>
</div></blockquote><div><br>Isn't it achieved with <br><br>optional<=
T> foo =3D *foo_ptr;<br><br>again with onus on the user to ensure code s=
afety and correctness? If the purpose of all that extra complexity (ptr(), =
assignment from a ptr, etc.) is to save a few key strokes, then IMO it is m=
isguided as it results in obfuscated code where the user *assumes* the beha=
vior (unless he has an intimate knowledge of all apis in use) rather than s=
imply reads what is *actually* there. <br>
<br></div></div><br>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--14dae9340fafc7662904d402bea5--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 24 Jan 2013 00:46:39 -0600
Raw View
--089e0122f170ac153204d4032e23
Content-Type: text/plain; charset=ISO-8859-1
On 24 January 2013 00:16, Vladimir Batov <vb.mail.247@gmail.com> wrote:
> There is no misunderstanding when one uses the std language facilities to
> retrieve a pointer:
>
> Foo foo1;
> Foo* ptr = &foo1; // #1
>
> That deployment is idiomatic in C/C++. The user knows that the onus is on
> him to make sure ptrs are valid. I am hoping no one is arguing that (liking
> or not is another matter). Then, if getting access to the underlying object
>
> optional<Foo> foo2;
> Foo& ref = *foo2; // #2
>
Ah, the problem also happens with references. What happens when you do:
optional<int> i(2);
int& ir = *i;
i = nullopt; // cannot use ir
i = 3; // can we use ir?
This discussion also begs the question: should we be able to construct
>> and/or assign an optional<T> from a T*?
>>
>
> Isn't it achieved with
>
> optional<T> foo = *foo_ptr;
>
No. The semantics I envision are: if foo_ptr is null, then foo should be
disengaged; otherwise, it should have a copy of *foo_ptr.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--089e0122f170ac153204d4032e23
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 24 January 2013 00:16, Vladimir Batov <span dir=3D"ltr"><<a href=3D"m=
ailto:vb.mail.247@gmail.com" target=3D"_blank">vb.mail.247@gmail.com</a>>=
;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
<div class=3D"gmail_quote"><div class=3D"im">There is no misunderstanding w=
hen one uses the std language facilities to retrieve a pointer:</div><div><=
br>Foo foo1;<br>Foo* ptr =3D &foo1; // #1<br><br>That deployment is idi=
omatic in C/C++. The user knows that the onus is on him to make sure ptrs a=
re valid. I am hoping no one is arguing that (liking or not is another matt=
er). Then, if getting access to the underlying object <br>
<br>optional<Foo> foo2;<br>Foo& ref =3D *foo2; // #2<br></div></d=
iv></blockquote><div><br></div><div>Ah, the problem also happens with refer=
ences. =A0What happens when you do:</div><div><br></div><div>optional<in=
t> i(2);</div>
<div>int& ir =3D *i;</div><div>i =3D nullopt; =A0// cannot use ir</div>=
<div>i =3D 3; =A0// can we use ir?</div><div><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">
<div class=3D"gmail_quote"><div class=3D"im">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"gmail_quote"><div>This discuss=
ion also begs the question: =A0should we be able to construct and/or assign=
an optional<T> from a T*?</div>
</div></blockquote></div><div><br>Isn't it achieved with <br><br>option=
al<T> foo =3D *foo_ptr;<br></div></div></blockquote><div><br></div><d=
iv>No. =A0The semantics I envision are: =A0if foo_ptr is null, then foo sho=
uld be disengaged; otherwise, it should have a copy of *foo_ptr.</div>
</div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=
=A0 (847) 691-1404
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--089e0122f170ac153204d4032e23--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Thu, 24 Jan 2013 08:04:06 +0100
Raw View
2013/1/24 Nevin Liber <nevin@eviloverlord.com>:
> My position:
>
> I am strongly against calling this feature get().
>
> I am weakly for this feature with a better name, such as to_pointer()
> (either as a free function or a member function).
I'm generally in favour for this feature, it also has a pendant in
comparable types: For example, std::function has
template<typename T> T* target() noexcept;
template<typename T> const T* target() const noexcept;
for this (It needs to be a template in std::function, because we have
type-erasure here), In optional<T> it could be declared as
T* target() noexcept;
const T* target() const noexcept;
I'm not so happy with "to_pointer", because that sounds like a
conversion to me. Whether "target" is ideal, I'm not sure.
The length of this discussion about this feature might indicate that
it might be worth to consider to defer a standardization of this
function for the moment.
- Daniel
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 24 Jan 2013 09:12:47 +0200
Raw View
On 24 January 2013 09:04, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wrot=
e:
> 2013/1/24 Nevin Liber <nevin@eviloverlord.com>:
>> My position:
>> I am strongly against calling this feature get().
>> I am weakly for this feature with a better name, such as to_pointer()
>> (either as a free function or a member function).
> I'm generally in favour for this feature, it also has a pendant in
> comparable types: For example, std::function has
> template<typename T> T* target() noexcept;
> template<typename T> const T* target() const noexcept;
> for this (It needs to be a template in std::function, because we have
> type-erasure here), In optional<T> it could be declared as
> T* target() noexcept;
> const T* target() const noexcept;
> I'm not so happy with "to_pointer", because that sounds like a
> conversion to me. Whether "target" is ideal, I'm not sure.
Do we think optional models similar concepts as unique_ptr and shared_ptr?
Should the functions that extract a pointer from such "nullable proxies" ha=
ve
the same name? For generic code?
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Thu, 24 Jan 2013 08:34:12 +0100
Raw View
2013/1/24 Ville Voutilainen <ville.voutilainen@gmail.com>:
> On 24 January 2013 09:04, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wr=
ote:
>> 2013/1/24 Nevin Liber <nevin@eviloverlord.com>:
>>> My position:
>>> I am strongly against calling this feature get().
>>> I am weakly for this feature with a better name, such as to_pointer()
>>> (either as a free function or a member function).
>> I'm generally in favour for this feature, it also has a pendant in
>> comparable types: For example, std::function has
>> template<typename T> T* target() noexcept;
>> template<typename T> const T* target() const noexcept;
>> for this (It needs to be a template in std::function, because we have
>> type-erasure here), In optional<T> it could be declared as
>> T* target() noexcept;
>> const T* target() const noexcept;
>> I'm not so happy with "to_pointer", because that sounds like a
>> conversion to me. Whether "target" is ideal, I'm not sure.
>
> Do we think optional models similar concepts as unique_ptr and shared_ptr=
?
Only partially. One notable difference (that optional and function
have in common) is that they respect the cv-qualifications of the
undelying object.
> Should the functions that extract a pointer from such "nullable proxies" =
have
> the same name?
> For generic code?
If we had a common concept, I would say: Yes, but we have not and I
think it's too early now.
It also depends on the function name. For example "target" has a
specific meaning for std::function upfront. This doesn't hold for
optional. We could introduce it, but the question is whether it's
worth it and the right term here. Current definitions of optional are
based on "contained value" and "storage", so these could be considered
as a reasonable base for finding a good name.
- Daniel
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Thu, 24 Jan 2013 08:56:43 +0100
Raw View
On Thu, Jan 24, 2013 at 6:48 AM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 23 January 2013 17:31, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>>
>> On Thu, Jan 24, 2013 at 12:22 AM, Nevin Liber <nevin@eviloverlord.com>
>> wrote:
>> > Why should I expect anything in optional to return a pointer?
>
>
> I'm not arguing against the feature, I'm arguing against naming it get(),
> because nothing about pointers is implied by it. Even something as short as
> ptr() would be fine.
void f(string*);
shared_ptr<string> a;
unique_ptr<string> b;
optional<string> c;
f(a.get());
f(b.get());
f(c.ptr()); // ???
There's a natural mapping between optionals and pointers.
Having the same function name for all three would be nicely consistent.
> The practical lifetime for a non-null pointer returned is that it is valid
> while the optional is engaged. If an engaged optional is disengaged and
> then engaged, is the pointer still valid?
That's not specific to pointers, but I'd say no.
> This discussion also begs the question: should we be able to construct
> and/or assign an optional<T> from a T*?
Maybe
--
Olaf
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 24 Jan 2013 00:10:43 -0800 (PST)
Raw View
------=_Part_645_14532609.1359015043714
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, January 23, 2013 10:16:02 PM UTC-8, Vladimir Batov wrote:
>
> On Thu, Jan 24, 2013 at 4:48 PM, Nevin Liber <ne...@eviloverlord.com<javascript:>
> > wrote:
>
>> On 23 January 2013 17:31, Olaf van der Spek <olafv...@gmail.com<javascript:>
>> > wrote:
>>
>>> On Thu, Jan 24, 2013 at 12:22 AM, Nevin Liber <ne...@eviloverlord.com<javascript:>>
>>> wrote:
>>> > Why should I expect anything in optional to return a pointer?
>>>
>>
>> I'm not arguing against the feature, I'm arguing against naming it get(),
>> because nothing about pointers is implied by it. Even something as short
>> as ptr() would be fine.
>>
>> The practical lifetime for a non-null pointer returned is that it is
>> valid while the optional is engaged. If an engaged optional is disengaged
>> and then engaged, is the pointer still valid?
>>
>
> There is no misunderstanding when one uses the std language facilities to
> retrieve a pointer:
>
> Foo foo1;
> Foo* ptr = &foo1; // #1
>
> That deployment is idiomatic in C/C++. The user knows that the onus is on
> him to make sure ptrs are valid. I am hoping no one is arguing that (liking
> or not is another matter). Then, if getting access to the underlying object
>
> optional<Foo> foo2;
> Foo& ref = *foo2; // #2
>
> does not cause any issues, then, I do not see the next step of marrying #1
> and #2 together as too hard to read for a C/C++ programmer:
>
> optional<Foo> foo2;
> Foo* ptr = &*foo2;
>
Because, quite frankly, no programmer should ever write that, nor should
they want to. If I have a pointer to something, and I want to get that
pointer... then I would be getting what I already have. `&*` by all rights
is a* *no-op.
If the object is a smart pointer, then this is still wrong. The idiomatic
way to get a pointer from a smart pointer is to call the `get` method, not
`&*`.
Lastly, `foo2` is not a pointer, nor is it a smart pointer (it has value
semantics, unlike most other smart pointers). So there's no reason to
expect that to be the way to get a pointer to its member. One would
reasonably expect that the idiomatic way to do that would be to call a
function.
That also requires very little :-) from the Foo developer to "support" the
> feature. It's an entirely another matter when's done like
>
> Foo foo1;
> Foo* ptr = foo.ptr(); // or get()
> optional<Foo> foo2;
> Foo* ptr2 = foo2.ptr();
>
> as without learning/understanding what ptr() *actually* does the user
> cannot rely on ptr2. Obviously that adds a hassle to the developer.
>
I don't really buy that. Applying & to an object is a language feature
(ignoring cases where someone perversely overloads that operator).
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_645_14532609.1359015043714
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Wednesday, January 23, 2013 10:16:02 PM UTC-8, Vladimir Batov wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div class=3D"gmail_quote"=
>On Thu, Jan 24, 2013 at 4:48 PM, Nevin Liber <span dir=3D"ltr"><<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"e10axAMMmtkJ">n=
e...@eviloverlord.com</a>></span> wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">
<div>On 23 January 2013 17:31, Olaf van der Spek <span dir=3D"ltr"><<a h=
ref=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"e10axAMMmtkJ=
">olafv...@gmail.com</a>></span> wrote:<br></div><div class=3D"gmail_quo=
te"><div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div>On Thu, Jan 24, 2013 at 12:22 AM, Nevin Liber <<a href=3D"javascrip=
t:" target=3D"_blank" gdf-obfuscated-mailto=3D"e10axAMMmtkJ">ne...@evilover=
lord.com</a>> wrote:<br>
> Why should I expect anything in optional to return a pointer?<br></div=
></blockquote><div><br></div></div><div>I'm not arguing against the feature=
, I'm arguing against naming it get(), because nothing about pointers is im=
plied by it. Even something as short as ptr() would be fine.</div>
<div><br></div><div>The practical lifetime for a non-null pointer returned =
is that it is valid while the optional is engaged. If an engaged opti=
onal is disengaged and then engaged, is the pointer still valid?</div></div=
>
</blockquote><div><br>There is no misunderstanding when one uses the std la=
nguage facilities to retrieve a pointer:<br><br>Foo foo1;<br>Foo* ptr =3D &=
amp;foo1; // #1<br><br>That deployment is idiomatic in C/C++. The user know=
s that the onus is on him to make sure ptrs are valid. I am hoping no one i=
s arguing that (liking or not is another matter). Then, if getting access t=
o the underlying object <br>
<br>optional<Foo> foo2;<br>Foo& ref =3D *foo2; // #2<br><br>does =
not cause any issues, then, I do not see the next step of marrying #1 and #=
2 together as too hard to read for a C/C++ programmer:<br><br>optional<F=
oo> foo2;<br>
Foo* ptr =3D &*foo2;<br></div></div></blockquote><div><br>Because, quit=
e frankly, no programmer should ever write that, nor should they want to. I=
f I have a pointer to something, and I want to get that pointer... then I w=
ould be getting what I already have. `&*` by all rights is a<i> </i>no-=
op.<br><br>If the object is a smart pointer, then this is still wrong. The =
idiomatic way to get a pointer from a smart pointer is to call the `get` me=
thod, not `&*`.<br><br>Lastly, `foo2` is not a pointer, nor is it a sma=
rt pointer (it has value semantics, unlike most other smart pointers). So t=
here's no reason to expect that to be the way to get a pointer to its membe=
r. One would reasonably expect that the idiomatic way to do that would be t=
o call a function.<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 class=3D"gmail_quote"><div>That also requires very little :-) from t=
he Foo developer to "support" the feature. It's an entirely another matter =
when's done like <br><br>Foo foo1;<br>Foo* ptr =3D foo.ptr(); // or get()<b=
r>
optional<Foo> foo2;<br>Foo* ptr2 =3D foo2.ptr();<br><br>as without le=
arning/understanding what ptr() *actually* does the user cannot rely on ptr=
2. Obviously that adds a hassle to the developer.</div></div></blockquote><=
div><br>I don't really buy that. Applying & to an object is a language =
feature (ignoring cases where someone perversely overloads that operator).<=
/div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_645_14532609.1359015043714--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 24 Jan 2013 00:16:45 -0800 (PST)
Raw View
------=_Part_1666_11753023.1359015405213
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, January 23, 2013 10:46:39 PM UTC-8, Nevin ":-)" Liber wrote:
>
> On 24 January 2013 00:16, Vladimir Batov <vb.ma...@gmail.com <javascript:>
> > wrote:
>
>> This discussion also begs the question: should we be able to construct
>>> and/or assign an optional<T> from a T*?
>>>
>>
>> Isn't it achieved with
>>
>> optional<T> foo = *foo_ptr;
>>
>
> No. The semantics I envision are: if foo_ptr is null, then foo should be
> disengaged; otherwise, it should have a copy of *foo_ptr.
>
I strongly disagree with this. `optional` is *not* a pointer. It is not a
smart pointer. It has value semantics and doesn't work like any other smart
pointer type. Therefore, it's interface should act like it has value
semantics (another reason to use `value` which returns a reference, rather
than `get` which returns a pointer).
You don't copy things by passing a pointer. You copy things by passing a
reference. So if you want to copy something you have a pointer to, you must
reference that pointer. This is no different than having a pointer to a
std::string and having to reference that pointer in order to call a
function that takes a std::string by value or by reference.
Now, I wouldn't mind a global function that could do this. Maybe
`opt_from_ptr`. You give it a `T*`, and it returns an `optional<T>`. But I
don't believe that you should be able to generally do this with a pointer.
At the very least, if we allow it, it should be an *explicit* constructor,
so you can't use copy initialization with it.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_1666_11753023.1359015405213
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Wednesday, January 23, 2013 10:46:39 PM UTC-8, Nevin ":-)" Liber=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 24 January 2013 00:1=
6, Vladimir Batov <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"wbuKd5S40ycJ">vb.ma...@gmail.com</a>></s=
pan> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv class=3D"gmail_quote"><div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"=
gmail_quote"><div>This discussion also begs the question: should we b=
e able to construct and/or assign an optional<T> from a T*?</div>
</div></blockquote></div><div><br>Isn't it achieved with <br><br>optional&l=
t;T> foo =3D *foo_ptr;<br></div></div></blockquote><div><br></div><div>N=
o. The semantics I envision are: if foo_ptr is null, then foo s=
hould be disengaged; otherwise, it should have a copy of *foo_ptr.</div></d=
iv></blockquote><div><br>I strongly disagree with this. `optional` is <i>no=
t</i> a pointer. It is not a smart pointer. It has value semantics and does=
n't work like any other smart pointer type. Therefore, it's interface shoul=
d act like it has value semantics (another reason to use `value` which retu=
rns a reference, rather than `get` which returns a pointer).<br><br>You don=
't copy things by passing a pointer. You copy things by passing a reference=
.. So if you want to copy something you have a pointer to, you must referenc=
e that pointer. This is no different than having a pointer to a std::string=
and having to reference that pointer in order to call a function that take=
s a std::string by value or by reference.<br><br>Now, I wouldn't mind a glo=
bal function that could do this. Maybe `opt_from_ptr`. You give it a `T*`, =
and it returns an `optional<T>`. But I don't believe that you should =
be able to generally do this with a pointer. At the very least, if we allow=
it, it should be an <i>explicit</i> constructor, so you can't use copy ini=
tialization with it.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1666_11753023.1359015405213--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 24 Jan 2013 02:16:23 -0600
Raw View
--f46d043be240a3c06304d4046faa
Content-Type: text/plain; charset=ISO-8859-1
On 24 January 2013 01:56, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> shared_ptr<string> a;
> unique_ptr<string> b;
> optional<string> c;
>
> f(a.get());
> f(b.get());
> f(c.ptr()); // ???
>
> There's a natural mapping between optionals and pointers.
> Having the same function name for all three would be nicely consistent.
>
But it isn't.
get() for smart pointers returns exactly what they stored (modulo type
conversions) in the smart pointer in the first place. That isn't true for
optional (unless get() returns a reference, not a pointer). shared_ptr and
unique_ptr model pointers; optional does not. It shouldn't use the same
terminology for a different kind of access. function.target() is a much
closer match.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--f46d043be240a3c06304d4046faa
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 24 January 2013 01:56, Olaf van der Spek <span dir=3D"ltr"><<a href=
=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</a>=
></span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">
<div class=3D"im">shared_ptr<string> a;</div>
unique_ptr<string> b;<br>
optional<string> c;<br>
<br>
f(a.get());<br>
f(b.get());<br>
f(c.ptr()); // ???<br>
<br>
There's a natural mapping between optionals and pointers.<br>
Having the same function name for all three would be nicely consistent.<br>=
</blockquote><div><br></div><div>But it isn't. =A0</div><div><br></div>=
<div>get() for smart pointers returns exactly what they stored (modulo type=
conversions) in the smart pointer in the first place. =A0That isn't tr=
ue for optional (unless get() returns a reference, not a pointer). =A0share=
d_ptr and unique_ptr model pointers; optional does not. =A0It shouldn't=
use the same terminology for a different kind of access. =A0function.targe=
t() is a much closer match.</div>
</div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=
=A0 (847) 691-1404
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--f46d043be240a3c06304d4046faa--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Thu, 24 Jan 2013 09:25:49 +0100
Raw View
On Thu, Jan 24, 2013 at 9:16 AM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 24 January 2013 01:56, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>>
>> shared_ptr<string> a;
>> unique_ptr<string> b;
>> optional<string> c;
>>
>> f(a.get());
>> f(b.get());
>> f(c.ptr()); // ???
>>
>> There's a natural mapping between optionals and pointers.
>> Having the same function name for all three would be nicely consistent.
>
>
> But it isn't.
>
> get() for smart pointers returns exactly what they stored (modulo type
> conversions) in the smart pointer in the first place. That isn't true for
> optional (unless get() returns a reference, not a pointer). shared_ptr and
There's no natural mapping between optionals and references, is there?
If a reference is desired, use *c. Note that this too is consistent
with pointers. *a and *b give you a reference too.
> unique_ptr model pointers; optional does not. It shouldn't use the same
> terminology for a different kind of access.
IMO the access isn't different. And both do model the nullable concept.
--
Olaf
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 24 Jan 2013 02:28:41 -0600
Raw View
--089e0122f170904d4204d4049bb8
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 24 January 2013 01:04, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wrot=
e:
> T* target() noexcept;
> const T* target() const noexcept;
>
> I'm not so happy with "to_pointer", because that sounds like a
> conversion to me.
In some sense, we are converting, from value semantics to pointer
semantics. But I see your point.
> Whether "target" is ideal, I'm not sure.
>
I'm not sure what is right, but I am pretty sure that get() is wrong. I'm
fine with target().
--=20
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
--089e0122f170904d4204d4049bb8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 24 January 2013 01:04, Daniel Kr=FCgler <span dir=3D"ltr"><<a href=3D=
"mailto:daniel.kruegler@gmail.com" target=3D"_blank">daniel.kruegler@gmail.=
com</a>></span> wrote:<br><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
T* target() noexcept;<br>
const T* target() const noexcept;<br>
<br>
I'm not so happy with "to_pointer", because that sounds like =
a<br>
conversion to me.</blockquote><div><br></div><div>In some sense, we are con=
verting, from value semantics to pointer semantics. =A0But I see your point=
..</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Whether "target" is ideal, I'm not sure.<br></blockquote><di=
v><br></div><div>I'm not sure what is right, but I am pretty sure that =
get() is wrong. =A0I'm fine with target().</div></div>-- <br>=A0Nevin &=
quot;:-)" Liber=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com=
" target=3D"_blank">nevin@eviloverlord.com</a>>=A0 (847) 691-1404
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--089e0122f170904d4204d4049bb8--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 24 Jan 2013 02:34:16 -0600
Raw View
--f46d044286faaa719b04d404af33
Content-Type: text/plain; charset=ISO-8859-1
On 24 January 2013 02:25, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> > unique_ptr model pointers; optional does not. It shouldn't use the same
> > terminology for a different kind of access.
>
> IMO the access isn't different.
Where else in the standard does get() not return what was stored? smart
pointers, reference_wrapper and tuple all do.
> And both do model the nullable concept.
>
So does function, and it doesn't use get().
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--f46d044286faaa719b04d404af33
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 24 January 2013 02:25, Olaf van der Spek <span dir=3D"ltr"><<a href=
=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</a>=
></span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">
<div class=3D"im">> unique_ptr model pointers; optional does not. =A0It =
shouldn't use the same</div><div class=3D"im">
> terminology for a different kind of access.<br>
<br>
</div>IMO the access isn't different.</blockquote><div><br></div><div>W=
here else in the standard does get() not return what was stored? =A0smart p=
ointers, reference_wrapper and tuple all do.</div><div>=A0</div><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
And both do model the nullable concept.<br></blockquote><div><br></div><di=
v>So does function, and it doesn't use get().=A0</div></div>-- <br>=A0N=
evin ":-)" Liber=A0 <mailto:<a href=3D"mailto:nevin@eviloverlo=
rd.com" target=3D"_blank">nevin@eviloverlord.com</a>>=A0 (847) 691-1404
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--f46d044286faaa719b04d404af33--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Thu, 24 Jan 2013 09:41:37 +0100
Raw View
On Thu, Jan 24, 2013 at 9:34 AM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 24 January 2013 02:25, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>>
>> > unique_ptr model pointers; optional does not. It shouldn't use the same
>> > terminology for a different kind of access.
>>
>> IMO the access isn't different.
>
>
> Where else in the standard does get() not return what was stored? smart
> pointers, reference_wrapper and tuple all do.
Tuple doesn't have a nullary get() AFAIK.
Optional doesn't store a value, it stores null or a value. And you
can't map that to just a reference to a value, you lose part of the
info (and run into undefined behavior without extra check).
>> And both do model the nullable concept.
>
>
> So does function, and it doesn't use get().
True. I'm not familiar with function, but are you suggesting optional
and function are more similar than optional and (smart) pointer?
--
Olaf
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 24 Jan 2013 10:55:32 +0200
Raw View
On 24 January 2013 10:34, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 24 January 2013 02:25, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>> > unique_ptr model pointers; optional does not. It shouldn't use the same
>> > terminology for a different kind of access.
>> IMO the access isn't different.
> Where else in the standard does get() not return what was stored? smart
> pointers, reference_wrapper and tuple all do.
Is that significant? I don't see why I'd care about get() not
returning exactly what
was stored. That's not the reason why I call get().
>> And both do model the nullable concept.
> So does function, and it doesn't use get().
Well, function::target is a red herring - it has to receive a type
argument in order
to convert properly, due to erasure.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Thu, 24 Jan 2013 10:00:50 +0100
Raw View
2013/1/24 Ville Voutilainen <ville.voutilainen@gmail.com>:
> On 24 January 2013 10:34, Nevin Liber <nevin@eviloverlord.com> wrote:
>>> And both do model the nullable concept.
>> So does function, and it doesn't use get().
>
> Well, function::target is a red herring - it has to receive a type
> argument in order
> to convert properly, due to erasure.
I don't want to insist on target() as being the ideal name for it, but
lets not mixin different problem categories here. The sole reason why
std::function does need to make target() a template is because it is a
type-erasing wrapper, while std::optional is not. Still, the function
has a similar purpose, so target() *could* be used for optional, but
would not be a function template here.
- Daniel
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 24 Jan 2013 11:06:07 +0200
Raw View
On 24 January 2013 11:00, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wrot=
e:
> I don't want to insist on target() as being the ideal name for it, but
> lets not mixin different problem categories here. The sole reason why
> std::function does need to make target() a template is because it is a
> type-erasing wrapper, while std::optional is not. Still, the function
> has a similar purpose, so target() *could* be used for optional, but
> would not be a function template here.
I suppose we agree. But naming the function target() is a step further away=
from
the reason for naming it get(). The whole point of naming it get() is
to be able to
use the same generic code both with optionals and with smart pointers (and =
yes,
Daniel, I know you know that, I'm talking to the 'audience' :)). If
that's seen as
a significantly important use case, that's a point for get() rather
than target().
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Thu, 24 Jan 2013 01:12:44 -0800 (PST)
Raw View
------=_Part_289_17747769.1359018764287
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu czwartek, 24 stycznia 2013 07:46:39 UTC+1 u=BFytkownik Nevin ":-)"=
=20
Liber napisa=B3:
>
> On 24 January 2013 00:16, Vladimir Batov <vb.ma...@gmail.com <javascript:=
>
> > wrote:
>
>> There is no misunderstanding when one uses the std language facilities t=
o=20
>> retrieve a pointer:
>>
>> Foo foo1;
>> Foo* ptr =3D &foo1; // #1
>>
>> That deployment is idiomatic in C/C++. The user knows that the onus is o=
n=20
>> him to make sure ptrs are valid. I am hoping no one is arguing that (lik=
ing=20
>> or not is another matter). Then, if getting access to the underlying obj=
ect=20
>>
>> optional<Foo> foo2;
>> Foo& ref =3D *foo2; // #2
>>
>
> Ah, the problem also happens with references. What happens when you do:
>
> optional<int> i(2);
> int& ir =3D *i;
> i =3D nullopt; // cannot use ir
> i =3D 3; // can we use ir?
>
> =20
I wonder if we need to address this explicitly in the standardese. My=20
position was that "you know what other semantics of std::optional are: you=
=20
know what you are risking".
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_289_17747769.1359018764287
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu czwartek, 24 stycznia 2013 07:46:39 UTC+1 u=BFytkownik Nevin=
":-)" Liber napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 24 J=
anuary 2013 00:16, Vladimir Batov <span dir=3D"ltr"><<a href=3D"javascri=
pt:" target=3D"_blank" gdf-obfuscated-mailto=3D"wbuKd5S40ycJ">vb.ma...@gmai=
l.com</a>></span> wrote:<br><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<div class=3D"gmail_quote"><div>There is no misunderstanding when one uses =
the std language facilities to retrieve a pointer:</div><div><br>Foo foo1;<=
br>Foo* ptr =3D &foo1; // #1<br><br>That deployment is idiomatic in C/C=
++. The user knows that the onus is on him to make sure ptrs are valid. I a=
m hoping no one is arguing that (liking or not is another matter). Then, if=
getting access to the underlying object <br>
<br>optional<Foo> foo2;<br>Foo& ref =3D *foo2; // #2<br></div></d=
iv></blockquote><div><br></div><div>Ah, the problem also happens with refer=
ences. What happens when you do:</div><div><br></div><div>optional<=
;int> i(2);</div>
<div>int& ir =3D *i;</div><div>i =3D nullopt; // cannot use ir</d=
iv><div>i =3D 3; // can we use ir?</div><div><br></div></div></blockq=
uote><div> </div><div>I wonder if we need to address this explicitly i=
n the standardese. My position was that "you know what other semantics of s=
td::optional are: you know what you are risking".<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_289_17747769.1359018764287--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Thu, 24 Jan 2013 01:22:46 -0800 (PST)
Raw View
------=_Part_319_22009990.1359019366807
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu czwartek, 24 stycznia 2013 08:56:43 UTC+1 u=BFytkownik Olaf van der=
=20
Spek napisa=B3:
>
> On Thu, Jan 24, 2013 at 6:48 AM, Nevin Liber <ne...@eviloverlord.com<java=
script:>>=20
> wrote:=20
> > On 23 January 2013 17:31, Olaf van der Spek <olafv...@gmail.com<javascr=
ipt:>>=20
> wrote:=20
> >>=20
> >> On Thu, Jan 24, 2013 at 12:22 AM, Nevin Liber <ne...@eviloverlord.com<=
javascript:>>=20
>
> >> wrote:=20
> >> > Why should I expect anything in optional to return a pointer?=20
> >=20
> >=20
> > I'm not arguing against the feature, I'm arguing against naming it=20
> get(),=20
> > because nothing about pointers is implied by it. Even something as=20
> short as=20
> > ptr() would be fine.=20
>
> void f(string*);=20
>
> shared_ptr<string> a;=20
> unique_ptr<string> b;=20
> optional<string> c;=20
>
> f(a.get());=20
> f(b.get());=20
> f(c.ptr()); // ???=20
>
> There's a natural mapping between optionals and pointers.=20
> Having the same function name for all three would be nicely consistent.=
=20
>
=20
There s a limit to this mapping/analogy though. For smart pointers (at=20
least unique_ptr and shared_ptr) the value returned by get() represent the=
=20
full (although trivial) set of salient attributes. That is:
bool equal( shared_ptr<T> p, shared_ptr<T> q )
{
hash(p); // <=3D> hash(p.get());
return p =3D=3D q; // <=3D> p.get() =3D=3D q.get();
}
bool equal( unique_ptr<T> & p, unique_ptr<T> & q )
{
hash(p); // <=3D> hash(p.get());
return p =3D=3D q; // <=3D> p.get() =3D=3D q.get();
}
This is not the case for optional.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_319_22009990.1359019366807
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu czwartek, 24 stycznia 2013 08:56:43 UTC+1 u=BFytkownik Olaf =
van der Spek napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thu,=
Jan 24, 2013 at 6:48 AM, Nevin Liber <<a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"23niZPP4o-0J">ne...@eviloverlord.com</a>&=
gt; wrote:
<br>> On 23 January 2013 17:31, Olaf van der Spek <<a href=3D"javascr=
ipt:" target=3D"_blank" gdf-obfuscated-mailto=3D"23niZPP4o-0J">olafv...@gma=
il.com</a>> wrote:
<br>>>
<br>>> On Thu, Jan 24, 2013 at 12:22 AM, Nevin Liber <<a href=3D"j=
avascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"23niZPP4o-0J">ne...@=
eviloverlord.com</a>>
<br>>> wrote:
<br>>> > Why should I expect anything in optional to return a poin=
ter?
<br>>
<br>>
<br>> I'm not arguing against the feature, I'm arguing against naming it=
get(),
<br>> because nothing about pointers is implied by it. Even someth=
ing as short as
<br>> ptr() would be fine.
<br>
<br>void f(string*);
<br>
<br>shared_ptr<string> a;
<br>unique_ptr<string> b;
<br>optional<string> c;
<br>
<br>f(a.get());
<br>f(b.get());
<br>f(c.ptr()); // ???
<br>
<br>There's a natural mapping between optionals and pointers.
<br>Having the same function name for all three would be nicely consistent.
<br></blockquote><div> <br><br>There s a limit to this mapping/analogy=
though. For smart pointers (at least unique_ptr and shared_ptr) the value =
returned by get() represent the full (although trivial) set of salient attr=
ibutes. That is:<br><br><div class=3D"prettyprint" style=3D"background-colo=
r: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: soli=
d; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><=
div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">bool</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> equal</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> shared=
_ptr</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">></span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> p</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> shared_ptr</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify"><</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">></span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> q </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br> hash</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">p</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" clas=
s=3D"styled-by-prettify">// <=3D> hash(p.get());</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> p </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">=3D=3D</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> q</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">// <=3D> p.get() =3D=3D q.get();</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br><br></span><br><div class=3D"prettyprint" style=3D"b=
ackground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bord=
er-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"=
prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">bool</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> equal</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> unique_ptr</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify"><</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">></s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> & p</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> unique_ptr</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> & q </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br> hash</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">p</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: #800;" class=3D"styled-by-prettify">// <=3D> hash(p=
..get());</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">r=
eturn</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> p </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> q</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #80=
0;" class=3D"styled-by-prettify">// <=3D> p.get() =3D=3D q.get();</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></di=
v></div></code></div><br>This is not the case for optional.<br><br><br><br>=
</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_319_22009990.1359019366807--
.
Author: Nikolay Ivchenkov <tsoae@mail.ru>
Date: Thu, 24 Jan 2013 01:28:13 -0800 (PST)
Raw View
------=_Part_2084_29270028.1359019693500
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, January 24, 2013 1:06:07 PM UTC+4, Ville Voutilainen wrote:
>
> The whole point of naming it get() is
> to be able to
> use the same generic code both with optionals and with smart pointers
>
It would be interesting to see examples of such a generic code.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_2084_29270028.1359019693500
Content-Type: text/html; charset=ISO-8859-1
On Thursday, January 24, 2013 1:06:07 PM UTC+4, Ville Voutilainen wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The whole point of naming it get() is
<br>to be able to
<br>use the same generic code both with optionals and with smart pointers<br></blockquote><div><br>It would be interesting to see examples of such a generic code.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
------=_Part_2084_29270028.1359019693500--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Thu, 24 Jan 2013 01:38:01 -0800 (PST)
Raw View
------=_Part_3090_14223419.1359020281230
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu czwartek, 24 stycznia 2013 00:20:24 UTC+1 u=BFytkownik Mikael=20
Kilpel=E4inen napisa=B3:
>
>
> > void func( optional<int> const& o ) {=20
> > if( o =3D=3D 1 ) { //instead of o && *o =3D=3D 1 or similar=20
> > whatever..=20
> > }=20
> > }=20
> >=20
> > That is, i don't need to check if the optional is engaged or not, so i=
=20
> > cannot forget it either and i don't need to type the name twice..=20
> > (okey, you can always do the comparison by constructing the optional=
=20
> > from the value and comparing)=20
> >=20
> Just wanted to add here that actually the one of most convient cases=20
> being..=20
>
> BOOST_CHECK( my_func_returning_optional() =3D=3D my_value );=20
>
> Again, i could construct optional of the right hand side, good enough,=20
> would work, might have performance implications though.=20
>
What do others think about offering the mixed assignment of T with=20
optional<T>? (given the potential risks)
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_3090_14223419.1359020281230
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu czwartek, 24 stycznia 2013 00:20:24 UTC+1 u=BFytkownik Mikae=
l Kilpel=E4inen napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>> void func( optional<int> const& o ) {
<br>> if( o =3D=3D 1 ) { //instead of o && *o =3D=
=3D 1 or similar
<br>> whatever..
<br>> }
<br>> }
<br>>
<br>> That is, i don't need to check if the optional is engaged or not, =
so i=20
<br>> cannot forget it either and i don't need to type the name twice..
<br>> (okey, you can always do the comparison by constructing the =
optional=20
<br>> from the value and comparing)
<br>>
<br>Just wanted to add here that actually the one of most convient cases be=
ing..
<br>
<br>BOOST_CHECK( my_func_returning_optional() =3D=3D my_value );
<br>
<br>Again, i could construct optional of the right hand side, good enough,=
=20
<br>would work, might have performance implications though.
<br></blockquote><div><br>What do others think about offering the mixed ass=
ignment of T with optional<T>? (given the potential risks)<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_3090_14223419.1359020281230--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 24 Jan 2013 01:38:25 -0800 (PST)
Raw View
------=_Part_310_8236131.1359020305346
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Thursday, January 24, 2013 1:06:07 AM UTC-8, Ville Voutilainen wrote:
>
> On 24 January 2013 11:00, Daniel Kr=FCgler <daniel....@gmail.com<javascri=
pt:>>=20
> wrote:=20
> > I don't want to insist on target() as being the ideal name for it, but=
=20
> > lets not mixin different problem categories here. The sole reason why=
=20
> > std::function does need to make target() a template is because it is a=
=20
> > type-erasing wrapper, while std::optional is not. Still, the function=
=20
> > has a similar purpose, so target() *could* be used for optional, but=20
> > would not be a function template here.=20
>
> I suppose we agree. But naming the function target() is a step further=20
> away from=20
> the reason for naming it get(). The whole point of naming it get() is=20
> to be able to=20
> use the same generic code both with optionals and with smart pointers (an=
d=20
> yes,=20
> Daniel, I know you know that, I'm talking to the 'audience' :)). If=20
> that's seen as=20
> a significantly important use case, that's a point for get() rather=20
> than target().
>
That's just it: I don't believe that we *should* be able to inter-operate=
=20
optionals and smart pointers in template code. They have very different=20
semantics (value vs. reference). std::ref is more like a smart pointer than=
=20
`optional`.
If some template code is taking an optional value or retrieving one or=20
something, then they will necessarily be doing different things with it=20
than if they got a pointer. Or, to put it another way, we should not treat=
=20
`optional` as `value_ptr`.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_310_8236131.1359020305346
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Thursday, January 24, 2013 1:06:07 AM UTC-8, Ville Voutilainen w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">On 24 January 2013 11:00,=
Daniel Kr=FCgler <<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"MjBQuM8E7JsJ">daniel....@gmail.com</a>> wrote:
<br>> I don't want to insist on target() as being the ideal name for it,=
but
<br>> lets not mixin different problem categories here. The sole reason =
why
<br>> std::function does need to make target() a template is because it =
is a
<br>> type-erasing wrapper, while std::optional is not. Still, the funct=
ion
<br>> has a similar purpose, so target() *could* be used for optional, b=
ut
<br>> would not be a function template here.
<br>
<br>I suppose we agree. But naming the function target() is a step further =
away from
<br>the reason for naming it get(). The whole point of naming it get() is
<br>to be able to
<br>use the same generic code both with optionals and with smart pointers (=
and yes,
<br>Daniel, I know you know that, I'm talking to the 'audience' :)). If
<br>that's seen as
<br>a significantly important use case, that's a point for get() rather
<br>than target().<br></blockquote><div><br>That's just it: I don't believe=
that we <i>should</i> be able to inter-operate optionals and smart pointer=
s in template code. They have very different semantics (value vs. reference=
). std::ref is more like a smart pointer than `optional`.<br><br>If some te=
mplate code is taking an optional value or retrieving one or something, the=
n they will necessarily be doing different things with it than if they got =
a pointer. Or, to put it another way, we should not treat `optional` as `va=
lue_ptr`.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_310_8236131.1359020305346--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Thu, 24 Jan 2013 10:44:45 +0100
Raw View
On Thu, Jan 24, 2013 at 10:38 AM, Andrzej Krzemie=C5=84ski
<akrzemi1@gmail.com> wrote:
>> BOOST_CHECK( my_func_returning_optional() =3D=3D my_value );
>>
>> Again, i could construct optional of the right hand side, good enough,
>> would work, might have performance implications though.
>
>
> What do others think about offering the mixed assignment of T with
> optional<T>? (given the potential risks)
Isn't this just a comparison?
Doesn't require assignment.
--=20
Olaf
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Thu, 24 Jan 2013 01:48:27 -0800 (PST)
Raw View
------=_Part_3099_25550348.1359020908020
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu czwartek, 24 stycznia 2013 10:44:45 UTC+1 u=BFytkownik Olaf van der=
=20
Spek napisa=B3:
>
> On Thu, Jan 24, 2013 at 10:38 AM, Andrzej Krzemie=F1ski=20
> <akrz...@gmail.com <javascript:>> wrote:=20
> >> BOOST_CHECK( my_func_returning_optional() =3D=3D my_value );=20
> >>=20
> >> Again, i could construct optional of the right hand side, good enough,=
=20
> >> would work, might have performance implications though.=20
> >=20
> >=20
> > What do others think about offering the mixed assignment of T with=20
> > optional<T>? (given the potential risks)=20
>
> Isn't this just a comparison?=20
> Doesn't require assignment.=20
>
My question is definitely only about comparison (currently mixed comparison=
=20
is explicitly prohibited in the proposal).
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_3099_25550348.1359020908020
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu czwartek, 24 stycznia 2013 10:44:45 UTC+1 u=BFytkownik Olaf =
van der Spek napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thu,=
Jan 24, 2013 at 10:38 AM, Andrzej Krzemie=F1ski
<br><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
ng7XDjU_4bwJ">akrz...@gmail.com</a>> wrote:
<br>>> BOOST_CHECK( my_func_returning_optional() =3D=3D my_value );
<br>>>
<br>>> Again, i could construct optional of the right hand side, good=
enough,
<br>>> would work, might have performance implications though.
<br>>
<br>>
<br>> What do others think about offering the mixed assignment of T with
<br>> optional<T>? (given the potential risks)
<br>
<br>Isn't this just a comparison?
<br>Doesn't require assignment.
<br></blockquote><div><br>My question is definitely only about comparison (=
currently mixed comparison is explicitly prohibited in the proposal).<br></=
div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_3099_25550348.1359020908020--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Thu, 24 Jan 2013 10:51:12 +0100
Raw View
On Thu, Jan 24, 2013 at 10:48 AM, Andrzej Krzemie=C5=84ski
<akrzemi1@gmail.com> wrote:
>> > What do others think about offering the mixed assignment of T with
>> > optional<T>? (given the potential risks)
>>
>> Isn't this just a comparison?
>> Doesn't require assignment.
>
>
> My question is definitely only about comparison (currently mixed comparis=
on
> is explicitly prohibited in the proposal).
Ah, so what are the potential risks?
Comparison sounds useful.
--=20
Olaf
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Thu, 24 Jan 2013 01:53:49 -0800 (PST)
Raw View
------=_Part_31_8109309.1359021229735
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu czwartek, 24 stycznia 2013 10:51:12 UTC+1 u=BFytkownik Olaf van der=
=20
Spek napisa=B3:
>
> On Thu, Jan 24, 2013 at 10:48 AM, Andrzej Krzemie=F1ski=20
> <akrz...@gmail.com <javascript:>> wrote:=20
> >> > What do others think about offering the mixed assignment of T with=
=20
> >> > optional<T>? (given the potential risks)=20
> >>=20
> >> Isn't this just a comparison?=20
> >> Doesn't require assignment.=20
> >=20
> >=20
> > My question is definitely only about comparison (currently mixed=20
> comparison=20
> > is explicitly prohibited in the proposal).=20
>
> Ah, so what are the potential risks?=20
> Comparison sounds useful.=20
>
Quoting the proposal:
One could also expect comparisons between T and optional<T>. The natural=20
semantics of such comparison would be:
template <class T>
bool operator=3D=3D(const optional<T>& a, const T& b)
{
return a =3D=3D make_optional(b);
}
We do not propose it because there is no strong motivation for such=20
comparisons. On the contrary, the inadvertent invocation o such comparisons=
=20
might be disastrous. Consider the following scenario. We have a class that=
=20
stores the number of passengers:=20
class MyPlan
{
unsigned passengerCount;
*// ...*
};
At some point we realize that sometimes we will not know the number of=20
passengers: either because we use lazy initialization techniques or because=
=20
we failed to compute the number. We change the type of the variable:
class MyPlan
{
optional<unsigned> passengerCount;
*// ...*
};
And we might expect that compiler will warn us in every place where we try=
=20
to access the value of passengerCount. However the following comparison=20
will continue to compile although the run-time behaviour will be different=
=20
than the one expected:
bool MyPlan::exceedsCapacity() const
{
return passengerCount > availableSeats;
*// availableSeats is of type unsigned int*
}
Since disengaged optional never compares greater than anything, the effect=
=20
we have is that if we do not know how many passengers there are we report=
=20
with certainty that their number does not exceed the capacity. For this=20
reason comparison between optional<T> and T are required to be reported as=
=20
errors at compile-time
=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_31_8109309.1359021229735
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu czwartek, 24 stycznia 2013 10:51:12 UTC+1 u=BFytkownik Olaf =
van der Spek napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thu,=
Jan 24, 2013 at 10:48 AM, Andrzej Krzemie=F1ski
<br><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
vyAUXl6xsZ0J">akrz...@gmail.com</a>> wrote:
<br>>> > What do others think about offering the mixed assignment =
of T with
<br>>> > optional<T>? (given the potential risks)
<br>>>
<br>>> Isn't this just a comparison?
<br>>> Doesn't require assignment.
<br>>
<br>>
<br>> My question is definitely only about comparison (currently mixed c=
omparison
<br>> is explicitly prohibited in the proposal).
<br>
<br>Ah, so what are the potential risks?
<br>Comparison sounds useful.
<br></blockquote><div><br>Quoting the proposal:<br><br><p>One could also ex=
pect comparisons between <code>T</code> and <code>optional<T></code>.=
The natural semantics of such comparison would be:</p>
<pre>template <class T>
bool operator=3D=3D(const optional<T>& a, const T& b)
{
return a =3D=3D make_optional(b);
}
</pre>
<p>We do not propose it because there is no strong motivation for such=20
comparisons. On the contrary, the inadvertent invocation o such=20
comparisons might be disastrous. Consider the following scenario. We=20
have a class that stores the number of passengers:
</p>
<pre>class MyPlan
{
unsigned passengerCount;
<em>// ...</em>
};</pre>
<p>At some point we realize that sometimes we will not know the number=20
of passengers: either because we use lazy initialization techniques or=20
because we failed to compute the number. We change the type of the=20
variable:</p>
<pre>class MyPlan
{
optional<unsigned> passengerCount;
<em>// ...</em>
};</pre>
<p>And we might expect that compiler will warn us in every place where we t=
ry to access the value of <code>passengerCount</code>.
However the following comparison will continue to compile although the=20
run-time behaviour will be different than the one expected:</p>
<pre>bool MyPlan::exceedsCapacity() const
{
return passengerCount > availableSeats;
<em>// availableSeats is of type unsigned int</em>
}
</pre>
<p>Since disengaged optional never compares greater than anything, the=20
effect we have is that if we do not know how many passengers there are=20
we report with certainty that their number does not exceed the capacity.
For this reason comparison between <code>optional<T></code> and <cod=
e>T</code> are required to be reported as errors at compile-time</p> <=
/div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_31_8109309.1359021229735--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Thu, 24 Jan 2013 11:28:12 +0100
Raw View
On Thu, Jan 24, 2013 at 10:53 AM, Andrzej Krzemie=C5=84ski
<akrzemi1@gmail.com> wrote:
>> Ah, so what are the potential risks?
>> Comparison sounds useful.
Ah, so the problem is what to do with a disengaged optional and a normal va=
lue.
Would only defining =3D=3D be safe?
Olaf
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 24 Jan 2013 12:37:21 +0200
Raw View
On 24 January 2013 11:38, Nicol Bolas <jmckesson@gmail.com> wrote:
> That's just it: I don't believe that we should be able to inter-operate
> optionals and smart pointers in template code. They have very different
> semantics (value vs. reference). std::ref is more like a smart pointer than
> `optional`.
They do? Regarding Nikolay's question about the generic code,
template <class T, class U> T* extract_ptr(U& src)
{
return src.get();
}
int main()
{
unique_ptr<int> x;
int* y = extract_ptr<int, unique_ptr<int>>(x);
}
Why shouldn't this just work for unique_ptr, shared_ptr and optional?
Regarding reference vs. value,
for this to work, optional::get() needs to return nullptr for a
disengaged optional.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Thu, 24 Jan 2013 03:12:38 -0800 (PST)
Raw View
------=_Part_82_5570560.1359025958765
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu czwartek, 24 stycznia 2013 11:28:12 UTC+1 u=BFytkownik Olaf van der=
=20
Spek napisa=B3:
>
> On Thu, Jan 24, 2013 at 10:53 AM, Andrzej Krzemie=F1ski=20
> <akrz...@gmail.com> wrote:=20
> >> Ah, so what are the potential risks?=20
> >> Comparison sounds useful.=20
>
> Ah, so the problem is what to do with a disengaged optional and a normal=
=20
> value.=20
> Would only defining =3D=3D be safe?=20
>
I guess it depends on how we define "safe". What do you expect the=20
following comparison to return?
return optional<int>{nullopt} !=3D 1;
Some people might expect this value to be true. Some other people might=20
prefer that this be an invalid comparison. If you belong to the latter=20
group, you would probably consider returning true unsafe. I guess the=20
differenc is in how you treat nullopt: is it just yet another value of=20
extended type int, or is it a missing value?
=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_82_5570560.1359025958765
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu czwartek, 24 stycznia 2013 11:28:12 UTC+1 u=BFytkownik Olaf van der =
Spek napisa=B3:<blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left=
: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; borde=
r-left-style: solid;" class=3D"gmail_quote">On Thu, Jan 24, 2013 at 10:53 A=
M, Andrzej Krzemie=F1ski
<br><<a target=3D"_blank">akrz...@gmail.com</a>> wrote:
<br>>> Ah, so what are the potential risks?
<br>>> Comparison sounds useful.
<br>
<br>Ah, so the problem is what to do with a disengaged optional and a norma=
l value.
<br>Would only defining =3D=3D be safe?
<br></blockquote><div><br>I guess it depends on how we define "safe". What =
do you expect the following comparison to return?<br><div style=3D"border: =
1px solid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(=
250, 250, 250);" class=3D"prettyprint"><code class=3D"prettyprint"><div cla=
ss=3D"subprettyprint"><span style=3D"color: rgb(0, 0, 136);" class=3D"style=
d-by-prettify">return</span><span style=3D"color: rgb(0, 0, 0);" class=3D"s=
tyled-by-prettify"> optional</span><span style=3D"color: rgb(0, 136, 0);" c=
lass=3D"styled-by-prettify"><int></span><span style=3D"color: rgb(102=
, 102, 0);" class=3D"styled-by-prettify">{</span><span style=3D"color: rgb(=
0, 0, 0);" class=3D"styled-by-prettify">nullopt</span><span style=3D"color:=
rgb(102, 102, 0);" class=3D"styled-by-prettify">}</span><span style=3D"col=
or: rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: rgb(102, 102, 0);" class=3D"styled-by-prettify">!=3D</span><span style=
=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span><span style=
=3D"color: rgb(0, 102, 102);" class=3D"styled-by-prettify">1</span><span st=
yle=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">;</span></div=
></code></div><br>Some people might expect this value to be true. Some othe=
r people might prefer that this be an invalid comparison. If you belong to =
the latter group, you would probably consider returning true unsafe. I gues=
s the differenc is in how you treat nullopt: is it just yet another value o=
f extended type int, or is it a missing value?</div><div> </div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_82_5570560.1359025958765--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Thu, 24 Jan 2013 12:17:27 +0100
Raw View
On Thu, Jan 24, 2013 at 12:12 PM, Andrzej Krzemie=C5=84ski
<akrzemi1@gmail.com> wrote:
>> Ah, so the problem is what to do with a disengaged optional and a normal
>> value.
>> Would only defining =3D=3D be safe?
>
>
> I guess it depends on how we define "safe". What do you expect the follow=
ing
> comparison to return?
> return optional<int>{nullopt} !=3D 1;
>
> Some people might expect this value to be true. Some other people might
> prefer that this be an invalid comparison. If you belong to the latter
> group, you would probably consider returning true unsafe. I guess the
> differenc is in how you treat nullopt: is it just yet another value of
> extended type int, or is it a missing value?
A compiler error, since !=3D is not =3D=3D
By only defining =3D=3D I really meant just that. So no operator!=3D
--=20
Olaf
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Thu, 24 Jan 2013 03:29:32 -0800 (PST)
Raw View
------=_Part_1514_8911419.1359026972121
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu czwartek, 24 stycznia 2013 12:17:27 UTC+1 u=BFytkownik Olaf van der=
=20
Spek napisa=B3:
>
> On Thu, Jan 24, 2013 at 12:12 PM, Andrzej Krzemie=F1ski=20
> <akrz...@gmail.com <javascript:>> wrote:=20
> >> Ah, so the problem is what to do with a disengaged optional and a=20
> normal=20
> >> value.=20
> >> Would only defining =3D=3D be safe?=20
> >=20
> >=20
> > I guess it depends on how we define "safe". What do you expect the=20
> following=20
> > comparison to return?=20
> > return optional<int>{nullopt} !=3D 1;=20
> >=20
> > Some people might expect this value to be true. Some other people might=
=20
> > prefer that this be an invalid comparison. If you belong to the latter=
=20
> > group, you would probably consider returning true unsafe. I guess the=
=20
> > differenc is in how you treat nullopt: is it just yet another value of=
=20
> > extended type int, or is it a missing value?=20
>
> A compiler error, since !=3D is not =3D=3D=20
> By only defining =3D=3D I really meant just that. So no operator!=3D=20
> --=20
> Olaf=20
>
Operator=3D=3D without operator!=3D ? Really?
But even then we have a similar question:
return optional<int>{nullopt} =3D=3D 1;
Shall it return false or fail to compile? similarly:
return string{"dog"} =3D=3D 1;
Shall it return false, or fail to compile?
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_1514_8911419.1359026972121
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu czwartek, 24 stycznia 2013 12:17:27 UTC+1 u=BFytkownik Olaf =
van der Spek napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thu,=
Jan 24, 2013 at 12:12 PM, Andrzej Krzemie=F1ski
<br><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
o0EoTeA0NXgJ">akrz...@gmail.com</a>> wrote:
<br>>> Ah, so the problem is what to do with a disengaged optional an=
d a normal
<br>>> value.
<br>>> Would only defining =3D=3D be safe?
<br>>
<br>>
<br>> I guess it depends on how we define "safe". What do you expect the=
following
<br>> comparison to return?
<br>> return optional<int>{nullopt} !=3D 1;
<br>>
<br>> Some people might expect this value to be true. Some other people =
might
<br>> prefer that this be an invalid comparison. If you belong to the la=
tter
<br>> group, you would probably consider returning true unsafe. I guess =
the
<br>> differenc is in how you treat nullopt: is it just yet another valu=
e of
<br>> extended type int, or is it a missing value?
<br>
<br>A compiler error, since !=3D is not =3D=3D
<br>By only defining =3D=3D I really meant just that. So no operator!=3D
<br>--=20
<br>Olaf
<br></blockquote><div><br>Operator=3D=3D without operator!=3D ? Really?<br>=
But even then we have a similar question:<br><br><div style=3D"border:1px s=
olid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,250,250=
)"><code><div><span style=3D"color:rgb(0,0,136)">return</span><span style=
=3D"color:rgb(0,0,0)"> optional</span><span style=3D"color:rgb(0,136,0)">&l=
t;int></span><span style=3D"color:rgb(102,102,0)">{</span><span style=3D=
"color:rgb(0,0,0)">nullopt</span><span style=3D"color:rgb(102,102,0)">}</sp=
an><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,10=
2,0)">=3D=3D</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"=
color:rgb(0,102,102)">1</span><span style=3D"color:rgb(102,102,0)">;</span>=
</div></code></div><br>Shall it return false or fail to compile? similarly:=
<br><br><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-wor=
d;background-color:rgb(250,250,250)"><code><div><span style=3D"color:rgb(0,=
0,136)">return</span><span style=3D"color:rgb(0,0,0)"> string{"dog"} =3D=3D=
1</span><span style=3D"color:rgb(102,102,0)">;</span></div></code></div><b=
r>Shall it return false, or fail to compile?<br><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1514_8911419.1359026972121--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Thu, 24 Jan 2013 12:31:30 +0100
Raw View
On Thu, Jan 24, 2013 at 12:29 PM, Andrzej Krzemie=C5=84ski
<akrzemi1@gmail.com> wrote:
>> A compiler error, since !=3D is not =3D=3D
>> By only defining =3D=3D I really meant just that. So no operator!=3D
>
>
> Operator=3D=3D without operator!=3D ? Really?
Maybe, but yeah, that might be weird.
> But even then we have a similar question:
>
> return optional<int>{nullopt} =3D=3D 1;
>
> Shall it return false or fail to compile? similarly:
False, that's the whole point of this request, isn't it?
> return string{"dog"} =3D=3D 1;
>
> Shall it return false, or fail to compile?
Fail, of course.
--=20
Olaf
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Thu, 24 Jan 2013 03:34:51 -0800 (PST)
Raw View
------=_Part_67_16488263.1359027292007
Content-Type: text/plain; charset=ISO-8859-1
> > But even then we have a similar question:
> >
> > return optional<int>{nullopt} == 1;
> >
> > Shall it return false or fail to compile? similarly:
>
> False, that's the whole point of this request, isn't it?
>
I can see two reasonable answers here: either return false or fail to
compile. Both answers have their merit.
>
> > return string{"dog"} == 1;
> >
> > Shall it return false, or fail to compile?
>
> Fail, of course.
> --
> Olaf
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_67_16488263.1359027292007
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">> But even then we have=
a similar question:
<br>>
<br>> return optional<int>{nullopt} =3D=3D 1;
<br>>
<br>> Shall it return false or fail to compile? similarly:
<br>
<br>False, that's the whole point of this request, isn't it?
<br></blockquote><div><br>I can see two reasonable answers here: either ret=
urn false or fail to compile. Both answers have their merit.<br> </div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">
<br>> return string{"dog"} =3D=3D 1;
<br>>
<br>> Shall it return false, or fail to compile?
<br>
<br>Fail, of course.
<br>--=20
<br>Olaf
<br></blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_67_16488263.1359027292007--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 24 Jan 2013 13:38:57 +0200
Raw View
On 24 January 2013 13:34, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> wro=
te:
>> > return optional<int>{nullopt} =3D=3D 1;
> I can see two reasonable answers here: either return false or fail to
> compile. Both answers have their merit.
We can compare nullptr to other pointer values with =3D=3D and !=3D, but no=
t
sanely with < and >.
I don't see the harm being able to compare optional<T>, even if it has a nu=
llopt
in it, with values of T.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Thu, 24 Jan 2013 03:44:29 -0800 (PST)
Raw View
------=_Part_1628_25929532.1359027869749
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu czwartek, 24 stycznia 2013 12:38:57 UTC+1 u=BFytkownik Ville=20
Voutilainen napisa=B3:
>
> On 24 January 2013 13:34, Andrzej Krzemie=F1ski <akrz...@gmail.com<javasc=
ript:>>=20
> wrote:=20
> >> > return optional<int>{nullopt} =3D=3D 1;=20
> > I can see two reasonable answers here: either return false or fail to=
=20
> > compile. Both answers have their merit.=20
>
> We can compare nullptr to other pointer values with =3D=3D and !=3D, but =
not=20
> sanely with < and >.=20
> I don't see the harm being able to compare optional<T>, even if it has a=
=20
> nullopt=20
> in it, with values of T.=20
>
Are you saying: allow mixed =3D=3D and !=3D and "poison" mixed <, <=3D, > a=
nd >=3D ?
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_1628_25929532.1359027869749
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu czwartek, 24 stycznia 2013 12:38:57 UTC+1 u=BFytkownik Ville=
Voutilainen napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 24 J=
anuary 2013 13:34, Andrzej Krzemie=F1ski <<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"BDmf9F6w3icJ">akrz...@gmail.com</a>>=
; wrote:
<br>>> > return optional<int>{nullopt} =3D=3D 1;
<br>> I can see two reasonable answers here: either return false or fail=
to
<br>> compile. Both answers have their merit.
<br>
<br>We can compare nullptr to other pointer values with =3D=3D and !=3D, bu=
t not
<br>sanely with < and >.
<br>I don't see the harm being able to compare optional<T>, even if i=
t has a nullopt
<br>in it, with values of T.
<br></blockquote><div><br>Are you saying: allow mixed =3D=3D and !=3D and "=
poison" mixed <, <=3D, > and >=3D ?<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1628_25929532.1359027869749--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Thu, 24 Jan 2013 05:46:07 -0600
Raw View
On Thu, Jan 24, 2013 at 5:34 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
> I can see two reasonable answers here: either return false or fail to
> compile. Both answers have their merit.
I think this should fail to compile, unless an explicit conversion
is inserted:
return optional<int>{nullopt} =3D=3D make_optional(1);
If `optional<int>{nullopt} =3D=3D 1` is allowed, then the API implies
that T is implicitly convertible to `optional<T>`, while they have
different semantics, as we proposed. Even operator=3D of
std::pair does not do this.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Thu, 24 Jan 2013 05:47:57 -0600
Raw View
On Thu, Jan 24, 2013 at 5:46 AM, Zhihao Yuan <lichray@gmail.com> wrote:
> Even operator= of
> std::pair does not do this.
Rationale operators, of course, not assignment.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Thu, 24 Jan 2013 03:52:19 -0800 (PST)
Raw View
------=_Part_1042_22397380.1359028339636
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu czwartek, 24 stycznia 2013 12:46:07 UTC+1 u=BFytkownik Zhihao Yuan=
=20
napisa=B3:
>
> On Thu, Jan 24, 2013 at 5:34 AM, Andrzej Krzemie=F1ski <akrz...@gmail.com=
<javascript:>>=20
> wrote:=20
> > I can see two reasonable answers here: either return false or fail to=
=20
> > compile. Both answers have their merit.=20
>
> I think this should fail to compile, unless an explicit conversion=20
> is inserted:=20
>
> return optional<int>{nullopt} =3D=3D make_optional(1);=20
>
> If `optional<int>{nullopt} =3D=3D 1` is allowed, then the API implies=20
> that T is implicitly convertible to `optional<T>`, while they have=20
> different semantics, as we proposed. Even operator=3D of=20
> std::pair does not do this.=20
>
In current proposal T *is* implicitly convertible to optional<T> (the=20
converting constructor is implicit).
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_1042_22397380.1359028339636
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu czwartek, 24 stycznia 2013 12:46:07 UTC+1 u=BFytkownik Zhiha=
o Yuan napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thu, Jan 2=
4, 2013 at 5:34 AM, Andrzej Krzemie=F1ski <<a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"N0py3xB2LGcJ">akrz...@gmail.com</a>&g=
t; wrote:
<br>> I can see two reasonable answers here: either return false or fail=
to
<br>> compile. Both answers have their merit.
<br>
<br>I think this should fail to compile, unless an explicit conversion
<br>is inserted:
<br>
<br> return optional<int>{nullopt} =3D=3D make_optional(1);
<br>
<br>If `optional<int>{nullopt} =3D=3D 1` is allowed, then the API imp=
lies
<br>that T is implicitly convertible to `optional<T>`, while they hav=
e
<br>different semantics, as we proposed. Even operator=3D of
<br>std::pair does not do this.
<br></blockquote><div><br>In current proposal T <i>is</i> implicitly conver=
tible to optional<T> (the converting constructor is implicit).<br></d=
iv>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1042_22397380.1359028339636--
.
Author: Nikolay Ivchenkov <tsoae@mail.ru>
Date: Thu, 24 Jan 2013 03:56:52 -0800 (PST)
Raw View
------=_Part_1420_15784776.1359028612930
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, January 24, 2013 2:37:21 PM UTC+4, Ville Voutilainen wrote:
>
> Regarding Nikolay's question about the generic code,
>
> template <class T, class U> T* extract_ptr(U& src)
> {
> return src.get();
> }
>
> int main()
> {
> unique_ptr<int> x;
> int* y = extract_ptr<int, unique_ptr<int>>(x);
> }
>
> Why shouldn't this just work for unique_ptr, shared_ptr and optional?
Why should we use extract_ptr at all? What goal have you achieved with it?
Here we could use
int *y = x.get();
instead.
std::optional could have ptr() or data() that would return (operator bool()
? operator->() : nullptr)
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_1420_15784776.1359028612930
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Thursday, January 24, 2013 2:37:21 PM UTC+4, Ville Voutilainen wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"> Regarding Nikolay's questio=
n about the generic code,
<br>
<br>template <class T, class U> T* extract_ptr(U& src)
<br>{
<br> return src.get();
<br>}
<br>
<br>int main()
<br>{
<br> unique_ptr<int> x;
<br> int* y =3D extract_ptr<int, unique_ptr<int>>(x);
<br>}
<br>
<br>Why shouldn't this just work for unique_ptr, shared_ptr and optional?</=
blockquote><div><br>Why should we use extract_ptr at all? What goal have yo=
u achieved with it? Here we could use<br><br> int *y =3D =
x.get();<br><br>instead.<br><br>std::optional could have ptr() or data() th=
at would return (operator bool() ? operator->() : nullptr)<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1420_15784776.1359028612930--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 24 Jan 2013 14:01:27 +0200
Raw View
On 24 January 2013 13:44, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> wro=
te:
>> We can compare nullptr to other pointer values with =3D=3D and !=3D, but=
not
>> sanely with < and >.
>> I don't see the harm being able to compare optional<T>, even if it has a
>> nullopt
>> in it, with values of T.
> Are you saying: allow mixed =3D=3D and !=3D and "poison" mixed <, <=3D, >=
and >=3D ?
I recommend making the latter non-existent, aka ill-formed. :) I'm not hell=
-bent
on having =3D=3D and !=3D, but I don't see them as harmful.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Thu, 24 Jan 2013 04:15:27 -0800 (PST)
Raw View
------=_Part_1514_331170.1359029727764
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu czwartek, 24 stycznia 2013 13:01:27 UTC+1 u=BFytkownik Ville=20
Voutilainen napisa=B3:
>
> On 24 January 2013 13:44, Andrzej Krzemie=F1ski <akrz...@gmail.com<javasc=
ript:>>=20
> wrote:=20
> >> We can compare nullptr to other pointer values with =3D=3D and !=3D, b=
ut not=20
> >> sanely with < and >.=20
> >> I don't see the harm being able to compare optional<T>, even if it has=
=20
> a=20
> >> nullopt=20
> >> in it, with values of T.=20
> > Are you saying: allow mixed =3D=3D and !=3D and "poison" mixed <, <=3D,=
> and >=3D=20
> ?=20
>
> I recommend making the latter non-existent, aka ill-formed. :) I'm not=20
> hell-bent=20
> on having =3D=3D and !=3D, but I don't see them as harmful.=20
>
In the current proposal they are explicitly poisoned, because if they=20
weren't the comparisons would just work due to implicit conversion from T=
=20
to optional<T>. This is similar to std::string comparisons:
return std::string{"dog"} =3D=3D "dog";
It just works even though there is no explicit "mixed" comparison operator.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_1514_331170.1359029727764
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu czwartek, 24 stycznia 2013 13:01:27 UTC+1 u=BFytkownik Ville=
Voutilainen napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 24 J=
anuary 2013 13:44, Andrzej Krzemie=F1ski <<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"Y6lk_JNoDSoJ">akrz...@gmail.com</a>>=
; wrote:
<br>>> We can compare nullptr to other pointer values with =3D=3D and=
!=3D, but not
<br>>> sanely with < and >.
<br>>> I don't see the harm being able to compare optional<T>, =
even if it has a
<br>>> nullopt
<br>>> in it, with values of T.
<br>> Are you saying: allow mixed =3D=3D and !=3D and "poison" mixed <=
;, <=3D, > and >=3D ?
<br>
<br>I recommend making the latter non-existent, aka ill-formed. :) I'm not =
hell-bent
<br>on having =3D=3D and !=3D, but I don't see them as harmful.
<br></blockquote><div><br>In the current proposal they are explicitly poiso=
ned, because if they weren't the comparisons would just work due to implici=
t conversion from T to optional<T>. This is similar to std::string co=
mparisons:<br><br><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"><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">string</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span st=
yle=3D"color: #080;" class=3D"styled-by-prettify">"dog"</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">=3D=3D</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"styl=
ed-by-prettify">"dog"</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span></div></code></div><br>It just works even though there is no e=
xplicit "mixed" comparison operator.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1514_331170.1359029727764--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 24 Jan 2013 14:17:17 +0200
Raw View
On 24 January 2013 14:15, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> wro=
te:
>> I recommend making the latter non-existent, aka ill-formed. :) I'm not
>> hell-bent
>> on having =3D=3D and !=3D, but I don't see them as harmful.
> In the current proposal they are explicitly poisoned, because if they
> weren't the comparisons would just work due to implicit conversion from T=
to
> optional<T>. This is similar to std::string comparisons:
Ah, I see now what you mean by "poisoned", and yes, I agree, poisoning them
is a good idea.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Thu, 24 Jan 2013 13:19:12 +0100
Raw View
2013/1/24 Ville Voutilainen <ville.voutilainen@gmail.com>:
> On 24 January 2013 13:44, Andrzej Krzemie=F1ski <akrzemi1@gmail.com> wrot=
e:
>>> We can compare nullptr to other pointer values with =3D=3D and !=3D, bu=
t not
>>> sanely with < and >.
>>> I don't see the harm being able to compare optional<T>, even if it has =
a
>>> nullopt
>>> in it, with values of T.
>> Are you saying: allow mixed =3D=3D and !=3D and "poison" mixed <, <=3D, =
> and >=3D ?
>
> I recommend making the latter non-existent, aka ill-formed. :) I'm not he=
ll-bent
> on having =3D=3D and !=3D, but I don't see them as harmful.
I haven't seen any rationale that sounded convincing to me to forbid
mixed relational operator comparison of optional<T> with T values,
including the example given in the proposing paper. First, any
comparison with pointers or smart pointers doesn't make sense in this
context, because an optional is *not* a pointer. It just is a wrapper
of T and supports an empty T state. If I replace in a class a T that
was initialized with a value t, than this code will still do the right
thing when I replace it with optional<T>. I call always safely compare
a T object with an optional<T> object, because the given T
conceptually behaves like an optional<T> with an engaged state of type
T. I would expect that this works out-of-the box. We are using
boost::optional in our company since ages and have taken advantage of
this supported mixed comparison so this looks like an established
existing practice to me. I'm astonished that the proposing paper
considers not to support these operations. If they indeed have good
grounds for not adding them, I would do so in a complete way, i.e. by
removing *all* mixed comparisons. But removing mixed comparison
support is not what I think as a good way to go.
- Daniel
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Thu, 24 Jan 2013 06:20:27 -0600
Raw View
On Thu, Jan 24, 2013 at 5:52 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
> In current proposal T is implicitly convertible to optional<T> (the
> converting constructor is implicit).
I see... And I know why it has a pointer-like interface now.
In your proposal, you want to treat optional<T> as an
extended T, which makes the semantics to be similar
to a pointer.
However, I regard it as an option type as in type
theory. Like, a container with an empty state.
https://en.wikipedia.org/wiki/Option_type
The latter one is theoretically safer, but it might be too late.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 24 Jan 2013 14:24:27 +0200
Raw View
On 24 January 2013 14:19, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wrot=
e:
>>> Are you saying: allow mixed =3D=3D and !=3D and "poison" mixed <, <=3D,=
> and >=3D ?
>> I recommend making the latter non-existent, aka ill-formed. :) I'm not h=
ell-bent
>> on having =3D=3D and !=3D, but I don't see them as harmful.
> I haven't seen any rationale that sounded convincing to me to forbid
> mixed relational operator comparison of optional<T> with T values,
> including the example given in the proposing paper. First, any
> comparison with pointers or smart pointers doesn't make sense in this
> context, because an optional is *not* a pointer. It just is a wrapper
I don't see why I shouldn't relate these comparisons to pointer operations.
In general, a pointer is a type that has a special value in its set of
values, that
value being nullptr. optional has a strikingly similar special value, that =
being
nullopt.
> of T and supports an empty T state. If I replace in a class a T that
> was initialized with a value t, than this code will still do the right
> thing when I replace it with optional<T>. I call always safely compare
> a T object with an optional<T> object, because the given T
> conceptually behaves like an optional<T> with an engaged state of type
> T. I would expect that this works out-of-the box. We are using
> boost::optional in our company since ages and have taken advantage of
> this supported mixed comparison so this looks like an established
> existing practice to me. I'm astonished that the proposing paper
> considers not to support these operations. If they indeed have good
> grounds for not adding them, I would do so in a complete way, i.e. by
> removing *all* mixed comparisons. But removing mixed comparison
> support is not what I think as a good way to go.
What are the semantics of operator< (and its ilk) when used with a disengag=
ed
optional?
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Thu, 24 Jan 2013 04:27:45 -0800 (PST)
Raw View
------=_Part_256_9820354.1359030465977
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu czwartek, 24 stycznia 2013 13:20:27 UTC+1 u=BFytkownik Zhihao Yuan=
=20
napisa=B3:
>
> On Thu, Jan 24, 2013 at 5:52 AM, Andrzej Krzemie=F1ski <akrz...@gmail.com=
<javascript:>>=20
> wrote:=20
> > In current proposal T is implicitly convertible to optional<T> (the=20
> > converting constructor is implicit).=20
>
> I see... And I know why it has a pointer-like interface now.=20
>
> In your proposal, you want to treat optional<T> as an=20
> extended T, which makes the semantics to be similar=20
> to a pointer.=20
>
> However, I regard it as an option type as in type=20
> theory. Like, a container with an empty state.=20
>
> https://en.wikipedia.org/wiki/Option_type=20
>
> The latter one is theoretically safer, but it might be too late.=20
>
Our intention is that std::optional be an Option type (or Maybe type=20
constructor from Haskell). We will need to stress this more in the=20
proposal. This is our primary motivation.
The interface we chose might not reflect that clearly enough, but this is=
=20
just the choice of function names. The model is that of Option type.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_256_9820354.1359030465977
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu czwartek, 24 stycznia 2013 13:20:27 UTC+1 u=BFytkownik Zhiha=
o Yuan napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thu, Jan 2=
4, 2013 at 5:52 AM, Andrzej Krzemie=F1ski <<a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"cuvtwWtxwuUJ">akrz...@gmail.com</a>&g=
t; wrote:
<br>> In current proposal T is implicitly convertible to optional<T&g=
t; (the
<br>> converting constructor is implicit).
<br>
<br>I see... And I know why it has a pointer-like interface now.
<br>
<br>In your proposal, you want to treat optional<T> as an
<br>extended T, which makes the semantics to be similar
<br>to a pointer.
<br>
<br>However, I regard it as an option type as in type
<br>theory. Like, a container with an empty state.
<br>
<br><a href=3D"https://en.wikipedia.org/wiki/Option_type" target=3D"_blank"=
>https://en.wikipedia.org/wiki/<wbr>Option_type</a>
<br>
<br>The latter one is theoretically safer, but it might be too late.
<br></blockquote><div><br>Our intention is that std::optional be an Option =
type (or Maybe type constructor from Haskell). We will need to stress this =
more in the proposal. This is our primary motivation.<br><br>The interface =
we chose might not reflect that clearly enough, but this is just the choice=
of function names. The model is that of Option type.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_256_9820354.1359030465977--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Thu, 24 Jan 2013 13:34:25 +0100
Raw View
2013/1/24 Ville Voutilainen <ville.voutilainen@gmail.com>:
> On 24 January 2013 14:19, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wr=
ote:
>>>> Are you saying: allow mixed =3D=3D and !=3D and "poison" mixed <, <=3D=
, > and >=3D ?
>>> I recommend making the latter non-existent, aka ill-formed. :) I'm not =
hell-bent
>>> on having =3D=3D and !=3D, but I don't see them as harmful.
>> I haven't seen any rationale that sounded convincing to me to forbid
>> mixed relational operator comparison of optional<T> with T values,
>> including the example given in the proposing paper. First, any
>> comparison with pointers or smart pointers doesn't make sense in this
>> context, because an optional is *not* a pointer. It just is a wrapper
>
> I don't see why I shouldn't relate these comparisons to pointer operation=
s.
OK, lets become more specific: It makes sense to compare them with
pointers in regard to the fact that a null pointer value has a
*specific* ordering relative to all other pointer values, namely that
it compares less. What I was meaning with my alert was the following:
A pointer of T isn't typically used as a replacement of T and expected
to be equivalent with it. But an optional<T> is often used as a
replacement of T and it usually works unless you need to be sure that
the content could be empty (disengaged) or not.
> In general, a pointer is a type that has a special value in its set of
> values, that
> value being nullptr. optional has a strikingly similar special value, tha=
t being
> nullopt.
This comparison makes sense to me. It means that I have a well-defined
ordering of the disengaged state compared to any engaged state. But a
T value has the same ordering result as an engaged optional<T> that
contents the same T value.
>> of T and supports an empty T state. If I replace in a class a T that
>> was initialized with a value t, than this code will still do the right
>> thing when I replace it with optional<T>. I call always safely compare
>> a T object with an optional<T> object, because the given T
>> conceptually behaves like an optional<T> with an engaged state of type
>> T. I would expect that this works out-of-the box. We are using
>> boost::optional in our company since ages and have taken advantage of
>> this supported mixed comparison so this looks like an established
>> existing practice to me. I'm astonished that the proposing paper
>> considers not to support these operations. If they indeed have good
>> grounds for not adding them, I would do so in a complete way, i.e. by
>> removing *all* mixed comparisons. But removing mixed comparison
>> support is not what I think as a good way to go.
>
> What are the semantics of operator< (and its ilk) when used with a diseng=
aged
> optional?
The empty (disengaged) state always compares less relative to any other T.
- Daniel
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 24 Jan 2013 14:38:35 +0200
Raw View
On 24 January 2013 14:34, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wrot=
e:
>> What are the semantics of operator< (and its ilk) when used with a disen=
gaged
>> optional?
> The empty (disengaged) state always compares less relative to any other T=
..
Makes sense to me, we are in non-violent agreement. :)
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Thu, 24 Jan 2013 13:41:51 +0100
Raw View
On Thu, Jan 24, 2013 at 1:38 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 24 January 2013 14:34, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wr=
ote:
>>> What are the semantics of operator< (and its ilk) when used with a dise=
ngaged
>>> optional?
>> The empty (disengaged) state always compares less relative to any other =
T.
>
> Makes sense to me, we are in non-violent agreement. :)
In SQL, null never compares true to anything (not even null) with
normal operators.
What do other languages like C# do?
--=20
Olaf
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Martinho Fernandes <martinho.fernandes@gmail.com>
Date: Thu, 24 Jan 2013 13:47:44 +0100
Raw View
On Thu, Jan 24, 2013 at 1:41 PM, Olaf van der Spek <olafvdspek@gmail.com> w=
rote:
> In SQL, null never compares true to anything (not even null) with
> normal operators.
> What do other languages like C# do?
In C# null always compares equal to null. For nullable types op<
always returns false if null is involved on either side, but that is
not what is used in containers. The comparison used in containers
(Nullable.Compare IIRC) compares null less than everything else.
Mit freundlichen Gr=FC=DFen,
Martinho
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Thu, 24 Jan 2013 04:49:13 -0800 (PST)
Raw View
------=_Part_901_23835337.1359031753529
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu czwartek, 24 stycznia 2013 13:19:12 UTC+1 u=BFytkownik Daniel Kr=FCg=
ler=20
napisa=B3:
>
> 2013/1/24 Ville Voutilainen <ville.vo...@gmail.com <javascript:>>:=20
> > On 24 January 2013 13:44, Andrzej Krzemie=F1ski <akrz...@gmail.com<java=
script:>>=20
> wrote:=20
> >>> We can compare nullptr to other pointer values with =3D=3D and !=3D, =
but not=20
> >>> sanely with < and >.=20
> >>> I don't see the harm being able to compare optional<T>, even if it ha=
s=20
> a=20
> >>> nullopt=20
> >>> in it, with values of T.=20
> >> Are you saying: allow mixed =3D=3D and !=3D and "poison" mixed <, <=3D=
, > and=20
> >=3D ?=20
> >=20
> > I recommend making the latter non-existent, aka ill-formed. :) I'm not=
=20
> hell-bent=20
> > on having =3D=3D and !=3D, but I don't see them as harmful.=20
>
> I haven't seen any rationale that sounded convincing to me to forbid=20
> mixed relational operator comparison of optional<T> with T values,=20
> including the example given in the proposing paper. First, any=20
> comparison with pointers or smart pointers doesn't make sense in this=20
> context, because an optional is *not* a pointer. It just is a wrapper=20
> of T and supports an empty T state. If I replace in a class a T that=20
> was initialized with a value t, than this code will still do the right=20
> thing when I replace it with optional<T>. I call always safely compare=20
> a T object with an optional<T> object, because the given T=20
> conceptually behaves like an optional<T> with an engaged state of type=20
> T. I would expect that this works out-of-the box. We are using=20
> boost::optional in our company since ages and have taken advantage of=20
> this supported mixed comparison so this looks like an established=20
> existing practice to me. I'm astonished that the proposing paper=20
> considers not to support these operations. If they indeed have good=20
> grounds for not adding them, I would do so in a complete way, i.e. by=20
> removing *all* mixed comparisons. But removing mixed comparison=20
> support is not what I think as a good way to go.=20
>
I agree with the "uniformity" argument here. Either they all go or they all=
=20
stay. If the "safety" argument is convincing enough, they should all go=20
(they are equally "unsafe"). If the issue about less-than comparison is=20
only about the ordering of nullopt, this argument is not good enough given=
=20
that we already provide operator< for optionals. And we want to provide it,=
=20
so that you can use optional in tree-based containers.
Regarding the "safety" argument, apparently we differ in experience with=20
using the mixed comparison. I would like to hear what others think.=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_901_23835337.1359031753529
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu czwartek, 24 stycznia 2013 13:19:12 UTC+1 u=BFytkownik Danie=
l Kr=FCgler napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">2013/1/2=
4 Ville Voutilainen <<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"nb7NgmJNfj0J">ville.vo...@gmail.com</a>>:
<br>> On 24 January 2013 13:44, Andrzej Krzemie=F1ski <<a href=3D"jav=
ascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"nb7NgmJNfj0J">akrz...@=
gmail.com</a>> wrote:
<br>>>> We can compare nullptr to other pointer values with =3D=3D=
and !=3D, but not
<br>>>> sanely with < and >.
<br>>>> I don't see the harm being able to compare optional<T&g=
t;, even if it has a
<br>>>> nullopt
<br>>>> in it, with values of T.
<br>>> Are you saying: allow mixed =3D=3D and !=3D and "poison" mixed=
<, <=3D, > and >=3D ?
<br>>
<br>> I recommend making the latter non-existent, aka ill-formed. :) I'm=
not hell-bent
<br>> on having =3D=3D and !=3D, but I don't see them as harmful.
<br>
<br>I haven't seen any rationale that sounded convincing to me to forbid
<br>mixed relational operator comparison of optional<T> with T values=
,
<br>including the example given in the proposing paper. First, any
<br>comparison with pointers or smart pointers doesn't make sense in this
<br>context, because an optional is *not* a pointer. It just is a wrapper
<br>of T and supports an empty T state. If I replace in a class a T that
<br>was initialized with a value t, than this code will still do the right
<br>thing when I replace it with optional<T>. I call always safely co=
mpare
<br>a T object with an optional<T> object, because the given T
<br>conceptually behaves like an optional<T> with an engaged state of=
type
<br>T. I would expect that this works out-of-the box. We are using
<br>boost::optional in our company since ages and have taken advantage of
<br>this supported mixed comparison so this looks like an established
<br>existing practice to me. I'm astonished that the proposing paper
<br>considers not to support these operations. If they indeed have good
<br>grounds for not adding them, I would do so in a complete way, i.e. by
<br>removing *all* mixed comparisons. But removing mixed comparison
<br>support is not what I think as a good way to go.
<br></blockquote><div><br>I agree with the "uniformity" argument here. Eith=
er they all go or they all stay. If the "safety" argument is convincing eno=
ugh, they should all go (they are equally "unsafe"). If the issue about les=
s-than comparison is only about the ordering of nullopt, this argument is n=
ot good enough given that we already provide operator< for optionals. An=
d we want to provide it, so that you can use optional in tree-based contain=
ers.<br><br>Regarding the "safety" argument, apparently we differ in experi=
ence with using the mixed comparison. I would like to hear what others thin=
k. <br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_901_23835337.1359031753529--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Thu, 24 Jan 2013 06:51:16 -0600
Raw View
On Thu, Jan 24, 2013 at 6:27 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
> The interface we chose might not reflect that clearly enough, but this is
> just the choice of function names. The model is that of Option type.
For short, I hope T is *not* implicitly convertible to optional<T>,
because I regard nullopt as a state, not a value; and optional<T>
is not T with one more value, it's a T with *two* states, like, an
optional T.
And I'm also not attracted by the `optional<int> x =3D 1` syntax.
However, as Daniel said, boost::optional has been wide spread for
many years. Maybe Boost-compatibility is import to your proposal.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 24 Jan 2013 10:12:35 -0600
Raw View
--20cf3074b5b298064804d40b16f4
Content-Type: text/plain; charset=ISO-8859-1
On 24 January 2013 02:55, Ville Voutilainen <ville.voutilainen@gmail.com>wrote:
> >> And both do model the nullable concept.
> > So does function, and it doesn't use get().
>
> Well, function::target is a red herring - it has to receive a type
> argument in order
> to convert properly, due to erasure.
>
So the rule isn't "if it supports the nullable concept, it should have a
member function named get() that returns a pointer."
I prefer the simpler "get() should return access to the value that was
originally stored".
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--20cf3074b5b298064804d40b16f4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 24 January 2013 02:55, Ville Voutilainen <span dir=3D"ltr"><<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@gmail.com</a>></span> wrote:<br><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">
>> And both do model the nullable concept.<br>
> So does function, and it doesn't use get().<br>
<br>
Well, function::target is a red herring - it has to receive a type<br>
argument in order<br>
to convert properly, due to erasure.<br></blockquote><div><br></div><div>So=
the rule isn't "if it supports the nullable concept, it should ha=
ve a member function named get() that returns a pointer."</div><div>
<br></div><div>I prefer the simpler "get() should return access to the=
value that was originally stored".</div></div>-- <br>=A0Nevin ":=
-)" Liber=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" targ=
et=3D"_blank">nevin@eviloverlord.com</a>>=A0 (847) 691-1404
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--20cf3074b5b298064804d40b16f4--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 24 Jan 2013 20:33:26 +0200
Raw View
On 24 January 2013 18:12, Nevin Liber <nevin@eviloverlord.com> wrote:
>> >> And both do model the nullable concept.
>> > So does function, and it doesn't use get().
>> Well, function::target is a red herring - it has to receive a type
>> argument in order
>> to convert properly, due to erasure.
> So the rule isn't "if it supports the nullable concept, it should have a
> member function named get() that returns a pointer."
> I prefer the simpler "get() should return access to the value that was
> originally stored".
The point I was trying to make is that the getter for the underlying value
for function is different, since it can't be invoked the same way. I don't
know whether it models the same concepts as the smart pointers do,
in that regard. Perhaps there's concept-wise "nullable" and "nullable
with erasure".
shared_ptr performs erasure for its deleter, but not for the underlying
type, so I guess it models the former?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Thu, 24 Jan 2013 15:47:22 -0300
Raw View
On Wed, Jan 23, 2013 at 8:28 PM, Andrzej Krzemie=F1ski <akrzemi1@gmail.com>=
wrote:
>
>
> W dniu =B6roda, 23 stycznia 2013 23:23:38 UTC+1 u=BFytkownik Jeffrey Yass=
kin
> napisa=B3:
>>
>> On Wed, Jan 23, 2013 at 2:18 PM, Andrzej Krzemie=F1ski <akrz...@gmail.co=
m>
>> wrote:
>> >
>> >> 4) In the absence of compiler support, what if get_value_or insists
>> >> that both of its arguments are either rvalues or lvalues? A mix cause=
s
>> >> a compile error. If both arguments are rvalues, it returns moved
>> >> versions. If both are lvalues, it returns a reference, of appropriate
>> >> const-ness.
>> >
>> >
>> > This would render the following, IMO typical, examples ill-formed:
>> >
>> > return getPosition().get_value_or(std::string::npos); // npos is an
>> > lvalue
>> >
>> > constexpr int LEAST =3D ~0;
>> > return getBiggestInt().get_value_or(LEAST); // rvalue-lvalue mismatch
>>
>> Yes it would. I still don't have a strong feeling for which of the
>> options is least-bad, which is why leaving it out and waiting for user
>> feedback is attractive.
>
>
> What do others feel about dropping get_value_or altogether? (at least for
> C++17)
>
-10
:)
While I think we are following the right strategy of a avoiding
features that are way too controversial, I use that all the time so to
me it's an essential part.
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 24 Jan 2013 12:49:05 -0600
Raw View
--00032557adae4a7f9204d40d4681
Content-Type: text/plain; charset=ISO-8859-1
On 24 January 2013 12:33, Ville Voutilainen <ville.voutilainen@gmail.com>wrote:
>
> shared_ptr performs erasure for its deleter, but not for the underlying
> type, so I guess it models the former?
>
It type erases both, doesn't it? The deleter certainly knows the
underlying type passed to the constructor. And users can use
*_pointer_cast<> templates to eventually access the underlying type of the
pointer, if they know what it is.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--00032557adae4a7f9204d40d4681
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 24 January 2013 12:33, Ville Voutilainen <span dir=3D"ltr"><<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@gmail.com</a>></span> wrote:<br><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">
<br>
shared_ptr performs erasure for its deleter, but not for the underlying<br>
type, so I guess it models the former?<br></blockquote><div><br>It type era=
ses both, doesn't it?=A0 The deleter certainly knows the underlying typ=
e passed to the constructor.=A0 And users can use *_pointer_cast<> te=
mplates to eventually access the underlying type of the pointer, if they kn=
ow what it is.<br>
</div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
>=A0 (847) 691-1404
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--00032557adae4a7f9204d40d4681--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Thu, 24 Jan 2013 15:52:22 -0300
Raw View
On Wed, Jan 23, 2013 at 8:37 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 24 January 2013 00:31, Mikael Kilpel=E4inen
> <mikael.kilpelainen@gmail.com> wrote:
>> What do others feel about dropping get_value_or altogether? (at least fo=
r
>> C++17)
>> I would find that very unfortunate, from my point of view it is one of t=
he
>> main use cases.
>
> I won't cry bloody murder if you drop it from the proposal. I won't
> cry bloody murder
> if it's in the proposal and the LWG chooses to axe it.
>
> However, I'm 100% certain that its returning a value is the right
> choice,
+1
Having considered everything that has been discussed about it, I agree
is the best "default" choice as well, specially in the context of a
proposal for a future C++, if we consider that C++ is moving toward
value semantics.
That is, today it might turned out to be a practical problem in some
real cases, just like it used to be returning a std::vector<> by
value. But in the same way that is not a problem anymore, I expect
that returning by value as opposed to by reference becomes more and
more common.
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 24 Jan 2013 20:53:24 +0200
Raw View
On 24 January 2013 20:49, Nevin Liber <nevin@eviloverlord.com> wrote:
>> shared_ptr performs erasure for its deleter, but not for the underlying
>> type, so I guess it models the former?
> It type erases both, doesn't it?
I don't think of it that way. Unless you mean passing Derived* to
shared_ptr<Base>.
> The deleter certainly knows the underlying
> type passed to the constructor. And users can use *_pointer_cast<>
> templates to eventually access the underlying type of the pointer, if they
> know what it is.
Here's a question: you said you think of get() as returning exactly
what was stored.
Does that apply to unique_ptr and shared_ptr for cases where they store a base
pointer but a derived pointer is passed to them?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Thu, 24 Jan 2013 15:58:58 -0300
Raw View
On Wed, Jan 23, 2013 at 8:44 PM, Jeffrey Yasskin <jyasskin@googlers.com> wrote:
>>>
>>> So &* is not a suitable replacement for a T* get() member.
>>
>> My point was not that &* was a replacement for get()... especially
>> given the fact that get() is a function and, therefore, its behavior
>> very much depend on its actual implementation rather than on one's
>> expectations what get() might do. My point was against 1) adding (as I
>> perceive) non-essential api and 2) legitimizing getting a pointer to
>> the underlying (likely on the stack) object.
>
> I do agree that get() isn't essential, but argument (2) doesn't
> convince me that it's bad. C++ programmers always have to deal with
> object lifetimes and pointers to values owned by other objects. For
> example, operator* also returns the address of the underlying object,
> and unique_ptr<T>::get() also returns a pointer to a value that will
> be destroyed (by default) when the unique_ptr goes out of scope.
>
FWIW, boost::optional has get_ptr.
I find it crystal clear have used it several times.
It was not included in the std proposal because it raises some
controversy, and unlike value_or, is not that much essential, so we
preferred to leave it out (least that is my reason). But it it where
up to me, it would have get_ptr() as well.
Best
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Thu, 24 Jan 2013 20:00:54 +0100
Raw View
2013/1/24 Fernando Cacciola <fernando.cacciola@gmail.com>:
> On Wed, Jan 23, 2013 at 8:44 PM, Jeffrey Yasskin <jyasskin@googlers.com> wrote:
>>>>
>>>> So &* is not a suitable replacement for a T* get() member.
>>>
>>> My point was not that &* was a replacement for get()... especially
>>> given the fact that get() is a function and, therefore, its behavior
>>> very much depend on its actual implementation rather than on one's
>>> expectations what get() might do. My point was against 1) adding (as I
>>> perceive) non-essential api and 2) legitimizing getting a pointer to
>>> the underlying (likely on the stack) object.
>>
>> I do agree that get() isn't essential, but argument (2) doesn't
>> convince me that it's bad. C++ programmers always have to deal with
>> object lifetimes and pointers to values owned by other objects. For
>> example, operator* also returns the address of the underlying object,
>> and unique_ptr<T>::get() also returns a pointer to a value that will
>> be destroyed (by default) when the unique_ptr goes out of scope.
>>
>
> FWIW, boost::optional has get_ptr.
> I find it crystal clear have used it several times.
>
> It was not included in the std proposal because it raises some
> controversy, and unlike value_or, is not that much essential, so we
> preferred to leave it out (least that is my reason). But it it where
> up to me, it would have get_ptr() as well.
Yes, I agree that get_ptr() would seem like a good naming choice to me.
- Daniel
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Thu, 24 Jan 2013 16:02:07 -0300
Raw View
On Wed, Jan 23, 2013 at 8:46 PM, Vladimir Batov <vb.mail.247@gmail.com> wro=
te:
> On Thu, Jan 24, 2013 at 9:28 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail=
..com> wrote:
>> ...
>> What do others feel about dropping get_value_or altogether? (at least fo=
r
>> C++17)
>
> I'd personally think it's be the right thing to do. To begin with I
> feel that functionality is not a property of optional but rather all
> nullable classes. So, IMO it needs to be implemented that way.
> Secondly, it seems to be a convenience feature which again raises the
> question if that belongs *with* the class. Thirdly, the amount of
> discussion generated about the function speaks volumes -- there is no
> clear-cut agreement on its behavior, applicability, etc.
>
I would agree if there were any serious chance to have "the best
thing" (read my post on the matter) in the std soon enough.
But without that, the practical usability of std::optional would be
compromised too much.
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Thu, 24 Jan 2013 16:04:23 -0300
Raw View
On Wed, Jan 23, 2013 at 8:56 PM, Vladimir Batov <vb.mail.247@gmail.com> wro=
te:
> On Thu, Jan 24, 2013 at 9:46 AM, Mikael Kilpel=E4inen
> <mikael.kilpelainen@gmail.com> wrote:
>> 23.1.2013 23:40, Ville Voutilainen kirjoitti:
>>
>>> On 24 January 2013 00:38, Vladimir Batov <vb.mail.247@gmail.com> wrote:
>>>>
>>>> optional<int> a;
>>>> int* ap1 =3D &*a;
>>>> int* ap2 =3D a ? &*a : 0;
>>>> int* ap3 =3D a.get();
>>>> For 'ap1' and 'ap2' one applies the same language knowledge (and
>>>> awareness) as for 'ap'. For 'ap3' though it's far from clear as it
>>>> applied the learning requirement. That learning requirement multiplied
>>>> by the number of new methods and the number of deployed classes deeply
>>>> affects productivity, readability, reliability.
>>>
>>> I happen to find ap3 massively more readable and reliable than ap2.
>>>
>> I can only agree with this!
>
> Not so fast! :-) The problem here is that your sensation of "massively
> more readable and reliable" is purely subjective and only based on
> your *interpretation* what get() *might* do. In reality, get() might
> do something altogether different (which obviously depends on how it's
> implemented).
OTOH, if it is called "get_ptr()", as it is in boost::optional, would
there by any possible confusion about what it does?
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Thu, 24 Jan 2013 16:14:54 -0300
Raw View
On Thu, Jan 24, 2013 at 5:12 AM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 24 January 2013 09:04, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wr=
ote:
>> 2013/1/24 Nevin Liber <nevin@eviloverlord.com>:
>>> My position:
>>> I am strongly against calling this feature get().
>>> I am weakly for this feature with a better name, such as to_pointer()
>>> (either as a free function or a member function).
>> I'm generally in favour for this feature, it also has a pendant in
>> comparable types: For example, std::function has
>> template<typename T> T* target() noexcept;
>> template<typename T> const T* target() const noexcept;
>> for this (It needs to be a template in std::function, because we have
>> type-erasure here), In optional<T> it could be declared as
>> T* target() noexcept;
>> const T* target() const noexcept;
>> I'm not so happy with "to_pointer", because that sounds like a
>> conversion to me. Whether "target" is ideal, I'm not sure.
>
> Do we think optional models similar concepts as unique_ptr and shared_ptr=
?
> Should the functions that extract a pointer from such "nullable proxies" =
have
> the same name? For generic code?
>
I don't think so.
As I mentioned, boost::optional has get_ptr() (get() alone is a
terrible choice IMO)
Daniel's target() also works for me.
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Thu, 24 Jan 2013 20:18:33 +0100
Raw View
2013/1/24 Fernando Cacciola <fernando.cacciola@gmail.com>:
> On Thu, Jan 24, 2013 at 5:12 AM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
>> On 24 January 2013 09:04, Daniel Kr=FCgler <daniel.kruegler@gmail.com> w=
rote:
>>> 2013/1/24 Nevin Liber <nevin@eviloverlord.com>:
>>>> My position:
>>>> I am strongly against calling this feature get().
>>>> I am weakly for this feature with a better name, such as to_pointer()
>>>> (either as a free function or a member function).
>>> I'm generally in favour for this feature, it also has a pendant in
>>> comparable types: For example, std::function has
>>> template<typename T> T* target() noexcept;
>>> template<typename T> const T* target() const noexcept;
>>> for this (It needs to be a template in std::function, because we have
>>> type-erasure here), In optional<T> it could be declared as
>>> T* target() noexcept;
>>> const T* target() const noexcept;
>>> I'm not so happy with "to_pointer", because that sounds like a
>>> conversion to me. Whether "target" is ideal, I'm not sure.
>>
>> Do we think optional models similar concepts as unique_ptr and shared_pt=
r?
>> Should the functions that extract a pointer from such "nullable proxies"=
have
>> the same name? For generic code?
>>
> I don't think so.
>
> As I mentioned, boost::optional has get_ptr() (get() alone is a
> terrible choice IMO)
>
> Daniel's target() also works for me.
I selected target() solely because I tried to find something that can
be compared in the current library. I think that get_ptr() is a good
solution, because we solve the potential semantic ambiguity with
get().
- Daniel
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Thu, 24 Jan 2013 16:18:57 -0300
Raw View
On Thu, Jan 24, 2013 at 5:56 AM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>
> void f(string*);
>
> shared_ptr<string> a;
> unique_ptr<string> b;
> optional<string> c;
>
> f(a.get());
> f(b.get());
> f(c.ptr()); // ???
>
> There's a natural mapping between optionals and pointers.
> Having the same function name for all three would be nicely consistent.
I don't think so.
The first two are smart pointers, in fact they are named with "_ptr",
so it's crystal clear what get() does on them.
But the third (optional<>) is not a pointer.
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Thu, 24 Jan 2013 16:24:38 -0300
Raw View
On Thu, Jan 24, 2013 at 6:10 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>> Foo* ptr = &*foo2;
>
>
> Because, quite frankly, no programmer should ever write that, nor should
> they want to.
I agree here, even if maybe for other reasons.
I regard the usage of operator & as a "C-ism".
In C++, I much prefer to use something else. A technical reason is
that you *can* (if you are mean enough) overload operator&. A
practical reason is that is impossible to grep because the same token
is used for references.
That's why there is boost::addressof(), which I always use instead of &
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Thu, 24 Jan 2013 16:29:02 -0300
Raw View
On Thu, Jan 24, 2013 at 7:12 AM, Andrzej Krzemie=F1ski <akrzemi1@gmail.com>=
wrote:
>
>
> W dniu czwartek, 24 stycznia 2013 07:46:39 UTC+1 u=BFytkownik Nevin ":-)"
> Liber napisa=B3:
>>
>> On 24 January 2013 00:16, Vladimir Batov <vb.ma...@gmail.com> wrote:
>>>
>>> There is no misunderstanding when one uses the std language facilities =
to
>>> retrieve a pointer:
>>>
>>> Foo foo1;
>>> Foo* ptr =3D &foo1; // #1
>>>
>>> That deployment is idiomatic in C/C++. The user knows that the onus is =
on
>>> him to make sure ptrs are valid. I am hoping no one is arguing that (li=
king
>>> or not is another matter). Then, if getting access to the underlying ob=
ject
>>>
>>> optional<Foo> foo2;
>>> Foo& ref =3D *foo2; // #2
>>
>>
>> Ah, the problem also happens with references. What happens when you do:
>>
>> optional<int> i(2);
>> int& ir =3D *i;
>> i =3D nullopt; // cannot use ir
>> i =3D 3; // can we use ir?
>>
>
> I wonder if we need to address this explicitly in the standardese. My
> position was that "you know what other semantics of std::optional are: yo=
u
> know what you are risking".
>
No, I don't think we need to.
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Thu, 24 Jan 2013 16:34:31 -0300
Raw View
On Thu, Jan 24, 2013 at 7:38 AM, Andrzej Krzemie=F1ski <akrzemi1@gmail.com>=
wrote:
>
>
> W dniu czwartek, 24 stycznia 2013 00:20:24 UTC+1 u=BFytkownik Mikael
> Kilpel=E4inen napisa=B3:
>>
>>
>> > void func( optional<int> const& o ) {
>> > if( o =3D=3D 1 ) { //instead of o && *o =3D=3D 1 or similar
>> > whatever..
>> > }
>> > }
>> >
>> > That is, i don't need to check if the optional is engaged or not, so i
>> > cannot forget it either and i don't need to type the name twice..
>> > (okey, you can always do the comparison by constructing the optional
>> > from the value and comparing)
>> >
>> Just wanted to add here that actually the one of most convient cases
>> being..
>>
>> BOOST_CHECK( my_func_returning_optional() =3D=3D my_value );
>>
>> Again, i could construct optional of the right hand side, good enough,
>> would work, might have performance implications though.
>
>
> What do others think about offering the mixed assignment of T with
> optional<T>? (given the potential risks)
>
This exists in boost::optional<>, so evidently I think is a nice feature.
It was dropped from std::optional<> to avoid the controversy about
"what *is* an optional". There were heated debates about this
assignment.
I don't find it essential though so I can leave without it.
Best
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Thu, 24 Jan 2013 11:56:11 -0800 (PST)
Raw View
------=_Part_331_27904171.1359057371755
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu czwartek, 24 stycznia 2013 20:34:31 UTC+1 u=BFytkownik Fernando=20
Cacciola napisa=B3:
>
> On Thu, Jan 24, 2013 at 7:38 AM, Andrzej Krzemie=F1ski <akrz...@gmail.com=
<javascript:>>=20
> wrote:=20
> >=20
> >=20
> > W dniu czwartek, 24 stycznia 2013 00:20:24 UTC+1 u=BFytkownik Mikael=20
> > Kilpel=E4inen napisa=B3:=20
> >>=20
> >>=20
> >> > void func( optional<int> const& o ) {=20
> >> > if( o =3D=3D 1 ) { //instead of o && *o =3D=3D 1 or similar=20
> >> > whatever..=20
> >> > }=20
> >> > }=20
> >> >=20
> >> > That is, i don't need to check if the optional is engaged or not, so=
=20
> i=20
> >> > cannot forget it either and i don't need to type the name twice..=20
> >> > (okey, you can always do the comparison by constructing the optiona=
l=20
> >> > from the value and comparing)=20
> >> >=20
> >> Just wanted to add here that actually the one of most convient cases=
=20
> >> being..=20
> >>=20
> >> BOOST_CHECK( my_func_returning_optional() =3D=3D my_value );=20
> >>=20
> >> Again, i could construct optional of the right hand side, good enough,=
=20
> >> would work, might have performance implications though.=20
> >=20
> >=20
> > What do others think about offering the mixed assignment of T with=20
> > optional<T>? (given the potential risks)=20
> >=20
>
> This exists in boost::optional<>, so evidently I think is a nice feature.=
=20
>
> It was dropped from std::optional<> to avoid the controversy about=20
> "what *is* an optional". There were heated debates about this=20
> assignment.=20
> I don't find it essential though so I can leave without it.=20
>
Putting this question in another way, if we allow the mixed comparison=20
between T and optional<T> would anyone object?
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_331_27904171.1359057371755
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu czwartek, 24 stycznia 2013 20:34:31 UTC+1 u=BFytkownik Ferna=
ndo Cacciola napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thu,=
Jan 24, 2013 at 7:38 AM, Andrzej Krzemie=F1ski <<a href=3D"javascript:"=
target=3D"_blank" gdf-obfuscated-mailto=3D"2AfZWnoIDtcJ">akrz...@gmail.com=
</a>> wrote:
<br>>
<br>>
<br>> W dniu czwartek, 24 stycznia 2013 00:20:24 UTC+1 u=BFytkownik Mika=
el
<br>> Kilpel=E4inen napisa=B3:
<br>>>
<br>>>
<br>>> > void func( optional<int> const& o ) {
<br>>> > if( o =3D=3D 1 ) { //instead of o &&=
; *o =3D=3D 1 or similar
<br>>> > whatever..
<br>>> > }
<br>>> > }
<br>>> >
<br>>> > That is, i don't need to check if the optional is engaged=
or not, so i
<br>>> > cannot forget it either and i don't need to type the name=
twice..
<br>>> > (okey, you can always do the comparison by construc=
ting the optional
<br>>> > from the value and comparing)
<br>>> >
<br>>> Just wanted to add here that actually the one of most convient=
cases
<br>>> being..
<br>>>
<br>>> BOOST_CHECK( my_func_returning_optional() =3D=3D my_value );
<br>>>
<br>>> Again, i could construct optional of the right hand side, good=
enough,
<br>>> would work, might have performance implications though.
<br>>
<br>>
<br>> What do others think about offering the mixed assignment of T with
<br>> optional<T>? (given the potential risks)
<br>>
<br>
<br>This exists in boost::optional<>, so evidently I think is a nice =
feature.
<br>
<br>It was dropped from std::optional<> to avoid the controvers=
y about
<br>"what *is* an optional". There were heated debates about this
<br>assignment.
<br>I don't find it essential though so I can leave without it.
<br></blockquote><div><br>Putting this question in another way, if we allow=
the mixed comparison between T and optional<T> would anyone object?<=
br><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_331_27904171.1359057371755--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Thu, 24 Jan 2013 14:05:21 -0600
Raw View
On Thu, Jan 24, 2013 at 1:56 PM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
> Putting this question in another way, if we allow the mixed comparison
> between T and optional<T> would anyone object?
Since T is implicitly convertible to optional<T>, so no objection.
It's as natural as a positive integer is comparable to a natural
number.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 24 Jan 2013 22:13:40 +0200
Raw View
On 24 January 2013 21:18, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
> On Thu, Jan 24, 2013 at 5:56 AM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>> void f(string*);
>> shared_ptr<string> a;
>> unique_ptr<string> b;
>> optional<string> c;
>> f(a.get());
>> f(b.get());
>> f(c.ptr()); // ???
>> There's a natural mapping between optionals and pointers.
>> Having the same function name for all three would be nicely consistent.
> I don't think so.
> The first two are smart pointers, in fact they are named with "_ptr",
> so it's crystal clear what get() does on them.
> But the third (optional<>) is not a pointer.
We all know optional is not a pointer. The question is, does it have anything
in common with smart pointers? Do they or do they not model any common
concepts? I have no love for the name .get(). If I could make them all
..get_ptr(),
I'd do it in a heartbeat. The problem is that smart pointers already name their
"extract a pointer from a nullable proxy"-function .get(). I think optional
models a similar concept when it comes to operator* and get(), so that's why
I think it should be get() rather than get_ptr(). target() and
get_ptr() aren't common
with anything, which to some people may be a good thing. I would
actually find it
potentially confusing to have target(), since it's still not called in
a similar fashion to
std::function's target<T>().
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Thu, 24 Jan 2013 17:29:05 -0300
Raw View
On Thu, Jan 24, 2013 at 6:13 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 24 January 2013 21:18, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
>> On Thu, Jan 24, 2013 at 5:56 AM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>>> void f(string*);
>>> shared_ptr<string> a;
>>> unique_ptr<string> b;
>>> optional<string> c;
>>> f(a.get());
>>> f(b.get());
>>> f(c.ptr()); // ???
>>> There's a natural mapping between optionals and pointers.
>>> Having the same function name for all three would be nicely consistent.
>> I don't think so.
>> The first two are smart pointers, in fact they are named with "_ptr",
>> so it's crystal clear what get() does on them.
>> But the third (optional<>) is not a pointer.
>
> We all know optional is not a pointer. The question is, does it have anything
> in common with smart pointers?
Yes.
> Do they or do they not model any common
> concepts?
They are both models of the NullableProxy concept
> I have no love for the name .get(). If I could make them all
> .get_ptr(),
> I'd do it in a heartbeat. The problem is that smart pointers already name their
> "extract a pointer from a nullable proxy"-function .get(). I think optional
> models a similar concept when it comes to operator*
yes
> and get()
Have in mind that in boost::optinoal<>, get() returns a references and
get_ptr() a pointer.
There is currently no get() in std::optional as of R3
> so that's why
> I think it should be get() rather than get_ptr(). target() and
> get_ptr() aren't common
> with anything, which to some people may be a good thing.
I understand the desire to have a commion idiom to "extract a pointer
from a nullable proxy".
I just don't think that should be a get() member that returns a pointer.
Interestingly:
boost::shared_ptr, et. al. (which preceded std::shared_ptr by several
years) has an overload for the free function
boost::get_pointer()
so does boost::optional<>
so the common idiom already exists and has been used for many many years.
Unfortunately, the free function get_pointer() was dropped from the
std::shared_ptr proposal, for the same reason we dropped it from the
std::optional proposal, which is the same reason we dropped the free
function get_value_or() which would also be overloaded for standard
smart pointers.
Best
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Fri, 25 Jan 2013 07:31:46 +1100
Raw View
On Fri, Jan 25, 2013 at 6:24 AM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> On Thu, Jan 24, 2013 at 6:10 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>>> Foo* ptr = &*foo2;
>>
>> Because, quite frankly, no programmer should ever write that, nor should
>> they want to.
Hmm, that was quite a strong statement what C++ programmers at-large
can (or rather cannot) do. Is it the & in particular or any two
operators next to each other? Is **this OK? How about *++it? It does
not mean I *love* the &* construct. I personally do not even see
myself needing a pointer to the underlying object everyday. What I am
saying is that when/if I *do* need such a pointer, the language
already provides facilities to achieve that without the need of
needlessly inflating the api and trying to replace the language
facilities to suit one's personal taste/style. It is a std proposal we
are talking about... with much wider audience in mind and
impact/implications.
> I agree here, even if maybe for other reasons.
>
> I regard the usage of operator & as a "C-ism".
>
> In C++, I much prefer to use something else. A technical reason is
> that you *can* (if you are mean enough) overload operator&. A
> practical reason is that is impossible to grep because the same token
> is used for references.
>
> That's why there is boost::addressof(), which I always use instead of &
Fernando, I understand that you might have personal reasons not to
like this particular or any other operator and I can honestly agree
with a few of your reasons that you listed. However, I do not believe
arguing against a language facility or trying to "deprecate"/replace
it on the std-lib level is a wise move. Yes, I am aware of
pointer_type get_ptr() { return m_initialized ? get_ptr_impl() : 0 ; }
Is the api an essential, core api? I doubt that as I believe it can be
quite happily implemented outside the class... by those who need it.
Even then I consider deployment of direct "v ? &*v : 0" more readable
than get_ptr(). Because the former (no matter how ugly it might appear
to some) *tells* me what happens and in the case of a function call
(get_ptr or any other) I need to know or assume what happens under the
hood and how corner cases are handled. In one isolated case it might
not matter. On a much wider scale the impact is multiplied manifolds
and is considerable. Say, a mundane but valid example -- you are a s/w
architect doing code reviews. Fun? Hardly. Essential? Well, yes, for
really serious s/w. Glancing over many lines of somebody else's code,
would you prefer *knowing* what "v ? &*v : 0" does or assuming what an
aptly (or not) named function might do?
As for attractiveness of &* or a possibility of it overloaded, then
these are language issues and IMO beyond a particular library. IMO the
language sets the rules, we play by the rules. Much more so, in the
code proposed for the std-lib. Does it make sense?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 24 Jan 2013 22:42:54 +0200
Raw View
On 24 January 2013 22:29, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
>> Do they or do they not model any common
>> concepts?
> They are both models of the NullableProxy concept
> I understand the desire to have a commion idiom to "extract a pointer
> from a nullable proxy".
That's the whole point of having a concept that multiple classes model - being
able to program with the concept rather than having to program differently
for each different class.
> I just don't think that should be a get() member that returns a pointer.
Why? Because boost didn't choose get()? What's the likelyhood of having
get_ptr() for the other types supposedly modeling a "nullableproxy"? What's
the point of claiming that these classes modify a common concept if
there's no benefit from that for practical code?
> Interestingly:
> boost::shared_ptr, et. al. (which preceded std::shared_ptr by several
> years) has an overload for the free function
> boost::get_pointer()
> so does boost::optional<>
> so the common idiom already exists and has been used for many many years.
> Unfortunately, the free function get_pointer() was dropped from the
> std::shared_ptr proposal, for the same reason we dropped it from the
> std::optional proposal, which is the same reason we dropped the free
> function get_value_or() which would also be overloaded for standard
> smart pointers.
Well, if we deem it likely that get_pointer is coming back, I see
little reason to
add a get_ptr(), and I can live with dropping the idea of get() as a
function, whatever
its name. However, I wouldn't mind having LWG take a look at a proposal that
includes it, in whichever form.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Fri, 25 Jan 2013 07:43:54 +1100
Raw View
On Fri, Jan 25, 2013 at 7:29 AM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> ...
> Unfortunately, the free function get_pointer() was dropped from the
> std::shared_ptr proposal, for the same reason we dropped it from the
> std::optional proposal, which is the same reason we dropped the free
> function get_value_or() which would also be overloaded for standard
> smart pointers.
I understand that the (unfortunate?) trend has been set. However, if
we agree that, say, get_value_or's correct implementation would be a
free-standing function, then is it worth a try to establish this trend
rather than insisting and further entrenching the wrong one? Is it
futile trying to introduce get_value_or as as free-standing function
but in the context of the optional proposal with all the
justifications that have been given in the forum? It's hard *not* to
see the value and extendibility of, say, get_value_or as a free
function? What am I missing or have forgotten?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Thu, 24 Jan 2013 17:48:44 -0300
Raw View
On Thu, Jan 24, 2013 at 6:31 PM, Vladimir Batov <vb.mail.247@gmail.com> wrote:
> On Fri, Jan 25, 2013 at 6:24 AM, Fernando Cacciola
>> In C++, I much prefer to use something else. A technical reason is
>> that you *can* (if you are mean enough) overload operator&. A
>> practical reason is that is impossible to grep because the same token
>> is used for references.
>>
>> That's why there is boost::addressof(), which I always use instead of &
>
> Fernando, I understand that you might have personal reasons not to
> like this particular or any other operator and I can honestly agree
> with a few of your reasons that you listed. However, I do not believe
> arguing against a language facility or trying to "deprecate"/replace
> it on the std-lib level is a wise move.
Fair enough. I have a strong personal feeling against the usage of
operator & for taking the address of an object, but that's personal
and can't be used as an argument.
>Yes, I am aware of
>
> pointer_type get_ptr() { return m_initialized ? get_ptr_impl() : 0 ; }
>
On the technical side though, get_ptr_impl() does not suffer from an
unintended overload of &, so this version is effectively safer.
> Is the api an essential, core api? I doubt that as I believe it can be
> quite happily implemented outside the class... by those who need it.
Absolutely. So we initially drop it from the proposal.
Still, I would be happier to have it in.
> Even then I consider deployment of direct "v ? &*v : 0" more readable
> than get_ptr(). Because the former (no matter how ugly it might appear
> to some) *tells* me what happens
Allow me to insist here. It does not really tell me what happens
because operator& can be overloaded. So in reality, I can't be sure by
just looking at it.
> and in the case of a function call
> (get_ptr or any other) I need to know or assume what happens under the
> hood and how corner cases are handled. In one isolated case it might
> not matter. On a much wider scale the impact is multiplied manifolds
> and is considerable. Say, a mundane but valid example -- you are a s/w
> architect doing code reviews. Fun? Hardly. Essential? Well, yes, for
> really serious s/w. Glancing over many lines of somebody else's code,
> would you prefer *knowing* what "v ? &*v : 0" does or assuming what an
> aptly (or not) named function might do?
>
It depends on the function. If it is a function of a std library
facility, then I have no problems since I will know what it does.
So, here is a counter argument using your own approach: it is better
to standardize functions that can be shown to be common practice,
specially if such practice is large, as is the case of boost::optional
existing API, because then we all know what it does. If, OTOH, there
is no get_ptr() or such in std::optional<> but then, *because of
that*, a team deploys their own, it might end up occurring what you
just mentioned. But then the "cure" is to standardize it.
Best
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Fri, 25 Jan 2013 07:50:18 +1100
Raw View
On Fri, Jan 25, 2013 at 7:42 AM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> ...
> Well, if we deem it likely that get_pointer is coming back, I see
> little reason to
> add a get_ptr(), and I can live with dropping the idea of get() as a
> function, whatever
> its name. However, I wouldn't mind having LWG take a look at a proposal that
> includes it, in whichever form.
That'd seem like a very sensible architectural approach. These
facilities (get_pointer, get_value_or, etc) are properties of a group
of of classes (NullableProxies) and IMO should be implemented as such,
i.e. orthogonally to individual class implementations and importantly
uniformly.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Thu, 24 Jan 2013 18:13:18 -0300
Raw View
On Thu, Jan 24, 2013 at 6:50 PM, Vladimir Batov <vb.mail.247@gmail.com> wrote:
> On Fri, Jan 25, 2013 at 7:42 AM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
>> ...
>> Well, if we deem it likely that get_pointer is coming back, I see
>> little reason to
>> add a get_ptr(), and I can live with dropping the idea of get() as a
>> function, whatever
>> its name. However, I wouldn't mind having LWG take a look at a proposal that
>> includes it, in whichever form.
>
> That'd seem like a very sensible architectural approach. These
> facilities (get_pointer, get_value_or, etc) are properties of a group
> of of classes (NullableProxies) and IMO should be implemented as such,
> i.e. orthogonally to individual class implementations and importantly
> uniformly.
>
For the case of get_pointer, however named, I'm well OK with sticking
with the proposal as is, which does not have it.
Then I would happily seek to have the more general get_pointer and get_value_or.
However, for the case of get_value_or the situation is different (so
please let's no mix the two in the same discussion).
I *strongly* (is that empathized enough?) believe that there cannot be
a C++ with an utility for optional values without a standardized
convenience for "getting the value or". I discussed this at length in
previous discussions.
But then, what shall I do?
Say we file the proposal without a member get_value_or(), and file the
general function in a separate proposal (or even as an optional
clause), then the committee votes such that we end up with
std::optional<> but no get_value_or() of any form. If that happens, I
will feel like C++ made a step back and I might start to wonder if it
wouldn't have been better is we just stick with boost::optional
instead.
So, from my position as a mere outside proposer (I'm not even in the
committee, thanks to my beloved Argentinian National Body which seems
to not even know what C++ is :( ), I need to make a move that would
make sure the utility is minimally complete. Like I said before, there
are lots of parts that I accepted to cut out compared to
boost::optional, but the idiom to "get the value or" is IMO an
essential part of it. And FWIW it is very very common in most, if not
all, other nullable types in the other languages that I know of.
Best
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Fri, 25 Jan 2013 08:14:34 +1100
Raw View
On Fri, Jan 25, 2013 at 7:48 AM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> On Thu, Jan 24, 2013 at 6:31 PM, Vladimir Batov <vb.mail.247@gmail.com> wrote:
>
>> Even then I consider deployment of direct "v ? &*v : 0" more readable
>> than get_ptr(). Because the former (no matter how ugly it might appear
>> to some) *tells* me what happens
>
> Allow me to insist here. It does not really tell me what happens
> because operator& can be overloaded. So in reality, I can't be sure by
> just looking at it.
Understood. However, the possibility of an operator overloaded is not
specific to &, is it? More so, the behavior of standard language
operators a much-much-(another-much?) better understood/expected. By
overloading, I say "I overloaded op&() for my class to emulate the
known/well-understood behavior". So, the possibility of those behavior
modified is fairly academic. Not so with functions where I essentially
say "I have some (unknown) functionality that I had to encapsulate in
a function. Go and learn what it does".
>> and in the case of a function call
>> (get_ptr or any other) I need to know or assume what happens under the
>> hood and how corner cases are handled. In one isolated case it might
>> not matter. On a much wider scale the impact is multiplied manifolds
>> and is considerable. Say, a mundane but valid example -- you are a s/w
>> architect doing code reviews. Fun? Hardly. Essential? Well, yes, for
>> really serious s/w. Glancing over many lines of somebody else's code,
>> would you prefer *knowing* what "v ? &*v : 0" does or assuming what an
>> aptly (or not) named function might do?
>>
> It depends on the function. If it is a function of a std library
> facility, then I have no problems since I will know what it does.
My issue is not with any one particular function. My problem is that,
when those functions are many, the programmer (especially the
reader/reviewer) quickly loses control of the situation. I personally
cannot possibly remember all APIs of all std and Boost classes... let
alone their precise behavior.
> So, here is a counter argument using your own approach: it is better
> to standardize functions that can be shown to be common practice,
> specially if such practice is large, as is the case of boost::optional
> existing API, because then we all know what it does. If, OTOH, there
> is no get_ptr() or such in std::optional<> but then, *because of
> that*, a team deploys their own, it might end up occurring what you
> just mentioned. But then the "cure" is to standardize it.
Yes, I am all for it. Say, get_value_or is a separate concept and
should be implemented as such. Consequently, if one needs that
concept/facility with NullableProxies, then he'll use it in a
consistent across-the-board manner -- get_value_or(optional),
get_value_or(shared_ptr), etc. If for whatever reason one does not
need/use the facility, then he'll happily use optional, shared_ptr,
etc. without those classes "polluted" (for his need) with irrelevant
(for him) apis. Nice, isn't it?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 24 Jan 2013 16:16:09 -0500
Raw View
On Thu, Jan 24, 2013 at 7:34 AM, Daniel Kr=FCgler
<daniel.kruegler@gmail.com> wrote:
>>
>> What are the semantics of operator< (and its ilk) when used with a disen=
gaged
>> optional?
>
> The empty (disengaged) state always compares less relative to any other T=
..
>
> - Daniel
>
> --
If you also mean that all T's compare greater, then I'm not sure that
sits too well with me. T is some type with a full "algebra" defined
on it - ie functions that can be called on T, operators, etc. Those
functions define Why do we think we can magically extend that algebra
*correctly* for all T? Why don't we also try to change every function
that takes a T into a similar function that takes an optional<T> ? Why
stop at operator<() ?
Given some of the headaches involved with NaN, I'm also not sure which
"side" of the discussion using it as an analogy promotes, but I think
we should consider floating point numbers and NaN as another analogy
of "all values of T ... plus None".
NaN _does_ compare with any other float, but always returns false.
I actually think that is philosophically correct, at least in the
sense of "is NaN less than 3?" =3D> (for example) "is chair less than 3"
=3D> is it true that "chair is less than 3"? No, it is not true. Nor is
chair greater than 3.
So I understand why NaN compares the way it does. Should
optional<int>(nullopt) work the same as NaN?
Or would it be better to say "is chair is less than 3" makes no sense
=3D> ie should not compile. Quite possibly.
ie (if any of the above made sense) I think that mixed relational
comparison should either not compile ("doesn't make sense"), or should
always return false (follow NaN rules).
Tony
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Thu, 24 Jan 2013 15:16:58 -0600
Raw View
On Thu, Jan 24, 2013 at 3:13 PM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> Then I would happily seek to have the more general get_pointer and get_value_or.
A random thought:
How about to overload std::addressof for NullableProxy by returning
nullptr if it's disengaged?
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 24 Jan 2013 16:20:02 -0500
Raw View
On Thu, Jan 24, 2013 at 4:16 PM, Zhihao Yuan <lichray@gmail.com> wrote:
> On Thu, Jan 24, 2013 at 3:13 PM, Fernando Cacciola
> <fernando.cacciola@gmail.com> wrote:
>> Then I would happily seek to have the more general get_pointer and get_value_or.
>
> A random thought:
>
> How about to overload std::addressof for NullableProxy by returning
> nullptr if it's disengaged?
>
That occurred to me as well, but I was going to put a smiley at the
end - for the whole reason (IIUC) of addressof() was to work around
overloads of &. So to overload addressof() would just seem wryly
ironic. And probably bad :-)
Tony
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Fri, 25 Jan 2013 08:21:43 +1100
Raw View
On Fri, Jan 25, 2013 at 8:13 AM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> ...
> However, for the case of get_value_or the situation is different (so
> please let's no mix the two in the same discussion).
>
> I *strongly* (is that empathized enough?) believe that there cannot be
> a C++ with an utility for optional values without a standardized
> convenience for "getting the value or". I discussed this at length in
> previous discussions.
>
> But then, what shall I do?
Could you remind me what was wrong with your original (I think) idea
of having std::get_value_of a free-standing function but proposing it
as part (and in the context) of the optional?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Beman Dawes <bdawes@acm.org>
Date: Thu, 24 Jan 2013 16:31:20 -0500
Raw View
On Thu, Jan 24, 2013 at 3:48 PM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> On Thu, Jan 24, 2013 at 6:31 PM, Vladimir Batov <vb.mail.247@gmail.com> wrote:
....
>> and in the case of a function call
>> (get_ptr or any other) I need to know or assume what happens under the
>> hood and how corner cases are handled. In one isolated case it might
>> not matter. On a much wider scale the impact is multiplied manifolds
>> and is considerable. Say, a mundane but valid example -- you are a s/w
>> architect doing code reviews. Fun? Hardly. Essential? Well, yes, for
>> really serious s/w. Glancing over many lines of somebody else's code,
>> would you prefer *knowing* what "v ? &*v : 0" does or assuming what an
>> aptly (or not) named function might do?
>>
> It depends on the function. If it is a function of a std library
> facility, then I have no problems since I will know what it does.
>
> So, here is a counter argument using your own approach: it is better
> to standardize functions that can be shown to be common practice,
> specially if such practice is large, as is the case of boost::optional
> existing API, because then we all know what it does. If, OTOH, there
> is no get_ptr() or such in std::optional<> but then, *because of
> that*, a team deploys their own, it might end up occurring what you
> just mentioned. But then the "cure" is to standardize it.
Fernando,
While std-proposals and other mailing lists are great for getting
community feedback, the only way to know for sure if a feature is so
controversial that it must be pulled is to ask the LEWG, LWG, or SG
processing the proposal for a vote at a meeting. That is particularly
true for something like optional that has a long history of
wide-spread use. So you should propose what you think is best for the
standard library. Trust yourself. The committee will strike the
function if they think it is a problem - that's part of their job.
--Beman
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: =?ISO-8859-1?Q?Mikael_Kilpel=E4inen?=
Date: Thu, 24 Jan 2013 22:36:08 +0100
Raw View
24.1.2013 22:13, Fernando Cacciola kirjoitti:
> So, from my position as a mere outside proposer (I'm not even in the
> committee, thanks to my beloved Argentinian National Body which seems
> to not even know what C++ is :( ), I need to make a move that would
> make sure the utility is minimally complete. Like I said before, there
> are lots of parts that I accepted to cut out compared to
> boost::optional, but the idiom to "get the value or" is IMO an
> essential part of it. And FWIW it is very very common in most, if not
> all, other nullable types in the other
I very much agree that "get value or" is essential part of such concept,
I just feel that people are not used to such a comfortable function.
That is, they are most likely using the exactly same concept without
realising one could do it easier.. namely get_value_or. So I think we
should just stick with it and get people to use it. Also nothing
prevents to have both, member and free function .. we have that for swap
already at least.
Mikael
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Thu, 24 Jan 2013 15:37:14 -0600
Raw View
On Thu, Jan 24, 2013 at 3:16 PM, Tony V E <tvaneerd@gmail.com> wrote:
> Or would it be better to say "is chair is less than 3" makes no sense
> => ie should not compile. Quite possibly.
This is my opinion of to have a strong optional<T>, which is denied.
However, a type system with optional<T> is still saver than a
universal nullable type system.
> So I understand why NaN compares the way it does. Should
> optional<int>(nullopt) work the same as NaN?
There is a tiny difference, because optional<T> is a T with
**one** more possible value, while there are multiple NaNs.
So my opinion is,
undefined == undefined => true
undefined != undefined => false
undefined < undefined => false
undefined > undefined => false
Reason: one value
undefined == a defined value => false
undefined != a defined value => true
Reason: different values
undefined <, <=, >, >= a defined value => false
Reason: algebraically incomparable.
As seen in JavaScript.
The opinion, undefined < a defined value,
is seen in Perl and Python.
BTW, either one is OK for an optional<T>(nullopt) being stored
in a sequential/associate container, since we only use less<T>.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 24 Jan 2013 23:50:23 +0200
Raw View
On 24 January 2013 23:31, Beman Dawes <bdawes@acm.org> wrote:
> While std-proposals and other mailing lists are great for getting
> community feedback, the only way to know for sure if a feature is so
> controversial that it must be pulled is to ask the LEWG, LWG, or SG
> processing the proposal for a vote at a meeting. That is particularly
> true for something like optional that has a long history of
> wide-spread use. So you should propose what you think is best for the
> standard library. Trust yourself. The committee will strike the
> function if they think it is a problem - that's part of their job.
+1. On this particular forum, you will get the opinion of "everybody
and their brother",
including people who ultimately play no part in deciding what does or
does not go
into the standard. As I've insinuated a couple of times, I think you
should include
even potentially controversial facilities as Beman said, and get
feedback from L(E)WG.
Of course, chances are they will give you feedback about
get_value_or/get/whatever
even if you choose to omit them from the next proposal.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Thu, 24 Jan 2013 14:20:43 -0800 (PST)
Raw View
------=_Part_52_25481329.1359066043290
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu czwartek, 24 stycznia 2013 21:42:54 UTC+1 u=BFytkownik Ville=20
Voutilainen napisa=B3:
>
> On 24 January 2013 22:29, Fernando Cacciola <fernando...@gmail.com<javasc=
ript:>>=20
> wrote:=20
> >> Do they or do they not model any common=20
> >> concepts?=20
> > They are both models of the NullableProxy concept=20
>
> > I understand the desire to have a commion idiom to "extract a pointer=
=20
> > from a nullable proxy".=20
>
> That's the whole point of having a concept that multiple classes model -=
=20
> being=20
> able to program with the concept rather than having to program differentl=
y=20
> for each different class.=20
>
I admit that I am not entirely following this sub-thread of converting a=20
NullableProxy into a pointer, but let me share this thought. Sorry if it is=
=20
obvious.
NullableProxy gives sufficient interface -- only with contextual conversion=
=20
to bool and operator* returning a reference -- for anyone to be able to=20
implement get_pointer function himself:
template <typemname NulableProxy>
auto get_pointer(NulableProxy && np) -> decltype(addressof(*np))
{
return bool(np) ? addressof(*np) : nullptr;
}
You do not have to require of NullableProxy the member function=20
get_pointer, especially that raw pointers are also models of NulableProxy=
=20
and cannot provide it.=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_52_25481329.1359066043290
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu czwartek, 24 stycznia 2013 21:42:54 UTC+1 u=BFytkownik Ville=
Voutilainen napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 24 J=
anuary 2013 22:29, Fernando Cacciola <<a href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"BIxbkJv_p0UJ">fernando...@gmail.com</a>>=
; wrote:
<br>>> Do they or do they not model any common
<br>>> concepts?
<br>> They are both models of the NullableProxy concept
<br>
<br>> I understand the desire to have a commion idiom to "extract a poin=
ter
<br>> from a nullable proxy".
<br>
<br>That's the whole point of having a concept that multiple classes model =
- being
<br>able to program with the concept rather than having to program differen=
tly
<br>for each different class.
<br></blockquote><div><br>I admit that I am not entirely following this sub=
-thread of converting a NullableProxy into a pointer, but let me share this=
thought. Sorry if it is obvious.<br><br>NullableProxy gives sufficient int=
erface -- only with contextual conversion to bool and operator* returning a=
reference -- for anyone to be able to implement get_pointer function himse=
lf:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 2=
50, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wid=
th: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">t=
emplate</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">typemname </span><=
span style=3D"color: #606;" class=3D"styled-by-prettify">NulableProxy</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">></span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> get_pointer</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">NulableProxy</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">&&</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> np</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">-></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">decltype</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">addressof</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(*</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">np</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">))</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br> </span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
bool</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">np</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">?</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> addressof</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(*</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">np</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">nullptr</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><br><br>You do not ha=
ve to require of NullableProxy the member function get_pointer, especially =
that raw pointers are also models of NulableProxy and cannot provide it. </=
div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_52_25481329.1359066043290--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Thu, 24 Jan 2013 14:48:07 -0800 (PST)
Raw View
------=_Part_98_4793469.1359067687658
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu czwartek, 24 stycznia 2013 22:21:43 UTC+1 u=BFytkownik Vladimir Bato=
v=20
napisa=B3:
>
> On Fri, Jan 25, 2013 at 8:13 AM, Fernando Cacciola=20
> <fernando...@gmail.com <javascript:>> wrote:=20
> > ...=20
> > However, for the case of get_value_or the situation is different (so=20
> > please let's no mix the two in the same discussion).=20
> >=20
> > I *strongly* (is that empathized enough?) believe that there cannot be=
=20
> > a C++ with an utility for optional values without a standardized=20
> > convenience for "getting the value or". I discussed this at length in=
=20
> > previous discussions.=20
> >=20
> > But then, what shall I do?=20
>
> Could you remind me what was wrong with your original (I think) idea=20
> of having std::get_value_of a free-standing function but proposing it=20
> as part (and in the context) of the optional?=20
>
It is very difficult (at least for me) to come up with the 'generic'=20
version of get_value_or. While types optional<T>, shared_ptr<T> and T*=20
share the same syntax with nearly the same semantics (I only refer to=20
operator bool and operator*) there is one significant difference between=20
optional<T> and all pointers. The former contains the "proxied" value. This=
=20
means that its operator* propagates const-ness, while pointers' (smart or=
=20
dumb) operator* does not. This complicates the implementation more than I=
=20
would imagine. You need to distinguish the "classes" of NullableProxies:=20
containing and non-containing.=20
My impression was that we (Fernando and I) would not be able to come up=20
with the robust proposal within the reasonably short amount of time, and=20
providing a poor specification of generic get_value_or would cause harm.=20
Therefore a member function get_value_or is a step towards the robust=20
free-standing generic get_value_or in the future: we do not reserve the=20
name in namespace std and anyone is able to propose a generic version if=20
they know how. Instead we offer a tiny optional-specific convenience=20
function. Because it is not generic, we know how to implement it. And my=20
feeling is that et_value_or is needed far more frequently for optional than=
=20
for any other smart or dumb pointer.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_98_4793469.1359067687658
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu czwartek, 24 stycznia 2013 22:21:43 UTC+1 u=BFytkownik Vladi=
mir Batov napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Ja=
n 25, 2013 at 8:13 AM, Fernando Cacciola
<br><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
pMoQ42Jl90IJ">fernando...@gmail.com</a>> wrote:
<br>> ...
<br>> However, for the case of get_value_or the situation is different (=
so
<br>> please let's no mix the two in the same discussion).
<br>>
<br>> I *strongly* (is that empathized enough?) believe that there canno=
t be
<br>> a C++ with an utility for optional values without a standardized
<br>> convenience for "getting the value or". I discussed this at length=
in
<br>> previous discussions.
<br>>
<br>> But then, what shall I do?
<br>
<br>Could you remind me what was wrong with your original (I think) idea
<br>of having std::get_value_of a free-standing function but proposing it
<br>as part (and in the context) of the optional?
<br></blockquote><div><br>It is very difficult (at least for me) to come up=
with the 'generic' version of get_value_or. While types optional<T>,=
shared_ptr<T> and T* share the same syntax with nearly the same sema=
ntics (I only refer to operator bool and operator*) there is one significan=
t difference between optional<T> and all pointers. The former contain=
s the "proxied" value. This means that its operator* propagates const-ness,=
while pointers' (smart or dumb) operator* does not. This complicates the i=
mplementation more than I would imagine. You need to distinguish the "class=
es" of NullableProxies: containing and non-containing. <br><br>My impressio=
n was that we (Fernando and I) would not be able to come up with the robust=
proposal within the reasonably short amount of time, and providing a poor =
specification of generic get_value_or would cause harm. Therefore a member =
function get_value_or is a step towards the robust free-standing generic ge=
t_value_or in the future: we do not reserve the name in namespace std and a=
nyone is able to propose a generic version if they know how. Instead we off=
er a tiny optional-specific convenience function. Because it is not generic=
, we know how to implement it. And my feeling is that et_value_or is needed=
far more frequently for optional than for any other smart or dumb pointer.=
<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_98_4793469.1359067687658--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Thu, 24 Jan 2013 14:56:20 -0800 (PST)
Raw View
------=_Part_85_24865217.1359068180649
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu czwartek, 24 stycznia 2013 22:16:09 UTC+1 u=BFytkownik Tony V E=20
napisa=B3:
>
> On Thu, Jan 24, 2013 at 7:34 AM, Daniel Kr=FCgler=20
> <daniel....@gmail.com <javascript:>> wrote:=20
> >>=20
> >> What are the semantics of operator< (and its ilk) when used with a=20
> disengaged=20
> >> optional?=20
> >=20
> > The empty (disengaged) state always compares less relative to any other=
=20
> T.=20
> >=20
> > - Daniel=20
> >=20
> > --=20
>
> If you also mean that all T's compare greater, then I'm not sure that=20
> sits too well with me. T is some type with a full "algebra" defined=20
> on it - ie functions that can be called on T, operators, etc. Those=20
> functions define Why do we think we can magically extend that algebra=20
> *correctly* for all T? Why don't we also try to change every function=20
> that takes a T into a similar function that takes an optional<T> ? Why=20
> stop at operator<() ?=20
>
>
> Given some of the headaches involved with NaN, I'm also not sure which=20
> "side" of the discussion using it as an analogy promotes, but I think=20
> we should consider floating point numbers and NaN as another analogy=20
> of "all values of T ... plus None".=20
>
> NaN _does_ compare with any other float, but always returns false.=20
>
> I actually think that is philosophically correct, at least in the=20
> sense of "is NaN less than 3?" =3D> (for example) "is chair less than 3"=
=20
> =3D> is it true that "chair is less than 3"? No, it is not true. Nor is=
=20
> chair greater than 3.=20
>
> So I understand why NaN compares the way it does. Should=20
> optional<int>(nullopt) work the same as NaN?=20
>
> Or would it be better to say "is chair is less than 3" makes no sense=20
> =3D> ie should not compile. Quite possibly.=20
>
> ie (if any of the above made sense) I think that mixed relational=20
> comparison should either not compile ("doesn't make sense"), or should=20
> always return false (follow NaN rules).=20
>
=20
Note two things however. First, the comparison between two optionals=20
already exists (in the proposal) and has non-NaN aemantics (nullopt is just=
=20
another value of T). Are you proposing to change this also?
=20
Second, the semantics of NaN make floating-point types not suitable for=20
keys in tree-like container: because there exists a value (NaN) that does=
=20
not satisfy the axms of Strict Weak Ordering. In contrast, optional<int>=20
and its operator< does implement Strict Weak Ordering.
=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_85_24865217.1359068180649
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br>W dniu czwartek, 24 stycznia 2013 22:16:09 UTC+1 u=BFytkownik Tony V E =
napisa=B3:<blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex=
; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-lef=
t-style: solid;" class=3D"gmail_quote"><p>On Thu, Jan 24, 2013 at 7:34 AM, =
Daniel Kr=FCgler
<br><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
BqkZ5KleV-YJ">daniel....@gmail.com</a>> wrote:
<br>>>
<br>>> What are the semantics of operator< (and its ilk) when used=
with a disengaged
<br>>> optional?
<br>>
<br>> The empty (disengaged) state always compares less relative to any =
other T.
<br>>
<br>> - Daniel
<br>>
<br>> --
<br>
<br>If you also mean that all T's compare greater, then I'm not sure that
<br>sits too well with me. T is some type with a full "algebra" defin=
ed
<br>on it - ie functions that can be called on T, operators, etc. Tho=
se
<br>functions define Why do we think we can magically extend that alg=
ebra
<br>*correctly* for all T? Why don't we also try to change every func=
tion
<br>that takes a T into a similar function that takes an optional<T> =
? Why
<br>stop at operator<() ?
<br>
<br>
<br>Given some of the headaches involved with NaN, I'm also not sure which
<br>"side" of the discussion using it as an analogy promotes, but I think
<br>we should consider floating point numbers and NaN as another analogy
<br>of "all values of T ... plus None".
<br>
<br>NaN _does_ compare with any other float, but always returns false.
<br>
<br>I actually think that is philosophically correct, at least in the
<br>sense of "is NaN less than 3?" =3D> (for example) "is chair less tha=
n 3"
<br>=3D> is it true that "chair is less than 3"? No, it is not true. Nor=
is
<br>chair greater than 3.
<br>
<br>So I understand why NaN compares the way it does. Should
<br>optional<int>(nullopt) work the same as NaN?
<br>
<br>Or would it be better to say "is chair is less than 3" makes no sense
<br>=3D> ie should not compile. Quite possibly.
<br>
<br>ie (if any of the above made sense) I think that mixed relational
<br>comparison should either not compile ("doesn't make sense"), or should
<br>always return false (follow NaN rules).
</p></blockquote><div> </div><div>Note two things however. First, the =
comparison between two optionals already exists (in the proposal) and has n=
on-NaN aemantics (nullopt is just another value of T). Are you proposing to=
change this also?</div><div> </div><div>Second, the semantics of NaN =
make floating-point types not suitable for keys in tree-like container: bec=
ause there exists a value (NaN) that does not satisfy the axms of Strict We=
ak Ordering. In contrast, optional<int> and its operator< doe=
s implement Strict Weak Ordering.</div><div> </div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_85_24865217.1359068180649--
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Fri, 25 Jan 2013 12:38:38 +1100
Raw View
--f46d044794f793cc3304d412fc05
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
On Fri, Jan 25, 2013 at 9:48 AM, Andrzej Krzemie=F1ski <akrzemi1@gmail.com>=
wrote:
> W dniu czwartek, 24 stycznia 2013 22:21:43 UTC+1 u=BFytkownik Vladimir Ba=
tov
> napisa=B3:
>>
>> On Fri, Jan 25, 2013 at 8:13 AM, Fernando Cacciola
>> <fernando...@gmail.com> wrote:
>> > ...
>> > But then, what shall I do?
>>
>> Could you remind me what was wrong with your original (I think) idea
>> of having std::get_value_of a free-standing function but proposing it
>> as part (and in the context) of the optional?
>>
>
> It is very difficult (at least for me) to come up with the 'generic'
> version of get_value_or. While types optional<T>, shared_ptr<T> and T*
> share the same syntax with nearly the same semantics (I only refer to
> operator bool and operator*) there is one significant difference between
> optional<T> and all pointers. The former contains the "proxied" value. Th=
is
> means that its operator* propagates const-ness, while pointers' (smart or
> dumb) operator* does not. This complicates the implementation more than I
> would imagine. You need to distinguish the "classes" of NullableProxies:
> containing and non-containing.
>
> My impression was that we (Fernando and I) would not be able to come up
> with the robust proposal within the reasonably short amount of time, and
> providing a poor specification of generic get_value_or would cause harm.
> Therefore a member function get_value_or is a step towards the robust
> free-standing generic get_value_or in the future: we do not reserve the
> name in namespace std and anyone is able to propose a generic version if
> they know how. Instead we offer a tiny optional-specific convenience
> function. Because it is not generic, we know how to implement it. And my
> feeling is that et_value_or is needed far more frequently for optional th=
an
> for any other smart or dumb pointer.
>
Andrzej,
I admit that I find your explanation very convincing and on the "tactical"
one-class level I'd most likely come to that same conclusion to save myself
quite a bit of hassle. On the "strategic" architectural level though I feel
it is most likely to create an unfortunate precedent that will lead to that
approach proliferating in other classes. Just see how many times the
some-other-class-already-has-or-does-that "argument". As a result, it
seems, the library will suffer as a whole as a certain distinct concept is
not implemented in a proper orthogonal way but rather retrofitted into
every class... fully or partially. My personal (idealistic?) preference
would be to keep two groups -- optional et al and get_value_or and the
likes -- separate... like, say, various strings and string_algo. Stuffing
an algorithm into every string class looks like a horrible thing to do and
I find it difficult to reconcile with optional going down that path.
What Beman suggested makes a lot of sense to me. As far as get_value_of is
concerned, you are first here. You have the right of the first night, so to
speak. So, may I suggest, you propose what you feel is right for
optional... give some consideration to possible later extension... but do
not get hooked up on the "extensibility" part too much if it gets in your
way of moving forward as far as optional is concerned. When the time comes
to extend get_value_if, that concept will be considered in its own right
and then optional might need to be adjusted to reflect those requirements
and experiences. Does it make sense? Sorry, sounds like a lot of beating
around the bush without actually suggesting how to get out of there. :-)
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
--f46d044794f793cc3304d412fc05
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_quote">On Fri, Jan 25, 2013 at 9:48 AM, Andrzej Krzemie=
=F1ski <span dir=3D"ltr"><<a href=3D"mailto:akrzemi1@gmail.com" target=
=3D"_blank">akrzemi1@gmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
W dniu czwartek, 24 stycznia 2013 22:21:43 UTC+1 u=BFytkownik Vladimir Bato=
v napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Fri, Jan 25, 20=
13 at 8:13 AM, Fernando Cacciola
<br></div><div><<a>fernando...@gmail.com</a>> wrote:
<br>>
....<br>> But then, what shall I do?
<br>
<br>Could you remind me what was wrong with your original (I think) idea
<br>of having std::get_value_of a free-standing function but proposing it
<br>as part (and in the context) of the optional?
<br></div></blockquote><div><br>It is very difficult (at least for me) to c=
ome up with the 'generic' version of get_value_or. While types opti=
onal<T>, shared_ptr<T> and T* share the same syntax with nearly=
the same semantics (I only refer to operator bool and operator*) there is =
one significant difference between optional<T> and all pointers. The =
former contains the "proxied" value. This means that its operator=
* propagates const-ness, while pointers' (smart or dumb) operator* does=
not. This complicates the implementation more than I would imagine. You ne=
ed to distinguish the "classes" of NullableProxies: containing an=
d non-containing. <br>
<br>My impression was that we (Fernando and I) would not be able to come up=
with the robust proposal within the reasonably short amount of time, and p=
roviding a poor specification of generic get_value_or would cause harm. The=
refore a member function get_value_or is a step towards the robust free-sta=
nding generic get_value_or in the future: we do not reserve the name in nam=
espace std and anyone is able to propose a generic version if they know how=
.. Instead we offer a tiny optional-specific convenience function. Because i=
t is not generic, we know how to implement it. And my feeling is that et_va=
lue_or is needed far more frequently for optional than for any other smart =
or dumb pointer.<br>
</div></blockquote></div><br>Andrzej,<br><br>I admit that I find your expla=
nation very convincing and on the "tactical" one-class level I=
9;d most likely come to that same conclusion to save myself quite a bit of =
hassle. On the "strategic" architectural level though I feel it i=
s most likely to create an unfortunate precedent that will lead to that app=
roach proliferating in other classes. Just see how many times the some-othe=
r-class-already-has-or-does-that "argument". As a result, it seem=
s, the library will suffer as a whole as a certain distinct concept is not =
implemented in a proper orthogonal way but rather retrofitted into every cl=
ass... fully or partially. My personal (idealistic?) preference would be to=
keep two groups -- optional et al and get_value_or and the likes -- separa=
te... like, say, various strings and string_algo. Stuffing an algorithm int=
o every string class looks like a horrible thing to do and I find it diffic=
ult to reconcile with optional going down that path. <br>
<br>What Beman suggested makes a lot of sense to me. As far as get_value_of=
is concerned, you are first here. You have the right of the first night, s=
o to speak. So, may I suggest, you propose what you feel is right for optio=
nal... give some consideration to possible later extension... but do not ge=
t hooked up on the "extensibility" part too much if it gets in yo=
ur way of moving forward as far as optional is concerned. When the time com=
es to extend get_value_if, that concept will be considered in its own right=
and then optional might need to be adjusted to reflect those requirements =
and experiences. Does it make sense? Sorry, sounds like a lot of beating ar=
ound the bush without actually suggesting how to get out of there. :-)<br>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--f46d044794f793cc3304d412fc05--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Fri, 25 Jan 2013 00:35:27 -0300
Raw View
On Thu, Jan 24, 2013 at 9:34 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
>
>> > But even then we have a similar question:
>> >
>> > return optional<int>{nullopt} =3D=3D 1;
>> >
>> > Shall it return false or fail to compile? similarly:
>>
>> False, that's the whole point of this request, isn't it?
>
>
> I can see two reasonable answers here: either return false or fail to
> compile. Both answers have their merit.
>
Let's make sure not to confuse the question of having mixed
comparisons from the question of what the comparisons should do.
There is no doubt that
optional<T> relop T (or T relop optional<T> for that matter)
should do absolutely the same as
optional<T> relop optional<T>
whatever that is.
A different question is how to define the semantics of relational
operations among optionals (both implicit and explicit).
Regarding that, I like the definition that exist in boost::optional,
which happens to be what Daniel suggested (IIUC):
nullopt < engaged -> true
engaged < nullopt -> false
nullopt =3D=3D eganged -> false
engaged =3D=3D nullopt -> false
nulopt =3D=3D nullopt -> true
I noticed only now that this is different in the current
std::optional. IMO, this is a possible mistake, and I think the
semantics in boost::optional are better.
Best
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 25 Jan 2013 00:07:49 -0500
Raw View
On Thu, Jan 24, 2013 at 10:35 PM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> On Thu, Jan 24, 2013 at 9:34 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail=
..com> wrote:
>>
>>> > But even then we have a similar question:
>>> >
>>> > return optional<int>{nullopt} =3D=3D 1;
>>> >
>>> > Shall it return false or fail to compile? similarly:
>>>
>>> False, that's the whole point of this request, isn't it?
>>
>>
>> I can see two reasonable answers here: either return false or fail to
>> compile. Both answers have their merit.
>>
>
> Let's make sure not to confuse the question of having mixed
> comparisons from the question of what the comparisons should do.
>
> There is no doubt that
Really?
>
> optional<T> relop T (or T relop optional<T> for that matter)
>
> should do absolutely the same as
>
> optional<T> relop optional<T>
>
> whatever that is.
>
I think there have been doubts presented. Isn't there a suggestion
that optional<T> relop T not compile?
Maybe because T and optional<T> are not the same type?
Or do I misunderstand?
> A different question is how to define the semantics of relational
> operations among optionals (both implicit and explicit).
>
> Regarding that, I like the definition that exist in boost::optional,
> which happens to be what Daniel suggested (IIUC):
>
> nullopt < engaged -> true
>
> engaged < nullopt -> false
>
> nullopt =3D=3D eganged -> false
>
> engaged =3D=3D nullopt -> false
>
> nulopt =3D=3D nullopt -> true
>
> I noticed only now that this is different in the current
> std::optional. IMO, this is a possible mistake, and I think the
> semantics in boost::optional are better.
>
> Best
>
> --
> Fernando Cacciola
> SciSoft Consulting, Founder
> http://www.scisoft-consulting.com
>
> --
>
> ---
> 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.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propo=
sals/?hl=3Den.
>
>
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 25 Jan 2013 00:18:37 -0500
Raw View
On Thu, Jan 24, 2013 at 5:56 PM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
>>
>> So I understand why NaN compares the way it does. Should
>> optional<int>(nullopt) work the same as NaN?
>>
>> Or would it be better to say "is chair is less than 3" makes no sense
>> =3D> ie should not compile. Quite possibly.
>>
>> ie (if any of the above made sense) I think that mixed relational
>> comparison should either not compile ("doesn't make sense"), or should
>> always return false (follow NaN rules).
>
>
> Note two things however. First, the comparison between two optionals alre=
ady
> exists (in the proposal) and has non-NaN aemantics (nullopt is just anoth=
er
> value of T). Are you proposing to change this also?
>
I think optional<T> relop optional<T> is fine, with nullopt < T for all T.
I think that optional<T> reopt T is questionable.
One other difference with NaN is that (IIRC) NaN !=3D NaN. Whereas I
would expect optional<T>(nullopt) =3D=3D optional<T>(nullopt).
As for "proposing" - I'm rarely proposing or even suggesting a change.
More likely I am suggesting that we think about some other aspect or
think about the issue in another light. Sometimes I don't even agree
with myself, I just think it should be considered.
> Second, the semantics of NaN make floating-point types not suitable for k=
eys
> in tree-like container: because there exists a value (NaN) that does not
> satisfy the axms of Strict Weak Ordering. In contrast, optional<int> and =
its
> operator< does implement Strict Weak Ordering.
>
Yes, optional<> with Strict Weak Ordering is why I think optional<>
relopt optional<> is worthwhile - more for practical reasons than
philosophical, although I think it is also philosophically sound.
But optional<T> relopt T might be best poisoned.
Tony
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 25 Jan 2013 00:46:38 -0500
Raw View
On Wed, Jan 23, 2013 at 1:06 PM, Zhihao Yuan <lichray@gmail.com> wrote:
>
> Besides, the _naming_ of get_value_or is somewhat misleading.
> People tend to read it like "get value, or doing something", which
> result in a request of `get_value_or([]{...})`. Since .value() with an
> exception is a nice naming, maybe we can rename `get_value_or`
> into just `value_or`.
>
> So
> opt.value() + exception
> opt() + exception
> opt.value_or(fallback);
>
I like value_or(). The get seemed redundant. What to go one step further?
optional<T> foo = ...
T t = foo.or(17);
Or is 'or', even in this context, converted to '||'?
foo.else(17) ? :-)
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 25 Jan 2013 00:52:24 -0500
Raw View
On Wed, Jan 23, 2013 at 3:49 PM, Vladimir Batov <vb.mail.247@gmail.com> wrote:
> On Thu, Jan 24, 2013 at 2:54 AM, Tony V E <tvaneerd@gmail.com> wrote:
>> On Wed, Jan 23, 2013 at 9:00 AM, Ville Voutilainen
>> ...
>> And if you had
>> optional<functionlike> fn;
>> fn(some, params);
>> I might think it was calling operator() on the contained value.
>> ie
>> fn(emplace, foo)
>> vs
>> (*fn)(emplace, foo)
>> Who would recognize those as completely different?
>
> Uhm, everyone?... They look different and they do different things...
true, however:
- alternatively, fn(params) could std::forward the params to the
callable, when wrapping callables. (Not saying this is necessarily a
good idea, but if you want the optional<T> to act like T, then that
would be the result.) Making fn(emplace, foo) potentially ambiguous.
- they mean the same when fn is a pointer-to-function.
- you may work with some better programmers than I have :-)
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Fri, 25 Jan 2013 01:14:49 -0800 (PST)
Raw View
------=_Part_30_14178919.1359105289697
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu pi=B1tek, 25 stycznia 2013 04:35:27 UTC+1 u=BFytkownik Fernando Cacc=
iola=20
napisa=B3:
>
> On Thu, Jan 24, 2013 at 9:34 AM, Andrzej Krzemie=F1ski <akrz...@gmail.com=
<javascript:>>=20
> wrote:=20
> >=20
> >> > But even then we have a similar question:=20
> >> >=20
> >> > return optional<int>{nullopt} =3D=3D 1;=20
> >> >=20
> >> > Shall it return false or fail to compile? similarly:=20
> >>=20
> >> False, that's the whole point of this request, isn't it?=20
> >=20
> >=20
> > I can see two reasonable answers here: either return false or fail to=
=20
> > compile. Both answers have their merit.=20
> >=20
>
> Let's make sure not to confuse the question of having mixed=20
> comparisons from the question of what the comparisons should do.=20
>
> There is no doubt that=20
>
> optional<T> relop T (or T relop optional<T> for that matter)=20
>
> should do absolutely the same as=20
>
> optional<T> relop optional<T>=20
>
> whatever that is.=20
>
> A different question is how to define the semantics of relational=20
> operations among optionals (both implicit and explicit).=20
>
> Regarding that, I like the definition that exist in boost::optional,=20
> which happens to be what Daniel suggested (IIUC):=20
>
> nullopt < engaged -> true=20
>
> engaged < nullopt -> false=20
>
> nullopt =3D=3D eganged -> false=20
>
> engaged =3D=3D nullopt -> false=20
>
> nulopt =3D=3D nullopt -> true=20
>
> I noticed only now that this is different in the current=20
> std::optional. IMO, this is a possible mistake, and I think the=20
> semantics in boost::optional are better.=20
>
The intention was for std::optional to provide the same relop semantics as=
=20
boost::optional. If this is not the case, it is a bug in the proposal.=20
However, when I look at the proposal I cannot tell the difference from the=
=20
boost::optional semantics highlighted above. Quoting the wording from the=
=20
proposal:
bool operator=3D=3D(const optional<T>& x, const optional<T>& y);
Returns:
If bool(x) !=3D bool(y), false; otherwise if bool(x) =3D=3D false, true;=20
otherwise *x =3D=3D *y.
I think it covers the expectations:
nullopt =3D=3D eganged -> false=20
engaged =3D=3D nullopt -> false=20
nulopt =3D=3D nullopt -> true=20
Similarly for LessThan relation:
bool operator<(const optional<T>& x, const optional<T>& y);
Returns:
If (!y), false; otherwise, if (!x), true; otherwise *x < *y.
The following expectations do hold:
engaged < nullopt -> false=20
nullopt < engaged -> true=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_30_14178919.1359105289697
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu pi=B1tek, 25 stycznia 2013 04:35:27 UTC+1 u=BFytkownik Ferna=
ndo Cacciola napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thu,=
Jan 24, 2013 at 9:34 AM, Andrzej Krzemie=F1ski <<a href=3D"javascript:"=
target=3D"_blank" gdf-obfuscated-mailto=3D"1zY0qLyn0sgJ">akrz...@gmail.com=
</a>> wrote:
<br>>
<br>>> > But even then we have a similar question:
<br>>> >
<br>>> > return optional<int>{nullopt} =3D=3D 1;
<br>>> >
<br>>> > Shall it return false or fail to compile? similarly:
<br>>>
<br>>> False, that's the whole point of this request, isn't it?
<br>>
<br>>
<br>> I can see two reasonable answers here: either return false or fail=
to
<br>> compile. Both answers have their merit.
<br>>
<br>
<br>Let's make sure not to confuse the question of having mixed
<br>comparisons from the question of what the comparisons should do.
<br>
<br>There is no doubt that
<br>
<br>optional<T> relop T (or T relop optional<T> for that matter=
)
<br>
<br>should do absolutely the same as
<br>
<br>optional<T> relop optional<T>
<br>
<br>whatever that is.
<br>
<br>A different question is how to define the semantics of relational
<br>operations among optionals (both implicit and explicit).
<br>
<br>Regarding that, I like the definition that exist in boost::optional,
<br>which happens to be what Daniel suggested (IIUC):
<br>
<br>nullopt < engaged -> true
<br>
<br>engaged < nullopt -> false
<br>
<br>nullopt =3D=3D eganged -> false
<br>
<br>engaged =3D=3D nullopt -> false
<br>
<br>nulopt =3D=3D nullopt -> true
<br>
<br>I noticed only now that this is different in the current
<br>std::optional. IMO, this is a possible mistake, and I think the
<br>semantics in boost::optional are better.
<br></blockquote><div><br></div><div>The intention was for std::optional to=
provide the same relop semantics as boost::optional. If this is not the ca=
se, it is a bug in the proposal. However, when I look at the proposal I can=
not tell the difference from the boost::optional semantics highlighted=
above. Quoting the wording from the proposal:</div><div><br></div><di=
v><p class=3D"function" style=3D"font-size: medium; line-height: normal; co=
lor: rgb(0, 0, 0); font-family: 'Times New Roman';"><code>bool operator=3D=
=3D(const optional<T>& x, const optional<T>& y);</code>=
</p><dl class=3D"attribute" style=3D"margin-left: 2em; color: rgb(0, 0, 0);=
font-family: 'Times New Roman'; font-size: medium;"><dt style=3D"padding-r=
ight: 1ex; float: left; font-style: italic;">Returns:</dt><dd style=3D"marg=
in-left: 0em;"><p>If <code>bool(x) !=3D bool(y)</code>, <code>fal=
se</code>; otherwise if <code>bool(x) =3D=3D false</code>, <code>=
true</code>; otherwise <code>*x =3D=3D *y</code>.</p></dd></dl></div><=
div><br></div><div>I think it covers the expectations:</div><div><br></div>=
<div> nullopt =3D=3D eganged -> false <br> engaged =3D=3D=
nullopt -> false <br> nulopt =3D=3D nullopt -> true <=
br></div><div><br></div><div>Similarly for LessThan relation:</div><div><br=
></div><div><p class=3D"function" style=3D"font-size: medium; line-height: =
normal; color: rgb(0, 0, 0); font-family: 'Times New Roman';"><code>bool op=
erator<(const optional<T>& x, const optional<T>& y);=
</code></p><dl class=3D"attribute" style=3D"margin-left: 2em; color: rgb(0,=
0, 0); font-family: 'Times New Roman'; font-size: medium;"><dt style=3D"pa=
dding-right: 1ex; float: left; font-style: italic;">Returns:</dt><dd style=
=3D"margin-left: 0em;"><p>If <code>(!y)</code>, <code>false</code=
>; otherwise, if <code>(!x)</code>, <code>true</code>; otherwise&=
nbsp;<code>*x < *y</code>.</p></dd></dl></div><div>The following expecta=
tions do hold:</div><div> engaged < nullopt -> false <br></=
div><div> nullopt < engaged -> true <br><br></div><div><br>=
</div><div><p class=3D"function" style=3D"color: rgb(0, 0, 0); font-family:=
'Times New Roman'; font-size: medium; line-height: normal;"><br></p></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_30_14178919.1359105289697--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Fri, 25 Jan 2013 01:17:21 -0800 (PST)
Raw View
------=_Part_412_9513884.1359105441174
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu pi=B1tek, 25 stycznia 2013 06:46:38 UTC+1 u=BFytkownik Tony V E napi=
sa=B3:
>
> On Wed, Jan 23, 2013 at 1:06 PM, Zhihao Yuan <lic...@gmail.com<javascript=
:>>=20
> wrote:=20
> >=20
> > Besides, the _naming_ of get_value_or is somewhat misleading.=20
> > People tend to read it like "get value, or doing something", which=20
> > result in a request of `get_value_or([]{...})`. Since .value() with an=
=20
> > exception is a nice naming, maybe we can rename `get_value_or`=20
> > into just `value_or`.=20
> >=20
> > So=20
> > opt.value() + exception=20
> > opt() + exception=20
> > opt.value_or(fallback);=20
> >=20
>
> I like value_or(). The get seemed redundant. What to go one step=20
> further?=20
>
> optional<T> foo =3D ...=20
>
> T t =3D foo.or(17);=20
>
> Or is 'or', even in this context, converted to '||'?=20
>
> foo.else(17) ? :-)=20
>
At some point someone even suggested overloading operator ||:
T t =3D foo || 17;
But this is more like a funny fact. We are not proposing it.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_412_9513884.1359105441174
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu pi=B1tek, 25 stycznia 2013 06:46:38 UTC+1 u=BFytkownik Tony =
V E napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wed, Jan 23, =
2013 at 1:06 PM, Zhihao Yuan <<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"71pu32TSm5gJ">lic...@gmail.com</a>> wrote:
<br>>
<br>> Besides, the _naming_ of get_value_or is somewhat misleading.
<br>> People tend to read it like "get value, or doing something", which
<br>> result in a request of `get_value_or([]{...})`. Since .value=
() with an
<br>> exception is a nice naming, maybe we can rename `get_value_or`
<br>> into just `value_or`.
<br>>
<br>> So
<br>> opt.value() + exception
<br>> opt() + exception
<br>> opt.value_or(fallback);
<br>>
<br>
<br>I like value_or(). The get seemed redundant. What to go one=
step further?
<br>
<br>optional<T> foo =3D ...
<br>
<br>T t =3D foo.or(17);
<br>
<br>Or is 'or', even in this context, converted to '||'?
<br>
<br>foo.else(17) ? :-)
<br></blockquote><div><br></div><div>At some point someone even suggested o=
verloading operator ||:<br><div style=3D"background-color: rgb(250, 250, 25=
0); border: 1px solid rgb(187, 187, 187); word-wrap: break-word;" class=3D"=
prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">T t </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> foo </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">||</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"s=
tyled-by-prettify">17</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span></div></code></div><br></div><div>But this is more like a funn=
y fact. We are not proposing it.</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_412_9513884.1359105441174--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Fri, 25 Jan 2013 01:37:00 -0800 (PST)
Raw View
------=_Part_441_7273357.1359106620450
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu pi=B1tek, 25 stycznia 2013 02:38:38 UTC+1 u=BFytkownik Vladimir Bato=
v=20
napisa=B3:
>
> On Fri, Jan 25, 2013 at 9:48 AM, Andrzej Krzemie=F1ski <akrz...@gmail.com=
<javascript:>
> > wrote:
>
>> W dniu czwartek, 24 stycznia 2013 22:21:43 UTC+1 u=BFytkownik Vladimir=
=20
>> Batov napisa=B3:
>>>
>>> On Fri, Jan 25, 2013 at 8:13 AM, Fernando Cacciola=20
>>> <fernando...@gmail.com> wrote:=20
>>> > ...
>>> > But then, what shall I do?=20
>>>
>>> Could you remind me what was wrong with your original (I think) idea=20
>>> of having std::get_value_of a free-standing function but proposing it=
=20
>>> as part (and in the context) of the optional?=20
>>>
>>
>> It is very difficult (at least for me) to come up with the 'generic'=20
>> version of get_value_or. While types optional<T>, shared_ptr<T> and T*=
=20
>> share the same syntax with nearly the same semantics (I only refer to=20
>> operator bool and operator*) there is one significant difference between=
=20
>> optional<T> and all pointers. The former contains the "proxied" value. T=
his=20
>> means that its operator* propagates const-ness, while pointers' (smart o=
r=20
>> dumb) operator* does not. This complicates the implementation more than =
I=20
>> would imagine. You need to distinguish the "classes" of NullableProxies:=
=20
>> containing and non-containing.=20
>>
>> My impression was that we (Fernando and I) would not be able to come up=
=20
>> with the robust proposal within the reasonably short amount of time, and=
=20
>> providing a poor specification of generic get_value_or would cause harm.=
=20
>> Therefore a member function get_value_or is a step towards the robust=20
>> free-standing generic get_value_or in the future: we do not reserve the=
=20
>> name in namespace std and anyone is able to propose a generic version if=
=20
>> they know how. Instead we offer a tiny optional-specific convenience=20
>> function. Because it is not generic, we know how to implement it. And my=
=20
>> feeling is that et_value_or is needed far more frequently for optional t=
han=20
>> for any other smart or dumb pointer.
>>
>
> Andrzej,
>
> I admit that I find your explanation very convincing and on the "tactical=
"=20
> one-class level I'd most likely come to that same conclusion to save myse=
lf=20
> quite a bit of hassle. On the "strategic" architectural level though I fe=
el=20
> it is most likely to create an unfortunate precedent that will lead to th=
at=20
> approach proliferating in other classes. Just see how many times the=20
> some-other-class-already-has-or-does-that "argument". As a result, it=20
> seems, the library will suffer as a whole as a certain distinct concept i=
s=20
> not implemented in a proper orthogonal way but rather retrofitted into=20
> every class... fully or partially. My personal (idealistic?) preference=
=20
> would be to keep two groups -- optional et al and get_value_or and the=20
> likes -- separate... like, say, various strings and string_algo. Stuffing=
=20
> an algorithm into every string class looks like a horrible thing to do an=
d=20
> I find it difficult to reconcile with optional going down that path.=20
>
> What Beman suggested makes a lot of sense to me. As far as get_value_of i=
s=20
> concerned, you are first here. You have the right of the first night, so =
to=20
> speak. So, may I suggest, you propose what you feel is right for=20
> optional... give some consideration to possible later extension... but do=
=20
> not get hooked up on the "extensibility" part too much if it gets in your=
=20
> way of moving forward as far as optional is concerned. When the time come=
s=20
> to extend get_value_if, that concept will be considered in its own right=
=20
> and then optional might need to be adjusted to reflect those requirements=
=20
> and experiences. Does it make sense? Sorry, sounds like a lot of beating=
=20
> around the bush without actually suggesting how to get out of there. :-)
>
Well -- I hope I understood you -- it does make sense. It is just that I=20
believe we are already going down this path.=20
Regarding get_value_or (now renamed to value_or), the whole point of making=
=20
it optional-specific member function, with optional-specific semantics=20
(like return by value) is to leave room for future generic function.
Regarding functions like get_pointer, I didn't have the chance to express=
=20
my opinion yet. Given my usage experience with boost::optional (I use it a=
=20
lot, this is the most busy Boost library in my work), I never needed to=20
convert an optional object to a pointer, therefore I am fine with not=20
providing it as member function right now, and leaving the generalized=20
version for the future.
In fact, never in my work did I have to use get_value_or either. I use=20
optional references more often than get_value_or. As Robert Ramey pointed=
=20
out, the whole purpose of returning optional<T> is to force the caller to=
=20
examine two different possibilities and fork two different control paths.=
=20
get_value_or is somehow against this idea. I guess it is used to glue two=
=20
interfaces with different philosophies.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_441_7273357.1359106620450
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu pi=B1tek, 25 stycznia 2013 02:38:38 UTC+1 u=BFytkownik Vladi=
mir Batov napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div class=
=3D"gmail_quote">On Fri, Jan 25, 2013 at 9:48 AM, Andrzej Krzemie=F1ski <sp=
an dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated=
-mailto=3D"z8luFgzpFLwJ">akrz...@gmail.com</a>></span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
W dniu czwartek, 24 stycznia 2013 22:21:43 UTC+1 u=BFytkownik Vladimir Bato=
v napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Fri, Jan 25, 20=
13 at 8:13 AM, Fernando Cacciola
<br></div><div><<a>fernando...@gmail.com</a>> wrote:
<br>>
....<br>> But then, what shall I do?
<br>
<br>Could you remind me what was wrong with your original (I think) idea
<br>of having std::get_value_of a free-standing function but proposing it
<br>as part (and in the context) of the optional?
<br></div></blockquote><div><br>It is very difficult (at least for me) to c=
ome up with the 'generic' version of get_value_or. While types optional<=
T>, shared_ptr<T> and T* share the same syntax with nearly the sam=
e semantics (I only refer to operator bool and operator*) there is one sign=
ificant difference between optional<T> and all pointers. The former c=
ontains the "proxied" value. This means that its operator* propagates const=
-ness, while pointers' (smart or dumb) operator* does not. This complicates=
the implementation more than I would imagine. You need to distinguish the =
"classes" of NullableProxies: containing and non-containing. <br>
<br>My impression was that we (Fernando and I) would not be able to come up=
with the robust proposal within the reasonably short amount of time, and p=
roviding a poor specification of generic get_value_or would cause harm. The=
refore a member function get_value_or is a step towards the robust free-sta=
nding generic get_value_or in the future: we do not reserve the name in nam=
espace std and anyone is able to propose a generic version if they know how=
.. Instead we offer a tiny optional-specific convenience function. Because i=
t is not generic, we know how to implement it. And my feeling is that et_va=
lue_or is needed far more frequently for optional than for any other smart =
or dumb pointer.<br>
</div></blockquote></div><br>Andrzej,<br><br>I admit that I find your expla=
nation very convincing and on the "tactical" one-class level I'd most likel=
y come to that same conclusion to save myself quite a bit of hassle. On the=
"strategic" architectural level though I feel it is most likely to create =
an unfortunate precedent that will lead to that approach proliferating in o=
ther classes. Just see how many times the some-other-class-already-has-<wbr=
>or-does-that "argument". As a result, it seems, the library will suffer as=
a whole as a certain distinct concept is not implemented in a proper ortho=
gonal way but rather retrofitted into every class... fully or partially. My=
personal (idealistic?) preference would be to keep two groups -- optional =
et al and get_value_or and the likes -- separate... like, say, various stri=
ngs and string_algo. Stuffing an algorithm into every string class looks li=
ke a horrible thing to do and I find it difficult to reconcile with optiona=
l going down that path. <br>
<br>What Beman suggested makes a lot of sense to me. As far as get_value_of=
is concerned, you are first here. You have the right of the first night, s=
o to speak. So, may I suggest, you propose what you feel is right for optio=
nal... give some consideration to possible later extension... but do not ge=
t hooked up on the "extensibility" part too much if it gets in your way of =
moving forward as far as optional is concerned. When the time comes to exte=
nd get_value_if, that concept will be considered in its own right and then =
optional might need to be adjusted to reflect those requirements and experi=
ences. Does it make sense? Sorry, sounds like a lot of beating around the b=
ush without actually suggesting how to get out of there. :-)<br></blockquot=
e><div><br>Well -- I hope I understood you -- it does make sense. It is jus=
t that I believe we are already going down this path. <br><br>Regarding get=
_value_or (now renamed to value_or), the whole point of making it optional-=
specific member function, with optional-specific semantics (like return by =
value) is to leave room for future generic function.<br><br>Regarding funct=
ions like get_pointer, I didn't have the chance to express my opinion yet. =
Given my usage experience with boost::optional (I use it a lot, this is the=
most busy Boost library in my work), I never needed to convert an optional=
object to a pointer, therefore I am fine with not providing it as member f=
unction right now, and leaving the generalized version for the future.<br><=
br>In fact, never in my work did I have to use get_value_or either. I use o=
ptional references more often than get_value_or. As Robert Ramey pointed ou=
t, the whole purpose of returning optional<T> is to force the caller =
to examine two different possibilities and fork two different control paths=
.. get_value_or is somehow against this idea. I guess it is used to glue two=
interfaces with different philosophies.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_441_7273357.1359106620450--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Fri, 25 Jan 2013 01:48:16 -0800 (PST)
Raw View
------=_Part_486_18116855.1359107296759
Content-Type: text/plain; charset=ISO-8859-1
> Yes, optional<> with Strict Weak Ordering is why I think optional<>
> relopt optional<> is worthwhile - more for practical reasons than
> philosophical, although I think it is also philosophically sound.
>
> But optional<T> relopt T might be best poisoned.
>
Let me just add one thought atop of what you said. Given that we have an
implicit conversion from T to optional<T>, the semantics of optional<T>
relopt T becomes "natural". This is why we are discussing the poisoning
rather than not introducing additional relop functions. For this reason I
consider either poisoning the mixed relops or giving them the "natural"
semantics by simply not poisoning them. Mixed relops with NaN like
semantics are not acceptable for me for the above reason.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_486_18116855.1359107296759
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">Yes, optional<> with=
Strict Weak Ordering is why I think optional<>
<br>relopt optional<> is worthwhile - more for practical reasons than
<br>philosophical, although I think it is also philosophically sound.
<br>
<br>But optional<T> relopt T might be best poisoned.
<br></blockquote><div><br>Let me just add one thought atop of what you said=
.. Given that we have an implicit conversion from T to optional<T>, th=
e semantics of optional<T> relopt T becomes "natural". This is why we=
are discussing the poisoning rather than not introducing additional relop =
functions. For this reason I consider either poisoning the mixed relops or =
giving them the "natural" semantics by simply not poisoning them. Mixed rel=
ops with NaN like semantics are not acceptable for me for the above reason.=
<br><br><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_486_18116855.1359107296759--
.
Author: Cassio Neri <cassio.neri@gmail.com>
Date: Fri, 25 Jan 2013 04:06:29 -0800 (PST)
Raw View
------=_Part_609_31192899.1359115589786
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, January 25, 2013 9:48:16 AM UTC, Andrzej Krzemie=C5=84ski wrote:
>
> Let me just add one thought atop of what you said. Given that we have an=
=20
> implicit conversion from T to optional<T>, the semantics of optional<T>=
=20
> relopt T becomes "natural". This is why we are discussing the poisoning=
=20
> rather than not introducing additional relop functions. For this reason I=
=20
> consider either poisoning the mixed relops or giving them the "natural"=
=20
> semantics by simply not poisoning them. Mixed relops with NaN like=20
> semantics are not acceptable for me for the above reason.=20
>
> Hi guys,
There are orthogonal questions regarding the comparison operators (Are mixe=
d
comparisons allowed? How does a disengaged optional<T> compares with other
objects?) I tried to formalize the problem, taking into account the ideas
proposed so far. I believe this can help defining a strategy for the
proposal and set some terminology. Although I'm bad with naming, I suggest
we keep the terminology below for the moment just to avoid bike shed
discussions. We can revisit it later if you believe a terminology is indeed
required but mine is not appropriate.
Let T be a type. For simplicity, we assume that T supports all comparisons
(=3D=3D, !=3D, <, <=3D, >, >=3D) but it might support only a subset of them=
..
Let:
val be a T
opt be a optional<T> (engaged or not)
dis be a disengaged optional<T>
eng, eng2 be engaged optional<T>s
a and b be any of the above
@ be any of =3D=3D, !=3D, <, <=3D, >, >=3D.
I believe the following property is a consensus:
* Extension : (eng @ eng2) =3D=3D (*eng @ *eng2)
Consider also the following property:
* Redundancy :
(a !=3D b) =3D=3D !(a =3D=3D b)
(a > b) =3D=3D (b < a)
(a <=3D b) =3D=3D !(b < a)
(a >=3D b) =3D=3D !(a < b)
We have two orthogonal set of policies:
=20
1) Mixed comparison policies:
* Poisoned mixed comparison : (opt @ val) is ill formed
* Allowed mixed comparison : (eng @ val) =3D=3D (*eng @ val)
2) Disengaged comparison policies:
* Minimal disengaged :
(dis =3D=3D dis) =3D=3D true
(dis < eng) =3D=3D true
(dis < dis) =3D=3D false
+ Redundancy
=20
* Maximal disengaged :
(dis =3D=3D dis) =3D=3D true
(eng < dis) =3D=3D true
(dis < dis) =3D=3D false
+ Redundancy
=20
* Strong NaN :
(dis @ dis) =3D=3D false
(dis @ eng) =3D=3D false
=20
* Weak NaN :
(dis =3D=3D dis) =3D=3D true
(dis !=3D dis) =3D=3D false =20
(dis @ eng) =3D=3D false
Except from the Extension property above, nothing else seems to be a
consensus.
The proposal can either:
1) Drop comparisons altogether.
2) Decide a set of policies above. For instance, "Allowed mixed comparison"
+ "Minimal Disengaged".
3) Add a template parameter to optional which comparisons are delegated to:
template <
typename T,
typename ComparisonPolicy =3D default_comparison_policy<T>
>
class optional {
...
};
template <typename T, typename CP>
bool operator <(const optional<T, CP>& a, const optional<T, CP>& b) {
return CP::operator <(a, b);
}
template <typename T, typename CP>
bool operator <(const T& a, const optional<T, CP>& b) {
return CP::operator <(a, b);
}
template <typename T, typename CP>
bool operator <(const optional<T, CP>& a, const T& b) {
return CP::operator <(a, b);
}
In addition the proposal would define the ComparisonPolicy concept and
specify one implementation, default_comparison_policy, which would be the
default. Users could define and use their own.
4) Add two template parameter options to optional to allow for fine tuning
of the policies:
template <
typename T,
typename MixedComparisonPolicy =3D default_mixed_comparison_policy<T>
typename DisengagedComparisonPolicy =3D=20
default_disengaged_comparison_policy<T>
>
class optional {
...
};
// Implementations of operator < using the two policies. I guess this is
feasible.
My opinion is that 1) and 2) are very strict. 3 is my favorite. 4 is too
much.
HTH
Cassio.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_609_31192899.1359115589786
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, January 25, 2013 9:48:16 AM UTC, Andrzej Krzemie=C5=84ski wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">Let me just add one thought at=
op of what you said. Given that we have an implicit conversion from T to op=
tional<T>, the semantics of optional<T> relopt T becomes "natur=
al". This is why we are discussing the poisoning rather than not introducin=
g additional relop functions. For this reason I consider either poisoning t=
he mixed relops or giving them the "natural" semantics by simply not poison=
ing them. Mixed relops with NaN like semantics are not acceptable for me fo=
r the above reason. <br><div><br></div></blockquote><div>Hi guys,<br><br>Th=
ere are orthogonal questions regarding the comparison operators (Are mixed<=
br>comparisons allowed? How does a disengaged optional<T> compares wi=
th other<br>objects?) I tried to formalize the problem, taking into account=
the ideas<br>proposed so far. I believe this can help defining a strategy =
for the<br>proposal and set some terminology. Although I'm bad with naming,=
I suggest<br>we keep the terminology below for the moment just to avoid bi=
ke shed<br>discussions. We can revisit it later if you believe a terminolog=
y is indeed<br>required but mine is not appropriate.<br><br>Let T be a type=
.. For simplicity, we assume that T supports all comparisons<br>(=3D=3D, !=
=3D, <, <=3D, >, >=3D) but it might support only a subset of th=
em.<br><br>Let:<br><br>val be a T<br>opt be a optional<T> (engaged or=
not)<br>dis be a disengaged optional<T><br>eng, eng2 be engaged opti=
onal<T>s<br>a and b be any of the above<br>@ be any of =3D=3D, !=3D, =
<, <=3D, >, >=3D.<br><br>I believe the following property is a =
consensus:<br><br>* Extension : (eng @ eng2) =3D=3D (*eng @ *eng2)<br><br>C=
onsider also the following property:<br><br>* Redundancy :<br> (a !=
=3D b) =3D=3D !(a =3D=3D b)<br> (a > b) =3D=3D (b < a)<br> =
; (a <=3D b) =3D=3D !(b < a)<br> (a >=3D b) =3D=3D !(a < =
b)<br><br>We have two orthogonal set of policies:<br> <br>1) Mixed com=
parison policies:<br><br>* Poisoned mixed comparison : (opt @ val) is ill f=
ormed<br><br>* Allowed mixed comparison : (eng @ val) =3D=3D (*eng @ =
val)<br><br>2) Disengaged comparison policies:<br><br>* Minimal disengaged =
:<br> (dis =3D=3D dis) =3D=3D true<br> (dis < eng) =3D=3D tr=
ue<br> (dis < dis) =3D=3D false<br> + Redundancy<br> <b=
r>* Maximal disengaged :<br> (dis =3D=3D dis) =3D=3D true<br> (=
eng < dis) =3D=3D true<br> (dis < dis) =3D=3D false<br> +=
Redundancy<br> <br>* Strong NaN :<br> (dis @ dis) =3D=3D false<=
br> (dis @ eng) =3D=3D false<br> <br>* Weak NaN :<br> (dis=
=3D=3D dis) =3D=3D true<br> (dis !=3D dis) =3D=3D false <br>&n=
bsp; (dis @ eng) =3D=3D false<br><br>Except from the Extension property abo=
ve, nothing else seems to be a<br>consensus.<br><br>The proposal can either=
:<br><br>1) Drop comparisons altogether.<br><br>2) Decide a set of policies=
above. For instance, "Allowed mixed comparison"<br>+ "Minimal Disengaged".=
<br><br>3) Add a template parameter to optional which comparisons are deleg=
ated to:<br><br>template <<br> typename T,<br> typename Comp=
arisonPolicy =3D default_comparison_policy<T><br>><br>class option=
al {<br> ...<br>};<br><br>template <typename T, typename CP><br=
>bool operator <(const optional<T, CP>& a, const optional<T=
, CP>& b) {<br> return CP::operator <(a, b);<br>}<br><br>te=
mplate <typename T, typename CP><br>bool operator <(const T& a=
, const optional<T, CP>& b) {<br> return CP::operator <(=
a, b);<br>}<br><br>template <typename T, typename CP><br>bool operato=
r <(const optional<T, CP>& a, const T& b) {<br> retu=
rn CP::operator <(a, b);<br>}<br><br>In addition the proposal would defi=
ne the ComparisonPolicy concept and<br>specify one implementation, default_=
comparison_policy, which would be the<br>default. Users could define and us=
e their own.<br><br>4) Add two template parameter options to optional to al=
low for fine tuning<br>of the policies:<br><br>template <<br> type=
name T,<br> typename MixedComparisonPolicy =3D default_mixed_comparis=
on_policy<T><br> typename DisengagedComparisonPolicy =3D defaul=
t_disengaged_comparison_policy<T><br>><br>class optional {<br>&nbs=
p; ...<br>};<br><br>// Implementations of operator < using the two polic=
ies. I guess this is<br>feasible.<br><br>My opinion is that 1) and 2) are v=
ery strict. 3 is my favorite. 4 is too<br>much.<br><br>HTH<br>Cassio.<br><b=
r></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_609_31192899.1359115589786--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Fri, 25 Jan 2013 10:21:52 -0300
Raw View
On Fri, Jan 25, 2013 at 3:07 AM, Tony V E <tvaneerd@gmail.com> wrote:
>
> I think there have been doubts presented. Isn't there a suggestion
> that optional<T> relop T not compile?
> Maybe because T and optional<T> are not the same type?
>
> Or do I misunderstand?
>
Oh.. I wasn't clear.
I meant that, if it compiles, there is no doubt that it should do the
same as the comparison of proper optionals.
(not that there is no doubt it should compile)
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Fri, 25 Jan 2013 10:25:30 -0300
Raw View
On Fri, Jan 25, 2013 at 3:18 AM, Tony V E <tvaneerd@gmail.com> wrote:
> On Thu, Jan 24, 2013 at 5:56 PM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail=
..com> wrote:
>>>
>>> So I understand why NaN compares the way it does. Should
>>> optional<int>(nullopt) work the same as NaN?
>>>
>>> Or would it be better to say "is chair is less than 3" makes no sense
>>> =3D> ie should not compile. Quite possibly.
>>>
>>> ie (if any of the above made sense) I think that mixed relational
>>> comparison should either not compile ("doesn't make sense"), or should
>>> always return false (follow NaN rules).
>>
>>
>> Note two things however. First, the comparison between two optionals alr=
eady
>> exists (in the proposal) and has non-NaN aemantics (nullopt is just anot=
her
>> value of T). Are you proposing to change this also?
>>
>
> I think optional<T> relop optional<T> is fine, with nullopt < T for all T=
..
> I think that optional<T> reopt T is questionable.
>
OK, why?
When Andrzej and I started working on this, we discussed it and I
recall very well that he convinced me that it is better to disallow
mixed comparisons, but I don't remember why now :)
So, what are your reasons?
> One other difference with NaN is that (IIRC) NaN !=3D NaN.
Right. Which is why you have to isnan(). Not very useful IMO and I
don't recall ever reading a rationale for such behavior.
> Whereas I
> would expect optional<T>(nullopt) =3D=3D optional<T>(nullopt).
>
Indeed. That's how it is proposed.
Best
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Fri, 25 Jan 2013 10:28:16 -0300
Raw View
On Fri, Jan 25, 2013 at 7:14 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
>
> The intention was for std::optional to provide the same relop semantics a=
s
> boost::optional. If this is not the case, it is a bug in the proposal.
> However, when I look at the proposal I cannot tell the difference from th=
e
> boost::optional semantics highlighted above.
Sorry, my bad.
When I re-read the separate section about comparisons against nullopt,
I got it backwards.
Best
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Fri, 25 Jan 2013 10:31:26 -0300
Raw View
On Fri, Jan 25, 2013 at 7:48 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
>
>> Yes, optional<> with Strict Weak Ordering is why I think optional<>
>> relopt optional<> is worthwhile - more for practical reasons than
>> philosophical, although I think it is also philosophically sound.
>>
>> But optional<T> relopt T might be best poisoned.
>
>
> Let me just add one thought atop of what you said. Given that we have an
> implicit conversion from T to optional<T>, the semantics of optional<T>
> relopt T becomes "natural". This is why we are discussing the poisoning
> rather than not introducing additional relop functions. For this reason I
> consider either poisoning the mixed relops or giving them the "natural"
> semantics by simply not poisoning them.
Right.
Can you remind me why you thought it was better to disallow mixed
comparisons? I remember I agreed with you but now I can't think of why
:)
Best
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Fri, 25 Jan 2013 10:33:29 -0300
Raw View
On Fri, Jan 25, 2013 at 10:06 AM, Cassio Neri <cassio.neri@gmail.com> wrote:
Good summary. I think it captured well the choices and the current
state of the discussion.
>
> My opinion is that 1) and 2) are very strict. 3 is my favorite. 4 is too
> much.
>
We ruled out any policy-based design so (3) is not an option.
Please look at the past discussion for the reasons.
Best
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Vincent Jacquet <vjacquet@flowgroup.fr>
Date: Fri, 25 Jan 2013 06:26:06 -0800 (PST)
Raw View
------=_Part_716_2756393.1359123966542
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi,
If I understand correctly, this proposal addresses two different problems:=
=20
nullable types and lazy intialization (advanced use case section).
I have been working with another language that address these issues with 2=
=20
different objects: Nullable<T> and Lazy<T>. The former can be explicity=20
converted to T and throws if it wasn't initialized. You cannot do that with=
=20
the second but you can specify initialization strategies for the latter=20
when used concurrently from several threads.
Did you considered addressing those issues separatly and, if you did, why=
=20
did you choose to define a single class?
You often use nullable or null in you proposal, you even define optional<T>=
=20
as a nullable type T, is there any reason to rule out the name nullable<T>?
My opinion might be biased because I did a lot of C# but I find the term=20
optional somehow confusing as, in a method call, a parameter is optional=20
when a default value is provided in the function declaration. But=20
optional<T> does not define a default value, it models the fact that there=
=20
is a value or not.
I also have a little question about:
optional<int> oi =3D 1; *// works*
If I can initialize "oi" right from contruction, why whould I make it=20
optional in the first place?
And finally, if the following code is correct (I might have misinterpret=20
the proposal):
optional<int> oi;
oi =3D 1;
int i =3D *oi;
Isn't it a little bit odd to have to put "*" when accessing but not when=20
setting?
This is an interresting proposal, I hope I am not too much a bother with my=
=20
silly questions.
Best regards,
Vincent
On Tuesday, January 22, 2013 10:18:49 PM UTC+1, Andrzej Krzemie=C5=84ski wr=
ote:
>
> Hi Everyone,
> We are ready with the 3rd revision of std::optional proposal. The main=20
> changes:
>
> - optional<T> is hashable for hashable T=E2=80=99s.
> - Removed optional references =E2=80=94 they will be proposed separate=
ly.
> - get_value_or is now optional-specific member function.
> - optional<T> is a literal type.
> - Removed reference implementation. We now only provide the=20
> implementation of the parts that we consider non-trivial.
>
> We would appreciate your feedback and suggestions.
>
> Regards,
> &rzej
>
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_716_2756393.1359123966542
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div>Hi,</div><div><br></div><div>If I understand correctly, this proposal =
addresses two different problems: nullable types and lazy intialization (ad=
vanced use case section).</div><div>I have been working with another langua=
ge that address these issues with 2 different objects: Nullable<T> an=
d Lazy<T>. The former can be explicity converted to T and throws if i=
t wasn't initialized. You cannot do that with the second but you can specif=
y initialization strategies for the latter when used concurrently from seve=
ral threads.</div><div><br></div><div>Did you considered addressing those i=
ssues separatly and, if you did, why did you choose to define a single clas=
s?</div><div><br></div><div>You often use nullable or null in you proposal,=
you even define optional<T> as a nullable type T, is there any reaso=
n to rule out the name nullable<T>?<br></div><div>My opinion might be=
biased because I did a lot of C# but I find the term optional somehow conf=
using as, in a method call, a parameter is optional when a default value is=
provided in the function declaration. But optional<T> does not defin=
e a default value, it models the fact that there is a value or not.</div><d=
iv><br></div><div><br></div><div>I also have a little question about:</div>=
<div><pre style=3D"margin-left: 20pt; color: rgb(0, 0, 0);">optional<int=
> oi =3D 1; <em style=3D"font-family: 'OCR A Extended', Consolas, 'Lucid=
a Console', monospace;">// works</em></pre></div><div><br></div><div>If I c=
an initialize "oi" right from contruction, why whould I make it optional in=
the first place?</div><div><br></div><div>And finally, if the following co=
de is correct (I might have misinterpret the proposal):</div><div>optional&=
lt;int> oi;</div><div>oi =3D 1;</div><div>int i =3D *oi;</div><div><br><=
/div><div>Isn't it a little bit odd to have to put "*" when accessing but n=
ot when setting?</div><div><br></div><div>This is an interresting proposal,=
I hope I am not too much a bother with my silly questions.</div><div><br><=
/div><div>Best regards,</div><div>Vincent</div><div><br><br>On Tuesday, Jan=
uary 22, 2013 10:18:49 PM UTC+1, Andrzej Krzemie=C5=84ski wrote:<blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">Hi Everyone,<br>We are ready with the 3rd=
revision of std::optional proposal. The main changes:<br><ul><li><code>opt=
ional<T></code> is hashable for hashable <code>T</code>=E2=80=99s.</l=
i><li>Removed optional references =E2=80=94 they will be proposed separatel=
y.</li><li><code>get_value_or</code> is now <code>optional</code>-specific =
member function.</li><li><code>optional<T></code> is a literal type.<=
/li><li>Removed reference implementation. We now only provide the implement=
ation of the parts that we consider non-trivial.</li></ul>We would apprecia=
te your feedback and suggestions.<br><br>Regards,<br>&rzej<br></blockqu=
ote></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_716_2756393.1359123966542--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Fri, 25 Jan 2013 06:46:00 -0800 (PST)
Raw View
------=_Part_710_30409188.1359125160721
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu pi=B1tek, 25 stycznia 2013 14:31:26 UTC+1 u=BFytkownik Fernando Cacc=
iola=20
napisa=B3:
>
> On Fri, Jan 25, 2013 at 7:48 AM, Andrzej Krzemie=F1ski <akrz...@gmail.com=
<javascript:>>=20
> wrote:=20
> >=20
> >> Yes, optional<> with Strict Weak Ordering is why I think optional<>=20
> >> relopt optional<> is worthwhile - more for practical reasons than=20
> >> philosophical, although I think it is also philosophically sound.=20
> >>=20
> >> But optional<T> relopt T might be best poisoned.=20
> >=20
> >=20
> > Let me just add one thought atop of what you said. Given that we have a=
n=20
> > implicit conversion from T to optional<T>, the semantics of optional<T>=
=20
> > relopt T becomes "natural". This is why we are discussing the poisoning=
=20
> > rather than not introducing additional relop functions. For this reason=
=20
> I=20
> > consider either poisoning the mixed relops or giving them the "natural"=
=20
> > semantics by simply not poisoning them.=20
>
> Right.=20
>
> Can you remind me why you thought it was better to disallow mixed=20
> comparisons? I remember I agreed with you but now I can't think of why=20
> :)=20
>
Quoting the rationale from the proposal:
One could also expect comparisons between T and optional<T>. The natural=20
semantics of such comparison would be:
template <class T>
bool operator=3D=3D(const optional<T>& a, const T& b)
{
return a =3D=3D make_optional(b);
}
We do not propose it because there is no strong motivation for such=20
comparisons. On the contrary, the inadvertent invocation o such comparisons=
=20
might be disastrous. Consider the following scenario. We have a class that=
=20
stores the number of passengers:=20
class MyPlan
{
unsigned passengerCount;
*// ...*
};
At some point we realize that sometimes we will not know the number of=20
passengers: either because we use lazy initialization techniques or because=
=20
we failed to compute the number. We change the type of the variable:
class MyPlan
{
optional<unsigned> passengerCount;
*// ...*
};
And we might expect that compiler will warn us in every place where we try=
=20
to access the value of passengerCount. However the following comparison=20
will continue to compile although the run-time behaviour will be different=
=20
than the one expected:
bool MyPlan::exceedsCapacity() const
{
return passengerCount > availableSeats;
*// availableSeats is of type unsigned int*
}
Since disengaged optional never compares greater than anything, the effect=
=20
we have is that if we do not know how many passengers there are we report=
=20
with certainty that their number does not exceed the capacity. For this=20
reason comparison between optional<T> and T are required to be reported as=
=20
errors at compile-time
=20
>
> Best=20
>
> --=20
> Fernando Cacciola=20
> SciSoft Consulting, Founder=20
> http://www.scisoft-consulting.com=20
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_710_30409188.1359125160721
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu pi=B1tek, 25 stycznia 2013 14:31:26 UTC+1 u=BFytkownik Ferna=
ndo Cacciola napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Fri,=
Jan 25, 2013 at 7:48 AM, Andrzej Krzemie=F1ski <<a href=3D"javascript:"=
target=3D"_blank" gdf-obfuscated-mailto=3D"FZnkM7dM1XgJ">akrz...@gmail.com=
</a>> wrote:
<br>>
<br>>> Yes, optional<> with Strict Weak Ordering is why I think=
optional<>
<br>>> relopt optional<> is worthwhile - more for practical rea=
sons than
<br>>> philosophical, although I think it is also philosophically sou=
nd.
<br>>>
<br>>> But optional<T> relopt T might be best poisoned.
<br>>
<br>>
<br>> Let me just add one thought atop of what you said. Given that we h=
ave an
<br>> implicit conversion from T to optional<T>, the semantics of =
optional<T>
<br>> relopt T becomes "natural". This is why we are discussing the pois=
oning
<br>> rather than not introducing additional relop functions. For this r=
eason I
<br>> consider either poisoning the mixed relops or giving them the "nat=
ural"
<br>> semantics by simply not poisoning them.
<br>
<br>Right.
<br>
<br>Can you remind me why you thought it was better to disallow mixed
<br>comparisons? I remember I agreed with you but now I can't think of why
<br>:)
<br></blockquote><div><br>Quoting the rationale from the proposal:<br><br><=
p>One could also expect comparisons between <code>T</code> and <code>option=
al<T></code>. The natural semantics of such comparison would be:</p>
<pre>template <class T>
bool operator=3D=3D(const optional<T>& a, const T& b)
{
return a =3D=3D make_optional(b);
}
</pre>
<p>We do not propose it because there is no strong motivation for such=20
comparisons. On the contrary, the inadvertent invocation o such=20
comparisons might be disastrous. Consider the following scenario. We=20
have a class that stores the number of passengers:
</p>
<pre>class MyPlan
{
unsigned passengerCount;
<em>// ...</em>
};</pre>
<p>At some point we realize that sometimes we will not know the number=20
of passengers: either because we use lazy initialization techniques or=20
because we failed to compute the number. We change the type of the=20
variable:</p>
<pre>class MyPlan
{
optional<unsigned> passengerCount;
<em>// ...</em>
};</pre>
<p>And we might expect that compiler will warn us in every place where we t=
ry to access the value of <code>passengerCount</code>.
However the following comparison will continue to compile although the=20
run-time behaviour will be different than the one expected:</p>
<pre>bool MyPlan::exceedsCapacity() const
{
return passengerCount > availableSeats;
<em>// availableSeats is of type unsigned int</em>
}
</pre>
<p>Since disengaged optional never compares greater than anything, the=20
effect we have is that if we do not know how many passengers there are=20
we report with certainty that their number does not exceed the capacity.
For this reason comparison between <code>optional<T></code> and <cod=
e>T</code> are required to be reported as errors at compile-time</p><p><br>=
</p> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Best
<br>
<br>--
<br>Fernando Cacciola
<br>SciSoft Consulting, Founder
<br><a href=3D"http://www.scisoft-consulting.com" target=3D"_blank">http://=
www.scisoft-consulting.<wbr>com</a>
<br></blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_710_30409188.1359125160721--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Fri, 25 Jan 2013 11:49:44 -0300
Raw View
On Fri, Jan 25, 2013 at 12:26 PM, Vincent Jacquet <vjacquet@flowgroup.fr> wrote:
> Hi,
>
> If I understand correctly, this proposal addresses two different problems:
> nullable types and lazy intialization (advanced use case section).
> I have been working with another language that address these issues with 2
> different objects: Nullable<T> and Lazy<T>. The former can be explicity
> converted to T and throws if it wasn't initialized. You cannot do that with
> the second but you can specify initialization strategies for the latter when
> used concurrently from several threads.
>
Although you naturally can post-initialize a nullable type, that is
not really the same as lazy-initialization, so our proposal does not
really addresses the second problem.
With lazy initialization, you do need a value, always. Null is not a
valid choice. The only difference with an ordinary type is that the
value is only initialized if you actually access it (and for that the
typical use case if using a function, stored in the wrapper, to do the
initialization, as is the case with .Net 4 Lazy<T>).
That's quite different from a value can be be null.
A separate class should be provided for that (and I happen to use lazy
initialization for optimization purposes all the time, for which I'm
always doing it by hand, so I had already considered implementing such
a lazy<> class)
> Did you considered addressing those issues separatly and, if you did, why
> did you choose to define a single class?
>
Like I said, there are separate issues and optional<> does not
addresses lazy initialization.
> You often use nullable or null in you proposal, you even define optional<T>
> as a nullable type T, is there any reason to rule out the name nullable<T>?
Historical reasons.
This proposal derives from boost::optional<>, which was first
introduced 10 years ago.
At that time, there was no Nullable<> and AFAICT the term was not
known, or common enough at least.
> My opinion might be biased because I did a lot of C# but I find the term
> optional somehow confusing as, in a method call, a parameter is optional
> when a default value is provided in the function declaration. But
> optional<T> does not define a default value, it models the fact that there
> is a value or not.
>
>
> I also have a little question about:
>
> optional<int> oi = 1; // works
>
>
> If I can initialize "oi" right from contruction, why whould I make it
> optional in the first place?
>
Because you can null it later. There are some use cases that do that.
> And finally, if the following code is correct (I might have misinterpret the
> proposal):
> optional<int> oi;
> oi = 1;
> int i = *oi;
>
> Isn't it a little bit odd to have to put "*" when accessing but not when
> setting?
>
Not really.
oi = 1
would set the value even if there was no value before.
*o1 = 1
would fail if oi was null before the assignment.
Best
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Fri, 25 Jan 2013 11:58:08 -0300
Raw View
On Fri, Jan 25, 2013 at 11:46 AM, Andrzej Krzemie=C5=84ski
<akrzemi1@gmail.com> wrote:
>
> bool MyPlan::exceedsCapacity() const
> {
> return passengerCount > availableSeats;
> // availableSeats is of type unsigned int
> }
>
> Since disengaged optional never compares greater than anything, the effec=
t
> we have is that if we do not know how many passengers there are we report
> with certainty that their number does not exceed the capacity
>
Hmm, I don't find this example to be a sound rationale for disallowing
mixed comparisons.
If a user writes that code, is his or her responsibility to know what
the code does and for instance realize that the result of the
predicate might be different from what he or she expected in the case
of a nullopt.
Is that the only reason? If so then I definitely think we should put
that back in.
FWIW, here's how I think that predicate should be written:
uncertain<bool> MyPlan::exceedsCapacity() const
{
return passengerCount ? passengerCount > availableSeats : indeterminate ;
}
(uncertain<> is an utility that exists in CGAL, but I think is fairly
evident what it does and why I used it there)
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Fri, 25 Jan 2013 07:28:49 -0800 (PST)
Raw View
------=_Part_135_5011167.1359127729920
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu pi=B1tek, 25 stycznia 2013 15:58:08 UTC+1 u=BFytkownik Fernando Cacc=
iola=20
napisa=B3:
>
> On Fri, Jan 25, 2013 at 11:46 AM, Andrzej Krzemie=F1ski=20
> <akrz...@gmail.com <javascript:>> wrote:=20
> >=20
> > bool MyPlan::exceedsCapacity() const=20
> > {=20
> > return passengerCount > availableSeats;=20
> > // availableSeats is of type unsigned int=20
> > }=20
> >=20
> > Since disengaged optional never compares greater than anything, the=20
> effect=20
> > we have is that if we do not know how many passengers there are we=20
> report=20
> > with certainty that their number does not exceed the capacity=20
> >=20
> Hmm, I don't find this example to be a sound rationale for disallowing=20
> mixed comparisons.=20
>
> If a user writes that code, is his or her responsibility to know what=20
> the code does and for instance realize that the result of the=20
> predicate might be different from what he or she expected in the case=20
> of a nullopt.=20
>
> Is that the only reason? If so then I definitely think we should put=20
> that back in.=20
>
=20
Yes: this was the only reason.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_135_5011167.1359127729920
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu pi=B1tek, 25 stycznia 2013 15:58:08 UTC+1 u=BFytkownik Ferna=
ndo Cacciola napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Fri,=
Jan 25, 2013 at 11:46 AM, Andrzej Krzemie=F1ski
<br><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
3g4njEzQvLIJ">akrz...@gmail.com</a>> wrote:
<br>>
<br>> bool MyPlan::exceedsCapacity() const
<br>> {
<br>> return passengerCount > availableSeats;
<br>> // availableSeats is of type unsigned int
<br>> }
<br>>
<br>> Since disengaged optional never compares greater than anything, th=
e effect
<br>> we have is that if we do not know how many passengers there are we=
report
<br>> with certainty that their number does not exceed the capacity
<br>>
<br>Hmm, I don't find this example to be a sound rationale for disallowing
<br>mixed comparisons.
<br>
<br>If a user writes that code, is his or her responsibility to know what
<br>the code does and for instance realize that the result of the
<br>predicate might be different from what he or she expected in the case
<br>of a nullopt.
<br>
<br>Is that the only reason? If so then I definitely think we should put
<br>that back in.
<br></blockquote><div> <br>Yes: this was the only reason.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_135_5011167.1359127729920--
.
Author: Vincent Jacquet <vjacquet@flowgroup.fr>
Date: Fri, 25 Jan 2013 07:44:34 -0800 (PST)
Raw View
------=_Part_800_19263410.1359128674882
Content-Type: text/plain; charset=ISO-8859-1
On Friday, January 25, 2013 3:49:44 PM UTC+1, Fernando Cacciola wrote:
> On Fri, Jan 25, 2013 at 12:26 PM, Vincent Jacquet <vjac...@flowgroup.fr<javascript:>>
> wrote:
> > Hi,
> >
> > If I understand correctly, this proposal addresses two different
> problems:
> > nullable types and lazy intialization (advanced use case section).
> > I have been working with another language that address these issues with
> 2
> > different objects: Nullable<T> and Lazy<T>. The former can be explicity
> > converted to T and throws if it wasn't initialized. You cannot do that
> with
> > the second but you can specify initialization strategies for the latter
> when
> > used concurrently from several threads.
> >
>
> Although you naturally can post-initialize a nullable type, that is
> not really the same as lazy-initialization, so our proposal does not
> really addresses the second problem.
>
> With lazy initialization, you do need a value, always. Null is not a
> valid choice. The only difference with an ordinary type is that the
> value is only initialized if you actually access it (and for that the
> typical use case if using a function, stored in the wrapper, to do the
> initialization, as is the case with .Net 4 Lazy<T>).
> That's quite different from a value can be be null.
> A separate class should be provided for that (and I happen to use lazy
> initialization for optimization purposes all the time, for which I'm
> always doing it by hand, so I had already considered implementing such
> a lazy<> class)
>
> > Did you considered addressing those issues separatly and, if you did,
> why
> > did you choose to define a single class?
> >
> Like I said, there are separate issues and optional<> does not
> addresses lazy initialization.
>
But this is presented as an advanced use case, along with the Car example
which, BTW, seems wrong as the engine_ and mileage_ are mutable optional<>,
eventhough optional is not synchronized (see
<http://isocpp.org/blog/2012/12/you-dont-know-const-and-mutable-herb-sutter>).
>
> > You often use nullable or null in you proposal, you even define
> optional<T>
> > as a nullable type T, is there any reason to rule out the name
> nullable<T>?
>
> Historical reasons.
> This proposal derives from boost::optional<>, which was first
> introduced 10 years ago.
> At that time, there was no Nullable<> and AFAICT the term was not
> known, or common enough at least.
>
So you wouldn't mind changing the name if you were given good reasons to do
so? (Don't worry, I do not consider "because it sounds nicer" or "because
other language/framework named it that way" as good reasons)
>
> > My opinion might be biased because I did a lot of C# but I find the term
> > optional somehow confusing as, in a method call, a parameter is optional
> > when a default value is provided in the function declaration. But
> > optional<T> does not define a default value, it models the fact that
> there
> > is a value or not.
> >
> >
> > I also have a little question about:
> >
> > optional<int> oi = 1; // works
> >
> >
> > If I can initialize "oi" right from contruction, why whould I make it
> > optional in the first place?
> >
>
> Because you can null it later. There are some use cases that do that.
>
I did not have thought about this as much as you did, so I currently do not
see any. Do you mind giving me some?
>
> > And finally, if the following code is correct (I might have misinterpret
> the
> > proposal):
> > optional<int> oi;
> > oi = 1;
> > int i = *oi;
> >
> > Isn't it a little bit odd to have to put "*" when accessing but not when
> > setting?
> >
> Not really.
>
> oi = 1
>
> would set the value even if there was no value before.
>
> *o1 = 1
>
> would fail if oi was null before the assignment.
>
Sorry, I missed the "T& operator *();" while reading the proposal.
>
> Best
>
>
> --
> Fernando Cacciola
> SciSoft Consulting, Founder
> http://www.scisoft-consulting.com
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_800_19263410.1359128674882
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Friday, January 25, 2013 3:49:44 PM UTC+1, Fernando Cacciola wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Jan 25, 2013 at 12:26 P=
M, Vincent Jacquet <<a href=3D"javascript:" target=3D"_blank" gdf-obfusc=
ated-mailto=3D"JTjD24o3S-wJ">vjac...@flowgroup.fr</a>> wrote:
<br>> Hi,
<br>>
<br>> If I understand correctly, this proposal addresses two different p=
roblems:
<br>> nullable types and lazy intialization (advanced use case section).
<br>> I have been working with another language that address these issue=
s with 2
<br>> different objects: Nullable<T> and Lazy<T>. The former=
can be explicity
<br>> converted to T and throws if it wasn't initialized. You cannot do =
that with
<br>> the second but you can specify initialization strategies for the l=
atter when
<br>> used concurrently from several threads.
<br>>
<br>
<br>Although you naturally can post-initialize a nullable type, that is
<br>not really the same as lazy-initialization, so our proposal does not
<br>really addresses the second problem.
<br>
<br>With lazy initialization, you do need a value, always. Null is not a
<br>valid choice. The only difference with an ordinary type is that the
<br>value is only initialized if you actually access it (and for that the
<br>typical use case if using a function, stored in the wrapper, to do the
<br>initialization, as is the case with .Net 4 Lazy<T>).
<br>That's quite different from a value can be be null.
<br>A separate class should be provided for that (and I happen to use lazy
<br>initialization for optimization purposes all the time, for which I'm
<br>always doing it by hand, so I had already considered implementing such
<br>a lazy<> class)
<br>
<br>> Did you considered addressing those issues separatly and, if you d=
id, why
<br>> did you choose to define a single class?
<br>>
<br>Like I said, there are separate issues and optional<> does not
<br>addresses lazy initialization.
<br></blockquote><div><br></div><div>But this is presented as an advanced u=
se case, along with the Car example which, BTW, seems wrong as the engine_ =
and <span style=3D"color: rgb(0, 0, 0);">mileage_</span> are muta=
ble optional<>, eventhough optional is not synchronized (see <http=
://isocpp.org/blog/2012/12/you-dont-know-const-and-mutable-herb-sutter>)=
..<br></div><div><br></div><div><br></div><div> </div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">
<br>> You often use nullable or null in you proposal, you even define op=
tional<T>
<br>> as a nullable type T, is there any reason to rule out the name nul=
lable<T>?
<br>
<br>Historical reasons.
<br>This proposal derives from boost::optional<>, which was first
<br>introduced 10 years ago.
<br>At that time, there was no Nullable<> and AFAICT the term was not
<br>known, or common enough at least.
<br></blockquote><div><br></div><div>So you wouldn't mind changing the name=
if you were given good reasons to do so? (Don't worry, I do not consider "=
because it sounds nicer" or "because other language/framework named it that=
way" as good reasons)</div><div> </div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;">
<br>> My opinion might be biased because I did a lot of C# but I find th=
e term
<br>> optional somehow confusing as, in a method call, a parameter is op=
tional
<br>> when a default value is provided in the function declaration. But
<br>> optional<T> does not define a default value, it models the f=
act that there
<br>> is a value or not.
<br>>
<br>>
<br>> I also have a little question about:
<br>>
<br>> optional<int> oi =3D 1; // works
<br>>
<br>>
<br>> If I can initialize "oi" right from contruction, why whould I make=
it
<br>> optional in the first place?
<br>>
<br>
<br>Because you can null it later. There are some use cases that do that.
<br></blockquote><div><br></div><div>I did not have thought about this as m=
uch as you did, so I currently do not see any. Do you mind giving me some?<=
/div><div><br></div><div> </div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
1ex;">
<br>> And finally, if the following code is correct (I might have misint=
erpret the
<br>> proposal):
<br>> optional<int> oi;
<br>> oi =3D 1;
<br>> int i =3D *oi;
<br>>
<br>> Isn't it a little bit odd to have to put "*" when accessing but no=
t when
<br>> setting?
<br>>
<br>Not really.
<br>
<br>oi =3D 1
<br>
<br>would set the value even if there was no value before.
<br>
<br>*o1 =3D 1
<br>
<br>would fail if oi was null before the assignment.
<br></blockquote><div><br></div><div>Sorry, I missed the "<span style=3D"co=
lor: rgb(0, 0, 0);">T& operator *();" while reading the proposal.</span=
></div><div> </div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Best
<br>
<br>
<br>--
<br>Fernando Cacciola
<br>SciSoft Consulting, Founder
<br><a href=3D"http://www.scisoft-consulting.com" target=3D"_blank">http://=
www.scisoft-consulting.<wbr>com</a>
<br></blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_800_19263410.1359128674882--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Fri, 25 Jan 2013 17:01:02 +0100
Raw View
On Fri, Jan 25, 2013 at 3:58 PM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> On Fri, Jan 25, 2013 at 11:46 AM, Andrzej Krzemie=C5=84ski
> <akrzemi1@gmail.com> wrote:
>>
>> bool MyPlan::exceedsCapacity() const
>> {
>> return passengerCount > availableSeats;
>> // availableSeats is of type unsigned int
>> }
>>
>> Since disengaged optional never compares greater than anything, the effe=
ct
>> we have is that if we do not know how many passengers there are we repor=
t
>> with certainty that their number does not exceed the capacity
>>
> Hmm, I don't find this example to be a sound rationale for disallowing
> mixed comparisons.
>
> If a user writes that code, is his or her responsibility to know what
> the code does and for instance realize that the result of the
> predicate might be different from what he or she expected in the case
> of a nullopt.
>
> Is that the only reason? If so then I definitely think we should put
> that back in.
The argument was that if passengerCount is changed from int to
optional<int>, the user expected that code to fail to compile.
Otherwise the meaning might silently change.
Olaf
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Fri, 25 Jan 2013 08:04:00 -0800 (PST)
Raw View
------=_Part_5_25606922.1359129840580
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu pi=B1tek, 25 stycznia 2013 16:44:34 UTC+1 u=BFytkownik Vincent Jacqu=
et=20
napisa=B3:
>
> On Friday, January 25, 2013 3:49:44 PM UTC+1, Fernando Cacciola wrote:
>
>> On Fri, Jan 25, 2013 at 12:26 PM, Vincent Jacquet <vjac...@flowgroup.fr>=
=20
>> wrote:=20
>> > Hi,=20
>> >=20
>> > If I understand correctly, this proposal addresses two different=20
>> problems:=20
>> > nullable types and lazy intialization (advanced use case section).=20
>> > I have been working with another language that address these issues=20
>> with 2=20
>> > different objects: Nullable<T> and Lazy<T>. The former can be explicit=
y=20
>> > converted to T and throws if it wasn't initialized. You cannot do that=
=20
>> with=20
>> > the second but you can specify initialization strategies for the latte=
r=20
>> when=20
>> > used concurrently from several threads.=20
>> >=20
>>
>> Although you naturally can post-initialize a nullable type, that is=20
>> not really the same as lazy-initialization, so our proposal does not=20
>> really addresses the second problem.=20
>>
>> With lazy initialization, you do need a value, always. Null is not a=20
>> valid choice. The only difference with an ordinary type is that the=20
>> value is only initialized if you actually access it (and for that the=20
>> typical use case if using a function, stored in the wrapper, to do the=
=20
>> initialization, as is the case with .Net 4 Lazy<T>).=20
>> That's quite different from a value can be be null.=20
>> A separate class should be provided for that (and I happen to use lazy=
=20
>> initialization for optimization purposes all the time, for which I'm=20
>> always doing it by hand, so I had already considered implementing such=
=20
>> a lazy<> class)=20
>>
>> > Did you considered addressing those issues separatly and, if you did,=
=20
>> why=20
>> > did you choose to define a single class?=20
>> >=20
>> Like I said, there are separate issues and optional<> does not=20
>> addresses lazy initialization.=20
>>
>
> But this is presented as an advanced use case, along with the Car example=
=20
> which, BTW, seems wrong as the engine_ and mileage_ are mutable=20
> optional<>, eventhough optional is not synchronized (see <
> http://isocpp.org/blog/2012/12/you-dont-know-const-and-mutable-herb-sutte=
r
> >).
>
The example presents how the _deferred_ initialization works in optional --=
=20
this is different that lazy initialization. The example shows how you can=
=20
implement lazy initialization in your type using deferred initialization=20
offered by optional.=20
And you are right: this example is not thread-safe.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_5_25606922.1359129840580
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu pi=B1tek, 25 stycznia 2013 16:44:34 UTC+1 u=BFytkownik Vince=
nt Jacquet napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Friday=
, January 25, 2013 3:49:44 PM UTC+1, Fernando Cacciola wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
#ccc solid;padding-left:1ex">On Fri, Jan 25, 2013 at 12:26 PM, Vincent Jac=
quet <<a>vjac...@flowgroup.fr</a>> wrote:
<br>> Hi,
<br>>
<br>> If I understand correctly, this proposal addresses two different p=
roblems:
<br>> nullable types and lazy intialization (advanced use case section).
<br>> I have been working with another language that address these issue=
s with 2
<br>> different objects: Nullable<T> and Lazy<T>. The former=
can be explicity
<br>> converted to T and throws if it wasn't initialized. You cannot do =
that with
<br>> the second but you can specify initialization strategies for the l=
atter when
<br>> used concurrently from several threads.
<br>>
<br>
<br>Although you naturally can post-initialize a nullable type, that is
<br>not really the same as lazy-initialization, so our proposal does not
<br>really addresses the second problem.
<br>
<br>With lazy initialization, you do need a value, always. Null is not a
<br>valid choice. The only difference with an ordinary type is that the
<br>value is only initialized if you actually access it (and for that the
<br>typical use case if using a function, stored in the wrapper, to do the
<br>initialization, as is the case with .Net 4 Lazy<T>).
<br>That's quite different from a value can be be null.
<br>A separate class should be provided for that (and I happen to use lazy
<br>initialization for optimization purposes all the time, for which I'm
<br>always doing it by hand, so I had already considered implementing such
<br>a lazy<> class)
<br>
<br>> Did you considered addressing those issues separatly and, if you d=
id, why
<br>> did you choose to define a single class?
<br>>
<br>Like I said, there are separate issues and optional<> does not
<br>addresses lazy initialization.
<br></blockquote><div><br></div><div>But this is presented as an advanced u=
se case, along with the Car example which, BTW, seems wrong as the engine_ =
and <span style=3D"color:rgb(0,0,0)">mileage_</span> are mutable =
optional<>, eventhough optional is not synchronized (see <<a href=
=3D"http://isocpp.org/blog/2012/12/you-dont-know-const-and-mutable-herb-sut=
ter" target=3D"_blank">http://isocpp.org/blog/2012/<wbr>12/you-dont-know-co=
nst-and-<wbr>mutable-herb-sutter</a>>).<br></div></blockquote><div><br>T=
he example presents how the _deferred_ initialization works in optional -- =
this is different that lazy initialization. The example shows how you can i=
mplement lazy initialization in your type using deferred initialization off=
ered by optional. <br><br>And you are right: this example is not thread-saf=
e.<br><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_5_25606922.1359129840580--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Fri, 25 Jan 2013 08:12:49 -0800 (PST)
Raw View
------=_Part_22_4174549.1359130370014
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu pi=B1tek, 25 stycznia 2013 17:01:02 UTC+1 u=BFytkownik Olaf van der =
Spek=20
napisa=B3:
>
> On Fri, Jan 25, 2013 at 3:58 PM, Fernando Cacciola=20
> <fernando...@gmail.com <javascript:>> wrote:=20
> > On Fri, Jan 25, 2013 at 11:46 AM, Andrzej Krzemie=F1ski=20
> > <akrz...@gmail.com <javascript:>> wrote:=20
> >>=20
> >> bool MyPlan::exceedsCapacity() const=20
> >> {=20
> >> return passengerCount > availableSeats;=20
> >> // availableSeats is of type unsigned int=20
> >> }=20
> >>=20
> >> Since disengaged optional never compares greater than anything, the=20
> effect=20
> >> we have is that if we do not know how many passengers there are we=20
> report=20
> >> with certainty that their number does not exceed the capacity=20
> >>=20
> > Hmm, I don't find this example to be a sound rationale for disallowing=
=20
> > mixed comparisons.=20
> >=20
> > If a user writes that code, is his or her responsibility to know what=
=20
> > the code does and for instance realize that the result of the=20
> > predicate might be different from what he or she expected in the case=
=20
> > of a nullopt.=20
> >=20
> > Is that the only reason? If so then I definitely think we should put=20
> > that back in.=20
>
> The argument was that if passengerCount is changed from int to=20
> optional<int>, the user expected that code to fail to compile.=20
> Otherwise the meaning might silently change.=20
>
Olaf is right here. Perhaps the example fails to deliver the message=20
clearly. It tells the story that really occurred to me in my work. I=20
changed type int to optional<int> and expected the compiler to warn me=20
about any unsafe usage of my new type. "Unsafe" means here wherever I read=
=20
the value (rather than write). The compiler was successful in most of the=
=20
cases, but due to the mixed rel-op, it failed in this case. The relops are=
=20
the only "unsafe" read of optional value in boost::optional interface.
int o;
int i =3D o;
if I change o to be optional<int> the program fails to compile (and I can=
=20
expect it during refactoring).
int o;
return 1 =3D=3D o;
This still compiles after the refactoring.=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_22_4174549.1359130370014
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu pi=B1tek, 25 stycznia 2013 17:01:02 UTC+1 u=BFytkownik Olaf =
van der Spek napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Fri,=
Jan 25, 2013 at 3:58 PM, Fernando Cacciola
<br><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
abSD4StNnZYJ">fernando...@gmail.com</a>> wrote:
<br>> On Fri, Jan 25, 2013 at 11:46 AM, Andrzej Krzemie=F1ski
<br>> <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"abSD4StNnZYJ">akrz...@gmail.com</a>> wrote:
<br>>>
<br>>> bool MyPlan::exceedsCapacity() const
<br>>> {
<br>>> return passengerCount > availableSeats;
<br>>> // availableSeats is of type unsigned int
<br>>> }
<br>>>
<br>>> Since disengaged optional never compares greater than anything=
, the effect
<br>>> we have is that if we do not know how many passengers there ar=
e we report
<br>>> with certainty that their number does not exceed the capacity
<br>>>
<br>> Hmm, I don't find this example to be a sound rationale for disallo=
wing
<br>> mixed comparisons.
<br>>
<br>> If a user writes that code, is his or her responsibility to know w=
hat
<br>> the code does and for instance realize that the result of the
<br>> predicate might be different from what he or she expected in the c=
ase
<br>> of a nullopt.
<br>>
<br>> Is that the only reason? If so then I definitely think we should p=
ut
<br>> that back in.
<br>
<br>The argument was that if passengerCount is changed from int to
<br>optional<int>, the user expected that code to fail to compile.
<br>Otherwise the meaning might silently change.
<br></blockquote><div><br>Olaf is right here. Perhaps the example fails to =
deliver the message clearly. It tells the story that really occurred to me =
in my work. I changed type int to optional<int> and expected the comp=
iler to warn me about any unsafe usage of my new type. "Unsafe" means here =
wherever I read the value (rather than write). The compiler was successful =
in most of the cases, but due to the mixed rel-op, it failed in this case. =
The relops are the only "unsafe" read of optional value in boost::optional =
interface.<br><br>int o;<br>int i =3D o;<br><br>if I change o to be optiona=
l<int> the program fails to compile (and I can expect it during refac=
toring).<br><br>int o;<br>return 1 =3D=3D o;<br><br>This still compiles aft=
er the refactoring. <br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_22_4174549.1359130370014--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Fri, 25 Jan 2013 08:19:04 -0800 (PST)
Raw View
------=_Part_220_8516964.1359130744550
Content-Type: text/plain; charset=ISO-8859-1
> > I also have a little question about:
> >
> > optional<int> oi = 1; // works
> >
> >
> > If I can initialize "oi" right from contruction, why whould I make it
> > optional in the first place?
> >
>
> Because you can null it later. There are some use cases that do that.
>
There are other reasons. consider this:
int compute(std::string arg1, optional<int> arg2);
I can use my function in two ways:
return compute("cat", 1);
return compute("cat", nullopt);
or an even more probable use-case:
int compute(std::string arg1, optional<int> arg2 = nullopt);
//
return compute("cat", 1);
return compute("cat");
now
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_220_8516964.1359130744550
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">> I also have a l=
ittle question about:
<br>>
<br>> optional<int> oi =3D 1; // works
<br>>
<br>>
<br>> If I can initialize "oi" right from contruction, why whould I make=
it
<br>> optional in the first place?
<br>>
<br>
<br>Because you can null it later. There are some use cases that do that.
<br></blockquote><div><br>There are other reasons. consider this:<br><br><d=
iv class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bor=
der-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word=
-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprin=
t"><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> compute</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">string</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> arg1</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> optional</span><span style=3D"color: #080;" class=3D"styled-by-p=
rettify"><int></span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> arg2</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span></div></code></div><br>I can use my function in two ways:<br><br><d=
iv class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bor=
der-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word=
-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprin=
t"><span style=3D"color: #008;" class=3D"styled-by-prettify">return</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> compute</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #080;" class=3D"styled-by-prettify">"cat"</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>return</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> co=
mpute</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span style=3D"color: #080;" class=3D"styled-by-prettify">"cat"</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> nullopt</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><br>or=
an even more probable use-case:<br><br><div class=3D"prettyprint" style=3D=
"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bo=
rder-style: solid; border-width: 1px; word-wrap: break-word;"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;"=
class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> compute</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">::</span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
string</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> arg=
1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> optional</span><s=
pan style=3D"color: #080;" class=3D"styled-by-prettify"><int></span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> arg2 </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> nullopt</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color:=
#800;" class=3D"styled-by-prettify">//</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> compute</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #080;" class=3D"styled-by-p=
rettify">"cat"</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> compute</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #080;" class=
=3D"styled-by-prettify">"cat"</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span></div></code></div><br><br><br>now <br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_220_8516964.1359130744550--
.
Author: Vincent Jacquet <vjacquet@flowgroup.fr>
Date: Fri, 25 Jan 2013 08:37:38 -0800 (PST)
Raw View
------=_Part_434_19199969.1359131858375
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Ok, now I feel stupid ;).
On Friday, January 25, 2013 5:19:04 PM UTC+1, Andrzej Krzemie=C5=84ski wrot=
e:
>
> =20
>
>> > I also have a little question about:=20
>> >=20
>> > optional<int> oi =3D 1; // works=20
>> >=20
>> >=20
>> > If I can initialize "oi" right from contruction, why whould I make it=
=20
>> > optional in the first place?=20
>> >=20
>>
>> Because you can null it later. There are some use cases that do that.=20
>>
>
> There are other reasons. consider this:
>
> int compute(std::string arg1, optional<int> arg2);
>
> I can use my function in two ways:
>
> return compute("cat", 1);
> return compute("cat", nullopt);
>
> or an even more probable use-case:
>
> int compute(std::string arg1, optional<int> arg2 =3D nullopt);
>
> //
> return compute("cat", 1);
> return compute("cat");
>
>
>
> now =20
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_434_19199969.1359131858375
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Ok, now I feel stupid ;).<br><br>On Friday, January 25, 2013 5:19:04 PM UTC=
+1, Andrzej Krzemie=C5=84ski wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"> <br><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">> I also have a =
little question about:
<br>>
<br>> optional<int> oi =3D 1; // works
<br>>
<br>>
<br>> If I can initialize "oi" right from contruction, why whould I make=
it
<br>> optional in the first place?
<br>>
<br>
<br>Because you can null it later. There are some use cases that do that.
<br></blockquote><div><br>There are other reasons. consider this:<br><br><d=
iv 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><span=
style=3D"color:#008">int</span><span style=3D"color:#000"> compute</span><=
span style=3D"color:#660">(</span><span style=3D"color:#000">std</span><spa=
n style=3D"color:#660">::</span><span style=3D"color:#008">string</span><sp=
an style=3D"color:#000"> arg1</span><span style=3D"color:#660">,</span><spa=
n style=3D"color:#000"> optional</span><span style=3D"color:#080"><int&g=
t;</span><span style=3D"color:#000"> arg2</span><span style=3D"color:#660">=
);</span><span style=3D"color:#000"><br></span></div></code></div><br>I can=
use my function in two ways:<br><br><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><span style=3D"color:#008">return</span><=
span style=3D"color:#000"> compute</span><span style=3D"color:#660">(</span=
><span style=3D"color:#080">"cat"</span><span style=3D"color:#660">,</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#066">1</span><span=
style=3D"color:#660">);</span><span style=3D"color:#000"><br></span><span =
style=3D"color:#008">return</span><span style=3D"color:#000"> compute</span=
><span style=3D"color:#660">(</span><span style=3D"color:#080">"cat"</span>=
<span style=3D"color:#660">,</span><span style=3D"color:#000"> nullopt</spa=
n><span style=3D"color:#660">);</span><span style=3D"color:#000"><br></span=
></div></code></div><br>or an even more probable use-case:<br><br><div styl=
e=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><span style=
=3D"color:#008">int</span><span style=3D"color:#000"> compute</span><span s=
tyle=3D"color:#660">(</span><span style=3D"color:#000">std</span><span styl=
e=3D"color:#660">::</span><span style=3D"color:#008">string</span><span sty=
le=3D"color:#000"> arg1</span><span style=3D"color:#660">,</span><span styl=
e=3D"color:#000"> optional</span><span style=3D"color:#080"><int></sp=
an><span style=3D"color:#000"> arg2 </span><span style=3D"color:#660">=3D</=
span><span style=3D"color:#000"> nullopt</span><span style=3D"color:#660">)=
;</span><span style=3D"color:#000"><br><br></span><span style=3D"color:#800=
">//</span><span style=3D"color:#000"><br></span><span style=3D"color:#008"=
>return</span><span style=3D"color:#000"> compute</span><span style=3D"colo=
r:#660">(</span><span style=3D"color:#080">"cat"</span><span style=3D"color=
:#660">,</span><span style=3D"color:#000"> </span><span style=3D"color:#066=
">1</span><span style=3D"color:#660">);</span><span style=3D"color:#000"><b=
r></span><span style=3D"color:#008">return</span><span style=3D"color:#000"=
> compute</span><span style=3D"color:#660">(</span><span style=3D"color:#08=
0">"cat"</span><span style=3D"color:#660">);</span><span style=3D"color:#00=
0"><br></span></div></code></div><br><br><br>now <br></div></blockquo=
te>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_434_19199969.1359131858375--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Fri, 25 Jan 2013 13:44:10 -0300
Raw View
On Fri, Jan 25, 2013 at 1:12 PM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
>
> int o;
> int i =3D o;
>
> if I change o to be optional<int> the program fails to compile (and I can
> expect it during refactoring).
>
> int o;
> return 1 =3D=3D o;
>
> This still compiles after the refactoring.
>
OK well at least now I fully recall this argument. I'm not sure I
(still) share it but I least I see your concern.
If we keep the choice of poisoning it, the rationale should be more
elaborate at least.
First of all, promoting T to optional<T> *is* a fairly common thing to
do, so we are not looking at a corner case.
If I do that (and I must have, but that was way too long to remember,
since I've used it myself several years before first proposing it to
Boost), I wouldn't at all expect the compiler to warm me if I screwed
up. I would go to the trouble of looking at each use of the variable
and make sure it does something that still makes sense.
When you do that sort of change you are explicitly deciding that the
value can not exists. That IMO is one significant change, and if you
have used ordering operators (=3D=3D and !=3D won't ever be a problem, by
the way), then you must do something about it because you might need
to handle the ordering against 'nothing' in a special way (as is in
your example).
No doubt a compiler error would force you to go over that, but I'm not
sure it is required.
Consider that, for example, we do require that implicit conversions to
T are disabled. If you had
void foo( int ) ;
int i ;
foo(i) ;
and you promote int to be optional<T>, then *there is no use case*
where passing a nullopt to foo() will work. So silently compiling this
would be a sure trap.
OTOH, the case of ordering comparison is only problem if it is,
depending on the required meaning of the expression.
That is, if you had:
int i ;
if ( i < 1 )
then you changed i to optional<int>()
it might very well happen that, the result of
if ( nullopt < 1 )
returning true is exactly right.
Unlike the case of the implicit conversion to T, the changed semantics
are not necessarily wrong, and you might not need the compiler to
force you to change it.
So, I don't think that we need to cut out a useful feature just to
have the compiler fail on a piece of code that *might*, only in some
cases, be a problem.
IMO, a construct should be ill-formed only when there are values for
which it will always be wrong no matter the context, intention or
requirement.
Best
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Fri, 25 Jan 2013 13:46:53 -0300
Raw View
On Fri, Jan 25, 2013 at 1:37 PM, Vincent Jacquet <vjacquet@flowgroup.fr> wrote:
> Ok, now I feel stupid ;).
Well, given the serious and realistic use cases Andrzej posted, the
one I suggested was, well... lacking imagination, to be polite.
So you're not alone in the sentiment :)
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 25 Jan 2013 12:29:17 -0500
Raw View
On Fri, Jan 25, 2013 at 11:44 AM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> On Fri, Jan 25, 2013 at 1:12 PM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail=
..com> wrote:
>>
>> int o;
>> int i =3D o;
>>
>> if I change o to be optional<int> the program fails to compile (and I ca=
n
>> expect it during refactoring).
>>
>> int o;
>> return 1 =3D=3D o;
>>
>> This still compiles after the refactoring.
>>
>
> OK well at least now I fully recall this argument. I'm not sure I
> (still) share it but I least I see your concern.
>
> If we keep the choice of poisoning it, the rationale should be more
> elaborate at least.
>
> First of all, promoting T to optional<T> *is* a fairly common thing to
> do, so we are not looking at a corner case.
>
> If I do that (and I must have, but that was way too long to remember,
> since I've used it myself several years before first proposing it to
> Boost), I wouldn't at all expect the compiler to warm me if I screwed
> up. I would go to the trouble of looking at each use of the variable
> and make sure it does something that still makes sense.
>
> When you do that sort of change you are explicitly deciding that the
> value can not exists. That IMO is one significant change, and if you
> have used ordering operators (=3D=3D and !=3D won't ever be a problem, by
> the way), then you must do something about it because you might need
> to handle the ordering against 'nothing' in a special way (as is in
> your example).
>
> No doubt a compiler error would force you to go over that, but I'm not
> sure it is required.
>
> Consider that, for example, we do require that implicit conversions to
> T are disabled. If you had
>
> void foo( int ) ;
> int i ;
> foo(i) ;
>
> and you promote int to be optional<T>, then *there is no use case*
> where passing a nullopt to foo() will work. So silently compiling this
> would be a sure trap.
>
> OTOH, the case of ordering comparison is only problem if it is,
> depending on the required meaning of the expression.
>
> That is, if you had:
>
> int i ;
>
> if ( i < 1 )
>
> then you changed i to optional<int>()
>
> it might very well happen that, the result of
>
> if ( nullopt < 1 )
>
> returning true is exactly right.
>
> Unlike the case of the implicit conversion to T, the changed semantics
> are not necessarily wrong, and you might not need the compiler to
> force you to change it.
>
> So, I don't think that we need to cut out a useful feature just to
> have the compiler fail on a piece of code that *might*, only in some
> cases, be a problem.
>
> IMO, a construct should be ill-formed only when there are values for
> which it will always be wrong no matter the context, intention or
> requirement.
>
I would conclude the exact opposite. Given that you don't know how I
might want nullopt < 1 to behave, why do you pick one and standardize
it?
In particular:
> OTOH, the case of ordering comparison is only problem if it is,
> depending on the required meaning of the expression.
>
You don't know the requirements, thus why would you decide for me?
You don't know the meaning, why give it one?
Tony
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Fri, 25 Jan 2013 14:38:51 -0300
Raw View
On Fri, Jan 25, 2013 at 2:29 PM, Tony V E <tvaneerd@gmail.com> wrote:
>
> I would conclude the exact opposite. Given that you don't know how I
> might want nullopt < 1 to behave, why do you pick one and standardize
> it?
>
What would you say about:
nullopt < make_optional(1)
?
Because I don't know just as well. Or would you object to that also?
> In particular:
>
>> OTOH, the case of ordering comparison is only problem if it is,
>> depending on the required meaning of the expression.
>>
>
> You don't know the requirements, thus why would you decide for me?
>
> You don't know the meaning, why give it one?
>
Neither I do in the case of
nullopt < make_optional(1)
yet that is proposed as valid.
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: =?UTF-8?B?TWlrYWVsIEtpbHBlbMOkaW5lbg==?=
Date: Fri, 25 Jan 2013 18:55:27 +0100
Raw View
25.1.2013 17:44, Fernando Cacciola kirjoitti:
> When you do that sort of change you are explicitly deciding that the
> value can not exists. That IMO is one significant change, and if you
> have used ordering operators (== and != won't ever be a problem, by
> the way),
This is what i tried to say earlier, == and != are not affected by the
rationale.
> then you must do something about it because you might need
> to handle the ordering against 'nothing' in a special way (as is in
> your example).
Right, there probably is more cases without the mixed relational
operations that fail as well.
I would be very careful making this kind of change.
btw. about the conceptual models in the proposal ..
| Model (2) treats optional<T> as etier a value of type T or value
nullopt, allocated in the same storage, along with the way of
determining which of the two it is. The interface in | this model
requires operations such as comparison to T, comparison to nullopt,
assignment and creation from either. It is easy to determine what the
value of the optional | | | object is in this model: the type it stores
(T or nullopt_t) and possibly the value of T. This is the model that we
propose.
Here it explicitly states _model requires operations such as comparison
to T_
Another thing I find interesting is..
| Model (3) treats optional<T> as a special case container. This begs
for a container-like interface: empty to check if the object is
disengaged, emplace to engage the object, and | clear to disengage it.
Also, the value of optional object in this model is well defined: the
size of the container (0 or 1) and the value of the element if the size
is 1. This model | | would serve our pupose equally well. The choice
between models (2) and (3) is to a certain degree arbitrary. One
argument in favour of (2) is that it has been used in practise | | for a
while in Boost.Optional.
I don't really agree that this model would serve equally well, for one,
containers don't have relational operators.
Mikael
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 25 Jan 2013 12:06:32 -0600
Raw View
--f46d044306ac0879fc04d420cc71
Content-Type: text/plain; charset=ISO-8859-1
On 25 January 2013 11:29, Tony V E <tvaneerd@gmail.com> wrote:
> I would conclude the exact opposite. Given that you don't know how I
> might want nullopt < 1 to behave, why do you pick one and standardize
> it?
>
Because it covers the 99% use case. Why should it be hard for most people
to use?
Do you also believe that set and map should not use less for a default
ordering, but instead require that the user *always* provide a comparator?
Note: I'm not arguing for policy based design here. optional<T> should be
easy to use and cover the 99% case. The 1%-ers can wrap optional<T> in
their own type and give it whatever alternate behavior they want.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--f46d044306ac0879fc04d420cc71
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_quote">On 25 January 2013 11:29, Tony V E <span dir=3D"=
ltr"><<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@g=
mail.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">
<div id=3D":2zk">I would conclude the exact opposite. =A0Given that you don=
't know how I<br>
might want nullopt < 1 to behave, why do you pick one and standardize<br=
>
it?<br></div></blockquote></div><br><div>Because it covers the 99% use case=
.. =A0Why should it be hard for most people to use?</div><div><br></div><div=
>Do you also believe that set and map should not use less for a default ord=
ering, but instead require that the user *always* provide a comparator?</di=
v>
<div><br></div><div>Note: =A0I'm not arguing for policy based design he=
re. =A0optional<T> should be easy to use and cover the 99% case. =A0T=
he 1%-ers can wrap optional<T> in their own type and give it whatever=
alternate behavior they want.<br>
-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"mailto:nevin=
@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=A0 (847=
) 691-1404
</div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--f46d044306ac0879fc04d420cc71--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Fri, 25 Jan 2013 19:21:05 +0100
Raw View
On Fri, Jan 25, 2013 at 5:44 PM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> When you do that sort of change you are explicitly deciding that the
> value can not exists. That IMO is one significant change, and if you
> have used ordering operators (== and != won't ever be a problem, by
> the way),
Are you sure about that?
If null is used as unknown, then I think those two operators are a problem too.
--
Olaf
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: =?ISO-8859-1?Q?Mikael_Kilpel=E4inen?=
Date: Fri, 25 Jan 2013 19:38:03 +0100
Raw View
25.1.2013 19:21, Olaf van der Spek kirjoitti:
> On Fri, Jan 25, 2013 at 5:44 PM, Fernando Cacciola
> <fernando.cacciola@gmail.com> wrote:
>> When you do that sort of change you are explicitly deciding that the
>> value can not exists. That IMO is one significant change, and if you
>> have used ordering operators (== and != won't ever be a problem, by
>> the way),
> Are you sure about that?
> If null is used as unknown, then I think those two operators are a problem too.
null? you mean some specific value of the underlaying type of optional?
then why would you change it to optional in first place? and if you do,
you need to take special care to
fix your code as now you introduced two special values. I think
comparing in mixed way is no more dangerous than comparing in general
with optional,
there are always cases that will break if you _just_ change the type and
don't take care. For example, you very often
put your constants in variables, you change the type without thinking
and you have the exact same problem as
explained in the proposal.
Mikael
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Fri, 25 Jan 2013 20:21:19 +0100
Raw View
On Fri, Jan 25, 2013 at 7:38 PM, Mikael Kilpel=E4inen
<mikael.kilpelainen@gmail.com> wrote:
>> Are you sure about that?
>> If null is used as unknown, then I think those two operators are a probl=
em
>> too.
>
> null? you mean some specific value of the underlaying type of optional?
No, I mean nullopt.
--=20
Olaf
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?ISO-8859-1?Q?Mikael_Kilpel=E4inen?=
Date: Fri, 25 Jan 2013 20:23:59 +0100
Raw View
25.1.2013 20:21, Olaf van der Spek kirjoitti:
> On Fri, Jan 25, 2013 at 7:38 PM, Mikael Kilpel=E4inen
> <mikael.kilpelainen@gmail.com> wrote:
>>> Are you sure about that?
>>> If null is used as unknown, then I think those two operators are a prob=
lem
>>> too.
>> null? you mean some specific value of the underlaying type of optional?
> No, I mean nullopt.
>
Can you elaborate please, why is it a problem?
Mikael
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 25 Jan 2013 16:59:15 -0500
Raw View
On Fri, Jan 25, 2013 at 1:06 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 25 January 2013 11:29, Tony V E <tvaneerd@gmail.com> wrote:
>>
>> I would conclude the exact opposite. Given that you don't know how I
>> might want nullopt < 1 to behave, why do you pick one and standardize
>> it?
>
>
> Because it covers the 99% use case. Why should it be hard for most people
> to use?
>
I think 99% is a bit high. I think it will too often be a misuse.
I think allowing opt<T> < opt<T> but not opt<T> < T is a reasonable compromise.
> Do you also believe that set and map should not use less for a default
> ordering, but instead require that the user *always* provide a comparator?
>
Somewhat tangential, but I always thought map should use map_less<>
which then defaults to less<> if not overridden. ie one more
extension point - definable by the developer writing the Key type,
instead of the developer using the map. Still as usable, but ordering
for lookup is not always the same as ordering for other reasons. (Of
course this may often have been due to the lack of a hash_map).
I say somewhat tangential because I think it relates to optional and
to "separation of concerns" - less<T> as used with a map is
reasonable, but it is an assumption of equivalence that doesn't
actually exist. Luckily you can override it. But I'd prefer if the
standard was more strict on principles. Saying map uses map_less<> is
hard to argue as wrong (it becomes self-referential, self-consistent).
Overly pedantic maybe, but not wrong. It is defining maps
constraints only in terms of map (not all constraints, but an
important one - the ordering of the key). Then, as a separate step,
defining reasonable defaults for those constraints. Separates the
concepts between supplier and user - let the user (map) define the
concept. Thus map_less<>, not less<>.
So, somewhat similarly, I'd separate what opt<T> rel opt<T> means from
what opt<T> rel T means. As they are different.
> Note: I'm not arguing for policy based design here.
agreed!
> optional<T> should be
> easy to use and cover the 99% case. The 1%-ers can wrap optional<T> in
> their own type and give it whatever alternate behavior they want.
> --
> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Fri, 25 Jan 2013 23:46:17 -0800 (PST)
Raw View
------=_Part_733_21843387.1359186377852
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu pi=B1tek, 25 stycznia 2013 18:55:27 UTC+1 u=BFytkownik Mikael=20
Kilpel=E4inen napisa=B3:
>
> 25.1.2013 17:44, Fernando Cacciola kirjoitti:=20
> > When you do that sort of change you are explicitly deciding that the=20
> > value can not exists. That IMO is one significant change, and if you=20
> > have used ordering operators (=3D=3D and !=3D won't ever be a problem, =
by=20
> > the way),=20
> This is what i tried to say earlier, =3D=3D and !=3D are not affected by =
the=20
> rationale.=20
>
Well, my intuition tells me even =3D=3D and !=3D may be affected. For insta=
nce:
bool is_true( bool b )
{
return b !=3D false;
}
=20
Now if we change b from bool to optional<bool>... I am pretty sure one can=
=20
come up with a more realistic example.
> > then you must do something about it because you might need=20
> > to handle the ordering against 'nothing' in a special way (as is in=20
> > your example).=20
> Right, there probably is more cases without the mixed relational=20
> operations that fail as well.=20
> I would be very careful making this kind of change.=20
>
> btw. about the conceptual models in the proposal ..=20
>
> | Model (2) treats optional<T> as etier a value of type T or value=20
> nullopt, allocated in the same storage, along with the way of=20
> determining which of the two it is. The interface in | this model=20
> requires operations such as comparison to T, comparison to nullopt,=20
> assignment and creation from either. It is easy to determine what the=20
> value of the optional | | | object is in this model: the type it stores=
=20
> (T or nullopt_t) and possibly the value of T. This is the model that we=
=20
> propose.=20
>
> Here it explicitly states _model requires operations such as comparison=
=20
> to T_=20
>
>
> Another thing I find interesting is..=20
>
> | Model (3) treats optional<T> as a special case container. This begs=20
> for a container-like interface: empty to check if the object is=20
> disengaged, emplace to engage the object, and | clear to disengage it.=20
> Also, the value of optional object in this model is well defined: the=20
> size of the container (0 or 1) and the value of the element if the size=
=20
> is 1. This model | | would serve our pupose equally well. The choice=20
> between models (2) and (3) is to a certain degree arbitrary. One=20
> argument in favour of (2) is that it has been used in practise | | for a=
=20
> while in Boost.Optional.=20
>
> I don't really agree that this model would serve equally well, for one,=
=20
> containers don't have relational operators.=20
>
>
> Mikael=20
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_733_21843387.1359186377852
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu pi=B1tek, 25 stycznia 2013 18:55:27 UTC+1 u=BFytkownik Mikae=
l Kilpel=E4inen napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">25.1=
..2013 17:44, Fernando Cacciola kirjoitti:
<br>> When you do that sort of change you are explicitly deciding that t=
he
<br>> value can not exists. That IMO is one significant change, and if y=
ou
<br>> have used ordering operators (=3D=3D and !=3D won't ever be a prob=
lem, by
<br>> the way),
<br>This is what i tried to say earlier, =3D=3D and !=3D are not affected b=
y the=20
<br>rationale.
<br></blockquote><div><br>Well, my intuition tells me even =3D=3D and !=3D =
may be affected. For instance:<br><br> bool is_true( bool b )<br>&nbs=
p; {<br> return b !=3D false;<br> }<br> <br>No=
w if we change b from bool to optional<bool>... I am pretty sure one =
can come up with a more realistic example.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">
<br>> then you must do something about it because you might need
<br>> to handle the ordering against 'nothing' in a special way (as is i=
n
<br>> your example).
<br>Right, there probably is more cases without the mixed relational=20
<br>operations that fail as well.
<br>I would be very careful making this kind of change.
<br>
<br>btw. about the conceptual models in the proposal ..
<br>
<br>| Model (2) treats optional<T> as etier a value of type T or valu=
e=20
<br>nullopt, allocated in the same storage, along with the way of=20
<br>determining which of the two it is. The interface in | this model=20
<br>requires operations such as comparison to T, comparison to nullopt,=20
<br>assignment and creation from either. It is easy to determine what the=
=20
<br>value of the optional | | | object is in this model: the type it stores=
=20
<br>(T or nullopt_t) and possibly the value of T. This is the model that we=
=20
<br>propose.
<br>
<br>Here it explicitly states _model requires operations such as comparison=
=20
<br>to T_
<br>
<br>
<br>Another thing I find interesting is..
<br>
<br>| Model (3) treats optional<T> as a special case container. This =
begs=20
<br>for a container-like interface: empty to check if the object is=20
<br>disengaged, emplace to engage the object, and | clear to disengage it.=
=20
<br>Also, the value of optional object in this model is well defined: the=
=20
<br>size of the container (0 or 1) and the value of the element if the size=
=20
<br>is 1. This model | | would serve our pupose equally well. The choice=20
<br>between models (2) and (3) is to a certain degree arbitrary. One=20
<br>argument in favour of (2) is that it has been used in practise | | for =
a=20
<br>while in Boost.Optional.
<br>
<br>I don't really agree that this model would serve equally well, for one,=
=20
<br>containers don't have relational operators.
<br>
<br>
<br>Mikael
<br></blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_733_21843387.1359186377852--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Sat, 26 Jan 2013 00:09:33 -0800 (PST)
Raw View
------=_Part_732_16464197.1359187773806
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu pi=B1tek, 25 stycznia 2013 17:44:10 UTC+1 u=BFytkownik Fernando Cacc=
iola=20
napisa=B3:
>
> On Fri, Jan 25, 2013 at 1:12 PM, Andrzej Krzemie=F1ski <akrz...@gmail.com=
<javascript:>>=20
> wrote:=20
> >=20
> > int o;=20
> > int i =3D o;=20
> >=20
> > if I change o to be optional<int> the program fails to compile (and I=
=20
> can=20
> > expect it during refactoring).=20
> >=20
> > int o;=20
> > return 1 =3D=3D o;=20
> >=20
> > This still compiles after the refactoring.=20
> >=20
>
> OK well at least now I fully recall this argument. I'm not sure I=20
> (still) share it but I least I see your concern.=20
>
> If we keep the choice of poisoning it, the rationale should be more=20
> elaborate at least.=20
>
Yes, I will do that, regardless of what we decide. Before going to the=20
arguments, let me state my position here. I believe there are good=20
arguments for either case and the decision my need to be arbitrary. I would=
=20
only like to pin down the point of the disagreement.
=20
>
> First of all, promoting T to optional<T> *is* a fairly common thing to=20
> do, so we are not looking at a corner case.=20
>
Yes. But do you mean implicit conversions, or also mixed relops?
=20
>
> If I do that (and I must have, but that was way too long to remember,=20
> since I've used it myself several years before first proposing it to=20
> Boost), I wouldn't at all expect the compiler to warm me if I screwed=20
> up. I would go to the trouble of looking at each use of the variable=20
> and make sure it does something that still makes sense.=20
>
"I would not expect" -- but this is perhaps because you are used to mixed=
=20
relops in boost::optional and not having this compiler check. If=20
boost::optional were different, perhaps you would expect this help from the=
=20
compiler. We are at the point of deciding what std::optional will offer=20
(similarity to boost::optional is one of the criteria), and also deciding=
=20
what the users can and cannot expect.
> When you do that sort of change you are explicitly deciding that the=20
> value can not exists. That IMO is one significant change, and if you=20
> have used ordering operators (=3D=3D and !=3D won't ever be a problem, by=
=20
> the way), then you must do something about it because you might need=20
> to handle the ordering against 'nothing' in a special way (as is in=20
> your example).=20
>
On the other hand, I if I have the guarantee that mixed relops are poisoned=
=20
I can be relieved of "explicitly deciding" and be guaranteed that the=20
compiler will warn me. In a way, we are trading one feature for the other.
> No doubt a compiler error would force you to go over that, but I'm not=20
> sure it is required.=20
>
> Consider that, for example, we do require that implicit conversions to=20
> T are disabled. If you had=20
>
> void foo( int ) ;=20
> int i ;=20
> foo(i) ;=20
>
> and you promote int to be optional<T>, then *there is no use case*=20
> where passing a nullopt to foo() will work. So silently compiling this=20
> would be a sure trap.=20
>
> OTOH, the case of ordering comparison is only problem if it is,=20
> depending on the required meaning of the expression.=20
>
> That is, if you had:=20
>
> int i ;=20
>
> if ( i < 1 )=20
>
> then you changed i to optional<int>()=20
>
> it might very well happen that, the result of=20
>
> if ( nullopt < 1 )=20
>
> returning true is exactly right.=20
>
> Unlike the case of the implicit conversion to T, the changed semantics=20
> are not necessarily wrong, and you might not need the compiler to=20
> force you to change it.=20
>
But in your latter example, when you choose to chenge the type of i from=
=20
int to optional<int> why not also change 1 to make_optional(1)?
Do you recall any real-life case where you needed the mized comparison and=
=20
converting T to optional<T> wouldn't work?
=20
> So, I don't think that we need to cut out a useful feature just to=20
> have the compiler fail on a piece of code that *might*, only in some=20
> cases, be a problem.=20
>
> IMO, a construct should be ill-formed only when there are values for=20
> which it will always be wrong no matter the context, intention or=20
> requirement.=20
>
=20
I see what you are saying. I am not sure I agree with this statement. (I am=
=20
not sure that I disagree either.)
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_732_16464197.1359187773806
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu pi=B1tek, 25 stycznia 2013 17:44:10 UTC+1 u=BFytkownik Ferna=
ndo Cacciola napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Fri,=
Jan 25, 2013 at 1:12 PM, Andrzej Krzemie=F1ski <<a href=3D"javascript:"=
target=3D"_blank" gdf-obfuscated-mailto=3D"2Y9Y5IhXv9kJ">akrz...@gmail.com=
</a>> wrote:
<br>>
<br>> int o;
<br>> int i =3D o;
<br>>
<br>> if I change o to be optional<int> the program fails to compi=
le (and I can
<br>> expect it during refactoring).
<br>>
<br>> int o;
<br>> return 1 =3D=3D o;
<br>>
<br>> This still compiles after the refactoring.
<br>>
<br>
<br>OK well at least now I fully recall this argument. I'm not sure I
<br>(still) share it but I least I see your concern.
<br>
<br>If we keep the choice of poisoning it, the rationale should be more
<br>elaborate at least.
<br></blockquote><div><br>Yes, I will do that, regardless of what we decide=
.. Before going to the arguments, let me state my position here. I believe t=
here are good arguments for either case and the decision my need to be arbi=
trary. I would only like to pin down the point of the disagreement.<br>&nbs=
p;<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>First of all, promoting T to optional<T> *is* a fairly common thi=
ng to
<br>do, so we are not looking at a corner case.
<br></blockquote><div><br>Yes. But do you mean implicit conversions, or als=
o mixed relops?<br> <br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">
<br>If I do that (and I must have, but that was way too long to remember,
<br>since I've used it myself several years before first proposing it to
<br>Boost), I wouldn't at all expect the compiler to warm me if I screwed
<br>up. I would go to the trouble of looking at each use of the variable
<br>and make sure it does something that still makes sense.
<br></blockquote><div><br>"I would not expect" -- but this is perhaps=
because you are used to mixed relops in boost::optional and not having thi=
s compiler check. If boost::optional were different, perhaps you would expe=
ct this help from the compiler. We are at the point of deciding what std::o=
ptional will offer (similarity to boost::optional is one of the criteria), =
and also deciding what the users can and cannot expect.<br><br></div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">
<br>When you do that sort of change you are explicitly deciding that the
<br>value can not exists. That IMO is one significant change, and if you
<br>have used ordering operators (=3D=3D and !=3D won't ever be a problem, =
by
<br>the way), then you must do something about it because you might need
<br>to handle the ordering against 'nothing' in a special way (as is in
<br>your example).
<br></blockquote><div><br>On the other hand, I if I have the guarantee that=
mixed relops are poisoned I can be relieved of "explicitly deciding" and b=
e guaranteed that the compiler will warn me. In a way, we are trading one f=
eature for the other.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">
<br>No doubt a compiler error would force you to go over that, but I'm not
<br>sure it is required.
<br>
<br>Consider that, for example, we do require that implicit conversions to
<br>T are disabled. If you had
<br>
<br>void foo( int ) ;
<br>int i ;
<br>foo(i) ;
<br>
<br>and you promote int to be optional<T>, then *there is no use case=
*
<br>where passing a nullopt to foo() will work. So silently compiling this
<br>would be a sure trap.
<br>
<br>OTOH, the case of ordering comparison is only problem if it is,
<br>depending on the required meaning of the expression.
<br>
<br>That is, if you had:
<br>
<br>int i ;
<br>
<br>if ( i < 1 )
<br>
<br>then you changed i to optional<int>()
<br>
<br>it might very well happen that, the result of
<br>
<br>if ( nullopt < 1 )
<br>
<br>returning true is exactly right.
<br>
<br>Unlike the case of the implicit conversion to T, the changed semantics
<br>are not necessarily wrong, and you might not need the compiler to
<br>force you to change it.
<br></blockquote><div><br>But in your latter example, when you choose=
to chenge the type of i from int to optional<int> why not also chang=
e 1 to make_optional(1)?<br><br>Do you recall any real-life case where you =
needed the mized comparison and converting T to optional<T> wouldn't =
work?<br> <br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">So, I=
don't think that we need to cut out a useful feature just to
<br>have the compiler fail on a piece of code that *might*, only in some
<br>cases, be a problem.
<br>
<br>IMO, a construct should be ill-formed only when there are values for
<br>which it will always be wrong no matter the context, intention or
<br>requirement.
<br></blockquote><div> <br>I see what you are saying. I am not sure I =
agree with this statement. (I am not sure that I disagree either.)<br></div=
>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_732_16464197.1359187773806--
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Sat, 26 Jan 2013 19:27:49 +1100
Raw View
--14dae9340347c8659d04d42cd16c
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
On Sat, Jan 26, 2013 at 6:46 PM, Andrzej Krzemie=F1ski <akrzemi1@gmail.com>=
wrote:
> W dniu pi=B1tek, 25 stycznia 2013 18:55:27 UTC+1 u=BFytkownik Mikael
> Kilpel=E4inen napisa=B3:
>
>> 25.1.2013 17:44, Fernando Cacciola kirjoitti:
>> > When you do that sort of change you are explicitly deciding that the
>> > value can not exists. That IMO is one significant change, and if you
>> > have used ordering operators (=3D=3D and !=3D won't ever be a problem,=
by
>> > the way),
>> This is what i tried to say earlier, =3D=3D and !=3D are not affected by=
the
>> rationale.
>>
>
> Well, my intuition tells me even =3D=3D and !=3D may be affected. For ins=
tance:
>
> bool is_true( bool b )
> {
> return b !=3D false;
> }
>
> Now if we change b from bool to optional<bool>... I am pretty sure one ca=
n
> come up with a more realistic example.
>
I suspect the problem with the example above is that its original
implementation seems flawed. It does not test the b=3D=3Dtrue but b!=3Dfals=
e and
applies the reasoning -- the value can only be in one of the two states
(true, false), therefore, if that's not one state (not 'false'), then it
must be the other one (true). Obviously, that reasoning falters with 3
states (disengaged, true, false) and not an 'optional' "fault".
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
--14dae9340347c8659d04d42cd16c
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_quote">On Sat, Jan 26, 2013 at 6:46 PM, Andrzej Krzemie=
=F1ski <span dir=3D"ltr"><<a href=3D"mailto:akrzemi1@gmail.com" target=
=3D"_blank">akrzemi1@gmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
W dniu pi=B1tek, 25 stycznia 2013 18:55:27 UTC+1 u=BFytkownik Mikael Kilpel=
=E4inen napisa=B3:<div class=3D"im"><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>25.1.2013 17:44, Fernando Cacciola kirjoitti:
<br>> When you do that sort of change you are explicitly deciding that t=
he
<br>> value can not exists. That IMO is one significant change, and if y=
ou
<br>> have used ordering operators (=3D=3D and !=3D won't ever be a =
problem, by
<br>> the way),
<br>This is what i tried to say earlier, =3D=3D and !=3D are not affected b=
y the=20
<br>rationale.
<br></blockquote></div><div><br>Well, my intuition tells me even =3D=3D and=
!=3D may be affected. For instance:<br><br>=A0 bool is_true( bool b )<br>=
=A0 {<br>=A0=A0=A0 return b !=3D false;<br>=A0 }<br>=A0<br>Now if we change=
b from bool to optional<bool>... I am pretty sure one can come up wi=
th a more realistic example.<br>
</div></blockquote></div><br>I suspect the problem with the example above i=
s that its original implementation seems flawed. It does not test the b=3D=
=3Dtrue but b!=3Dfalse and applies the reasoning -- the value can only be i=
n one of the two states (true, false), therefore, if that's not one sta=
te (not 'false'), then it must be the other one (true). Obviously, =
that reasoning falters with 3 states (disengaged, true, false) and not an &=
#39;optional' "fault". <br>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--14dae9340347c8659d04d42cd16c--
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Sat, 26 Jan 2013 00:53:56 -0800 (PST)
Raw View
------=_Part_581_14444547.1359190436365
Content-Type: text/plain; charset=ISO-8859-1
On Friday, January 25, 2013 4:52:24 PM UTC+11, Tony V E wrote:
>
> On Wed, Jan 23, 2013 at 3:49 PM, Vladimir Batov <vb.ma...@gmail.com<javascript:>>
> wrote:
> > On Thu, Jan 24, 2013 at 2:54 AM, Tony V E <tvan...@gmail.com<javascript:>>
> wrote:
> >> On Wed, Jan 23, 2013 at 9:00 AM, Ville Voutilainen
> >> ...
> >> And if you had
> >> optional<functionlike> fn;
> >> fn(some, params);
> >> I might think it was calling operator() on the contained value.
> >> ie
> >> fn(emplace, foo)
> >> vs
> >> (*fn)(emplace, foo)
> >> Who would recognize those as completely different?
> >
> > Uhm, everyone?... They look different and they do different things...
>
> true, however:
>
> - alternatively, fn(params) could std::forward the params to the
> callable, when wrapping callables. (Not saying this is necessarily a
> good idea, but if you want the optional<T> to act like T, then that
> would be the result.) Making fn(emplace, foo) potentially ambiguous.
>
> - they mean the same when fn is a pointer-to-function.
>
> - you may work with some better programmers than I have :-)
>
Indeed, I certainly agree with your arguments on a more generic level...
IMO that is one of C++ qualities. Some like it, some not. In any case one
particular class is not the place to try and "fix" any perceived
flaws/ambiguities/etc. of the language. Especially, given that in the
context of 'optional'
optional<Foo> fn; //#1
fn(emplace, foo); // #2
(*fn)(emplace, foo) // #3
unambiguously mean different things. I might be possibly missing something
but I simply read the second like as "apply two parameters to the 'fn'
object (which is 'optional'); the third reads -- "dereference fn and then
apply two parameters to the result". Some might prefer more visible visual
difference like:
fn.apply(emplace, foo); // #2
fn.dereference().apply(emplace, foo) // #3
However, that probably belongs to some other language-syntax related
discussion and outside of the current optional-related scope.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_581_14444547.1359190436365
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br>On Friday, January 25, 2013 4:52:24 PM UTC+11, Tony V E wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
1px #ccc solid;padding-left: 1ex;">On Wed, Jan 23, 2013 at 3:49 PM, Vladim=
ir Batov <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"P8h6JD8PLgoJ">vb.ma...@gmail.com</a>> wrote:
<br>> On Thu, Jan 24, 2013 at 2:54 AM, Tony V E <<a href=3D"javascrip=
t:" target=3D"_blank" gdf-obfuscated-mailto=3D"P8h6JD8PLgoJ">tvan...@gmail.=
com</a>> wrote:
<br>>> On Wed, Jan 23, 2013 at 9:00 AM, Ville Voutilainen
<br>>> ...
<br>>> And if you had
<br>>> optional<functionlike> fn;
<br>>> fn(some, params);
<br>>> I might think it was calling operator() on the contained value=
..
<br>>> ie
<br>>> fn(emplace, foo)
<br>>> vs
<br>>> (*fn)(emplace, foo)
<br>>> Who would recognize those as completely different?
<br>>
<br>> Uhm, everyone?... They look different and they do different things=
....
<br>
<br>true, however:
<br>
<br>- alternatively, fn(params) could std::forward the params to the
<br>callable, when wrapping callables. (Not saying this is necessarily a
<br>good idea, but if you want the optional<T> to act like T, then th=
at
<br>would be the result.) Making fn(emplace, foo) potentially ambiguo=
us.
<br>
<br>- they mean the same when fn is a pointer-to-function.
<br>
<br>- you may work with some better programmers than I have :-)
<br>
</blockquote><div><br>Indeed, I certainly agree with your arguments on a mo=
re generic level... IMO that is one of C++ qualities. Some like it, some no=
t. In any case one particular class is not the place to try and "fix" any p=
erceived flaws/ambiguities/etc. of the language. Especially, given that in =
the context of 'optional' <br><br>optional<Foo> fn; //#1<br>fn(emplac=
e, foo); // #2
<br>(*fn)(emplace, foo)
// #3<br><br>unambiguously mean different things. I might be possibly missi=
ng something but I simply read the second like as "apply two parameters to =
the 'fn' object (which is 'optional'); the third reads -- "dereference fn a=
nd then apply two parameters to the result". Some might prefer more visible=
visual difference like:<br><br>fn.apply(emplace, foo); // #2
<br>fn.dereference().apply(emplace, foo)
// #3<br><br>However, that probably belongs to some other language-syntax r=
elated discussion and outside of the current optional-related scope. <br>&n=
bsp;</div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_581_14444547.1359190436365--
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Sat, 26 Jan 2013 01:08:31 -0800 (PST)
Raw View
------=_Part_624_9250171.1359191311208
Content-Type: text/plain; charset=ISO-8859-1
On Saturday, January 26, 2013 4:38:51 AM UTC+11, Fernando Cacciola wrote:
>
> On Fri, Jan 25, 2013 at 2:29 PM, Tony V E <tvan...@gmail.com <javascript:>>
> wrote:
> >
> > I would conclude the exact opposite. Given that you don't know how I
> > might want nullopt < 1 to behave, why do you pick one and standardize
> > it?
> >
> What would you say about:
>
> nullopt < make_optional(1)
>
> ?
>
> Because I don't know just as well. Or would you object to that also?
>
> > In particular:
> >
> >> OTOH, the case of ordering comparison is only problem if it is,
> >> depending on the required meaning of the expression.
> >
> > You don't know the requirements, thus why would you decide for me?
> >
> > You don't know the meaning, why give it one?
> >
> Neither I do in the case of
>
> nullopt < make_optional(1)
>
> yet that is proposed as valid.
>
Could that be because that operation is essential for easy integration of
'optional' and there is already a precedence -- nullptr < "any valid
pointer"?
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_624_9250171.1359191311208
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Saturday, January 26, 2013 4:38:51 AM UTC+11, Fernando Cacciola wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Jan 25, 2013 at 2:29 PM,=
Tony V E <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mail=
to=3D"SPIHdrOsFHoJ">tvan...@gmail.com</a>> wrote:
<br>>
<br>> I would conclude the exact opposite. Given that you don't kn=
ow how I
<br>> might want nullopt < 1 to behave, why do you pick one and stand=
ardize
<br>> it?
<br>>
<br>What would you say about:
<br>
<br>nullopt < make_optional(1)
<br>
<br>?
<br>
<br>Because I don't know just as well. Or would you object to that al=
so?
<br>
<br>> In particular:
<br>>
<br>>> OTOH, the case of ordering comparison is only problem if it is=
,
<br>>> depending on the required meaning of the expression.
<br>>
<br>> You don't know the requirements, thus why would you decide for me?
<br>>
<br>> You don't know the meaning, why give it one?
<br>>
<br>Neither I do in the case of
<br>
<br>nullopt < make_optional(1)
<br>
<br>yet that is proposed as valid.
<br></blockquote><div><br>Could that be because that operation is essential=
for easy integration of 'optional' and there is already a precedence -- nu=
llptr < "any valid pointer"? <br></div><div> </div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_624_9250171.1359191311208--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Sat, 26 Jan 2013 03:57:21 -0800 (PST)
Raw View
------=_Part_848_25635949.1359201441194
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu sobota, 26 stycznia 2013 09:27:49 UTC+1 u=BFytkownik Vladimir Batov=
=20
napisa=B3:
>
> On Sat, Jan 26, 2013 at 6:46 PM, Andrzej Krzemie=F1ski <akrz...@gmail.com=
<javascript:>
> > wrote:
>
>> W dniu pi=B1tek, 25 stycznia 2013 18:55:27 UTC+1 u=BFytkownik Mikael=20
>> Kilpel=E4inen napisa=B3:
>>
>>> 25.1.2013 17:44, Fernando Cacciola kirjoitti:=20
>>> > When you do that sort of change you are explicitly deciding that the=
=20
>>> > value can not exists. That IMO is one significant change, and if you=
=20
>>> > have used ordering operators (=3D=3D and !=3D won't ever be a problem=
, by=20
>>> > the way),=20
>>> This is what i tried to say earlier, =3D=3D and !=3D are not affected b=
y the=20
>>> rationale.=20
>>>
>>
>> Well, my intuition tells me even =3D=3D and !=3D may be affected. For in=
stance:
>>
>> bool is_true( bool b )
>> {
>> return b !=3D false;
>> }
>> =20
>> Now if we change b from bool to optional<bool>... I am pretty sure one=
=20
>> can come up with a more realistic example.
>>
>
> I suspect the problem with the example above is that its original=20
> implementation seems flawed. It does not test the b=3D=3Dtrue but b!=3Dfa=
lse and=20
> applies the reasoning -- the value can only be in one of the two states=
=20
> (true, false), therefore, if that's not one state (not 'false'), then it=
=20
> must be the other one (true). Obviously, that reasoning falters with 3=20
> states (disengaged, true, false) and not an 'optional' "fault".=20
>
I admit the example is silly, but you should not treat my entire argument=
=20
as silly. I just cannot come up with a better example right now. But you=20
get the idea: even operator!=3D can fail to meet your expectations if you=
=20
promote your type T to optional<T>. =20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_848_25635949.1359201441194
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu sobota, 26 stycznia 2013 09:27:49 UTC+1 u=BFytkownik Vladimi=
r Batov napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div class=
=3D"gmail_quote">On Sat, Jan 26, 2013 at 6:46 PM, Andrzej Krzemie=F1ski <sp=
an dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated=
-mailto=3D"3TdBvlLZojwJ">akrz...@gmail.com</a>></span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
W dniu pi=B1tek, 25 stycznia 2013 18:55:27 UTC+1 u=BFytkownik Mikael Kilpel=
=E4inen napisa=B3:<div><blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">25.1.2013 17=
:44, Fernando Cacciola kirjoitti:
<br>> When you do that sort of change you are explicitly deciding that t=
he
<br>> value can not exists. That IMO is one significant change, and if y=
ou
<br>> have used ordering operators (=3D=3D and !=3D won't ever be a prob=
lem, by
<br>> the way),
<br>This is what i tried to say earlier, =3D=3D and !=3D are not affected b=
y the=20
<br>rationale.
<br></blockquote></div><div><br>Well, my intuition tells me even =3D=3D and=
!=3D may be affected. For instance:<br><br> bool is_true( bool b )<b=
r> {<br> return b !=3D false;<br> }<br> =
<br>Now if we change b from bool to optional<bool>... I am pretty sur=
e one can come up with a more realistic example.<br>
</div></blockquote></div><br>I suspect the problem with the example above i=
s that its original implementation seems flawed. It does not test the b=3D=
=3Dtrue but b!=3Dfalse and applies the reasoning -- the value can only be i=
n one of the two states (true, false), therefore, if that's not one state (=
not 'false'), then it must be the other one (true). Obviously, that reasoni=
ng falters with 3 states (disengaged, true, false) and not an 'optional' "f=
ault". <br></blockquote><div><br>I admit the example is silly, but you shou=
ld not treat my entire argument as silly. I just cannot come up with a bett=
er example right now. But you get the idea: even operator!=3D can fail to m=
eet your expectations if you promote your type T to optional<T>. &nbs=
p; <br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_848_25635949.1359201441194--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Sat, 26 Jan 2013 04:06:24 -0800 (PST)
Raw View
------=_Part_854_8362357.1359201985027
Content-Type: text/plain; charset=ISO-8859-1
> * Strong NaN :
> (dis @ dis) == false
> (dis @ eng) == false
>
Perhaps a bit off-topic, but let me remark on the difference I observe
between NaN and null-state.
NaN -- the way I understand it -- is the effect of 'erroneous' computation:
the arguments provided to the operation did not fit into the operation's
domain. It is the floating-point standard of signalling a logic error. (Or
am I wrong?). Null-state, on the other hand is the deliberate choice to
signal the (correct) lack of any other value.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_854_8362357.1359201985027
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>* Strong NaN :<=
br> (dis @ dis) =3D=3D false<br> (dis @ eng) =3D=3D false<br></=
div></blockquote><div><br>Perhaps a bit off-topic, but let me remark on the=
difference I observe between NaN and null-state.<br>NaN -- the way I under=
stand it -- is the effect of 'erroneous' computation: the arguments provide=
d to the operation did not fit into the operation's domain. It is the float=
ing-point standard of signalling a logic error. (Or am I wrong?). Null-stat=
e, on the other hand is the deliberate choice to signal the (correct) lack =
of any other value.<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
/blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_854_8362357.1359201985027--
.
Author: =?UTF-8?Q?R=C3=B3bert_D=C3=A1vid?= <lrdxgm@gmail.com>
Date: Sat, 26 Jan 2013 04:39:09 -0800 (PST)
Raw View
------=_Part_885_12698564.1359203949323
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
2013. janu=E1r 26., szombat 9:09:33 UTC+1 id=F5pontban Andrzej Krzemie=F1sk=
i a=20
k=F6vetkez=F5t =EDrta:
>
> But in your latter example, when you choose to chenge the type of i from=
=20
> int to optional<int> why not also change 1 to make_optional(1)?
>
> Do you recall any real-life case where you needed the mized comparison an=
d=20
> converting T to optional<T> wouldn't work?
> =20
>
>
I don't recall having a real-life case, but I can easily imagine the value=
=20
being a big fat object and I probably not want to copy it, thus to create=
=20
an optional from it - std::make_optional will copy the object, won't it?
struct BFO{ //Aka BigFatObject
std::array<double, 10000> data;
bool operator< (const BFO& right);
}
void foo() {
const std::optional<BFO>& opt =3D getOpt();
const BFO& val =3D getVal();
bool comp1 =3D opt < val;
bool comp2 =3D opt < std::make_optional(val);
}
The second also feels a bit unnatural, creating a temporary value, just to=
=20
compare it to something..
Furthermore, what if instead of BigFatObject, is have=20
ClassWithDeletedCopyConstructor?
Regards, Robert=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_885_12698564.1359203949323
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>2013. janu=E1r 26., szombat 9:09:33 UTC+1 id=F5pontban Andrzej Krze=
mie=F1ski a k=F6vetkez=F5t =EDrta:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">But in your latter example, when you choose to chenge the type =
of i from int to optional<int> why not also change 1 to make_optional=
(1)?<br><div><br>Do you recall any real-life case where you needed the mize=
d comparison and converting T to optional<T> wouldn't work?<br> =
<br></div><br></blockquote><div><br>I don't recall having a real-life case,=
but I can easily imagine the value being a big fat object and I probably n=
ot want to copy it, thus to create an optional from it - std::make_optional=
will copy the object, won't it?<br><br><div class=3D"prettyprint" style=3D=
"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bo=
rder-style: solid; border-width: 1px; word-wrap: break-word;"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;"=
class=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> BFO</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify=
">//Aka BigFatObject</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br> std</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify">array</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify"><</span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">double</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #066;" class=3D"styled-by-prettify">10000</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> data</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">bool</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">operator</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> BFO<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">&</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> right</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;"=
class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbs=
p; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">optional</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">BFO</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">>&</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> opt </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> getOpt</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br> </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">const</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> BFO</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> val </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> g=
etVal</span><span style=3D"color: #660;" class=3D"styled-by-prettify">();</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>&nbs=
p; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
bool</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> comp1=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> opt </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> val</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">bool</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> comp2 </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> opt </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify"><</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
make_optional</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">val</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><br>Th=
e second also feels a bit unnatural, creating a temporary value, just to co=
mpare it to something..<br>Furthermore, what if instead of BigFatObject, is=
have ClassWithDeletedCopyConstructor?<br><br>Regards, Robert <br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_885_12698564.1359203949323--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Sat, 26 Jan 2013 14:53:54 -0300
Raw View
--047d7b3a7ff8a4a96204d434bcc8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sat, Jan 26, 2013 at 8:57 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om>
wrote:
>
> I admit the example is silly
The problem with the example is not that is silly but that it doesn't
really exemplify the possible problem you are trying to showcase.
Like Vladimir said, the code is not really testing that b is not false. If
it did, it would not be a problem if 'b' where nullopt because that is not
false, just like any other value !=3D false is not false. If the code after
the changed failed because it actually meant to test b =3D=3D true.
Of course I admit that !b is very common idiom for testing a false boolean
condition (not your example but one that is equivalent), yet I don't think
we should disable mixed =3D=3D because of that.
That situation would occur if bool is changed to int, for example, which is
IMO is the same category of change.
>, but you should not treat my entire argument as
> silly. I just cannot come up with a better example right now. But you get
> the idea: even operator!=3D can fail to meet your expectations if you
promote
> your type T to optional<T>.
>
I get your hypothesis, but lacking a valid example, I think is actually
false: i.e., it cannot create a "legit" problem important enough to cut out
a feature.
Best
--=20
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
--047d7b3a7ff8a4a96204d434bcc8
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sat, Jan 26, 2013 at 8:57 AM, Andrzej Krzemie=F1ski <=
;<a href=3D"mailto:akrzemi1@gmail.com">akrzemi1@gmail.com</a>> wrote:<br=
>><br>> I admit the example is silly<br><br>The problem with the exam=
ple is not that is silly but that it doesn't really exemplify the possi=
ble problem you are trying to showcase.<br>
Like Vladimir said, the code is not really testing that b is not false. If =
it did, it would not be a problem if 'b' where nullopt because that=
is not false, just like any other value !=3D false is not false. If the co=
de after the changed failed because it actually meant to test b =3D=3D true=
..<br>
<br>Of course I admit that !b is very common idiom for testing a false bool=
ean condition (not your example but one that is equivalent), yet I don'=
t think we should disable mixed =3D=3D <font>be<font>cause of that.</font><=
/font><span class=3D"sewgfefrbv1skon"></span><span class=3D"sewgfefrbv1skon=
"></span><br>
<br>That situation would occur if bool is changed to int, for example, whic=
h is IMO is the same category of change.<br><br>>, but you should not tr=
eat my entire argument as<br>> silly. I just cannot come up with a bette=
r example right now. But you get<br>
> the idea: even operator!=3D can fail to meet your expectations if you =
promote<br>> your type T to optional<T>. =A0<br>><br>I get your=
hypothesis, but lacking a valid example, I think is actually false: i.e., =
it cannot create a "legit" problem important enough to cut out a =
feature.<br>
<br>Best<br><br><br><br>-- <br>Fernando Cacciola<br>SciSoft Consulting, Fou=
nder<br><a href=3D"http://www.scisoft-consulting.com">http://www.scisoft-co=
nsulting.com</a><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--047d7b3a7ff8a4a96204d434bcc8--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Sat, 26 Jan 2013 15:11:16 -0300
Raw View
--047d7b6222d0bacba104d434fa9e
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
On Sat, Jan 26, 2013 at 5:09 AM, Andrzej Krzemie=F1ski <akrzemi1@gmail.com>=
wrote:
>
>
> W dniu pi=B1tek, 25 stycznia 2013 17:44:10 UTC+1 u=BFytkownik Fernando
> Cacciola napisa=B3:
>
>> On Fri, Jan 25, 2013 at 1:12 PM, Andrzej Krzemie=F1ski <akrz...@gmail.co=
m>
>> wrote:
>> >
>> > int o;
>> > int i =3D o;
>> >
>> > if I change o to be optional<int> the program fails to compile (and I
>> can
>> > expect it during refactoring).
>> >
>> > int o;
>> > return 1 =3D=3D o;
>> >
>> > This still compiles after the refactoring.
>> >
>>
>> OK well at least now I fully recall this argument. I'm not sure I
>> (still) share it but I least I see your concern.
>>
>> If we keep the choice of poisoning it, the rationale should be more
>> elaborate at least.
>>
>
> Yes, I will do that, regardless of what we decide. Before going to the
> arguments, let me state my position here. I believe there are good
> arguments for either case and the decision my need to be arbitrary. I wou=
ld
> only like to pin down the point of the disagreement.
>
>
I hoped you followed the side thread I started titled "Dynamic of a
proposal"
It turns out that we can present mixed relops as an "optional" feature. We
document the proper wording in case it is accepted and also the proper
wording in case is not. Then Ville (who would be kind enough to champion
the proposal once again) will grab feedback, talks to us via email during
the meetings, and down the road re-arrange the proposal accordingly for the
final vote.
So, we are essentially collecting arguments at both sides to present in the
paper and help the committee make a choice.
The same goes for get_value_or vs .value_or sv none of that, and
get_pointer vs .get_ptr vs none of that.
>> First of all, promoting T to optional<T> *is* a fairly common thing to
>> do, so we are not looking at a corner case.
>>
>
> Yes. But do you mean implicit conversions, or also mixed relops?
>
I think mixed relops are also not a corner case. At least I'm sure that's
the case of the existing user experience with boost::optional since it is
allowed.
>
>>
>> If I do that (and I must have, but that was way too long to remember,
>> since I've used it myself several years before first proposing it to
>> Boost), I wouldn't at all expect the compiler to warm me if I screwed
>> up. I would go to the trouble of looking at each use of the variable
>> and make sure it does something that still makes sense.
>>
>
> "I would not expect" -- but this is perhaps because you are used to mixe=
d
> relops in boost::optional and not having this compiler check. If
> boost::optional were different, perhaps you would expect this help from t=
he
> compiler. We are at the point of deciding what std::optional will offer
> (similarity to boost::optional is one of the criteria), and also deciding
> what the users can and cannot expect.
>
> You are of course right that I'm biased by my experience with
boost::optional, however I was referring to my general approach to changes.
Or perhaps I should say general approach to programming: I don't rely too
much on compiler errors to help me discover problems in the code. That's
perhaps also biased by my work experience in which 99% of my mistakes have
nothing to do with syntax errors.
>
>> When you do that sort of change you are explicitly deciding that the
>> value can not exists. That IMO is one significant change, and if you
>> have used ordering operators (=3D=3D and !=3D won't ever be a problem, b=
y
>> the way), then you must do something about it because you might need
>> to handle the ordering against 'nothing' in a special way (as is in
>> your example).
>>
>
> On the other hand, I if I have the guarantee that mixed relops are
> poisoned I can be relieved of "explicitly deciding" and be guaranteed tha=
t
> the compiler will warn me. In a way, we are trading one feature for the
> other.
>
> Right. And I might understand why some would want the "security" feature.
In C++, I prefer versatility and power.
>
>> No doubt a compiler error would force you to go over that, but I'm not
>> sure it is required.
>>
>> Consider that, for example, we do require that implicit conversions to
>> T are disabled. If you had
>>
>> void foo( int ) ;
>> int i ;
>> foo(i) ;
>>
>> and you promote int to be optional<T>, then *there is no use case*
>> where passing a nullopt to foo() will work. So silently compiling this
>> would be a sure trap.
>>
>> OTOH, the case of ordering comparison is only problem if it is,
>> depending on the required meaning of the expression.
>>
>> That is, if you had:
>>
>> int i ;
>>
>> if ( i < 1 )
>>
>> then you changed i to optional<int>()
>>
>> it might very well happen that, the result of
>>
>> if ( nullopt < 1 )
>>
>> returning true is exactly right.
>>
>> Unlike the case of the implicit conversion to T, the changed semantics
>> are not necessarily wrong, and you might not need the compiler to
>> force you to change it.
>>
>
> But in your latter example, when you choose to chenge the type of i from
> int to optional<int> why not also change 1 to make_optional(1)?
>
> Hmm, but the class of examples we are considering are all about the case
when I changed the type and then I do not change any other code to follow
the change.
If I would consider to change 1 to make_optional(1) then I'm explicitly
looking at the code and then I don't need the compiler to warm me about
anything. For instance, I might very well just leave the 1 since I know I
don't have to change it.
--=20
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
--047d7b6222d0bacba104d434fa9e
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Jan 26, 2013 at 5:09 AM, Andrzej Krzemie=F1ski <span dir=3D"ltr"><<a=
href=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">akrzemi1@gmail.com</a=
>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><br>W dniu pi=B1tek, 25 stycznia 2013 17=
:44:10 UTC+1 u=BFytkownik Fernando Cacciola napisa=B3:<div class=3D"im"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
On Fri, Jan 25, 2013 at 1:12 PM, Andrzej Krzemie=F1ski <<a>akrz...@gmail=
..com</a>> wrote:
<br>>
<br>> int o;
<br>> int i =3D o;
<br>>
<br>> if I change o to be optional<int> the program fails to compi=
le (and I can
<br>> expect it during refactoring).
<br>>
<br>> int o;
<br>> return 1 =3D=3D o;
<br>>
<br>> This still compiles after the refactoring.
<br>>
<br>
<br>OK well at least now I fully recall this argument. I'm not sure I
<br>(still) share it but I least I see your concern.
<br>
<br>If we keep the choice of poisoning it, the rationale should be more
<br>elaborate at least.
<br></blockquote></div><div><br>Yes, I will do that, regardless of what we =
decide. Before going to the arguments, let me state my position here. I bel=
ieve there are good arguments for either case and the decision my need to b=
e arbitrary. I would only like to pin down the point of the disagreement.<b=
r>
=A0<br></div></blockquote><div><br></div><div>I hoped you followed the side=
thread I started titled "Dynamic of a proposal"<br><br></div><di=
v>It turns out that we can present mixed relops as an "optional" =
feature. We document the proper wording in case it is accepted and also the=
proper wording in case is not. Then Ville (who would be kind enough to cha=
mpion the proposal once again) will grab feedback, talks to us via email du=
ring the meetings, and down the road re-arrange the proposal accordingly fo=
r the final vote.<br>
<br></div><div>So, we are essentially collecting arguments at both sides to=
present in the paper and help the committee make a choice.<br><br></div><d=
iv>The same goes for get_value_or vs .value_or sv none of that, and get_poi=
nter vs .get_ptr vs none of that.<br>
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div></div><div class=3D"im"><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
<br>First of all, promoting T to optional<T> *is* a fairly common thi=
ng to
<br>do, so we are not looking at a corner case.
<br></blockquote></div><div><br>Yes. But do you mean implicit conversions, =
or also mixed relops?<br></div></blockquote><div><br></div><div>I think mix=
ed relops are also not a corner case. At least I'm sure that's the =
case of the existing user experience with boost::optional since it is allow=
ed.<br>
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div>=A0<br></div><div class=3D"im=
"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">
<br>If I do that (and I must have, but that was way too long to remember,
<br>since I've used it myself several years before first proposing it t=
o
<br>Boost), I wouldn't at all expect the compiler to warm me if I screw=
ed
<br>up. I would go to the trouble of looking at each use of the variable
<br>and make sure it does something that still makes sense.
<br></blockquote></div><div><br>"I would not expect" --=A0 but th=
is is perhaps because you are used to mixed relops in boost::optional and n=
ot having this compiler check. If boost::optional were different, perhaps y=
ou would expect this help from the compiler. We are at the point of decidin=
g what std::optional will offer (similarity to boost::optional is one of th=
e criteria), and also deciding what the users can and cannot expect.<br>
<br></div></blockquote><div>You are of course right that I'm biased by =
my experience with boost::optional, however I was referring to my general a=
pproach to changes. Or perhaps I should say general approach to programming=
: I don't rely too much on compiler errors to help me discover problems=
in the code. That's perhaps also biased by my work experience in which=
99% of my mistakes have nothing to do with syntax errors.<br>
<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div></div><div class=3D"im=
"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">
<br>When you do that sort of change you are explicitly deciding that the
<br>value can not exists. That IMO is one significant change, and if you
<br>have used ordering operators (=3D=3D and !=3D won't ever be a probl=
em, by
<br>the way), then you must do something about it because you might need
<br>to handle the ordering against 'nothing' in a special way (as i=
s in
<br>your example).
<br></blockquote></div><div><br>On the other hand, I if I have the guarante=
e that mixed relops are poisoned I can be relieved of "explicitly deci=
ding" and be guaranteed that the compiler will warn me. In a way, we a=
re trading one feature for the other.<br>
<br></div></blockquote><div>Right. And I might understand why some would wa=
nt the "security" feature. In C++, I prefer versatility and power=
..<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">
<div></div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>No doubt a compiler error would force you to go over that, but I'm =
not
<br>sure it is required.
<br>
<br>Consider that, for example, we do require that implicit conversions to
<br>T are disabled. If you had
<br>
<br>void foo( int ) ;
<br>int =A0i ;
<br>foo(i) ;
<br>
<br>and you promote int to be optional<T>, then *there is no use case=
*
<br>where passing a nullopt to foo() will work. So silently compiling this
<br>would be a sure trap.
<br>
<br>OTOH, the case of ordering comparison is only problem if it is,
<br>depending on the required meaning of the expression.
<br>
<br>That is, if you had:
<br>
<br>int i ;
<br>
<br>if ( i < 1 )
<br>
<br>then you changed i to optional<int>()
<br>
<br>it might very well happen that, the result of
<br>
<br>if ( nullopt < 1 )
<br>
<br>returning true is exactly right.
<br>
<br>Unlike the case of the implicit conversion to T, the changed semantics
<br>are not necessarily wrong, and you might not need the compiler to
<br>force you to change it.
<br></blockquote></div><div><br>But in your latter example, when you=A0 cho=
ose to chenge the type of i from int to optional<int> why not also ch=
ange 1 to make_optional(1)?<br><br></div></blockquote><div>Hmm, but the cla=
ss of examples we are considering are all about the case when I changed the=
type and then I do not change any other code to follow the change.<br>
<br></div><div>If I would consider to change 1 to make_optional(1) then I&#=
39;m explicitly looking at the code and then I don't need the compiler =
to warm me about anything. For instance, I might very well just leave the 1=
since I know I don't have to change it.<br>
<br></div></div>-- <br>Fernando Cacciola<br>SciSoft Consulting, Founder<br>=
<a href=3D"http://www.scisoft-consulting.com">http://www.scisoft-consulting=
..com</a>
</div></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--047d7b6222d0bacba104d434fa9e--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Sat, 26 Jan 2013 15:17:25 -0300
Raw View
--047d7b66f51563771f04d4351184
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sat, Jan 26, 2013 at 9:39 AM, R=C3=B3bert D=C3=A1vid <lrdxgm@gmail.com> =
wrote:
>
>
> 2013. janu=C3=A1r 26., szombat 9:09:33 UTC+1 id=C5=91pontban Andrzej Krze=
mie=C5=84ski a
> k=C3=B6vetkez=C5=91t =C3=ADrta:
>
>> But in your latter example, when you choose to chenge the type of i fro=
m
>> int to optional<int> why not also change 1 to make_optional(1)?
>>
>> Do you recall any real-life case where you needed the mized comparison
>> and converting T to optional<T> wouldn't work?
>>
>>
>>
> I don't recall having a real-life case, but I can easily imagine the valu=
e
> being a big fat object and I probably not want to copy it, thus to create
> an optional from it - std::make_optional will copy the object, won't it?
>
> struct BFO{ //Aka BigFatObject
> std::array<double, 10000> data;
> bool operator< (const BFO& right);
> }
>
> void foo() {
> const std::optional<BFO>& opt =3D getOpt();
> const BFO& val =3D getVal();
>
> bool comp1 =3D opt < val;
> bool comp2 =3D opt < std::make_optional(val);
> }
>
> The second also feels a bit unnatural, creating a temporary value, just t=
o
> compare it to something..
> Furthermore, what if instead of BigFatObject, is have
> ClassWithDeletedCopyConstructor?
>
> Now that is a very strong argument *in favor* of having mixed relops.
Wrapping an object inside an optional can be expensive, so by forcing the
wrapping we are imposing a performance penalty.
People might end up using:
opt ? * opt < val : true ;
*only* to avoid the penalty, in which case, IMO, the lib API would have
failed to be reasonably convenient.
--=20
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
--047d7b66f51563771f04d4351184
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Jan 26, 2013 at 9:39 AM, R=F3bert D=E1vid <span dir=3D"ltr"><<a href=
=3D"mailto:lrdxgm@gmail.com" target=3D"_blank">lrdxgm@gmail.com</a>></sp=
an> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><br>2013. janu=E1r 26., szombat 9:09:33 =
UTC+1 id=F5pontban Andrzej Krzemie=F1ski a k=F6vetkez=F5t =EDrta:<div class=
=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
But in your latter example, when you=A0 choose to chenge the type of i from=
int to optional<int> why not also change 1 to make_optional(1)?<br><=
div><br>Do you recall any real-life case where you needed the mized compari=
son and converting T to optional<T> wouldn't work?<br>
=A0<br></div><br></blockquote></div><div><br>I don't recall having a re=
al-life case, but I can easily imagine the value being a big fat object and=
I probably not want to copy it, thus to create an optional from it - std::=
make_optional will copy the object, won't it?<br>
<br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,18=
7,187);border-style:solid;border-width:1px;word-wrap:break-word"><code><div=
><span style=3D"color:#008">struct</span><span style> BFO</span><span style=
=3D"color:#660">{</span><span style> </span><span style=3D"color:#800">//Ak=
a BigFatObject</span><span style><br>
=A0 =A0 std</span><span style=3D"color:#660">::</span><span style>array</sp=
an><span style=3D"color:#660"><</span><span style=3D"color:#008">double<=
/span><span style=3D"color:#660">,</span><span style> </span><span style=3D=
"color:#066">10000</span><span style=3D"color:#660">></span><span style>=
data</span><span style=3D"color:#660">;</span><span style><br>
=A0 =A0 </span><span style=3D"color:#008">bool</span><span style> </span><s=
pan style=3D"color:#008">operator</span><span style=3D"color:#660"><</sp=
an><span style> </span><span style=3D"color:#660">(</span><span style=3D"co=
lor:#008">const</span><span style> BFO</span><span style=3D"color:#660">&am=
p;</span><span style> right</span><span style=3D"color:#660">);</span><span=
style><br>
</span><span style=3D"color:#660">}</span><span style><br><br></span><span =
style=3D"color:#008">void</span><span style> foo</span><span style=3D"color=
:#660">()</span><span style> </span><span style=3D"color:#660">{</span><spa=
n style><br>
=A0 =A0 </span><span style=3D"color:#008">const</span><span style> std</spa=
n><span style=3D"color:#660">::</span><span style>optional</span><span styl=
e=3D"color:#660"><</span><span style>BFO</span><span style=3D"color:#660=
">>&</span><span style> opt </span><span style=3D"color:#660">=3D</s=
pan><span style> getOpt</span><span style=3D"color:#660">();</span><span st=
yle><br>
=A0 =A0 </span><span style=3D"color:#008">const</span><span style> BFO</spa=
n><span style=3D"color:#660">&</span><span style> val </span><span styl=
e=3D"color:#660">=3D</span><span style> getVal</span><span style=3D"color:#=
660">();</span><span style><br>
<br>=A0 =A0 </span><span style=3D"color:#008">bool</span><span style> comp1=
</span><span style=3D"color:#660">=3D</span><span style> opt </span><span =
style=3D"color:#660"><</span><span style> val</span><span style=3D"color=
:#660">;</span><span style><br>
=A0 =A0 </span><span style=3D"color:#008">bool</span><span style> comp2 </s=
pan><span style=3D"color:#660">=3D</span><span style> opt </span><span styl=
e=3D"color:#660"><</span><span style> std</span><span style=3D"color:#66=
0">::</span><span style>make_optional</span><span style=3D"color:#660">(</s=
pan><span style>val</span><span style=3D"color:#660">);</span><span style><=
br>
</span><span style=3D"color:#660">}</span><span style><br></span></div></co=
de></div><br>The second also feels a bit unnatural, creating a temporary va=
lue, just to compare it to something..<br>Furthermore, what if instead of B=
igFatObject, is have ClassWithDeletedCopyConstructor?<br>
<br></div></blockquote><div>Now that is a very strong argument *in favor* o=
f having mixed relops. Wrapping an object inside an optional can be expensi=
ve, so by forcing the wrapping we are imposing a performance penalty.<br>
<br></div><div>People might end up using:<br><br></div><div>opt ? * opt <=
; val : true ;<br><br></div><div>*only* to avoid the penalty, in which case=
, IMO, the lib API would have failed to be reasonably convenient.<br></div>
<div><br></div></div>-- <br>Fernando Cacciola<br>SciSoft Consulting, Founde=
r<br><a href=3D"http://www.scisoft-consulting.com">http://www.scisoft-consu=
lting.com</a>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--047d7b66f51563771f04d4351184--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Sat, 26 Jan 2013 13:09:56 -0800 (PST)
Raw View
------=_Part_1_11443461.1359234596697
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu sobota, 26 stycznia 2013 19:11:16 UTC+1 u=BFytkownik Fernando Caccio=
la=20
napisa=B3:
>
> On Sat, Jan 26, 2013 at 5:09 AM, Andrzej Krzemie=F1ski <akrz...@gmail.com=
<javascript:>
> > wrote:
>
>>
>>
>> W dniu pi=B1tek, 25 stycznia 2013 17:44:10 UTC+1 u=BFytkownik Fernando=
=20
>> Cacciola napisa=B3:
>>
>>> On Fri, Jan 25, 2013 at 1:12 PM, Andrzej Krzemie=F1ski <akrz...@gmail.c=
om>=20
>>> wrote:=20
>>> >=20
>>> > int o;=20
>>> > int i =3D o;=20
>>> >=20
>>> > if I change o to be optional<int> the program fails to compile (and I=
=20
>>> can=20
>>> > expect it during refactoring).=20
>>> >=20
>>> > int o;=20
>>> > return 1 =3D=3D o;=20
>>> >=20
>>> > This still compiles after the refactoring.=20
>>> >=20
>>>
>>> OK well at least now I fully recall this argument. I'm not sure I=20
>>> (still) share it but I least I see your concern.=20
>>>
>>> If we keep the choice of poisoning it, the rationale should be more=20
>>> elaborate at least.=20
>>>
>>
>> Yes, I will do that, regardless of what we decide. Before going to the=
=20
>> arguments, let me state my position here. I believe there are good=20
>> arguments for either case and the decision my need to be arbitrary. I wo=
uld=20
>> only like to pin down the point of the disagreement.
>> =20
>>
>
> I hoped you followed the side thread I started titled "Dynamic of a=20
> proposal"
>
> It turns out that we can present mixed relops as an "optional" feature. W=
e=20
> document the proper wording in case it is accepted and also the proper=20
> wording in case is not. Then Ville (who would be kind enough to champion=
=20
> the proposal once again) will grab feedback, talks to us via email during=
=20
> the meetings, and down the road re-arrange the proposal accordingly for t=
he=20
> final vote.
>
> So, we are essentially collecting arguments at both sides to present in=
=20
> the paper and help the committee make a choice.
>
Sorry, in fact I didn't follow the thread. This is a good idea. And you are=
=20
right, let's still try to discuss the arguments for and against the=20
poisoning, so that we spare the Committee's time as much as possible.
=20
>
> The same goes for get_value_or vs .value_or sv none of that, and=20
> get_pointer vs .get_ptr vs none of that.
>
>
>
>>> First of all, promoting T to optional<T> *is* a fairly common thing to=
=20
>>> do, so we are not looking at a corner case.=20
>>>
>>
>> Yes. But do you mean implicit conversions, or also mixed relops?
>>
>
> I think mixed relops are also not a corner case. At least I'm sure that's=
=20
> the case of the existing user experience with boost::optional since it is=
=20
> allowed.
>
Still, if you could give some examples of where you needed them, it would=
=20
be easier to see why we are allowing the mixed relops.
=20
>
> =20
>>
>>>
>>> If I do that (and I must have, but that was way too long to remember,=
=20
>>> since I've used it myself several years before first proposing it to=20
>>> Boost), I wouldn't at all expect the compiler to warm me if I screwed=
=20
>>> up. I would go to the trouble of looking at each use of the variable=20
>>> and make sure it does something that still makes sense.=20
>>>
>>
>> "I would not expect" -- but this is perhaps because you are used to=20
>> mixed relops in boost::optional and not having this compiler check. If=
=20
>> boost::optional were different, perhaps you would expect this help from =
the=20
>> compiler. We are at the point of deciding what std::optional will offer=
=20
>> (similarity to boost::optional is one of the criteria), and also decidin=
g=20
>> what the users can and cannot expect.
>>
>> You are of course right that I'm biased by my experience with=20
> boost::optional, however I was referring to my general approach to change=
s.=20
> Or perhaps I should say general approach to programming: I don't rely too=
=20
> much on compiler errors to help me discover problems in the code. That's=
=20
> perhaps also biased by my work experience in which 99% of my mistakes hav=
e=20
> nothing to do with syntax errors.
>
> =20
>
>>
>>> When you do that sort of change you are explicitly deciding that the=20
>>> value can not exists. That IMO is one significant change, and if you=20
>>> have used ordering operators (=3D=3D and !=3D won't ever be a problem, =
by=20
>>> the way), then you must do something about it because you might need=20
>>> to handle the ordering against 'nothing' in a special way (as is in=20
>>> your example).=20
>>>
>>
>> On the other hand, I if I have the guarantee that mixed relops are=20
>> poisoned I can be relieved of "explicitly deciding" and be guaranteed th=
at=20
>> the compiler will warn me. In a way, we are trading one feature for the=
=20
>> other.
>>
>> Right. And I might understand why some would want the "security" feature=
..=20
> In C++, I prefer versatility and power.
> =20
>
>> =20
>>> No doubt a compiler error would force you to go over that, but I'm not=
=20
>>> sure it is required.=20
>>>
>>> Consider that, for example, we do require that implicit conversions to=
=20
>>> T are disabled. If you had=20
>>>
>>> void foo( int ) ;=20
>>> int i ;=20
>>> foo(i) ;=20
>>>
>>> and you promote int to be optional<T>, then *there is no use case*=20
>>> where passing a nullopt to foo() will work. So silently compiling this=
=20
>>> would be a sure trap.=20
>>>
>>> OTOH, the case of ordering comparison is only problem if it is,=20
>>> depending on the required meaning of the expression.=20
>>>
>>> That is, if you had:=20
>>>
>>> int i ;=20
>>>
>>> if ( i < 1 )=20
>>>
>>> then you changed i to optional<int>()=20
>>>
>>> it might very well happen that, the result of=20
>>>
>>> if ( nullopt < 1 )=20
>>>
>>> returning true is exactly right.=20
>>>
>>> Unlike the case of the implicit conversion to T, the changed semantics=
=20
>>> are not necessarily wrong, and you might not need the compiler to=20
>>> force you to change it.=20
>>>
>>
>> But in your latter example, when you choose to chenge the type of i fro=
m=20
>> int to optional<int> why not also change 1 to make_optional(1)?
>>
>> Hmm, but the class of examples we are considering are all about the case=
=20
> when I changed the type and then I do not change any other code to follow=
=20
> the change.
>
Not entirely. The way I think of it is the following. I want to change my=
=20
type from int to optional<int>, but I am not entirely sure in how many=20
other places I will have to also make some changes to make my refactoring=
=20
complete. I expect that I only type optional<int> in place of int and that=
=20
the compiler will detect all potentially dangerous places for me. (Of=20
course, I can only expect this if relops are poisoned.)
=20
>
> If I would consider to change 1 to make_optional(1) then I'm explicitly=
=20
> looking at the code and then I don't need the compiler to warm me about=
=20
> anything. For instance, I might very well just leave the 1 since I know I=
=20
> don't have to change it.
>
My expectation is this: expression if (i < 1) is identified by the compiler=
=20
as "potential problem". I have to respond to it. Either I refactor it to:
if (i) {
if (*i < 1) //...
}
else {
// new path
}=20
Or I type=20
if (i < make_optional(1))=20
in order to acknowledge that this comparison is still ok
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_1_11443461.1359234596697
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu sobota, 26 stycznia 2013 19:11:16 UTC+1 u=BFytkownik Fernand=
o Cacciola napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote">On Sat, Jan 26, 2013 at 5:09 AM, A=
ndrzej Krzemie=F1ski <span dir=3D"ltr"><<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"5UGBP5iTfhAJ">akrz...@gmail.com</a>>=
;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><br>W dniu pi=B1tek, 25 stycznia 2013 17=
:44:10 UTC+1 u=BFytkownik Fernando Cacciola napisa=B3:<div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex">
On Fri, Jan 25, 2013 at 1:12 PM, Andrzej Krzemie=F1ski <<a>akrz...@gmail=
..com</a>> wrote:
<br>>
<br>> int o;
<br>> int i =3D o;
<br>>
<br>> if I change o to be optional<int> the program fails to compi=
le (and I can
<br>> expect it during refactoring).
<br>>
<br>> int o;
<br>> return 1 =3D=3D o;
<br>>
<br>> This still compiles after the refactoring.
<br>>
<br>
<br>OK well at least now I fully recall this argument. I'm not sure I
<br>(still) share it but I least I see your concern.
<br>
<br>If we keep the choice of poisoning it, the rationale should be more
<br>elaborate at least.
<br></blockquote></div><div><br>Yes, I will do that, regardless of what we =
decide. Before going to the arguments, let me state my position here. I bel=
ieve there are good arguments for either case and the decision my need to b=
e arbitrary. I would only like to pin down the point of the disagreement.<b=
r>
<br></div></blockquote><div><br></div><div>I hoped you followed the s=
ide thread I started titled "Dynamic of a proposal"<br><br></div><div>It tu=
rns out that we can present mixed relops as an "optional" feature. We docum=
ent the proper wording in case it is accepted and also the proper wording i=
n case is not. Then Ville (who would be kind enough to champion the proposa=
l once again) will grab feedback, talks to us via email during the meetings=
, and down the road re-arrange the proposal accordingly for the final vote.=
<br>
<br></div><div>So, we are essentially collecting arguments at both sides to=
present in the paper and help the committee make a choice.<br></div></div>=
</div></div></blockquote><div><br>Sorry, in fact I didn't follow the thread=
.. This is a good idea. And you=20
are right, let's still try to discuss the arguments for and against the=20
poisoning, so that we spare the Committee's time as much as possible.<br>&n=
bsp;<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div><div class=3D"gmail_quote"><div><br></div><div>The same goes for get_=
value_or vs .value_or sv none of that, and get_pointer vs .get_ptr vs none =
of that.<br> <br></div></div></div></div></blockquote><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><d=
iv>
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div></div><div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex">
<br>First of all, promoting T to optional<T> *is* a fairly common thi=
ng to
<br>do, so we are not looking at a corner case.
<br></blockquote></div><div><br>Yes. But do you mean implicit conversions, =
or also mixed relops?<br></div></blockquote><div><br></div><div>I think mix=
ed relops are also not a corner case. At least I'm sure that's the case of =
the existing user experience with boost::optional since it is allowed.<br><=
/div></div></div></div></blockquote><div><br>Still, if you could give some =
examples of where you needed them, it would be easier to see why we are all=
owing the mixed relops.<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>
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div> <br></div><div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex">
<br>If I do that (and I must have, but that was way too long to remember,
<br>since I've used it myself several years before first proposing it to
<br>Boost), I wouldn't at all expect the compiler to warm me if I screwed
<br>up. I would go to the trouble of looking at each use of the variable
<br>and make sure it does something that still makes sense.
<br></blockquote></div><div><br>"I would not expect" -- but this is p=
erhaps because you are used to mixed relops in boost::optional and not havi=
ng this compiler check. If boost::optional were different, perhaps you woul=
d expect this help from the compiler. We are at the point of deciding what =
std::optional will offer (similarity to boost::optional is one of the crite=
ria), and also deciding what the users can and cannot expect.<br>
<br></div></blockquote><div>You are of course right that I'm biased by my e=
xperience with boost::optional, however I was referring to my general appro=
ach to changes. Or perhaps I should say general approach to programming: I =
don't rely too much on compiler errors to help me discover problems in the =
code. That's perhaps also biased by my work experience in which 99% of my m=
istakes have nothing to do with syntax errors.<br>
<br> <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div></div><div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex">
<br>When you do that sort of change you are explicitly deciding that the
<br>value can not exists. That IMO is one significant change, and if you
<br>have used ordering operators (=3D=3D and !=3D won't ever be a problem, =
by
<br>the way), then you must do something about it because you might need
<br>to handle the ordering against 'nothing' in a special way (as is in
<br>your example).
<br></blockquote></div><div><br>On the other hand, I if I have the guarante=
e that mixed relops are poisoned I can be relieved of "explicitly deciding"=
and be guaranteed that the compiler will warn me. In a way, we are trading=
one feature for the other.<br>
<br></div></blockquote><div>Right. And I might understand why some would wa=
nt the "security" feature. In C++, I prefer versatility and power.<br> =
;<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">
<div></div><div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>No doubt a compiler error would force you to go over that, but I'm not
<br>sure it is required.
<br>
<br>Consider that, for example, we do require that implicit conversions to
<br>T are disabled. If you had
<br>
<br>void foo( int ) ;
<br>int i ;
<br>foo(i) ;
<br>
<br>and you promote int to be optional<T>, then *there is no use case=
*
<br>where passing a nullopt to foo() will work. So silently compiling this
<br>would be a sure trap.
<br>
<br>OTOH, the case of ordering comparison is only problem if it is,
<br>depending on the required meaning of the expression.
<br>
<br>That is, if you had:
<br>
<br>int i ;
<br>
<br>if ( i < 1 )
<br>
<br>then you changed i to optional<int>()
<br>
<br>it might very well happen that, the result of
<br>
<br>if ( nullopt < 1 )
<br>
<br>returning true is exactly right.
<br>
<br>Unlike the case of the implicit conversion to T, the changed semantics
<br>are not necessarily wrong, and you might not need the compiler to
<br>force you to change it.
<br></blockquote></div><div><br>But in your latter example, when you =
choose to chenge the type of i from int to optional<int> why not also=
change 1 to make_optional(1)?<br><br></div></blockquote><div>Hmm, but the =
class of examples we are considering are all about the case when I changed =
the type and then I do not change any other code to follow the change.<br><=
/div></div></div></div></blockquote><div><br>Not entirely. The way I think =
of it is the following. I want to change=20
my type from int to optional<int>, but I am not entirely sure in=20
how many other places I will have to also make some changes to make my=20
refactoring complete. I expect that I only type optional<int> in=20
place of int and that the compiler will detect all potentially dangerous
places for me. (Of course, I can only expect this if relops are=20
poisoned.)<br> <br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>
<br></div><div>If I would consider to change 1 to make_optional(1) then I'm=
explicitly looking at the code and then I don't need the compiler to warm =
me about anything. For instance, I might very well just leave the 1 since I=
know I don't have to change it.</div></div></div></div></blockquote><div><=
br>My expectation is this: expression if (i < 1) is identified by the=20
compiler as "potential problem". I have to respond to it. Either I=20
refactor it to:<br><br><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"prettyprint"><d=
iv class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by=
-prettify">if</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">i</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br> </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">if</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(*</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
i </span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" clas=
s=3D"styled-by-prettify">//...</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">e=
lse</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><span st=
yle=3D"color: #800;" class=3D"styled-by-prettify">// new path</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> <br></span></div></code></div><br>Or=
I type <br><div class=3D"prettyprint" style=3D"background-color: rgb(250, =
250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wi=
dth: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D=
"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">=
if</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">i </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> make_optional</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #066;"=
class=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">))</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> <br><br></span></div></code></div><br>in order to acknowledge=
that this comparison is still ok<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1_11443461.1359234596697--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Sat, 26 Jan 2013 13:14:18 -0800 (PST)
Raw View
------=_Part_1254_377579.1359234858785
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu sobota, 26 stycznia 2013 13:39:09 UTC+1 u=BFytkownik R=F3bert D=E1vi=
d=20
napisa=B3:
>
>
>
> 2013. janu=E1r 26., szombat 9:09:33 UTC+1 id=F5pontban Andrzej Krzemie=F1=
ski a=20
> k=F6vetkez=F5t =EDrta:
>>
>> But in your latter example, when you choose to chenge the type of i fro=
m=20
>> int to optional<int> why not also change 1 to make_optional(1)?
>>
>> Do you recall any real-life case where you needed the mized comparison=
=20
>> and converting T to optional<T> wouldn't work?
>> =20
>>
>>
> I don't recall having a real-life case, but I can easily imagine the valu=
e=20
> being a big fat object and I probably not want to copy it, thus to create=
=20
> an optional from it - std::make_optional will copy the object, won't it?
>
> struct BFO{ //Aka BigFatObject
> std::array<double, 10000> data;
> bool operator< (const BFO& right);
> }
>
> void foo() {
> const std::optional<BFO>& opt =3D getOpt();
> const BFO& val =3D getVal();
>
> bool comp1 =3D opt < val;
> bool comp2 =3D opt < std::make_optional(val);
> }
>
> The second also feels a bit unnatural, creating a temporary value, just t=
o=20
> compare it to something..
> Furthermore, what if instead of BigFatObject, is have=20
> ClassWithDeletedCopyConstructor?
>
I almost buy the efficiency argument (although I cannot imagine this in=20
real life), but I do not buy the non-copyable example. It looks to me too=
=20
impossible to have to compare optionals of non-copyable types. These are=20
not values.=20
>
> Regards, Robert=20
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_1254_377579.1359234858785
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu sobota, 26 stycznia 2013 13:39:09 UTC+1 u=BFytkownik R=F3ber=
t D=E1vid napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br><br>20=
13. janu=E1r 26., szombat 9:09:33 UTC+1 id=F5pontban Andrzej Krzemie=F1ski =
a k=F6vetkez=F5t =EDrta:<blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">But in your=
latter example, when you choose to chenge the type of i from int to =
optional<int> why not also change 1 to make_optional(1)?<br><div><br>=
Do you recall any real-life case where you needed the mized comparison and =
converting T to optional<T> wouldn't work?<br> <br></div><br></b=
lockquote><div><br>I don't recall having a real-life case, but I can easily=
imagine the value being a big fat object and I probably not want to copy i=
t, thus to create an optional from it - std::make_optional will copy the ob=
ject, won't it?<br><br><div style=3D"background-color:rgb(250,250,250);bord=
er-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:bre=
ak-word"><code><div><span style=3D"color:#008">struct</span><span style=3D"=
color:#000"> BFO</span><span style=3D"color:#660">{</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#800">//Aka BigFatObject</span><span=
style=3D"color:#000"><br> std</span><span style=3D"color:#660=
">::</span><span style=3D"color:#000">array</span><span style=3D"color:#660=
"><</span><span style=3D"color:#008">double</span><span style=3D"color:#=
660">,</span><span style=3D"color:#000"> </span><span style=3D"color:#066">=
10000</span><span style=3D"color:#660">></span><span style=3D"color:#000=
"> data</span><span style=3D"color:#660">;</span><span style=3D"color:#000"=
><br> </span><span style=3D"color:#008">bool</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">operator</span><span sty=
le=3D"color:#660"><</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">(</span><span style=3D"color:#008">const</span><span style=
=3D"color:#000"> BFO</span><span style=3D"color:#660">&</span><span sty=
le=3D"color:#000"> right</span><span style=3D"color:#660">);</span><span st=
yle=3D"color:#000"><br></span><span style=3D"color:#660">}</span><span styl=
e=3D"color:#000"><br><br></span><span style=3D"color:#008">void</span><span=
style=3D"color:#000"> foo</span><span style=3D"color:#660">()</span><span =
style=3D"color:#000"> </span><span style=3D"color:#660">{</span><span style=
=3D"color:#000"><br> </span><span style=3D"color:#008">const</=
span><span style=3D"color:#000"> std</span><span style=3D"color:#660">::</s=
pan><span style=3D"color:#000">optional</span><span style=3D"color:#660">&l=
t;</span><span style=3D"color:#000">BFO</span><span style=3D"color:#660">&g=
t;&</span><span style=3D"color:#000"> opt </span><span style=3D"color:#=
660">=3D</span><span style=3D"color:#000"> getOpt</span><span style=3D"colo=
r:#660">();</span><span style=3D"color:#000"><br> </span><span=
style=3D"color:#008">const</span><span style=3D"color:#000"> BFO</span><sp=
an style=3D"color:#660">&</span><span style=3D"color:#000"> val </span>=
<span style=3D"color:#660">=3D</span><span style=3D"color:#000"> getVal</sp=
an><span style=3D"color:#660">();</span><span style=3D"color:#000"><br><br>=
</span><span style=3D"color:#008">bool</span><span style=3D"c=
olor:#000"> comp1 </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> opt </span><span style=3D"color:#660"><</span><span sty=
le=3D"color:#000"> val</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"><br> </span><span style=3D"color:#008">bool</s=
pan><span style=3D"color:#000"> comp2 </span><span style=3D"color:#660">=3D=
</span><span style=3D"color:#000"> opt </span><span style=3D"color:#660">&l=
t;</span><span style=3D"color:#000"> std</span><span style=3D"color:#660">:=
:</span><span style=3D"color:#000">make_optional</span><span style=3D"color=
:#660">(</span><span style=3D"color:#000">val</span><span style=3D"color:#6=
60">);</span><span style=3D"color:#000"><br></span><span style=3D"color:#66=
0">}</span><span style=3D"color:#000"><br></span></div></code></div><br>The=
second also feels a bit unnatural, creating a temporary value, just to com=
pare it to something..<br>Furthermore, what if instead of BigFatObject, is =
have ClassWithDeletedCopyConstructo<wbr>r?<br></div></blockquote><div><br>I=
almost buy the efficiency argument (although I cannot imagine this in real=
life), but I do not buy the non-copyable example. It looks to me too impos=
sible to have to compare optionals of non-copyable types. These are not val=
ues. <br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div><br>Regard=
s, Robert <br></div></blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1254_377579.1359234858785--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Sat, 26 Jan 2013 13:18:26 -0800 (PST)
Raw View
------=_Part_1305_16803630.1359235106210
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu sobota, 26 stycznia 2013 19:17:25 UTC+1 u=BFytkownik Fernando Caccio=
la=20
napisa=B3:
>
> On Sat, Jan 26, 2013 at 9:39 AM, R=F3bert D=E1vid <lrd...@gmail.com<javas=
cript:>
> > wrote:
>
>>
>>
>> 2013. janu=E1r 26., szombat 9:09:33 UTC+1 id=F5pontban Andrzej Krzemie=
=F1ski a=20
>> k=F6vetkez=F5t =EDrta:
>>
>>> But in your latter example, when you choose to chenge the type of i=20
>>> from int to optional<int> why not also change 1 to make_optional(1)?
>>>
>>> Do you recall any real-life case where you needed the mized comparison=
=20
>>> and converting T to optional<T> wouldn't work?
>>> =20
>>>
>>>
>> I don't recall having a real-life case, but I can easily imagine the=20
>> value being a big fat object and I probably not want to copy it, thus to=
=20
>> create an optional from it - std::make_optional will copy the object, wo=
n't=20
>> it?
>>
>> struct BFO{ //Aka BigFatObject
>> std::array<double, 10000> data;
>> bool operator< (const BFO& right);
>> }
>>
>> void foo() {
>> const std::optional<BFO>& opt =3D getOpt();
>> const BFO& val =3D getVal();
>>
>> bool comp1 =3D opt < val;
>> bool comp2 =3D opt < std::make_optional(val);
>> }
>>
>> The second also feels a bit unnatural, creating a temporary value, just=
=20
>> to compare it to something..
>> Furthermore, what if instead of BigFatObject, is have=20
>> ClassWithDeletedCopyConstructor?
>>
>> Now that is a very strong argument *in favor* of having mixed relops.=20
> Wrapping an object inside an optional can be expensive, so by forcing the=
=20
> wrapping we are imposing a performance penalty.
>
> People might end up using:
>
> opt ? * opt < val : true ;
>
> *only* to avoid the penalty, in which case, IMO, the lib API would have=
=20
> failed to be reasonably convenient.
>
=20
If such cases are rare, having to type the expression above may be a=20
reasonable compromise between safety and expressive power of the interface.=
=20
(of course, under some perception of "reasonable")=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_1305_16803630.1359235106210
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu sobota, 26 stycznia 2013 19:17:25 UTC+1 u=BFytkownik Fernand=
o Cacciola napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote">On Sat, Jan 26, 2013 at 9:39 AM, R=
=F3bert D=E1vid <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"MTDHvzETwSoJ">lrd...@gmail.com</a>></span>=
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><br>2013. janu=E1r 26., szombat 9:09:33 =
UTC+1 id=F5pontban Andrzej Krzemie=F1ski a k=F6vetkez=F5t =EDrta:<div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
But in your latter example, when you choose to chenge the type of i f=
rom int to optional<int> why not also change 1 to make_optional(1)?<b=
r><div><br>Do you recall any real-life case where you needed the mized comp=
arison and converting T to optional<T> wouldn't work?<br>
<br></div><br></blockquote></div><div><br>I don't recall having a rea=
l-life case, but I can easily imagine the value being a big fat object and =
I probably not want to copy it, thus to create an optional from it - std::m=
ake_optional will copy the object, won't it?<br>
<br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,18=
7,187);border-style:solid;border-width:1px;word-wrap:break-word"><code><div=
><span style=3D"color:#008">struct</span><span> BFO</span><span style=3D"co=
lor:#660">{</span><span> </span><span style=3D"color:#800">//Aka BigFatObje=
ct</span><span><br>
std</span><span style=3D"color:#660">::</span><span>array</sp=
an><span style=3D"color:#660"><</span><span style=3D"color:#008">double<=
/span><span style=3D"color:#660">,</span><span> </span><span style=3D"color=
:#066">10000</span><span style=3D"color:#660">></span><span> data</span>=
<span style=3D"color:#660">;</span><span><br>
</span><span style=3D"color:#008">bool</span><span> </span><s=
pan style=3D"color:#008">operator</span><span style=3D"color:#660"><</sp=
an><span> </span><span style=3D"color:#660">(</span><span style=3D"color:#0=
08">const</span><span> BFO</span><span style=3D"color:#660">&</span><sp=
an> right</span><span style=3D"color:#660">);</span><span><br>
</span><span style=3D"color:#660">}</span><span><br><br></span><span style=
=3D"color:#008">void</span><span> foo</span><span style=3D"color:#660">()</=
span><span> </span><span style=3D"color:#660">{</span><span><br>
</span><span style=3D"color:#008">const</span><span> std</spa=
n><span style=3D"color:#660">::</span><span>optional</span><span style=3D"c=
olor:#660"><</span><span>BFO</span><span style=3D"color:#660">>&<=
/span><span> opt </span><span style=3D"color:#660">=3D</span><span> getOpt<=
/span><span style=3D"color:#660">();</span><span><br>
</span><span style=3D"color:#008">const</span><span> BFO</spa=
n><span style=3D"color:#660">&</span><span> val </span><span style=3D"c=
olor:#660">=3D</span><span> getVal</span><span style=3D"color:#660">();</sp=
an><span><br>
<br> </span><span style=3D"color:#008">bool</span><span> comp1=
</span><span style=3D"color:#660">=3D</span><span> opt </span><span style=
=3D"color:#660"><</span><span> val</span><span style=3D"color:#660">;</s=
pan><span><br>
</span><span style=3D"color:#008">bool</span><span> comp2 </s=
pan><span style=3D"color:#660">=3D</span><span> opt </span><span style=3D"c=
olor:#660"><</span><span> std</span><span style=3D"color:#660">::</span>=
<span>make_optional</span><span style=3D"color:#660">(</span><span>val</spa=
n><span style=3D"color:#660">);</span><span><br>
</span><span style=3D"color:#660">}</span><span><br></span></div></code></d=
iv><br>The second also feels a bit unnatural, creating a temporary value, j=
ust to compare it to something..<br>Furthermore, what if instead of BigFatO=
bject, is have ClassWithDeletedCopyConstructo<wbr>r?<br>
<br></div></blockquote><div>Now that is a very strong argument *in favor* o=
f having mixed relops. Wrapping an object inside an optional can be expensi=
ve, so by forcing the wrapping we are imposing a performance penalty.<br>
<br></div><div>People might end up using:<br><br></div><div>opt ? * opt <=
; val : true ;<br><br></div><div>*only* to avoid the penalty, in which case=
, IMO, the lib API would have failed to be reasonably convenient.<br></div>=
</div></div></div></blockquote><div> <br>If such cases are rare, havin=
g to type the expression above may be a reasonable compromise between safet=
y and expressive power of the interface. (of course, under some perception =
of "reasonable") <br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1305_16803630.1359235106210--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Sat, 26 Jan 2013 13:26:28 -0800 (PST)
Raw View
------=_Part_516_1286165.1359235588309
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu sobota, 26 stycznia 2013 18:53:54 UTC+1 u=BFytkownik Fernando Caccio=
la=20
napisa=B3:
>
> On Sat, Jan 26, 2013 at 8:57 AM, Andrzej Krzemie=F1ski <akrz...@gmail.com=
<javascript:>>=20
> wrote:
> >
> > I admit the example is silly
>
> The problem with the example is not that is silly but that it doesn't=20
> really exemplify the possible problem you are trying to showcase.
> Like Vladimir said, the code is not really testing that b is not false. I=
f=20
> it did, it would not be a problem if 'b' where nullopt because that is no=
t=20
> false, just like any other value !=3D false is not false. If the code aft=
er=20
> the changed failed because it actually meant to test b =3D=3D true.
>
Given that bool has only two values, expression "b !=3D false" is a valid a=
nd=20
correct (albeit unusual) way of testing for value true. But I only give=20
this example because I am in a hurry, and cannot come up with a good one at=
=20
the point.
Imagine that for your variable 'count' of type int there is some value that=
=20
you have to watch out for:
bool Type::count_is_fine()
{
return count !=3D 12;
}
Now, if I promote 'count' to optional<int> with the null-state indicating=
=20
that the count has not yet been determined, the comparison may become=20
incorrect because 'count' may be in fact 12 but has not been determined yet=
..
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_516_1286165.1359235588309
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu sobota, 26 stycznia 2013 18:53:54 UTC+1 u=BFytkownik Fernand=
o Cacciola napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Sat, Jan 26, 2013 at 8:57 AM, Andrzej Krzemie=F1ski <<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"dK5zkod6XkEJ">a=
krz...@gmail.com</a>> wrote:<br>><br>> I admit the example is sill=
y<br><br>The problem with the example is not that is silly but that it does=
n't really exemplify the possible problem you are trying to showcase.<br>
Like Vladimir said, the code is not really testing that b is not false. If =
it did, it would not be a problem if 'b' where nullopt because that is not =
false, just like any other value !=3D false is not false. If the code after=
the changed failed because it actually meant to test b =3D=3D true.<br></d=
iv></blockquote><div><br>Given that bool has only two values, expression "b=
!=3D false" is a valid=20
and correct (albeit unusual) way of testing for value true. But I only=20
give this example because I am in a hurry, and cannot come up with a=20
good one at the point.<br><br>Imagine that for your variable 'count' of typ=
e int there is some value that you have to watch out for:<br><br><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
style=3D"color: #008;" class=3D"styled-by-prettify">bool</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">Type</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">count_is_fine</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br> </span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> count </span><span style=3D"color: #660;" class=3D"styled-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">12</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span></div></code></div><br>Now, if I prom=
ote 'count' to optional<int> with the null-state indicating that the =
count has not yet been determined, the comparison may become incorrect beca=
use 'count' may be in fact 12 but has not been determined yet.<br><br></div=
>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_516_1286165.1359235588309--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Sat, 26 Jan 2013 22:30:49 +0100
Raw View
On Sat, Jan 26, 2013 at 7:17 PM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> People might end up using:
>
> opt ? * opt < val : true ;
>
> *only* to avoid the penalty, in which case, IMO, the lib API would have
> failed to be reasonably convenient.
That's equivalent to !opt || *opt < val
Same as you'd write if opt were a pointer and quite reasonable IMO.
--
Olaf
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Sat, 26 Jan 2013 17:28:15 -0600
Raw View
On Sat, Jan 26, 2013 at 3:26 PM, Andrzej Krzemie=C5=84ski
<akrzemi1@gmail.com> wrote:>
> Imagine that for your variable 'count' of type int there is some value th=
at
> you have to watch out for:
>
> bool Type::count_is_fine()
> {
> return count !=3D 12;
> }
>
> Now, if I promote 'count' to optional<int> with the null-state indicating
> that the count has not yet been determined, the comparison may become
> incorrect because 'count' may be in fact 12 but has not been determined y=
et.
Again, is optional<T> a T with one more possible value? If so, I suppose
count !=3D 12;
should just work as is. Why? From the aspect of `12`, which is an `int`,
optional<int> is just, maybe, { -2147483649...2147483647 }, where there
is nothing wrong to compare them. optional<int>{nullopt} is determined,
just we can't use it's value, which is some value out of range.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Sun, 27 Jan 2013 11:24:51 +1100
Raw View
--14dae9340cf3593e6604d43a300d
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
On Sat, Jan 26, 2013 at 10:57 PM, Andrzej Krzemie=F1ski <akrzemi1@gmail.com=
>wrote:
> W dniu sobota, 26 stycznia 2013 09:27:49 UTC+1 u=BFytkownik Vladimir Bato=
v
> napisa=B3:
>
>> On Sat, Jan 26, 2013 at 6:46 PM, Andrzej Krzemie=F1ski <akrz...@gmail.co=
m>wrote:
>>
>>> W dniu pi=B1tek, 25 stycznia 2013 18:55:27 UTC+1 u=BFytkownik Mikael
>>> Kilpel=E4inen napisa=B3:
>>>
>>>> 25.1.2013 17:44, Fernando Cacciola kirjoitti:
>>>> > When you do that sort of change you are explicitly deciding that the
>>>> > value can not exists. That IMO is one significant change, and if you
>>>> > have used ordering operators (=3D=3D and !=3D won't ever be a proble=
m, by
>>>> > the way),
>>>> This is what i tried to say earlier, =3D=3D and !=3D are not affected =
by the
>>>> rationale.
>>>>
>>>
>>> Well, my intuition tells me even =3D=3D and !=3D may be affected. For i=
nstance:
>>>
>>> bool is_true( bool b )
>>> {
>>> return b !=3D false;
>>> }
>>>
>>> Now if we change b from bool to optional<bool>... I am pretty sure one
>>> can come up with a more realistic example.
>>>
>>
>> I suspect the problem with the example above is that its original
>> implementation seems flawed. It does not test the b=3D=3Dtrue but b!=3Df=
alse and
>> applies the reasoning -- the value can only be in one of the two states
>> (true, false), therefore, if that's not one state (not 'false'), then it
>> must be the other one (true). Obviously, that reasoning falters with 3
>> states (disengaged, true, false) and not an 'optional' "fault".
>>
>
> I admit the example is silly, but you should not treat my entire argument
> as silly. I just cannot come up with a better example right now. But you
> get the idea: even operator!=3D can fail to meet your expectations if you
> promote your type T to optional<T>.
>
>
Andrzej,
I never treated your example as silly. If you got that impression, I
apologize profusely. In fact, it is quite the opposite. I find your example
*extremely* representative of real-world situations when an implementation
works by accident and breaks when it's extended/generalized/refactored.
Deployment of 'optional' in your example highlighted the implementation
flaw. Blaming 'optional' for the failure would be like shooting the
messenger. So, I think I am with Fernando on this one.
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
--14dae9340cf3593e6604d43a300d
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_quote">On Sat, Jan 26, 2013 at 10:57 PM, Andrzej Krzemi=
e=F1ski <span dir=3D"ltr"><<a href=3D"mailto:akrzemi1@gmail.com" target=
=3D"_blank">akrzemi1@gmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
W dniu sobota, 26 stycznia 2013 09:27:49 UTC+1 u=BFytkownik Vladimir Batov =
napisa=B3:<div><div class=3D"h5"><blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv class=3D"gmail_quote">
On Sat, Jan 26, 2013 at 6:46 PM, Andrzej Krzemie=F1ski <span dir=3D"ltr">&l=
t;<a>akrz...@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:1=
ex">
W dniu pi=B1tek, 25 stycznia 2013 18:55:27 UTC+1 u=BFytkownik Mikael Kilpel=
=E4inen napisa=B3:<div><blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">25.1.2013 17=
:44, Fernando Cacciola kirjoitti:
<br>> When you do that sort of change you are explicitly deciding that t=
he
<br>> value can not exists. That IMO is one significant change, and if y=
ou
<br>> have used ordering operators (=3D=3D and !=3D won't ever be a =
problem, by
<br>> the way),
<br>This is what i tried to say earlier, =3D=3D and !=3D are not affected b=
y the=20
<br>rationale.
<br></blockquote></div><div><br>Well, my intuition tells me even =3D=3D and=
!=3D may be affected. For instance:<br><br>=A0 bool is_true( bool b )<br>=
=A0 {<br>=A0=A0=A0 return b !=3D false;<br>=A0 }<br>=A0<br>Now if we change=
b from bool to optional<bool>... I am pretty sure one can come up wi=
th a more realistic example.<br>
</div></blockquote></div><br>I suspect the problem with the example above i=
s that its original implementation seems flawed. It does not test the b=3D=
=3Dtrue but b!=3Dfalse and applies the reasoning -- the value can only be i=
n one of the two states (true, false), therefore, if that's not one sta=
te (not 'false'), then it must be the other one (true). Obviously, =
that reasoning falters with 3 states (disengaged, true, false) and not an &=
#39;optional' "fault". <br>
</blockquote></div></div><div><br>I admit the example is silly, but you sho=
uld not treat my entire argument as silly. I just cannot come up with a bet=
ter example right now. But you get the idea: even operator!=3D can fail to =
meet your expectations if you promote your type T to optional<T>.=A0 =
<br>
<br></div></blockquote><div><br>Andrzej,<br><br>I never treated your exampl=
e as silly. If you got that impression, I apologize profusely. In fact, it =
is quite the opposite. I find your example *extremely* representative of re=
al-world situations when an implementation works by accident and breaks whe=
n it's extended/generalized/refactored. Deployment of 'optional=
9; in your example highlighted the implementation flaw.=A0 Blaming 'opt=
ional' for the failure would be like shooting the messenger. So, I thin=
k I am with Fernando on this one.<br>
</div></div><br>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--14dae9340cf3593e6604d43a300d--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Sun, 27 Jan 2013 00:09:40 -0500
Raw View
On Fri, Jan 25, 2013 at 12:38 PM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> On Fri, Jan 25, 2013 at 2:29 PM, Tony V E <tvaneerd@gmail.com> wrote:
>>
>> I would conclude the exact opposite. Given that you don't know how I
>> might want nullopt < 1 to behave, why do you pick one and standardize
>> it?
>>
> What would you say about:
>
> nullopt < make_optional(1)
>
> ?
>
> Because I don't know just as well. Or would you object to that also?
>
No objection. optional<T> is a type, I expect it to have rules and
relationships. It's your type, so you can make the rules.
It is only when you mix it with my type that I start to wonder.
And pragmatically, it works nice for using optional<> in maps and
such. And I think the chance of mistake or unexpected consequences
are lower.
>> In particular:
>>
>>> OTOH, the case of ordering comparison is only problem if it is,
>>> depending on the required meaning of the expression.
>>>
>>
>> You don't know the requirements, thus why would you decide for me?
>>
>> You don't know the meaning, why give it one?
>>
> Neither I do in the case of
>
> nullopt < make_optional(1)
>
> yet that is proposed as valid.
>
>
Again, it is your type, I am just a user. I expect you to give it
rules. You know the meaning as well as anyone. You *should* give the
type meaning/semantics - otherwise it is useless. A type without
algebra (accompanying functions, operators, etc) is not really a type.
It is just a bag of bits. Maybe the question is where to draw the
line. I draw it at the type, not at the fuzzy area between types.
I guess some of my viewpoint is because I see optional<T> as a
*different type than T*, not just a "T-plus". Maybe I am too strict
about my types. Also, just to be clear, I could just as easily argue
the other side - I do see how, since we have implicit conversion, the
mixed relops just fall out naturally, and are a reasonable default.
But I do think the poisoning argument has validity -
logical/philosophical validity - beyond just examples of possible
"this code mistakenly compiled". Mistaken compilation is also a good
argument, but I think you mentioned wanting to here something more
fundamental. To me what is fundamental is that optional<T> and T are
truly different types. You don't compare vector<T> and T, or T* and
T.
Speaking of "reasonable default" - can the default be easily
overridden when needed? ie what if my use case would work out better
with nullopt always greater (maybe I want the indeterminate stuff to
be listed last - ie cars for sale, listed by price, no price given
means list it last) - can I do that (and still use operator syntax, ie
not resorting to functions like "my_less_than()"). So:
1. opt rel opt
- If this is mostly used in things like map/set I can easily supply my
own less predicate in the template. map<optional<Price>,
my_less_than> is fine here.
- Where is "opt rel opt" used _directly_ in code? Is that common? In
particular, is it common beyond the case of I know neither are
nullopt, I'm just too lazy to write *opt < *opt. (Or too lazy to
check for nullopt and don't really care which way nullopt is ordered)
- If I do care, can I override it? ie if I write
bool operator<(optional<Price> const & a, optional<Price> const & b) {
return !b || a < b; }
does that override the generic optional<> operator, or does it clash
and give a compiler error? I think this works since it is chosen over
a templatized version. Although if optional's operator< was written
as a member function it may actually clash I think. (as the member
function is not a template function, it is a normal function of a
template class)
2. mixed: opt<T> rel T (and vice-versa)
This, at least in our examples and in cases where uses of T get
changed to optional<T>, happens directly in code, not maps/sets.
Again, can I override this for my T if...
- poisoned by the standard?
- not poisoned?
If opt rel T is not poisoned by default, can I, say for my company's
coding standards, write a header file that _does_ poison it - for
*all* types T, not just a particular one? Then have that header be
included everywhere?
And with my custom poisoning, can I still "unpoison" particular cases
(types) as needed?
Basically, I'm wondering what the workarounds are for anyone that
doesn't like whatever gets decided for std::optional. If it can be
customized in all cases, OK; but if one design choice makes it harder
to workaround than the other, maybe we should pick the design that is
easiest to allow the user to customize as they please.
Sort of like the policy based suggestion, but without a policy-template design.
Tony
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Sun, 27 Jan 2013 00:15:54 -0500
Raw View
On Sat, Jan 26, 2013 at 7:06 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
>
>>
>> * Strong NaN :
>> (dis @ dis) =3D=3D false
>> (dis @ eng) =3D=3D false
>
>
> Perhaps a bit off-topic, but let me remark on the difference I observe
> between NaN and null-state.
> NaN -- the way I understand it -- is the effect of 'erroneous' computatio=
n:
> the arguments provided to the operation did not fit into the operation's
> domain. It is the floating-point standard of signalling a logic error. (O=
r
> am I wrong?). Null-state, on the other hand is the deliberate choice to
> signal the (correct) lack of any other value.
>
I think optional<> is used by many as a easy way to signal an error.
May not be the best use, but used that way nonetheless.
I think NaN _could_ be used as "unknown", but I suspect that is much
more rare. And would become even more rare once we have optional<>
:-)
Tony
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Sun, 27 Jan 2013 00:16:54 -0500
Raw View
On Sun, Jan 27, 2013 at 12:15 AM, Tony V E <tvaneerd@gmail.com> wrote:
> On Sat, Jan 26, 2013 at 7:06 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail=
..com> wrote:
>>
>>>
>>> * Strong NaN :
>>> (dis @ dis) =3D=3D false
>>> (dis @ eng) =3D=3D false
>>
>>
>> Perhaps a bit off-topic, but let me remark on the difference I observe
>> between NaN and null-state.
>> NaN -- the way I understand it -- is the effect of 'erroneous' computati=
on:
>> the arguments provided to the operation did not fit into the operation's
>> domain. It is the floating-point standard of signalling a logic error. (=
Or
>> am I wrong?). Null-state, on the other hand is the deliberate choice to
>> signal the (correct) lack of any other value.
>>
>
> I think optional<> is used by many as a easy way to signal an error.
> May not be the best use, but used that way nonetheless.
> I think NaN _could_ be used as "unknown", but I suspect that is much
> more rare. And would become even more rare once we have optional<>
> :-)
>
> Tony
.... but overall, I think your point is an important distinction.
Tony
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Sun, 27 Jan 2013 00:27:05 -0500
Raw View
On Sat, Jan 26, 2013 at 6:57 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
>
> I admit the example is silly
class RenderSurface
{
....
bool _dirty; // was there a change? does it need to be rerendered?
.....
};
void draw()
{
if (!_dirty) {
return;
}
}
You can probably see where this is going. Someone decides that, for
whatever reason, _dirty should be an optional<bool>. ie
- true =3D dirty
- false =3D clean
- nullopt - don't know, dirtiness not calculated. (note that
calculating dirty may be long, but still less than rendering, so not
the same as dirty =3D=3D true)
So that, I think, is a realistic example.
You could also say it is realistic for the programmer to search for
_dirty and check where it is used and decide what needs to be changed.
Or you could say that there was this one bug where only in a certain
case dirtiness was unknown so some "smart" programmer thought
optional<bool> would solve that case, and then missed the bugs he
introduced in other parts of the code...
Tony
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Matias Capeletto <matias.capeletto@gmail.com>
Date: Sun, 27 Jan 2013 08:45:58 +0100
Raw View
On Sun, Jan 27, 2013 at 6:27 AM, Tony V E <tvaneerd@gmail.com> wrote:
> So that, I think, is a realistic example.
Interesting discussion. Here is another example I was thinking about yesterday:
// Isometric if sy is nullopt
void lib_resize( double sx, optional<double> sy = nullopt );
..
void user_resize( double sx, double sy ) {
if( sx < 0 || sy < 0 ) {
// Handle mirror special case
}
lib_resize(sx,sy);
}
What will happen here if somebody will change sy parameter to be
optional in the user_resize function. With mixed relops,
user_resize(2) will silently be considered a mirror case.
I understand Fernando's argument about wanting to handle the very
common scenario of mixed relops without performance penalty and with
better code than:
opt ? *opt < val : true ; // or... !opt || *opt < val
opt ? *opt < val : false ; // or... opt && *opt < val
Maybe that is an utility that is worth including, but that the user
will have to choose to use:
less_or( opt, val, true ) ; // Internally opt ? *opt < val : orResult ;
less_or( opt, val, false ) ;
Or following the .value_or function, also given a member .less_or
function to optional.
With this, the user_resize will fail to compile when refactoring the
param to be optional and the user could solve it like:
void user_resize( double sx, double sy ) {
if( sx < 0 || sy.less_or(0, sx<0) ) {
// Handle mirror special case
}
lib_resize(sx,sy);
}
Best regards
Matias
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Matias Capeletto <matias.capeletto@gmail.com>
Date: Sun, 27 Jan 2013 08:48:09 +0100
Raw View
Now with the right code...
On Sun, Jan 27, 2013 at 8:45 AM, Matias Capeletto
<matias.capeletto@gmail.com> wrote:
> With this, the user_resize will fail to compile when refactoring the
> param to be optional and the user could solve it like:
void user_resize( double sx, optional<double> sy = nullopt ) {
if( sx < 0 || sy.less_or(0, sx<0) ) {
// Handle mirror special case
}
lib_resize(sx,sy);
}
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Kazutoshi Satoda <k_satoda@f2.dion.ne.jp>
Date: Sun, 27 Jan 2013 18:33:10 +0900
Raw View
On 2013/01/27 06:09 +0900, Andrzej Krzemie=C5=84ski wrote:
> ... The way I think of it is the following. I want to change my
> type from int to optional<int>, but I am not entirely sure in how many
> other places I will have to also make some changes to make my refactoring
> complete. I expect that I only type optional<int> in place of int and tha=
t
> the compiler will detect all potentially dangerous places for me. (Of
> course, I can only expect this if relops are poisoned.)
Please consider the case where the type of member was changed from T to
optional<T> with this code:
void Class::DoSomething()
{
if (member)
DoIt();
else
DoThat();
}
If T was a type which can be convertible to bool (e.g. bool, int, ...)
the semantics of the code would be silently changed with no diagnostics.
(Sorry if I'm missing something.)
Given the above as a similar example of "potentially dangerous places"
like mixed comparisons, would you drop the conversion to bool from=20
std::optional<> ? I believe you wouldn't.
If mixed comparison was poisoned for your reasonings, users would feel
more that "the compiler will detect all potentially dangerous places for
me". I think it will be more dangerous if some subtle cases, like above,
will left. (I think of sizeof(member), or meta function calls for
decltype(member) may exhibit more cases.)
I'm used to and OK with that the programmer is responsible to ensure the
safety of a change of type of a variable; "Look through all use of the
variable".
So my opinion is, please allow mixed comparison (in more efficient form
than boost::optional which causes implicit conversions).
--=20
k_satoda
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Sun, 27 Jan 2013 17:38:49 -0300
Raw View
--047d7b66f515416b4904d44b2840
Content-Type: text/plain; charset=ISO-8859-1
Considering that it seems that different users have different expectations
about what this should do, how about putting relops in a separate namespace?
Such that:
(A)
#include <optional>
void foo()
{
std:optional<int> a ,b ;
( a < b ) ; // ERROR, there is no definition for operator <
}
(B)
#include <optional>
#include <optional_relops>
using std::optional_rel_ops ;
void foo()
{
std:optional<int> a ,b ;
( a < b ) ; // OK now, relops in scope
int c ;
( a < c ) ; // ERROR; mixed < poisoned
}
(C)
#include <optional>
#include <optional_relops>
using std::optional_mixed_rel_ops ;
void foo()
{
std:optional<int> a ,b ;
( a < b ) ; // OK now, relops in scope
int c ;
( a < c ) ; // OK: mxied relops enabled now
}
That totally works for me. Thoughts?
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--047d7b66f515416b4904d44b2840
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_extra">Considering th=
at it seems that different users have different expectations about what thi=
s should do, how about putting relops in a separate namespace?<br></div><di=
v class=3D"gmail_extra">
Such that:<br><br></div><div class=3D"gmail_extra">(A)<br><br></div><div cl=
ass=3D"gmail_extra">#include <optional><br><br></div><div class=3D"gm=
ail_extra">void foo()<br>{<br></div><div class=3D"gmail_extra">=A0 std:opti=
onal<int> a ,b ;<br>
</div><div class=3D"gmail_extra">=A0 ( a < b ) ; // ERROR, there is no d=
efinition for operator <<br></div><div class=3D"gmail_extra">}<br></div>=
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">(B)<br><br =
clear=3D"all">
</div><div class=3D"gmail_extra"><div class=3D"gmail_extra">#include <op=
tional><br>#include <optional_relops><br><br></div><div class=3D"g=
mail_extra">using std::optional_rel_ops ;<br><br></div><div class=3D"gmail_=
extra">
void foo()<br>{<br></div><div class=3D"gmail_extra">=A0 std:optional<int=
> a ,b ;<br></div><div class=3D"gmail_extra">=A0 ( a < b ) ; // OK no=
w, relops in scope<br><br></div><div class=3D"gmail_extra">=A0 int c ;<br><=
/div><div class=3D"gmail_extra">
=A0 ( a < c ) ; // ERROR;=A0 mixed < poisoned <br></div><div class=3D=
"gmail_extra">}<br><br><div class=3D"gmail_extra">(C)<br><br clear=3D"all">=
</div><div class=3D"gmail_extra">#include <optional><br>#include <=
optional_relops><br>
<br></div><div class=3D"gmail_extra">using std::optional_mixed_rel_ops ;<br=
><br></div><div class=3D"gmail_extra">void foo()<br>{<br></div><div class=
=3D"gmail_extra">=A0 std:optional<int> a ,b ;<br></div><div class=3D"=
gmail_extra">
=A0 ( a < b ) ; // OK now, relops in scope<br><br></div><div class=3D"gm=
ail_extra">=A0 int c ;<br></div><div class=3D"gmail_extra">=A0 ( a < c )=
; // OK: mxied relops enabled now<br></div><div class=3D"gmail_extra">}<br=
><br></div>
<div class=3D"gmail_extra">That totally works for me. Thoughts?<br></div><b=
r></div><div class=3D"gmail_extra"><br clear=3D"all"></div><br>-- <br>Ferna=
ndo Cacciola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.scisof=
t-consulting.com">http://www.scisoft-consulting.com</a>
</div></div></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--047d7b66f515416b4904d44b2840--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Sun, 27 Jan 2013 17:48:38 -0300
Raw View
--047d7b3a7ff85f409604d44b4bbb
Content-Type: text/plain; charset=ISO-8859-1
On Sun, Jan 27, 2013 at 5:38 PM, Fernando Cacciola <
fernando.cacciola@gmail.com> wrote:
> Considering that it seems that different users have different expectations
> about what this should do, how about putting relops in a separate namespace?
>
Actually, now that I think about it, we don't even need the namespaces. It
suffices to have the "versions" in separate headers:
#include <optional>
NO relops defined
#include <optional_relops>
relops with poisoned mixed defined
#include <optional_mixed_relops>
mixed relops left unpoissoned (so there are defined ttough implicit
conversions from T to OPT T)
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--047d7b3a7ff85f409604d44b4bbb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Jan 27, 2013 at 5:38 PM, Fernando Cacciola <span dir=3D"ltr"><<a hre=
f=3D"mailto:fernando.cacciola@gmail.com" target=3D"_blank">fernando.cacciol=
a@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 dir=
=3D"ltr"><div class=3D"gmail_extra">Considering that it seems that differen=
t users have different expectations about what this should do, how about pu=
tting relops in a separate namespace?<br>
</div></div></div></blockquote><div><br></div><div>Actually, now that I thi=
nk about it, we don't even need the namespaces. It suffices to have the=
"versions" in separate headers:<br><br></div><div>#include <o=
ptional><br>
<br></div><div>NO relops defined<br><br>#include <optional_relops><br=
><br></div><div>relops with poisoned mixed defined<br><br>#include <opti=
onal_mixed_relops><br><br>mixed relops left unpoissoned (so there are de=
fined ttough implicit conversions from T to OPT T)<br>
<br></div></div><br>-- <br>Fernando Cacciola<br>SciSoft Consulting, Founder=
<br><a href=3D"http://www.scisoft-consulting.com">http://www.scisoft-consul=
ting.com</a>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--047d7b3a7ff85f409604d44b4bbb--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 27 Jan 2013 22:49:32 +0200
Raw View
On 27 January 2013 22:38, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
> Considering that it seems that different users have different expectations
> about what this should do, how about putting relops in a separate namespace?
> Such that:
> (A)
> #include <optional>
> void foo()
> {
> std:optional<int> a ,b ;
> ( a < b ) ; // ERROR, there is no definition for operator <
> }
> (B)
> #include <optional>
> #include <optional_relops>
> using std::optional_rel_ops ;
> void foo()
> {
> std:optional<int> a ,b ;
> ( a < b ) ; // OK now, relops in scope
>
> int c ;
> ( a < c ) ; // ERROR; mixed < poisoned
> }
> (C)
> #include <optional>
> #include <optional_relops>
> using std::optional_mixed_rel_ops ;
> void foo()
> {
> std:optional<int> a ,b ;
> ( a < b ) ; // OK now, relops in scope
> int c ;
> ( a < c ) ; // OK: mxied relops enabled now
> }
> That totally works for me. Thoughts?
I think it's neat. I think it's non-expert-unfriendly. I would prefer
your just making a stand
on whether to support or not to support (mixed) relops, and since
existing practice in boost
supports them, I would follow that.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Sun, 27 Jan 2013 18:03:33 -0600
Raw View
--047d7bb70dfe67fb4a04d44e04de
Content-Type: text/plain; charset=ISO-8859-1
On 27 January 2013 14:49, Ville Voutilainen <ville.voutilainen@gmail.com>wrote:
> I think it's non-expert-unfriendly. I would prefer
> your just making a stand
> on whether to support or not to support (mixed) relops, and since
> existing practice in boost
> supports them, I would follow that.
>
+1. Please don't turn optional into something overly complicated to use.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--047d7bb70dfe67fb4a04d44e04de
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_quote">On 27 January 2013 14:49, Ville Voutilainen <spa=
n dir=3D"ltr"><<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"=
_blank">ville.voutilainen@gmail.com</a>></span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
<div id=3D":13o">I think it's non-expert-unfriendly. I would prefer<br>
your just making a stand<br>
on whether to support or not to support (mixed) relops, and since<br>
existing practice in boost<br>
supports them, I would follow that.</div></blockquote></div><br>+1. =A0Plea=
se don't turn optional into something overly complicated to use.<br>-- =
<br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"mailto:nevin@ev=
iloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=A0 (847) 6=
91-1404
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--047d7bb70dfe67fb4a04d44e04de--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Mon, 28 Jan 2013 00:25:15 -0800 (PST)
Raw View
------=_Part_83_22687683.1359361515168
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu niedziela, 27 stycznia 2013 00:28:15 UTC+1 u=BFytkownik Zhihao Yuan=
=20
napisa=B3:
>
> On Sat, Jan 26, 2013 at 3:26 PM, Andrzej Krzemie=F1ski=20
> <akrz...@gmail.com <javascript:>> wrote:>=20
> > Imagine that for your variable 'count' of type int there is some value=
=20
> that=20
> > you have to watch out for:=20
> >=20
> > bool Type::count_is_fine()=20
> > {=20
> > return count !=3D 12;=20
> > }=20
> >=20
> > Now, if I promote 'count' to optional<int> with the null-state=20
> indicating=20
> > that the count has not yet been determined, the comparison may become=
=20
> > incorrect because 'count' may be in fact 12 but has not been determined=
=20
> yet.=20
>
> Again, is optional<T> a T with one more possible value? If so, I suppose=
=20
>
> count !=3D 12;=20
>
> should just work as is. Why? From the aspect of `12`, which is an `int`=
,=20
> optional<int> is just, maybe, { -2147483649...2147483647 }, where there=
=20
> is nothing wrong to compare them. optional<int>{nullopt} is determined,=
=20
> just we can't use it's value, which is some value out of range.=20
>
Yeah, I agree. If we allow the model "one additional value of T", we also=
=20
need to accept the above effect of the comparison.=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_83_22687683.1359361515168
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu niedziela, 27 stycznia 2013 00:28:15 UTC+1 u=BFytkownik Zhih=
ao Yuan napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Sat, Jan =
26, 2013 at 3:26 PM, Andrzej Krzemie=F1ski
<br><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
P1mehTfhaE0J">akrz...@gmail.com</a>> wrote:>
<br>> Imagine that for your variable 'count' of type int there is some v=
alue that
<br>> you have to watch out for:
<br>>
<br>> bool Type::count_is_fine()
<br>> {
<br>> return count !=3D 12;
<br>> }
<br>>
<br>> Now, if I promote 'count' to optional<int> with the null-sta=
te indicating
<br>> that the count has not yet been determined, the comparison may bec=
ome
<br>> incorrect because 'count' may be in fact 12 but has not been deter=
mined yet.
<br>
<br>Again, is optional<T> a T with one more possible value? If =
so, I suppose
<br>
<br> count !=3D 12;
<br>
<br>should just work as is. Why? From the aspect of `12`, which=
is an `int`,
<br>optional<int> is just, maybe, { -2147483649...2147483647 }, where=
there
<br>is nothing wrong to compare them. optional<int>{nullopt} is=
determined,
<br>just we can't use it's value, which is some value out of range.
<br></blockquote><div><br>Yeah, I agree. If we allow the model "one additio=
nal value of T", we also need to accept the above effect of the comparison.=
<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_83_22687683.1359361515168--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Mon, 28 Jan 2013 00:27:35 -0800 (PST)
Raw View
------=_Part_900_17950683.1359361655776
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu niedziela, 27 stycznia 2013 01:24:51 UTC+1 u=BFytkownik Vladimir Bat=
ov=20
napisa=B3:
>
> On Sat, Jan 26, 2013 at 10:57 PM, Andrzej Krzemie=F1ski <akrz...@gmail.co=
m<javascript:>
> > wrote:
>
>> W dniu sobota, 26 stycznia 2013 09:27:49 UTC+1 u=BFytkownik Vladimir Bat=
ov=20
>> napisa=B3:
>>
>>> On Sat, Jan 26, 2013 at 6:46 PM, Andrzej Krzemie=F1ski <akrz...@gmail.c=
om>wrote:
>>>
>>>> W dniu pi=B1tek, 25 stycznia 2013 18:55:27 UTC+1 u=BFytkownik Mikael=
=20
>>>> Kilpel=E4inen napisa=B3:
>>>>
>>>>> 25.1.2013 17:44, Fernando Cacciola kirjoitti:=20
>>>>> > When you do that sort of change you are explicitly deciding that th=
e=20
>>>>> > value can not exists. That IMO is one significant change, and if yo=
u=20
>>>>> > have used ordering operators (=3D=3D and !=3D won't ever be a probl=
em, by=20
>>>>> > the way),=20
>>>>> This is what i tried to say earlier, =3D=3D and !=3D are not affected=
by the=20
>>>>> rationale.=20
>>>>>
>>>>
>>>> Well, my intuition tells me even =3D=3D and !=3D may be affected. For=
=20
>>>> instance:
>>>>
>>>> bool is_true( bool b )
>>>> {
>>>> return b !=3D false;
>>>> }
>>>> =20
>>>> Now if we change b from bool to optional<bool>... I am pretty sure one=
=20
>>>> can come up with a more realistic example.
>>>>
>>>
>>> I suspect the problem with the example above is that its original=20
>>> implementation seems flawed. It does not test the b=3D=3Dtrue but b!=3D=
false and=20
>>> applies the reasoning -- the value can only be in one of the two states=
=20
>>> (true, false), therefore, if that's not one state (not 'false'), then i=
t=20
>>> must be the other one (true). Obviously, that reasoning falters with 3=
=20
>>> states (disengaged, true, false) and not an 'optional' "fault".=20
>>>
>>
>> I admit the example is silly, but you should not treat my entire argumen=
t=20
>> as silly. I just cannot come up with a better example right now. But you=
=20
>> get the idea: even operator!=3D can fail to meet your expectations if yo=
u=20
>> promote your type T to optional<T>. =20
>>
>>
> Andrzej,
>
> I never treated your example as silly. If you got that impression, I=20
> apologize profusely. In fact, it is quite the opposite. I find your examp=
le=20
> *extremely* representative of real-world situations when an implementatio=
n=20
> works by accident and breaks when it's extended/generalized/refactored.=
=20
> Deployment of 'optional' in your example highlighted the implementation=
=20
> flaw. Blaming 'optional' for the failure would be like shooting the=20
> messenger. So, I think I am with Fernando on this one.
>
=20
Sorry, I never got the negative impression. I only used word "silly"=20
because I was in a hurry. I am slowly getting convinced to mixed relops.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_900_17950683.1359361655776
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu niedziela, 27 stycznia 2013 01:24:51 UTC+1 u=BFytkownik Vlad=
imir Batov napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div clas=
s=3D"gmail_quote">On Sat, Jan 26, 2013 at 10:57 PM, Andrzej Krzemie=F1ski <=
span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscat=
ed-mailto=3D"7p2rqHEO_4MJ">akrz...@gmail.com</a>></span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">
W dniu sobota, 26 stycznia 2013 09:27:49 UTC+1 u=BFytkownik Vladimir Batov =
napisa=B3:<div><div><blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"g=
mail_quote">
On Sat, Jan 26, 2013 at 6:46 PM, Andrzej Krzemie=F1ski <span dir=3D"ltr">&l=
t;<a>akrz...@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:1=
ex">
W dniu pi=B1tek, 25 stycznia 2013 18:55:27 UTC+1 u=BFytkownik Mikael Kilpel=
=E4inen napisa=B3:<div><blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">25.1.2013 17=
:44, Fernando Cacciola kirjoitti:
<br>> When you do that sort of change you are explicitly deciding that t=
he
<br>> value can not exists. That IMO is one significant change, and if y=
ou
<br>> have used ordering operators (=3D=3D and !=3D won't ever be a prob=
lem, by
<br>> the way),
<br>This is what i tried to say earlier, =3D=3D and !=3D are not affected b=
y the=20
<br>rationale.
<br></blockquote></div><div><br>Well, my intuition tells me even =3D=3D and=
!=3D may be affected. For instance:<br><br> bool is_true( bool b )<b=
r> {<br> return b !=3D false;<br> }<br> =
<br>Now if we change b from bool to optional<bool>... I am pretty sur=
e one can come up with a more realistic example.<br>
</div></blockquote></div><br>I suspect the problem with the example above i=
s that its original implementation seems flawed. It does not test the b=3D=
=3Dtrue but b!=3Dfalse and applies the reasoning -- the value can only be i=
n one of the two states (true, false), therefore, if that's not one state (=
not 'false'), then it must be the other one (true). Obviously, that reasoni=
ng falters with 3 states (disengaged, true, false) and not an 'optional' "f=
ault". <br>
</blockquote></div></div><div><br>I admit the example is silly, but you sho=
uld not treat my entire argument as silly. I just cannot come up with a bet=
ter example right now. But you get the idea: even operator!=3D can fail to =
meet your expectations if you promote your type T to optional<T>.&nbs=
p; <br>
<br></div></blockquote><div><br>Andrzej,<br><br>I never treated your exampl=
e as silly. If you got that impression, I apologize profusely. In fact, it =
is quite the opposite. I find your example *extremely* representative of re=
al-world situations when an implementation works by accident and breaks whe=
n it's extended/generalized/<wbr>refactored. Deployment of 'optional' in y=
our example highlighted the implementation flaw. Blaming 'optional' f=
or the failure would be like shooting the messenger. So, I think I am with =
Fernando on this one.<br>
</div></div></blockquote><div> <br>Sorry, I never got the negative imp=
ression. I only used word "silly" because I was in a hurry. I am slowly get=
ting convinced to mixed relops.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_900_17950683.1359361655776--
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Mon, 28 Jan 2013 19:40:42 +1100
Raw View
--14dae9340faf81b4fe04d4553b50
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Jan 28, 2013 at 11:03 AM, Nevin Liber <nevin@eviloverlord.com>wrote:
> On 27 January 2013 14:49, Ville Voutilainen <ville.voutilainen@gmail.com>wrote:
>
>> I think it's non-expert-unfriendly. I would prefer
>> your just making a stand
>> on whether to support or not to support (mixed) relops, and since
>> existing practice in boost
>> supports them, I would follow that.
>>
>
> +1. Please don't turn optional into something overly complicated to use.
>
+1.
Fernando, your desire to accommodate varying requirements is quite noble.
However, some requirements/desires are, well, excessive/unjustified. People
arguing against mixed-rel-ops provided many interesting examples
demonstrating how a function fails when its argument is changed from, say,
'int' or bool' to optional<int>, etc. And those failures were quite
impressive. They argued that that would serve as a justification for
banning mixed-rel-ops.
I am really at loss where those expectations (of not needing to adjust
implementation to handle the changed input specifications) stem from. If an
input specs are extended by changing the func. argument from 'bool' to
'int' surely implementation adjustments are needed. Plenty of more subtle
examples. Say, an enum is extended. Then, all functions taking that enum
are most likely need to be re-visited even though their signatures are not
changed at all.
The basic principle of component design is that provided certain input
specifications a module provides certain functionality/output. No component
can give such a guarantee that, if the input specs change, the original
implementation will still work. And, surely, there are no such
expectations. Say, we designed a drainage system for a certain specified
throughput. Surely, it's unreasonable to expect our design will immediately
handle double the throughput.
So, if foo(int) has been implemented to handle the 'int'-based range, then
the expectation that the implementation will automatically handle extended
input (the range + nullopt) without modification is unreasonable.
In reality I suspect those examples to also be quite unlikely. A change of
a function's signature is most often (always?) a reflection/result of
changed requirements which most likely be reflected in the function
implementation. Otherwise, why'd change the signature in the first place?
As a separate counter-argument in favor of mixed-rel-ops might be that an
efficient mixed-rel-ops are too important for other developers using
optional as-is rather than retrofitting it. I think that arument has been
expressed quite a few times already in the thread.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--14dae9340faf81b4fe04d4553b50
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_quote">On Mon, Jan 28, 2013 at 11:03 AM, Nevin Liber <s=
pan dir=3D"ltr"><<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_bl=
ank">nevin@eviloverlord.com</a>></span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
<div class=3D"im"><div class=3D"gmail_quote">On 27 January 2013 14:49, Vill=
e Voutilainen <span dir=3D"ltr"><<a href=3D"mailto:ville.voutilainen@gma=
il.com" target=3D"_blank">ville.voutilainen@gmail.com</a>></span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
<div>I think it's non-expert-unfriendly. I would prefer<br>
your just making a stand<br>
on whether to support or not to support (mixed) relops, and since<br>
existing practice in boost<br>
supports them, I would follow that.</div></blockquote></div><br></div>+1. =
=A0Please don't turn optional into something overly complicated to use.=
<br></blockquote></div>+1.<br><br>Fernando, your desire to accommodate vary=
ing requirements is quite noble. However, some requirements/desires are, we=
ll, excessive/unjustified. People arguing against mixed-rel-ops provided ma=
ny interesting examples demonstrating how a function fails when its argumen=
t is changed from, say, 'int' or bool' to optional<int>, =
etc. And those failures were quite impressive. They argued that that would =
serve as a justification for banning mixed-rel-ops.<br>
<br>I am really at loss where those expectations (of not needing to adjust =
implementation to handle the changed input specifications) stem from. If an=
input specs are extended by changing the func. argument from 'bool'=
; to 'int' surely implementation adjustments are needed. Plenty of =
more subtle examples. Say, an enum is extended. Then, all functions taking =
that enum are most likely need to be re-visited even though their signature=
s are not changed at all. <br>
<br>The basic principle of component design is that provided certain input =
specifications a module provides certain functionality/output. No component=
can give such a guarantee that, if the input specs change, the original im=
plementation will still work. And, surely, there are no such expectations. =
Say, we designed a drainage system for a certain specified throughput. Sure=
ly, it's unreasonable to expect our design will immediately handle doub=
le the throughput. <br>
<br>So, if foo(int) has been implemented to handle the 'int'-based =
range, then the expectation that the implementation will automatically hand=
le extended input (the range + nullopt) without modification is unreasonabl=
e. <br>
<br>In reality I suspect those examples to also be quite unlikely. A change=
of a function's signature is most often (always?) a reflection/result =
of changed requirements which most likely be reflected in the function impl=
ementation. Otherwise, why'd change the signature in the first place? <=
br>
<br>As a separate counter-argument in favor of mixed-rel-ops might be that =
an efficient mixed-rel-ops are too important for other developers using opt=
ional as-is rather than retrofitting it. I think that arument has been expr=
essed quite a few times already in the thread.<br>
<br>=A0<br>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--14dae9340faf81b4fe04d4553b50--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Mon, 28 Jan 2013 00:44:39 -0800 (PST)
Raw View
------=_Part_455_26704720.1359362679773
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu niedziela, 27 stycznia 2013 06:09:40 UTC+1 u=BFytkownik Tony V E=20
napisa=B3:
>
> On Fri, Jan 25, 2013 at 12:38 PM, Fernando Cacciola=20
> <fernando...@gmail.com <javascript:>> wrote:=20
> > On Fri, Jan 25, 2013 at 2:29 PM, Tony V E <tvan...@gmail.com<javascript=
:>>=20
> wrote:=20
> >>=20
> >> I would conclude the exact opposite. Given that you don't know how I=
=20
> >> might want nullopt < 1 to behave, why do you pick one and standardize=
=20
> >> it?=20
> >>=20
> > What would you say about:=20
> >=20
> > nullopt < make_optional(1)=20
> >=20
> > ?=20
> >=20
> > Because I don't know just as well. Or would you object to that also?=
=20
> >=20
>
> No objection. optional<T> is a type, I expect it to have rules and=20
> relationships. It's your type, so you can make the rules.=20
> It is only when you mix it with my type that I start to wonder.=20
>
> And pragmatically, it works nice for using optional<> in maps and=20
> such. And I think the chance of mistake or unexpected consequences=20
> are lower.=20
>
>
> >> In particular:=20
> >>=20
> >>> OTOH, the case of ordering comparison is only problem if it is,=20
> >>> depending on the required meaning of the expression.=20
> >>>=20
> >>=20
> >> You don't know the requirements, thus why would you decide for me?=20
> >>=20
> >> You don't know the meaning, why give it one?=20
> >>=20
> > Neither I do in the case of=20
> >=20
> > nullopt < make_optional(1)=20
> >=20
> > yet that is proposed as valid.=20
> >=20
> >=20
>
> Again, it is your type, I am just a user. I expect you to give it=20
> rules. You know the meaning as well as anyone. You *should* give the=20
> type meaning/semantics - otherwise it is useless. A type without=20
> algebra (accompanying functions, operators, etc) is not really a type.=20
> It is just a bag of bits. Maybe the question is where to draw the=20
> line. I draw it at the type, not at the fuzzy area between types.=20
>
> I guess some of my viewpoint is because I see optional<T> as a=20
> *different type than T*, not just a "T-plus". Maybe I am too strict=20
> about my types. Also, just to be clear, I could just as easily argue=20
> the other side - I do see how, since we have implicit conversion, the=20
> mixed relops just fall out naturally, and are a reasonable default.=20
> But I do think the poisoning argument has validity -=20
> logical/philosophical validity - beyond just examples of possible=20
> "this code mistakenly compiled". Mistaken compilation is also a good=20
> argument, but I think you mentioned wanting to here something more=20
> fundamental. To me what is fundamental is that optional<T> and T are=20
> truly different types. You don't compare vector<T> and T, or T* and=20
> T.=20
>
"optional<T> and T are truly different types" -- this is a reasonable,=20
consistent model of optional<T>, however I believe that if we adopt it, we=
=20
need to consequently ban the implicit conversion from T to optional<T>.=20
vector<T> and T are not implicitly convertible from T either. While it is=
=20
also doable and logical under certain model of optional, I would be really=
=20
reluctant to do it, as it would prevent certain idiomatic use cases of=20
boost::optional. Therefore I personally am closer to adapting the model=20
"one additional value of T".
=20
>
> Speaking of "reasonable default" - can the default be easily=20
> overridden when needed? ie what if my use case would work out better=20
> with nullopt always greater (maybe I want the indeterminate stuff to=20
> be listed last - ie cars for sale, listed by price, no price given=20
> means list it last) - can I do that (and still use operator syntax, ie=20
> not resorting to functions like "my_less_than()"). So:=20
>
> 1. opt rel opt=20
> - If this is mostly used in things like map/set I can easily supply my=20
> own less predicate in the template. map<optional<Price>,=20
> my_less_than> is fine here.=20
> - Where is "opt rel opt" used _directly_ in code? Is that common? In=20
> particular, is it common beyond the case of I know neither are=20
> nullopt, I'm just too lazy to write *opt < *opt. (Or too lazy to=20
> check for nullopt and don't really care which way nullopt is ordered)=20
> - If I do care, can I override it? ie if I write=20
>
> bool operator<(optional<Price> const & a, optional<Price> const & b) {=20
> return !b || a < b; }=20
>
> does that override the generic optional<> operator, or does it clash=20
> and give a compiler error? I think this works since it is chosen over=20
> a templatized version. Although if optional's operator< was written=20
> as a member function it may actually clash I think. (as the member=20
> function is not a template function, it is a normal function of a=20
> template class)=20
>
>
> 2. mixed: opt<T> rel T (and vice-versa)=20
> This, at least in our examples and in cases where uses of T get=20
> changed to optional<T>, happens directly in code, not maps/sets.=20
> Again, can I override this for my T if...=20
> - poisoned by the standard?=20
> - not poisoned?=20
>
> If opt rel T is not poisoned by default, can I, say for my company's=20
> coding standards, write a header file that _does_ poison it - for=20
> *all* types T, not just a particular one? Then have that header be=20
> included everywhere?=20
> And with my custom poisoning, can I still "unpoison" particular cases=20
> (types) as needed?=20
>
> Basically, I'm wondering what the workarounds are for anyone that=20
> doesn't like whatever gets decided for std::optional. If it can be=20
> customized in all cases, OK; but if one design choice makes it harder=20
> to workaround than the other, maybe we should pick the design that is=20
> easiest to allow the user to customize as they please.=20
>
> Sort of like the policy based suggestion, but without a policy-template=
=20
> design.=20
>
Is it allowable by the standard? And does it have a precedent? For=20
instance, optional<T>::operator< can be implemented using function template=
=20
std::optional_less<T>. Users would be allowed to specialize this template=
=20
as they see fit. But I remember when "general purpose conversion mechanism"=
=20
was reviewed in Boost (was it Boost.Convert?), people concluded that such=
=20
mechanism would encourage breaking the ODR. Some libraries with with=20
customized operator would be linked against these without the customization=
..
You can always build your type atop optional<T> and provide any comparison=
=20
you want:
struct MyOptional : std::optional<T>
{
using optional<T>::optional;
bool operator<(MyOptional const&) const;
}
=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_455_26704720.1359362679773
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu niedziela, 27 stycznia 2013 06:09:40 UTC+1 u=BFytkownik Tony=
V E napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Jan 25,=
2013 at 12:38 PM, Fernando Cacciola
<br><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
kqU_lwXY4I0J">fernando...@gmail.com</a>> wrote:
<br>> On Fri, Jan 25, 2013 at 2:29 PM, Tony V E <<a href=3D"javascrip=
t:" target=3D"_blank" gdf-obfuscated-mailto=3D"kqU_lwXY4I0J">tvan...@gmail.=
com</a>> wrote:
<br>>>
<br>>> I would conclude the exact opposite. Given that you don'=
t know how I
<br>>> might want nullopt < 1 to behave, why do you pick one and s=
tandardize
<br>>> it?
<br>>>
<br>> What would you say about:
<br>>
<br>> nullopt < make_optional(1)
<br>>
<br>> ?
<br>>
<br>> Because I don't know just as well. Or would you object to th=
at also?
<br>>
<br>
<br>No objection. optional<T> is a type, I expect it to have ru=
les and
<br>relationships. It's your type, so you can make the rules.
<br>It is only when you mix it with my type that I start to wonder.
<br>
<br>And pragmatically, it works nice for using optional<> in maps and
<br>such. And I think the chance of mistake or unexpected consequence=
s
<br>are lower.
<br>
<br>
<br>>> In particular:
<br>>>
<br>>>> OTOH, the case of ordering comparison is only problem if i=
t is,
<br>>>> depending on the required meaning of the expression.
<br>>>>
<br>>>
<br>>> You don't know the requirements, thus why would you decide for=
me?
<br>>>
<br>>> You don't know the meaning, why give it one?
<br>>>
<br>> Neither I do in the case of
<br>>
<br>> nullopt < make_optional(1)
<br>>
<br>> yet that is proposed as valid.
<br>>
<br>>
<br>
<br>Again, it is your type, I am just a user. I expect you to give it
<br>rules. You know the meaning as well as anyone. You *should*=
give the
<br>type meaning/semantics - otherwise it is useless. A type without
<br>algebra (accompanying functions, operators, etc) is not really a type.
<br> It is just a bag of bits. Maybe the question is where to dr=
aw the
<br>line. I draw it at the type, not at the fuzzy area between types.
<br>
<br>I guess some of my viewpoint is because I see optional<T> as a
<br>*different type than T*, not just a "T-plus". Maybe I am too stri=
ct
<br>about my types. Also, just to be clear, I could just as easily ar=
gue
<br>the other side - I do see how, since we have implicit conversion, the
<br>mixed relops just fall out naturally, and are a reasonable default.
<br>But I do think the poisoning argument has validity -
<br>logical/philosophical validity - beyond just examples of possible
<br>"this code mistakenly compiled". Mistaken compilation is also a g=
ood
<br>argument, but I think you mentioned wanting to here something more
<br>fundamental. To me what is fundamental is that optional<T> =
and T are
<br>truly different types. You don't compare vector<T> and T, o=
r T* and
<br>T.
<br></blockquote><div><br>"optional<T> and T are
truly different types" -- this is a reasonable, consistent model of optiona=
l<T>, however I believe that if we adopt it, we need to consequently =
ban the implicit conversion from T to optional<T>. vector<T> an=
d T are not implicitly convertible from T either. While it is also doable a=
nd logical under certain model of optional, I would be really relucta=
nt to do it, as it would prevent certain idiomatic use cases of boost::opti=
onal. Therefore I personally am closer to adapting the model "one additiona=
l value of T".<br> </div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Speaking of "reasonable default" - can the default be easily
<br>overridden when needed? ie what if my use case would work out better
<br>with nullopt always greater (maybe I want the indeterminate stuff to
<br>be listed last - ie cars for sale, listed by price, no price given
<br>means list it last) - can I do that (and still use operator syntax, ie
<br>not resorting to functions like "my_less_than()"). So:
<br>
<br>1. opt rel opt
<br>- If this is mostly used in things like map/set I can easily supply my
<br>own less predicate in the template. map<optional<Price>,
<br>my_less_than> is fine here.
<br>- Where is "opt rel opt" used _directly_ in code? Is that common?=
In
<br>particular, is it common beyond the case of I know neither are
<br>nullopt, I'm just too lazy to write *opt < *opt. (Or too lazy =
to
<br>check for nullopt and don't really care which way nullopt is ordered)
<br>- If I do care, can I override it? ie if I write
<br>
<br>bool operator<(optional<Price> const & a, optional<Pric=
e> const & b) {
<br>return !b || a < b; }
<br>
<br>does that override the generic optional<> operator, or does it cl=
ash
<br>and give a compiler error? I think this works since it is chosen =
over
<br>a templatized version. Although if optional's operator< was wr=
itten
<br>as a member function it may actually clash I think. (as the member
<br>function is not a template function, it is a normal function of a
<br>template class)
<br>
<br>
<br>2. mixed: opt<T> rel T (and vice-versa)
<br>This, at least in our examples and in cases where uses of T get
<br>changed to optional<T>, happens directly in code, not maps/sets.
<br>Again, can I override this for my T if...
<br>- poisoned by the standard?
<br>- not poisoned?
<br>
<br>If opt rel T is not poisoned by default, can I, say for my company's
<br>coding standards, write a header file that _does_ poison it - for
<br>*all* types T, not just a particular one? Then have that header b=
e
<br>included everywhere?
<br>And with my custom poisoning, can I still "unpoison" particular cases
<br>(types) as needed?
<br>
<br>Basically, I'm wondering what the workarounds are for anyone that
<br>doesn't like whatever gets decided for std::optional. If it can b=
e
<br>customized in all cases, OK; but if one design choice makes it harder
<br>to workaround than the other, maybe we should pick the design that is
<br>easiest to allow the user to customize as they please.
<br>
<br>Sort of like the policy based suggestion, but without a policy-template=
design.
<br></blockquote><div><br>Is it allowable by the standard? And does it have=
a precedent? For instance, optional<T>::operator< can be implemen=
ted using function template std::optional_less<T>. Users would be all=
owed to specialize this template as they see fit. But I remember when "gene=
ral purpose conversion mechanism" was reviewed in Boost (was it Boost.Conve=
rt?), people concluded that such mechanism would encourage breaking the ODR=
.. Some libraries with with customized operator would be linked against thes=
e without the customization.<br><br>You can always build your type atop opt=
ional<T> and provide any comparison you want:<br><div class=3D"pretty=
print" 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"prettyprint"><div class=3D"subprettyprint"><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color:=
#008;" class=3D"styled-by-prettify">struct</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">MyOptional</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
::</span><span 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: #000;" class=3D"styled-by-prettify">T</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br> </span><span style=3D"color: #008;"=
class=3D"styled-by-prettify">using</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> optional</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">>::</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">optional</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&n=
bsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">bool<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">operator</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify"><(</span><span styl=
e=3D"color: #606;" class=3D"styled-by-prettify">MyOptional</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&)</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </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"style=
d-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span></div></code></div><br><br><br><br> </div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_455_26704720.1359362679773--
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Mon, 28 Jan 2013 19:52:43 +1100
Raw View
--14dae9340faf83ad5704d45566ab
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
On Mon, Jan 28, 2013 at 7:27 PM, Andrzej Krzemie=F1ski <akrzemi1@gmail.com>=
wrote:
> W dniu niedziela, 27 stycznia 2013 01:24:51 UTC+1 u=BFytkownik Vladimir
> Batov napisa=B3:
>
>> On Sat, Jan 26, 2013 at 10:57 PM, Andrzej Krzemie=F1ski <akrz...@gmail.c=
om>wrote:
>>
>>> W dniu sobota, 26 stycznia 2013 09:27:49 UTC+1 u=BFytkownik Vladimir Ba=
tov
>>> napisa=B3:
>>>
>>>> On Sat, Jan 26, 2013 at 6:46 PM, Andrzej Krzemie=F1ski <akrz...@gmail.=
com
>>>> > wrote:
>>>>
>>>>> W dniu pi=B1tek, 25 stycznia 2013 18:55:27 UTC+1 u=BFytkownik Mikael
>>>>> Kilpel=E4inen napisa=B3:
>>>>>
>>>>>> 25.1.2013 17:44, Fernando Cacciola kirjoitti:
>>>>>> > When you do that sort of change you are explicitly deciding that
>>>>>> the
>>>>>> > value can not exists. That IMO is one significant change, and if
>>>>>> you
>>>>>> > have used ordering operators (=3D=3D and !=3D won't ever be a prob=
lem, by
>>>>>> > the way),
>>>>>> This is what i tried to say earlier, =3D=3D and !=3D are not affecte=
d by
>>>>>> the
>>>>>> rationale.
>>>>>>
>>>>>
>>>>> Well, my intuition tells me even =3D=3D and !=3D may be affected. For
>>>>> instance:
>>>>>
>>>>> bool is_true( bool b )
>>>>> {
>>>>> return b !=3D false;
>>>>> }
>>>>>
>>>>> Now if we change b from bool to optional<bool>... I am pretty sure on=
e
>>>>> can come up with a more realistic example.
>>>>>
>>>>
>>>> I suspect the problem with the example above is that its original
>>>> implementation seems flawed. It does not test the b=3D=3Dtrue but b!=
=3Dfalse and
>>>> applies the reasoning -- the value can only be in one of the two state=
s
>>>> (true, false), therefore, if that's not one state (not 'false'), then =
it
>>>> must be the other one (true). Obviously, that reasoning falters with 3
>>>> states (disengaged, true, false) and not an 'optional' "fault".
>>>>
>>>
>>> I admit the example is silly, but you should not treat my entire
>>> argument as silly. I just cannot come up with a better example right no=
w.
>>> But you get the idea: even operator!=3D can fail to meet your expectati=
ons if
>>> you promote your type T to optional<T>.
>>>
>>>
>> Andrzej,
>>
>> I never treated your example as silly. If you got that impression, I
>> apologize profusely. In fact, it is quite the opposite. I find your exam=
ple
>> *extremely* representative of real-world situations when an implementati=
on
>> works by accident and breaks when it's extended/generalized/**refactored=
..
>> Deployment of 'optional' in your example highlighted the implementation
>> flaw. Blaming 'optional' for the failure would be like shooting the
>> messenger. So, I think I am with Fernando on this one.
>>
>
> Sorry, I never got the negative impression. I only used word "silly"
> because I was in a hurry. I am slowly getting convinced to mixed relops.
>
I am glad to hear that. In fact, when I look at it again I want to take
"works by accident" back. Your example works correctly based on the
original input specifications. I.e. the implementation *matches* the input
specs. Obviously, a change of the func. signature (regardless(!) if
'optional' is involved or not) indicates a change of the input specs.
Therefore, I argue that the expectation of the original implementation to
still *match* the input is, well, excessive.
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
--14dae9340faf83ad5704d45566ab
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_quote">On Mon, Jan 28, 2013 at 7:27 PM, Andrzej Krzemie=
=F1ski <span dir=3D"ltr"><<a href=3D"mailto:akrzemi1@gmail.com" target=
=3D"_blank">akrzemi1@gmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
W dniu niedziela, 27 stycznia 2013 01:24:51 UTC+1 u=BFytkownik Vladimir Bat=
ov napisa=B3:<div><div class=3D"h5"><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div class=3D"gmail_quote">
On Sat, Jan 26, 2013 at 10:57 PM, Andrzej Krzemie=F1ski <span dir=3D"ltr">&=
lt;<a>akrz...@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">
W dniu sobota, 26 stycznia 2013 09:27:49 UTC+1 u=BFytkownik Vladimir Batov =
napisa=B3:<div><div><blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"g=
mail_quote">
On Sat, Jan 26, 2013 at 6:46 PM, Andrzej Krzemie=F1ski <span dir=3D"ltr">&l=
t;<a>akrz...@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:1=
ex">
W dniu pi=B1tek, 25 stycznia 2013 18:55:27 UTC+1 u=BFytkownik Mikael Kilpel=
=E4inen napisa=B3:<div><blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">25.1.2013 17=
:44, Fernando Cacciola kirjoitti:
<br>> When you do that sort of change you are explicitly deciding that t=
he
<br>> value can not exists. That IMO is one significant change, and if y=
ou
<br>> have used ordering operators (=3D=3D and !=3D won't ever be a =
problem, by
<br>> the way),
<br>This is what i tried to say earlier, =3D=3D and !=3D are not affected b=
y the=20
<br>rationale.
<br></blockquote></div><div><br>Well, my intuition tells me even =3D=3D and=
!=3D may be affected. For instance:<br><br>=A0 bool is_true( bool b )<br>=
=A0 {<br>=A0=A0=A0 return b !=3D false;<br>=A0 }<br>=A0<br>Now if we change=
b from bool to optional<bool>... I am pretty sure one can come up wi=
th a more realistic example.<br>
</div></blockquote></div><br>I suspect the problem with the example above i=
s that its original implementation seems flawed. It does not test the b=3D=
=3Dtrue but b!=3Dfalse and applies the reasoning -- the value can only be i=
n one of the two states (true, false), therefore, if that's not one sta=
te (not 'false'), then it must be the other one (true). Obviously, =
that reasoning falters with 3 states (disengaged, true, false) and not an &=
#39;optional' "fault". <br>
</blockquote></div></div><div><br>I admit the example is silly, but you sho=
uld not treat my entire argument as silly. I just cannot come up with a bet=
ter example right now. But you get the idea: even operator!=3D can fail to =
meet your expectations if you promote your type T to optional<T>.=A0 =
<br>
<br></div></blockquote><div><br>Andrzej,<br><br>I never treated your exampl=
e as silly. If you got that impression, I apologize profusely. In fact, it =
is quite the opposite. I find your example *extremely* representative of re=
al-world situations when an implementation works by accident and breaks whe=
n it's extended/generalized/<u></u>refactored. Deployment of 'opti=
onal' in your example highlighted the implementation flaw.=A0 Blaming &=
#39;optional' for the failure would be like shooting the messenger. So,=
I think I am with Fernando on this one.<br>
</div></div></blockquote></div></div><div>=A0<br>Sorry, I never got the neg=
ative impression. I only used word "silly" because I was in a hur=
ry. I am slowly getting convinced to mixed relops.<br></div></blockquote>
<div><br>I am glad to hear that. In fact, when I look at it again I want to=
take "works by accident" back. Your example works correctly base=
d on the original input specifications. I.e. the implementation *matches* t=
he input specs. Obviously, a change of the func. signature (regardless(!) i=
f 'optional' is involved or not) indicates a change of the input sp=
ecs. Therefore, I argue that the expectation of the original implementation=
to still *match* the input is, well, excessive.=A0 <br>
</div></div><br>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--14dae9340faf83ad5704d45566ab--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 28 Jan 2013 11:01:04 +0200
Raw View
On 28 January 2013 10:44, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> wro=
te:
> "optional<T> and T are truly different types" -- this is a reasonable,
> consistent model of optional<T>, however I believe that if we adopt it, w=
e
> need to consequently ban the implicit conversion from T to optional<T>.
Again, this is against years of practical experience. Just because T
and optional<T>
are "truly different types" is no reason to ban implicit conversions
or mixed relops.
The concerns people have about that causing potential bugs boils down to a =
very
simple and blunt statement: people who are utterly helpless with debugging =
and
testing need so much hand-holding that we can't have any useful
utilities because
we have to be paranoid about things people can get wrong. Sure, it's unfort=
unate
if refactorings cause silent breakage, but we do have to consider how
uncomfortable
we want optional's interface to be for people who have the slightest
clue about what
they are doing when refactoring code.
My recommendation is to not mess with the implicit T->optional<T> conversio=
n,
and to allow mixed relops. For the arguably theoretical and rare cases
where that
will cause problems, the School of Hard Knocks will teach people to not edi=
t
code with a hacksaw.
I'm not against compile-time safety. I'm just saying that the
trade-off it would cause
here is not worth the trouble, IMO.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Mon, 28 Jan 2013 01:12:41 -0800 (PST)
Raw View
------=_Part_46_33401382.1359364361484
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu niedziela, 27 stycznia 2013 10:33:10 UTC+1 u=BFytkownik Kazutoshi=20
SATODA napisa=B3:
>
> On 2013/01/27 06:09 +0900, Andrzej Krzemie=EF=BF=BDski wrote:=20
> > ... The way I think of it is the following. I want to change my=20
> > type from int to optional<int>, but I am not entirely sure in how many=
=20
> > other places I will have to also make some changes to make my=20
> refactoring=20
> > complete. I expect that I only type optional<int> in place of int and=
=20
> that=20
> > the compiler will detect all potentially dangerous places for me. (Of=
=20
> > course, I can only expect this if relops are poisoned.)=20
>
> Please consider the case where the type of member was changed from T to=
=20
> optional<T> with this code:=20
> void Class::DoSomething()=20
> {=20
> if (member)=20
> DoIt();=20
> else=20
> DoThat();=20
> }=20
> If T was a type which can be convertible to bool (e.g. bool, int, ...)=20
> the semantics of the code would be silently changed with no diagnostics.=
=20
> (Sorry if I'm missing something.)=20
>
> Given the above as a similar example of "potentially dangerous places"=20
> like mixed comparisons, would you drop the conversion to bool from=20
> std::optional<> ? I believe you wouldn't.=20
>
> If mixed comparison was poisoned for your reasonings, users would feel=20
> more that "the compiler will detect all potentially dangerous places for=
=20
> me". I think it will be more dangerous if some subtle cases, like above,=
=20
> will left. (I think of sizeof(member), or meta function calls for=20
> decltype(member) may exhibit more cases.)=20
>
This is an excellent analysis. And I buy the argument. Since we cannot=20
offer a 100% "refactoring safety", half measures are as good as no=20
guarantee.
> I'm used to and OK with that the programmer is responsible to ensure the=
=20
> safety of a change of type of a variable; "Look through all use of the=20
> variable".=20
>
> So my opinion is, please allow mixed comparison (in more efficient form=
=20
> than boost::optional which causes implicit conversions).=20
>
> --=20
> k_satoda=20
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_46_33401382.1359364361484
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu niedziela, 27 stycznia 2013 10:33:10 UTC+1 u=BFytkownik Kazu=
toshi SATODA napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2013=
/01/27 06:09 +0900, Andrzej Krzemie=EF=BF=BDski wrote:
<br>> ... The way I think of it is the following. I want to change my
<br>> type from int to optional<int>, but I am not entirely sure i=
n how many
<br>> other places I will have to also make some changes to make my refa=
ctoring
<br>> complete. I expect that I only type optional<int> in place o=
f int and that
<br>> the compiler will detect all potentially dangerous places for me. =
(Of
<br>> course, I can only expect this if relops are poisoned.)
<br>
<br>Please consider the case where the type of member was changed from T to
<br>optional<T> with this code:
<br> void Class::DoSomething()
<br> {
<br> if (member)
<br> DoIt();
<br> else
<br> DoThat();
<br> }
<br>If T was a type which can be convertible to bool (e.g. bool, int, ...)
<br>the semantics of the code would be silently changed with no diagnostics=
..
<br>(Sorry if I'm missing something.)
<br>
<br>Given the above as a similar example of "potentially dangerous places"
<br>like mixed comparisons, would you drop the conversion to bool from=20
<br>std::optional<> ? I believe you wouldn't.
<br>
<br>If mixed comparison was poisoned for your reasonings, users would feel
<br>more that "the compiler will detect all potentially dangerous places fo=
r
<br>me". I think it will be more dangerous if some subtle cases, like above=
,
<br>will left. (I think of sizeof(member), or meta function calls for
<br>decltype(member) may exhibit more cases.)
<br></blockquote><div><br>This is an excellent analysis. And I buy the argu=
ment. Since we cannot offer a 100% "refactoring safety", half measures are =
as good as no guarantee.<br><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;">
<br>I'm used to and OK with that the programmer is responsible to ensure th=
e
<br>safety of a change of type of a variable; "Look through all use of the
<br>variable".
<br>
<br>So my opinion is, please allow mixed comparison (in more efficient form
<br>than boost::optional which causes implicit conversions).
<br>
<br>--=20
<br>k_satoda
<br></blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_46_33401382.1359364361484--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Mon, 28 Jan 2013 11:13:32 +0100
Raw View
On Mon, Jan 28, 2013 at 10:01 AM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> The concerns people have about that causing potential bugs boils down to a very
> simple and blunt statement: people who are utterly helpless with debugging and
> testing need so much hand-holding that we can't have any useful
> utilities because
> we have to be paranoid about things people can get wrong. Sure, it's unfortunate
> if refactorings cause silent breakage, but we do have to consider how
> uncomfortable
> we want optional's interface to be for people who have the slightest
> clue about what
> they are doing when refactoring code.
I don't think that's the core of this problem.
Supporting mixed relops is a bit like answering "What is the color of
this non-existing ball?" The color is undefined and I don't really
know how to map undefined to bool.
Even normal relops might suffer from this issue.
--
Olaf
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Mon, 28 Jan 2013 11:15:34 +0100
Raw View
On Mon, Jan 28, 2013 at 11:13 AM, Olaf van der Spek
<olafvdspek@gmail.com> wrote:
> On Mon, Jan 28, 2013 at 10:01 AM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
>> The concerns people have about that causing potential bugs boils down to a very
>> simple and blunt statement: people who are utterly helpless with debugging and
>> testing need so much hand-holding that we can't have any useful
>> utilities because
>> we have to be paranoid about things people can get wrong. Sure, it's unfortunate
>> if refactorings cause silent breakage, but we do have to consider how
>> uncomfortable
>> we want optional's interface to be for people who have the slightest
>> clue about what
>> they are doing when refactoring code.
>
> I don't think that's the core of this problem.
> Supporting mixed relops is a bit like answering "What is the color of
> this non-existing ball?" The color is undefined and I don't really
> know how to map undefined to bool.
> Even normal relops might suffer from this issue.
Let me also take this opportunity to request some links to real-world
client code using (mixed) relops.
Arguing about concrete code might be a bit easier.
--
Olaf
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 28 Jan 2013 12:28:00 +0200
Raw View
On 28 January 2013 12:15, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>> I don't think that's the core of this problem.
>> Supporting mixed relops is a bit like answering "What is the color of
>> this non-existing ball?" The color is undefined and I don't really
>> know how to map undefined to bool.
>> Even normal relops might suffer from this issue.
> Let me also take this opportunity to request some links to real-world
> client code using (mixed) relops.
> Arguing about concrete code might be a bit easier.
I suppose the boost people might know about such examples. Regarding mixed
relops, I fail to see how they are any different for optional as they
are for pointers
when nullptr is involved, and that's already well-specified.
People can also continue debating whether optional is pointer-like or
container-like
and whether it has operator* or whether it has X Y and Z. If we fail
to provide a useful
optional, I at least will continue expressing such things with
pointers. If I get paid
enough, I can express such things with a vector of 0-1 elements, but I certainly
don't expect to do that. ;)
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Mon, 28 Jan 2013 11:38:25 +0100
Raw View
On Mon, Jan 28, 2013 at 11:28 AM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
>> Let me also take this opportunity to request some links to real-world
>> client code using (mixed) relops.
>> Arguing about concrete code might be a bit easier.
>
> I suppose the boost people might know about such examples. Regarding mixed
I assume some people here are also using optional.
> relops, I fail to see how they are any different for optional as they
> are for pointers
> when nullptr is involved, and that's already well-specified.
Pointers don't support mixed relops, do they? You either compare the
pointer or the pointee.
--
Olaf
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 28 Jan 2013 12:45:20 +0200
Raw View
On 28 January 2013 12:38, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>> relops, I fail to see how they are any different for optional as they
>> are for pointers
>> when nullptr is involved, and that's already well-specified.
> Pointers don't support mixed relops, do they? You either compare the
> pointer or the pointee.
Very astute, but I think that's not problematic, as I see T and optional<T>
to be similar enough that optional<T> just adds the nullopt to the set of valid
values. Mixed relops are practically just an optimization to avoid having
to construct an optional<T> from a T and then do the comparison. All in
all, the benefits of mixed relops for optional are convincing enough for me
that I think we should have them, I'm not convinced by the concerns that
people have about the potential problems.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Mon, 28 Jan 2013 11:54:23 +0100
Raw View
On Mon, Jan 28, 2013 at 11:45 AM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 28 January 2013 12:38, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>>> relops, I fail to see how they are any different for optional as they
>>> are for pointers
>>> when nullptr is involved, and that's already well-specified.
>> Pointers don't support mixed relops, do they? You either compare the
>> pointer or the pointee.
>
> Very astute, but I think that's not problematic, as I see T and optional<T>
> to be similar enough that optional<T> just adds the nullopt to the set of valid
> values. Mixed relops are practically just an optimization to avoid having
> to construct an optional<T> from a T and then do the comparison.
There's no need to construct a temp optional, you could just use !opt
&& opt < 5 or so.
> All in
> all, the benefits of mixed relops for optional are convincing enough for me
> that I think we should have them, I'm not convinced by the concerns that
> people have about the potential problems.
Shouldn't we be looking at real-world code before concluding that it's
good to have them?
--
Olaf
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 28 Jan 2013 13:15:25 +0200
Raw View
On 28 January 2013 12:54, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>> Very astute, but I think that's not problematic, as I see T and optional<T>
>> to be similar enough that optional<T> just adds the nullopt to the set of valid
>> values. Mixed relops are practically just an optimization to avoid having
>> to construct an optional<T> from a T and then do the comparison.
> There's no need to construct a temp optional, you could just use !opt
> && opt < 5 or so.
Perhaps failing to write *opt < 5 there and using && instead of || is
an indication
that it would be simpler to have mixed relops? :)
>> All in
>> all, the benefits of mixed relops for optional are convincing enough for me
>> that I think we should have them, I'm not convinced by the concerns that
>> people have about the potential problems.
> Shouldn't we be looking at real-world code before concluding that it's
> good to have them?
I would expect people to also show real-world code where it's problematic
to have them. All we have so far from either side of the argument is concocted
examples. Anyway, sure, it would be helpful to look at real-world code before
making conclusions. However, I have made my conclusions - I trust my
judgement and my taste.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Mon, 28 Jan 2013 03:25:11 -0800 (PST)
Raw View
------=_Part_342_27100100.1359372311963
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu poniedzia=B3ek, 28 stycznia 2013 12:15:25 UTC+1 u=BFytkownik Ville=
=20
Voutilainen napisa=B3:
>
> On 28 January 2013 12:54, Olaf van der Spek <olafv...@gmail.com<javascrip=
t:>>=20
> wrote:=20
> >> Very astute, but I think that's not problematic, as I see T and=20
> optional<T>=20
> >> to be similar enough that optional<T> just adds the nullopt to the set=
=20
> of valid=20
> >> values. Mixed relops are practically just an optimization to avoid=20
> having=20
> >> to construct an optional<T> from a T and then do the comparison.=20
> > There's no need to construct a temp optional, you could just use !opt=
=20
> > && opt < 5 or so.=20
>
> Perhaps failing to write *opt < 5 there and using && instead of || is=20
> an indication=20
> that it would be simpler to have mixed relops? :)=20
>
> >> All in=20
> >> all, the benefits of mixed relops for optional are convincing enough=
=20
> for me=20
> >> that I think we should have them, I'm not convinced by the concerns=20
> that=20
> >> people have about the potential problems.=20
> > Shouldn't we be looking at real-world code before concluding that it's=
=20
> > good to have them?=20
>
> I would expect people to also show real-world code where it's problematic=
=20
> to have them. All we have so far from either side of the argument is=20
> concocted=20
> examples.=20
I protest. The example put in the proposal is what really happened to me in=
=20
my work in production code. You could argue if my expectations of=20
"refactoring safety" were legitimate, but I did have them.
On a slightly different subject, there are two "kinds" of arguments against=
=20
poisoning the relops. One is that "refactoring safety" is illegitimate=20
expectation or that it is less important that convenience. The other "kind"=
=20
is that it is impossible to offer "refactoring safety" for std::optional=20
anyway because of optional's contextual conversion to bool, especially (but=
=20
not only) in the case of optional<bool>. I find latter argument (stated=20
already by a couple of people) stronger, because it must sound convincing=
=20
even for people that value the "refactoring safety".
=20
> Anyway, sure, it would be helpful to look at real-world code before=20
> making conclusions. However, I have made my conclusions - I trust my=20
> judgement and my taste.=20
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_342_27100100.1359372311963
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu poniedzia=B3ek, 28 stycznia 2013 12:15:25 UTC+1 u=BFytkownik=
Ville Voutilainen napisa=B3:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">O=
n 28 January 2013 12:54, Olaf van der Spek <<a href=3D"javascript:" targ=
et=3D"_blank" gdf-obfuscated-mailto=3D"5txY1by-tmMJ">olafv...@gmail.com</a>=
> wrote:
<br>>> Very astute, but I think that's not problematic, as I see T an=
d optional<T>
<br>>> to be similar enough that optional<T> just adds the null=
opt to the set of valid
<br>>> values. Mixed relops are practically just an optimization to a=
void having
<br>>> to construct an optional<T> from a T and then do the com=
parison.
<br>> There's no need to construct a temp optional, you could just use !=
opt
<br>> && opt < 5 or so.
<br>
<br>Perhaps failing to write *opt < 5 there and using && instead=
of || is
<br>an indication
<br>that it would be simpler to have mixed relops? :)
<br>
<br>>> All in
<br>>> all, the benefits of mixed relops for optional are convincing =
enough for me
<br>>> that I think we should have them, I'm not convinced by the con=
cerns that
<br>>> people have about the potential problems.
<br>> Shouldn't we be looking at real-world code before concluding that =
it's
<br>> good to have them?
<br>
<br>I would expect people to also show real-world code where it's problemat=
ic
<br>to have them. All we have so far from either side of the argument is co=
ncocted
<br>examples. </blockquote><div><br>I protest. The example put in the propo=
sal is what really happened to me in my work in production code. You could =
argue if my expectations of "refactoring safety" were legitimate, but I did=
have them.<br><br>On a slightly different subject, there are two "kinds" o=
f arguments against poisoning the relops. One is that "refactoring safety" =
is illegitimate expectation or that it is less important that convenience. =
The other "kind" is that it is impossible to offer "refactoring safety" for=
std::optional anyway because of optional's contextual conversion to bool, =
especially (but not only) in the case of optional<bool>. I find latte=
r argument (stated already by a couple of people) stronger, because it must=
sound convincing even for people that value the "refactoring safety".<br>&=
nbsp;<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Anyway, sure, i=
t would be helpful to look at real-world code before
<br>making conclusions. However, I have made my conclusions - I trust my
<br>judgement and my taste.
<br></blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_342_27100100.1359372311963--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Mon, 28 Jan 2013 14:03:46 +0100
Raw View
On Mon, Jan 28, 2013 at 12:15 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 28 January 2013 12:54, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>>> Very astute, but I think that's not problematic, as I see T and optional<T>
>>> to be similar enough that optional<T> just adds the nullopt to the set of valid
>>> values. Mixed relops are practically just an optimization to avoid having
>>> to construct an optional<T> from a T and then do the comparison.
>> There's no need to construct a temp optional, you could just use !opt
>> && opt < 5 or so.
>
> Perhaps failing to write *opt < 5 there
I noticed the missing * when I reread it. And the compiler would've told me.
> and using && instead of || is
> an indication
> that it would be simpler to have mixed relops? :)
It's either opt && opt < 5 or !opt || opt < 5 or an alternative code path.
The right answer can only be given by the one writing that code, not
by the designer of optional.
> I would expect people to also show real-world code where it's problematic
> to have them. All we have so far from either side of the argument is concocted
> examples. Anyway, sure, it would be helpful to look at real-world code before
> making conclusions. However, I have made my conclusions - I trust my
> judgement and my taste.
Really? I don't think that's good enough for ISO standards.
--
Olaf
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 28 Jan 2013 15:29:42 +0200
Raw View
On 28 January 2013 15:03, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> It's either opt && opt < 5 or !opt || opt < 5 or an alternative code path.
> The right answer can only be given by the one writing that code, not
> by the designer of optional.
The designer of optional can give you the same answer with much simpler
syntax. You can still write more complex expression by using the optional
in a low level manner, but I fail to be convinced about that being a reason
not to have mixed relops in optional.
>> I would expect people to also show real-world code where it's problematic
>> to have them. All we have so far from either side of the argument is concocted
>> examples. Anyway, sure, it would be helpful to look at real-world code before
>> making conclusions. However, I have made my conclusions - I trust my
>> judgement and my taste.
> Really? I don't think that's good enough for ISO standards.
Well, if you can show some indisputable facts that show that mixed relops
are definitely a bad idea, I can change my mind. With the current information,
I have given it enough consideration to be able to make my mind about it.
Whether that's "enough" depends on what other people think about it.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Mon, 28 Jan 2013 10:38:00 -0300
Raw View
--047d7b34372c1e52af04d4596542
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Mon, Jan 28, 2013 at 8:25 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om>wrote:
>
> On a slightly different subject, there are two "kinds" of arguments
> against poisoning the relops. One is that "refactoring safety" is
> illegitimate expectation or that it is less important that convenience. T=
he
> other "kind" is that it is impossible to offer "refactoring safety" for
> std::optional anyway because of optional's contextual conversion to bool,
> especially (but not only) in the case of optional<bool>. I find latter
> argument (stated already by a couple of people) stronger, because it must
> sound convincing even for people that value the "refactoring safety".
>
Don't forget the most important argument: performance. By providing a
direct mixed relop, you save wrapping a value into an optional.
BTW, this means that is not sufficient to not poison the operators. We
actually need to provide a direct definition of them, one that specifically
avoids converting one of the arguments to optional<T>
--=20
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
--047d7b34372c1e52af04d4596542
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Jan 28, 2013 at 8:25 AM, Andrzej Krzemie=F1ski <span dir=3D"ltr"><<a=
href=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">akrzemi1@gmail.com</a=
>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><div>On a slightly different subject, th=
ere are two "kinds" of arguments against poisoning the relops. On=
e is that "refactoring safety" is illegitimate expectation or tha=
t it is less important that convenience. The other "kind" is that=
it is impossible to offer "refactoring safety" for std::optional=
anyway because of optional's contextual conversion to bool, especially=
(but not only) in the case of optional<bool>. I find latter argument=
(stated already by a couple of people) stronger, because it must sound con=
vincing even for people that value the "refactoring safety".<br>
</div></blockquote><div><br></div><div>Don't forget the most important =
argument: performance. By providing a direct mixed relop, you save wrapping=
a value into an optional.<br><br></div><div>BTW, this means that is not su=
fficient to not poison the operators. We actually need to provide a direct =
definition of them, one that specifically avoids converting one of the argu=
ments to optional<T><br>
</div></div><br>-- <br>Fernando Cacciola<br>SciSoft Consulting, Founder<br>=
<a href=3D"http://www.scisoft-consulting.com">http://www.scisoft-consulting=
..com</a>
</div></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--047d7b34372c1e52af04d4596542--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Mon, 28 Jan 2013 05:43:29 -0800 (PST)
Raw View
------=_Part_1131_28405275.1359380609197
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu poniedzia=B3ek, 28 stycznia 2013 14:38:00 UTC+1 u=BFytkownik Fernand=
o=20
Cacciola napisa=B3:
>
> On Mon, Jan 28, 2013 at 8:25 AM, Andrzej Krzemie=F1ski <akrz...@gmail.com=
<javascript:>
> > wrote:
>
>>
>> On a slightly different subject, there are two "kinds" of arguments=20
>> against poisoning the relops. One is that "refactoring safety" is=20
>> illegitimate expectation or that it is less important that convenience. =
The=20
>> other "kind" is that it is impossible to offer "refactoring safety" for=
=20
>> std::optional anyway because of optional's contextual conversion to bool=
,=20
>> especially (but not only) in the case of optional<bool>. I find latter=
=20
>> argument (stated already by a couple of people) stronger, because it mus=
t=20
>> sound convincing even for people that value the "refactoring safety".
>>
>
> Don't forget the most important argument: performance. By providing a=20
> direct mixed relop, you save wrapping a value into an optional.
>
> BTW, this means that is not sufficient to not poison the operators. We=20
> actually need to provide a direct definition of them, one that specifical=
ly=20
> avoids converting one of the arguments to optional<T>
>
Quite so. This is on my TODO list.
- &rzej=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_1131_28405275.1359380609197
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu poniedzia=B3ek, 28 stycznia 2013 14:38:00 UTC+1 u=BFytkownik=
Fernando Cacciola napisa=B3:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><div><div class=3D"gmail_quote">On Mon, Jan 28, 2013 at 8:2=
5 AM, Andrzej Krzemie=F1ski <span dir=3D"ltr"><<a href=3D"javascript:" t=
arget=3D"_blank" gdf-obfuscated-mailto=3D"XLMtchuRBvYJ">akrz...@gmail.com</=
a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><div>On a slightly different subject, th=
ere are two "kinds" of arguments against poisoning the relops. One is that =
"refactoring safety" is illegitimate expectation or that it is less importa=
nt that convenience. The other "kind" is that it is impossible to offer "re=
factoring safety" for std::optional anyway because of optional's contextual=
conversion to bool, especially (but not only) in the case of optional<b=
ool>. I find latter argument (stated already by a couple of people) stro=
nger, because it must sound convincing even for people that value the "refa=
ctoring safety".<br>
</div></blockquote><div><br></div><div>Don't forget the most important argu=
ment: performance. By providing a direct mixed relop, you save wrapping a v=
alue into an optional.<br><br></div><div>BTW, this means that is not suffic=
ient to not poison the operators. We actually need to provide a direct defi=
nition of them, one that specifically avoids converting one of the argument=
s to optional<T></div></div></div></div></blockquote><div><br>Quite s=
o. This is on my TODO list.<br>- &rzej <br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1131_28405275.1359380609197--
.
Author: Vincent Jacquet <vjacquet@flowgroup.fr>
Date: Mon, 28 Jan 2013 10:03:40 -0800 (PST)
Raw View
------=_Part_450_19361777.1359396220955
Content-Type: text/plain; charset=ISO-8859-1
The more I think about it, the more I wonder if we shouldn't define two
different representation of the same idea, because I can't decide if I want
a container-like interface or a pointer-like.
And if we want to have both in the same type, we might end up having
neither.
Does the following make sense to you or is it just wasteful ?
Let's define "optional<T>" as a container of T with zero or one element,
and nullable<T>, as a type to add null semantics to a type that does not
already have it, so it can store either a value of type T or nullptr.
Both represents wether we have a value or not, but they have a different
interface.
By definition, optional<T> does not require a special value to indicate
whether it contains a value or to empty the container. Also, as "T" is one
element, T can be implicitly converted to optional<T>. And, as optional<T>
is a container, it is not implicitly converted to bool.
optional<int> i; // default initialization, optional<T> is empty
assert(i.empty());
optional<int> j { 5 }; // optional<T> contains 5
assert(!j.empty());
j.clear(); // removes the value
assert(j.empty());
j = { 6 }; // optional<T> contains 6
i = j; // assignment performing deep copy
assert(!i.empty());
i = 4; // 4 is implicitly converted to optional<T>(4), then deep-copy.
// to get or set the value
int k;
k = *i.begin(); // container interface
k = i.at(0); // container interface, with bound checking
k = i[0]; // container interface
k = i.val(); // helper method?
k = (int&)i; // why not casting? it makes the operation explicit
k = *i; // WRONG, i is not a pointer, nor pointer-like. -> wouldn't work
either.
vector have relational operators, so does optional. As T can be implicitly
converted to optional<T>, mixed comparision would apply.
For those who are concerned, it could be possible to declare the mixed
operators as "poisonous" in a forbidding_of_mixed_optional_rel_ops
namespace.
if(i < 5) { ... } // would work
using namespace forbidding_of_mixed_optional_rel_ops;
if(i < 5) { ... } // won't compile
Considering nullable<T>, by definition, it can be considered as a pointer.
Therefore T cannot be implicitly converted to nullable<T>, as you cannot
write int* p = 5; But, it can be implicitly be converted to bool or
compared to nullptr.
nullable<int> i; // default initialization
assert(i == nullptr);
nullable<int> j { 5 };
assert(j);
j = nullptr; // removes the value, same as j.reset();
assert(j == nullptr);
j = make_nullable(6);
i = j; // asignment performing deep copy. It is a pointer-like interface,
not a pointer. shared_ptr increments the refcount, unique_ptr moves the
pointer...
assert(i);
*i = 4; // sets the value, undefined if i == nullptr
// to get or set the value
int k;
k = i.get(); // smart pointer interface
k = *i; // pointer-like interface, -> would work too
k = i.val(); // helper method?
// to set, we could define
i.reset();
i.val();
Like unique_ptr and shared_ptr, nullable<T> has relational operators, that
can be mixed only with nullptr_t. We could provide also
template <class T, class U>
bool operator== (const nullable<T>& lhs, const nullable<U>& rhs) noexcept;
if T and U can compare.
And, finally, we could also provide explicit conversion from nullable<T> to
optional<T>, and vice-versa, so we can use both of them.
What do you think?
Best regards,
Vincent
On Monday, January 28, 2013 11:28:00 AM UTC+1, Ville Voutilainen wrote:
>
> On 28 January 2013 12:15, Olaf van der Spek <olafv...@gmail.com<javascript:>>
> wrote:
> >> I don't think that's the core of this problem.
> >> Supporting mixed relops is a bit like answering "What is the color of
> >> this non-existing ball?" The color is undefined and I don't really
> >> know how to map undefined to bool.
> >> Even normal relops might suffer from this issue.
> > Let me also take this opportunity to request some links to real-world
> > client code using (mixed) relops.
> > Arguing about concrete code might be a bit easier.
>
> I suppose the boost people might know about such examples. Regarding mixed
> relops, I fail to see how they are any different for optional as they
> are for pointers
> when nullptr is involved, and that's already well-specified.
>
> People can also continue debating whether optional is pointer-like or
> container-like
> and whether it has operator* or whether it has X Y and Z. If we fail
> to provide a useful
> optional, I at least will continue expressing such things with
> pointers. If I get paid
> enough, I can express such things with a vector of 0-1 elements, but I
> certainly
> don't expect to do that. ;)
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_450_19361777.1359396220955
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>The more I think about it, the more I wonder if we shouldn't define tw=
o different representation of the same idea, because I can't decide if I wa=
nt a container-like interface or a pointer-like. </div><div>And if we =
want to have both in the same type, we might end up having neither. </=
div><div><br></div><div>Does the following make sense to you or is it just =
wasteful ?</div><div><br></div><div>Let's define "optional<T>" as a c=
ontainer of T with zero or one element, and nullable<T>, as a type to=
add null semantics to a type that does not already have it, so it can stor=
e either a value of type T or nullptr.</div><div>Both represents wether we =
have a value or not, but they have a different interface.</div><div><br></d=
iv><div><br></div><div>By definition, optional<T> does not require a =
special value to indicate whether it contains a value or to empty the conta=
iner. Also, as "T" is one element, T can be implicitly converted to optiona=
l<T>. And, as optional<T> is a container, it is not implicitly =
converted to bool.</div><div><br></div><div>optional<int> i; // defau=
lt initialization, optional<T> is empty</div><div>assert(i.empty());<=
/div><div><br></div><div>optional<int> j { 5 }; // optional<T> =
contains 5</div><div>assert(!j.empty());</div><div>j.clear(); // removes th=
e value</div><div>assert(j.empty());</div><div><br></div><div>j =3D { 6 }; =
// optional<T> contains 6</div><div>i =3D j; // assignment performing=
deep copy</div><div>assert(!i.empty());</div><div><br></div><div>i =3D 4; =
// 4 is implicitly converted to optional<T>(4), then deep-copy.</div>=
<div><br></div><div>// to get or set the value</div><div>int k;</div><div><=
br></div><div>k =3D *i.begin(); // container interface</div><div>k =3D i.at=
(0); // container interface, with bound checking</div><div>k =3D i[0]; // c=
ontainer interface</div><div>k =3D i.val(); // helper method?</div><div>k =
=3D (int&)i; // why not casting? it makes the operation explicit</div><=
div><br></div><div>k =3D *i; // WRONG, i is not a pointer, nor pointer-like=
.. -> wouldn't work either.</div><div><br></div><div><br></div><div>vecto=
r have relational operators, so does optional. As T can be implicitly conve=
rted to optional<T>, mixed comparision would apply.</div><div>For tho=
se who are concerned, it could be possible to declare the mixed operators a=
s "poisonous" in a forbidding_of_mixed_optional_rel_ops namespace.</div><di=
v><br></div><div>if(i < 5) { ... } // would work</div><div><br></div><di=
v>using namespace forbidding_of_mixed_optional_rel_ops;</div><div><br></div=
><div>if(i < 5) { ... } // won't compile</div><div><br></div><div><br></=
div><div>Considering nullable<T>, by definition, it can be considered=
as a pointer. Therefore T cannot be implicitly converted to nullable<T&=
gt;, as you cannot write int* p =3D 5; But, it can be implicitly be convert=
ed to bool or compared to nullptr.</div><div><br></div><div>nullable<int=
> i; // default initialization</div><div>assert(i =3D=3D nullptr);</div>=
<div><br></div><div>nullable<int> j { 5 };</div><div>assert(j);</div>=
<div>j =3D nullptr; // removes the value, same as j.reset();</div><div>asse=
rt(j =3D=3D nullptr);</div><div><br></div><div>j =3D make_nullable(6);</div=
><div>i =3D j; // asignment performing deep copy. It is a pointer-like inte=
rface, not a pointer. shared_ptr increments the refcount, unique_ptr moves =
the pointer...</div><div>assert(i); </div><div><br></div><div>*i =3D 4=
; // sets the value, undefined if i =3D=3D nullptr</div><div><br></div><div=
>// to get or set the value</div><div>int k;</div><div><br></div><div>k =3D=
i.get(); // smart pointer interface</div><div>k =3D *i; // pointer-like in=
terface, -> would work too</div><div>k =3D i.val(); // helper method?</d=
iv><div><br></div><div>// to set, we could define</div><div>i.reset();</div=
><div>i.val();</div><div><br></div><div>Like unique_ptr and shared_ptr, nul=
lable<T> has relational operators, that can be mixed only with nullpt=
r_t. We could provide also </div><div>template <class T, class U>=
;</div><div>bool operator=3D=3D (const nullable<T>& lhs, const nu=
llable<U>& rhs) noexcept;</div><div>if T and U can compare.</div>=
<div><br></div><div><br></div><div>And, finally, we could also provide expl=
icit conversion from nullable<T> to optional<T>, and vice-versa=
, so we can use both of them. </div><div><br></div><div><br></div><div=
>What do you think?</div><div><br></div><div>Best regards,</div><div>Vincen=
t</div><div><br></div><br>On Monday, January 28, 2013 11:28:00 AM UTC+1, Vi=
lle Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 28 Ja=
nuary 2013 12:15, Olaf van der Spek <<a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"B7tFDwWWfTMJ">olafv...@gmail.com</a>> wr=
ote:
<br>>> I don't think that's the core of this problem.
<br>>> Supporting mixed relops is a bit like answering "What is the c=
olor of
<br>>> this non-existing ball?" The color is undefined and I don't re=
ally
<br>>> know how to map undefined to bool.
<br>>> Even normal relops might suffer from this issue.
<br>> Let me also take this opportunity to request some links to real-wo=
rld
<br>> client code using (mixed) relops.
<br>> Arguing about concrete code might be a bit easier.
<br>
<br>I suppose the boost people might know about such examples. Regarding mi=
xed
<br>relops, I fail to see how they are any different for optional as they
<br>are for pointers
<br>when nullptr is involved, and that's already well-specified.
<br>
<br>People can also continue debating whether optional is pointer-like or
<br>container-like
<br>and whether it has operator* or whether it has X Y and Z. If we fail
<br>to provide a useful
<br>optional, I at least will continue expressing such things with
<br>pointers. If I get paid
<br>enough, I can express such things with a vector of 0-1 elements, but I =
certainly
<br>don't expect to do that. ;)
<br></blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_450_19361777.1359396220955--
.
Author: Jeffrey Yasskin <jyasskin@googlers.com>
Date: Mon, 28 Jan 2013 10:22:23 -0800
Raw View
On Mon, Jan 28, 2013 at 10:03 AM, Vincent Jacquet <vjacquet@flowgroup.fr> wrote:
> The more I think about it, the more I wonder if we shouldn't define two
> different representation of the same idea, because I can't decide if I want
> a container-like interface or a pointer-like.
> And if we want to have both in the same type, we might end up having
> neither.
>
> Does the following make sense to you or is it just wasteful ?
Just wasteful, IMO. We shouldn't provide two types that serve the same purpose.
> Let's define "optional<T>" as a container of T with zero or one element, and
> nullable<T>, as a type to add null semantics to a type that does not already
> have it, so it can store either a value of type T or nullptr.
> Both represents wether we have a value or not, but they have a different
> interface.
>
>
> By definition, optional<T> does not require a special value to indicate
> whether it contains a value or to empty the container. Also, as "T" is one
> element, T can be implicitly converted to optional<T>. And, as optional<T>
> is a container, it is not implicitly converted to bool.
>
> optional<int> i; // default initialization, optional<T> is empty
> assert(i.empty());
>
> optional<int> j { 5 }; // optional<T> contains 5
> assert(!j.empty());
> j.clear(); // removes the value
> assert(j.empty());
>
> j = { 6 }; // optional<T> contains 6
> i = j; // assignment performing deep copy
> assert(!i.empty());
>
> i = 4; // 4 is implicitly converted to optional<T>(4), then deep-copy.
>
> // to get or set the value
> int k;
>
> k = *i.begin(); // container interface
> k = i.at(0); // container interface, with bound checking
> k = i[0]; // container interface
> k = i.val(); // helper method?
> k = (int&)i; // why not casting? it makes the operation explicit
>
> k = *i; // WRONG, i is not a pointer, nor pointer-like. -> wouldn't work
> either.
>
>
> vector have relational operators, so does optional. As T can be implicitly
> converted to optional<T>, mixed comparision would apply.
> For those who are concerned, it could be possible to declare the mixed
> operators as "poisonous" in a forbidding_of_mixed_optional_rel_ops
> namespace.
>
> if(i < 5) { ... } // would work
>
> using namespace forbidding_of_mixed_optional_rel_ops;
>
> if(i < 5) { ... } // won't compile
>
>
> Considering nullable<T>, by definition, it can be considered as a pointer.
> Therefore T cannot be implicitly converted to nullable<T>, as you cannot
> write int* p = 5; But, it can be implicitly be converted to bool or compared
> to nullptr.
>
> nullable<int> i; // default initialization
> assert(i == nullptr);
>
> nullable<int> j { 5 };
> assert(j);
> j = nullptr; // removes the value, same as j.reset();
> assert(j == nullptr);
>
> j = make_nullable(6);
> i = j; // asignment performing deep copy. It is a pointer-like interface,
> not a pointer. shared_ptr increments the refcount, unique_ptr moves the
> pointer...
> assert(i);
>
> *i = 4; // sets the value, undefined if i == nullptr
>
> // to get or set the value
> int k;
>
> k = i.get(); // smart pointer interface
> k = *i; // pointer-like interface, -> would work too
> k = i.val(); // helper method?
>
> // to set, we could define
> i.reset();
> i.val();
>
> Like unique_ptr and shared_ptr, nullable<T> has relational operators, that
> can be mixed only with nullptr_t. We could provide also
> template <class T, class U>
> bool operator== (const nullable<T>& lhs, const nullable<U>& rhs) noexcept;
> if T and U can compare.
>
>
> And, finally, we could also provide explicit conversion from nullable<T> to
> optional<T>, and vice-versa, so we can use both of them.
>
>
> What do you think?
>
> Best regards,
> Vincent
>
>
> On Monday, January 28, 2013 11:28:00 AM UTC+1, Ville Voutilainen wrote:
>>
>> On 28 January 2013 12:15, Olaf van der Spek <olafv...@gmail.com> wrote:
>> >> I don't think that's the core of this problem.
>> >> Supporting mixed relops is a bit like answering "What is the color of
>> >> this non-existing ball?" The color is undefined and I don't really
>> >> know how to map undefined to bool.
>> >> Even normal relops might suffer from this issue.
>> > Let me also take this opportunity to request some links to real-world
>> > client code using (mixed) relops.
>> > Arguing about concrete code might be a bit easier.
>>
>> I suppose the boost people might know about such examples. Regarding mixed
>> relops, I fail to see how they are any different for optional as they
>> are for pointers
>> when nullptr is involved, and that's already well-specified.
>>
>> People can also continue debating whether optional is pointer-like or
>> container-like
>> and whether it has operator* or whether it has X Y and Z. If we fail
>> to provide a useful
>> optional, I at least will continue expressing such things with
>> pointers. If I get paid
>> enough, I can express such things with a vector of 0-1 elements, but I
>> certainly
>> don't expect to do that. ;)
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To post to this group, send email to std-proposals@isocpp.org.
> To unsubscribe from this group, send email to
> std-proposals+unsubscribe@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Mon, 28 Jan 2013 10:26:37 -0800 (PST)
Raw View
------=_Part_549_7231399.1359397597746
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu poniedzia=B3ek, 28 stycznia 2013 19:03:40 UTC+1 u=BFytkownik Vincent=
=20
Jacquet napisa=B3:
>
> The more I think about it, the more I wonder if we shouldn't define two=
=20
> different representation of the same idea, because I can't decide if I wa=
nt=20
> a container-like interface or a pointer-like.=20
> And if we want to have both in the same type, we might end up having=20
> neither.=20
>
> Does the following make sense to you or is it just wasteful ?
>
> Let's define "optional<T>" as a container of T with zero or one element,=
=20
> and nullable<T>, as a type to add null semantics to a type that does not=
=20
> already have it, so it can store either a value of type T or nullptr.
> Both represents wether we have a value or not, but they have a different=
=20
> interface.
>
>
> By definition, optional<T> does not require a special value to indicate=
=20
> whether it contains a value or to empty the container. Also, as "T" is on=
e=20
> element, T can be implicitly converted to optional<T>. And, as optional<T=
>=20
> is a container, it is not implicitly converted to bool.
>
> optional<int> i; // default initialization, optional<T> is empty
> assert(i.empty());
>
> optional<int> j { 5 }; // optional<T> contains 5
> assert(!j.empty());
> j.clear(); // removes the value
> assert(j.empty());
>
> j =3D { 6 }; // optional<T> contains 6
> i =3D j; // assignment performing deep copy
> assert(!i.empty());
>
> i =3D 4; // 4 is implicitly converted to optional<T>(4), then deep-copy.
>
> // to get or set the value
> int k;
>
> k =3D *i.begin(); // container interface
> k =3D i.at(0); // container interface, with bound checking
> k =3D i[0]; // container interface
> k =3D i.val(); // helper method?
> k =3D (int&)i; // why not casting? it makes the operation explicit
>
> k =3D *i; // WRONG, i is not a pointer, nor pointer-like. -> wouldn't wor=
k=20
> either.
>
>
> vector have relational operators, so does optional. As T can be implicitl=
y=20
> converted to optional<T>, mixed comparision would apply.
> For those who are concerned, it could be possible to declare the mixed=20
> operators as "poisonous" in a forbidding_of_mixed_optional_rel_ops=20
> namespace.
>
> if(i < 5) { ... } // would work
>
> using namespace forbidding_of_mixed_optional_rel_ops;
>
> if(i < 5) { ... } // won't compile
>
>
> Considering nullable<T>, by definition, it can be considered as a pointer=
..=20
> Therefore T cannot be implicitly converted to nullable<T>, as you cannot=
=20
> write int* p =3D 5; But, it can be implicitly be converted to bool or=20
> compared to nullptr.
>
> nullable<int> i; // default initialization
> assert(i =3D=3D nullptr);
>
> nullable<int> j { 5 };
> assert(j);
> j =3D nullptr; // removes the value, same as j.reset();
> assert(j =3D=3D nullptr);
>
> j =3D make_nullable(6);
> i =3D j; // asignment performing deep copy. It is a pointer-like interfac=
e,=20
> not a pointer. shared_ptr increments the refcount, unique_ptr moves the=
=20
> pointer...
> assert(i);=20
>
> *i =3D 4; // sets the value, undefined if i =3D=3D nullptr
>
> // to get or set the value
> int k;
>
> k =3D i.get(); // smart pointer interface
> k =3D *i; // pointer-like interface, -> would work too
> k =3D i.val(); // helper method?
>
> // to set, we could define
> i.reset();
> i.val();
>
> Like unique_ptr and shared_ptr, nullable<T> has relational operators, tha=
t=20
> can be mixed only with nullptr_t. We could provide also=20
> template <class T, class U>
> bool operator=3D=3D (const nullable<T>& lhs, const nullable<U>& rhs) noex=
cept;
> if T and U can compare.
>
>
> And, finally, we could also provide explicit conversion from nullable<T>=
=20
> to optional<T>, and vice-versa, so we can use both of them.=20
>
>
> What do you think?
>
I hope someone else will address your idea. I have spent too much time=20
looking at the details of the current "mixed" proposal, to be able to=20
objectively evaluate this one.
=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_549_7231399.1359397597746
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu poniedzia=B3ek, 28 stycznia 2013 19:03:40 UTC+1 u=BFytkownik=
Vincent Jacquet napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v>The more I think about it, the more I wonder if we shouldn't define two d=
ifferent representation of the same idea, because I can't decide if I want =
a container-like interface or a pointer-like. </div><div>And if we wan=
t to have both in the same type, we might end up having neither. </div=
><div><br></div><div>Does the following make sense to you or is it just was=
teful ?</div><div><br></div><div>Let's define "optional<T>" as a cont=
ainer of T with zero or one element, and nullable<T>, as a type to ad=
d null semantics to a type that does not already have it, so it can store e=
ither a value of type T or nullptr.</div><div>Both represents wether we hav=
e a value or not, but they have a different interface.</div><div><br></div>=
<div><br></div><div>By definition, optional<T> does not require a spe=
cial value to indicate whether it contains a value or to empty the containe=
r. Also, as "T" is one element, T can be implicitly converted to optional&l=
t;T>. And, as optional<T> is a container, it is not implicitly con=
verted to bool.</div><div><br></div><div>optional<int> i; // default =
initialization, optional<T> is empty</div><div>assert(i.empty());</di=
v><div><br></div><div>optional<int> j { 5 }; // optional<T> con=
tains 5</div><div>assert(!j.empty());</div><div>j.clear(); // removes the v=
alue</div><div>assert(j.empty());</div><div><br></div><div>j =3D { 6 }; // =
optional<T> contains 6</div><div>i =3D j; // assignment performing de=
ep copy</div><div>assert(!i.empty());</div><div><br></div><div>i =3D 4; // =
4 is implicitly converted to optional<T>(4), then deep-copy.</div><di=
v><br></div><div>// to get or set the value</div><div>int k;</div><div><br>=
</div><div>k =3D *i.begin(); // container interface</div><div>k =3D <a href=
=3D"http://i.at" target=3D"_blank">i.at</a>(0); // container interface, wit=
h bound checking</div><div>k =3D i[0]; // container interface</div><div>k =
=3D i.val(); // helper method?</div><div>k =3D (int&)i; // why not cast=
ing? it makes the operation explicit</div><div><br></div><div>k =3D *i; // =
WRONG, i is not a pointer, nor pointer-like. -> wouldn't work either.</d=
iv><div><br></div><div><br></div><div>vector have relational operators, so =
does optional. As T can be implicitly converted to optional<T>, mixed=
comparision would apply.</div><div>For those who are concerned, it could b=
e possible to declare the mixed operators as "poisonous" in a forbidding_of=
_mixed_optional_<wbr>rel_ops namespace.</div><div><br></div><div>if(i < =
5) { ... } // would work</div><div><br></div><div>using namespace forbiddin=
g_of_mixed_optional_<wbr>rel_ops;</div><div><br></div><div>if(i < 5) { .=
... } // won't compile</div><div><br></div><div><br></div><div>Considering n=
ullable<T>, by definition, it can be considered as a pointer. Therefo=
re T cannot be implicitly converted to nullable<T>, as you cannot wri=
te int* p =3D 5; But, it can be implicitly be converted to bool or compared=
to nullptr.</div><div><br></div><div>nullable<int> i; // default ini=
tialization</div><div>assert(i =3D=3D nullptr);</div><div><br></div><div>nu=
llable<int> j { 5 };</div><div>assert(j);</div><div>j =3D nullptr; //=
removes the value, same as j.reset();</div><div>assert(j =3D=3D nullptr);<=
/div><div><br></div><div>j =3D make_nullable(6);</div><div>i =3D j; // asig=
nment performing deep copy. It is a pointer-like interface, not a pointer. =
shared_ptr increments the refcount, unique_ptr moves the pointer...</div><d=
iv>assert(i); </div><div><br></div><div>*i =3D 4; // sets the value, u=
ndefined if i =3D=3D nullptr</div><div><br></div><div>// to get or set the =
value</div><div>int k;</div><div><br></div><div>k =3D i.get(); // smart poi=
nter interface</div><div>k =3D *i; // pointer-like interface, -> would w=
ork too</div><div>k =3D i.val(); // helper method?</div><div><br></div><div=
>// to set, we could define</div><div>i.reset();</div><div>i.val();</div><d=
iv><br></div><div>Like unique_ptr and shared_ptr, nullable<T> has rel=
ational operators, that can be mixed only with nullptr_t. We could provide =
also </div><div>template <class T, class U></div><div>bool opera=
tor=3D=3D (const nullable<T>& lhs, const nullable<U>& r=
hs) noexcept;</div><div>if T and U can compare.</div><div><br></div><div><b=
r></div><div>And, finally, we could also provide explicit conversion from n=
ullable<T> to optional<T>, and vice-versa, so we can use both o=
f them. </div><div><br></div><div><br></div><div>What do you think?</d=
iv></blockquote><div><br>I hope someone else will address your idea. I have=
spent too much time looking at the details of the current "mixed" proposal=
, to be able to objectively evaluate this one.<br></div><div> </div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_549_7231399.1359397597746--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Mon, 28 Jan 2013 10:49:06 -0800 (PST)
Raw View
------=_Part_1168_7051314.1359398946201
Content-Type: text/plain; charset=ISO-8859-1
>
> We would appreciate your feedback and suggestions.
>
One more thing that just came to my mind, and I would like to hear your
opinion on.
In case T has explicit copy/move constructor, should optional<T> also
provide explicit copy/move constructor and explicit constructor from T&&
and T const& ? Such "conditional" explicit constructor is implementable. I
just wonder how often it is the case that someone defines an explicit
copy/move constructor.
Regards,
&rzej
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_1168_7051314.1359398946201
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(=
204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">We would apprecia=
te your feedback and suggestions.<br></blockquote><div><br>One more thing t=
hat just came to my mind, and I would like to hear your opinion on.<br>In c=
ase T has explicit copy/move constructor, should optional<T> also pro=
vide explicit copy/move constructor and explicit constructor from T&&am=
p; and T const& ? Such "conditional" explicit constructor is implementa=
ble. I just wonder how often it is the case that someone defines an explici=
t copy/move constructor.<br><br>Regards,<br>&rzej <br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1168_7051314.1359398946201--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 28 Jan 2013 20:54:53 +0200
Raw View
On 28 January 2013 20:49, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> wro=
te:
>> We would appreciate your feedback and suggestions.
> One more thing that just came to my mind, and I would like to hear your
> opinion on.
> In case T has explicit copy/move constructor, should optional<T> also
> provide explicit copy/move constructor and explicit constructor from T&& =
and
> T const& ? Such "conditional" explicit constructor is implementable. I ju=
st
> wonder how often it is the case that someone defines an explicit copy/mov=
e
> constructor.
I also wonder how often someone wants that explicitness to carry over to wr=
apper
types. It doesn't carry over to lambdas, which use direct
initialization, for example.
I personally think explicit copy constructors are brain-damaged. I
would be ok with
them if you could explicitly pass-by-value with them, but they render
it completely
impossible to pass-by-value into functions. I have tried to find a
reasonable use
for that, but I have so far failed.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Mon, 28 Jan 2013 14:03:14 -0500
Raw View
On Mon, Jan 28, 2013 at 1:49 PM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
>> We would appreciate your feedback and suggestions.
>
>
> One more thing that just came to my mind, and I would like to hear your
> opinion on.
> In case T has explicit copy/move constructor, should optional<T> also
> provide explicit copy/move constructor and explicit constructor from T&& =
and
> T const& ? Such "conditional" explicit constructor is implementable. I ju=
st
> wonder how often it is the case that someone defines an explicit copy/mov=
e
> constructor.
>
> Regards,
> &rzej
>
Might want to start this as a separate email thread. This current
thread is........................................
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Mon, 28 Jan 2013 14:21:53 -0500
Raw View
On Mon, Jan 28, 2013 at 3:44 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
>
> You can always build your type atop optional<T> and provide any compariso=
n
> you want:
>
> struct MyOptional : std::optional<T>
> {
> using optional<T>::optional;
> bool operator<(MyOptional const&) const;
> }
>
>
I'm hoping that is *not* necessary. If I have Price and
optional<Price>, both essentially "my" types (optional<Price> is *my*
type just as much as MyOptional is - they both just use template
optional<> to build a type), I should be able to define the operators
between them:
bool operator<(optional<Price> const & opt, Price const & price)
{
return ...
}
//etc
As long as I can do that without colliding with the pre-defined
optional operators, I'm OK with mixed relational operators. And I
*think* that should be fine since optional's operator will be
templatized???
I shouldn't need to wrap *my* type in another *my* type just so I can
define the relations between *my* types.
Tony
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Mon, 28 Jan 2013 14:26:24 -0500
Raw View
On Mon, Jan 28, 2013 at 4:01 AM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 28 January 2013 10:44, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> w=
rote:
>> "optional<T> and T are truly different types" -- this is a reasonable,
>> consistent model of optional<T>, however I believe that if we adopt it, =
we
>> need to consequently ban the implicit conversion from T to optional<T>.
>
> Again, this is against years of practical experience. Just because T
> and optional<T>
> are "truly different types" is no reason to ban implicit conversions
> or mixed relops.
> The concerns people have about that causing potential bugs boils down to =
a very
> simple and blunt statement: people who are utterly helpless with debuggin=
g and
> testing need so much hand-holding that we can't have any useful
> utilities because
> we have to be paranoid about things people can get wrong. Sure, it's unfo=
rtunate
> if refactorings cause silent breakage, but we do have to consider how
> uncomfortable
> we want optional's interface to be for people who have the slightest
> clue about what
> they are doing when refactoring code.
>
> My recommendation is to not mess with the implicit T->optional<T> convers=
ion,
> and to allow mixed relops. For the arguably theoretical and rare cases
> where that
> will cause problems, the School of Hard Knocks will teach people to not e=
dit
> code with a hacksaw.
>
> I'm not against compile-time safety. I'm just saying that the
> trade-off it would cause
> here is not worth the trouble, IMO.
>
> --
I actually completely agree that the refactoring argument is weak. It
is valid, it will happen, but I agree it is not worth trade-off in
this case.
(My argument has always been more "philosophical" - Personally I just
think defining operators on my types for me is wrong.)
Tony
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Mon, 28 Jan 2013 13:27:38 -0600
Raw View
--20cf300fafc77b42a704d45e4777
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 28 January 2013 13:21, Tony V E <tvaneerd@gmail.com> wrote:
> On Mon, Jan 28, 2013 at 3:44 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail=
..com>
> wrote:
>
> > struct MyOptional : std::optional<T>
> > {
> > using optional<T>::optional;
> > bool operator<(MyOptional const&) const;
> > }
> >
> >
>
> I'm hoping that is *not* necessary. If I have Price and
> optional<Price>, both essentially "my" types (optional<Price> is *my*
> type just as much as MyOptional is - they both just use template
> optional<> to build a type), I should be able to define the operators
> between them:
>
> bool operator<(optional<Price> const & opt, Price const & price)
> {
> return ...
> }
> //etc
>
You cannot do that for vector<T>; why would you expect to be able to do it
for optional<T>?
--=20
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
--20cf300fafc77b42a704d45e4777
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 28 January 2013 13:21, Tony V E <span dir=3D"ltr"><<a href=3D"mailto:=
tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>></span> wro=
te:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On Mon, Jan 28, 2013 at 3:44 AM, Andrzej Krzemie=C5=84ski=
<<a href=3D"mailto:akrzemi1@gmail.com">akrzemi1@gmail.com</a>> wrote=
:<br><br>
> struct MyOptional : std::optional<T><br>
> {<br>
> =C2=A0 using optional<T>::optional;<br>
> =C2=A0 bool operator<(MyOptional =C2=A0const&) const;<br>
> }<br>
><br>
><br>
<br>
</div>I'm hoping that is *not* necessary. =C2=A0If I have Price and<br>
optional<Price>, both essentially "my" types =C2=A0(optiona=
l<Price> is *my*<br>
type just as much as MyOptional is - they both just use template<br>
optional<> to build a type), I should be able to define the operators=
<br>
between them:<br>
<br>
bool operator<(optional<Price> const & opt, Price const & =
price)<br>
{<br>
=C2=A0 =C2=A0 return ...<br>
}<br>
//etc<br></blockquote><div><br>You cannot do that for vector<T>; why =
would you expect to be able to do it for optional<T>?<br></div></div>=
-- <br>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=
=C2=A0 (847) 691-1404
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--20cf300fafc77b42a704d45e4777--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Mon, 28 Jan 2013 14:35:42 -0500
Raw View
On Mon, Jan 28, 2013 at 2:27 PM, Nevin Liber <nevin@eviloverlord.com> wrote=
:
> On 28 January 2013 13:21, Tony V E <tvaneerd@gmail.com> wrote:
>>
>> On Mon, Jan 28, 2013 at 3:44 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmai=
l.com>
>> wrote:
>>
>> > struct MyOptional : std::optional<T>
>> > {
>> > using optional<T>::optional;
>> > bool operator<(MyOptional const&) const;
>> > }
>> >
>> >
>>
>> I'm hoping that is *not* necessary. If I have Price and
>> optional<Price>, both essentially "my" types (optional<Price> is *my*
>> type just as much as MyOptional is - they both just use template
>> optional<> to build a type), I should be able to define the operators
>> between them:
>>
>> bool operator<(optional<Price> const & opt, Price const & price)
>> {
>> return ...
>> }
>> //etc
>
>
> You cannot do that for vector<T>; why would you expect to be able to do i=
t
> for optional<T>?
> --
> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
>
I understand that defining operator<(vector<T>, vector<T>) is
disallowed. As is defining things in std:: (for the most part).
But I find being able to define mixed operators - of my types - odd.
ie I can't define operator<(int, int), but I can still define
operator<(int, MyFoo). I know int is not std::int, but it would seem
like a reasonable pattern to me.
But I guess I'm not versed enough in some corners of the language.
What if I define operator<(optional<Price>) as a member function of
Price? Are member functions OK, but not free functions?
This is sort of why I am asking these questions - I really want to be
able to define relational operators as I need them. Is wrapping the
only way?
Tony
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Mon, 28 Jan 2013 16:36:34 -0300
Raw View
--047d7b62244a78467604d45e6752
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Mon, Jan 28, 2013 at 4:21 PM, Tony V E <tvaneerd@gmail.com> wrote:
> On Mon, Jan 28, 2013 at 3:44 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail=
..com>
> wrote:
> >
> > You can always build your type atop optional<T> and provide any
> comparison
> > you want:
> >
> > struct MyOptional : std::optional<T>
> > {
> > using optional<T>::optional;
> > bool operator<(MyOptional const&) const;
> > }
> >
> >
>
> I'm hoping that is *not* necessary. If I have Price and
> optional<Price>, both essentially "my" types (optional<Price> is *my*
> type just as much as MyOptional is - they both just use template
> optional<> to build a type), I should be able to define the operators
> between them:
>
> bool operator<(optional<Price> const & opt, Price const & price)
> {
> return ...
> }
> //etc
>
> As long as I can do that without colliding with the pre-defined
> optional operators, I'm OK with mixed relational operators. And I
> *think* that should be fine since optional's operator will be
> templatized???
>
> Yes.
Your version will be a better match.
--=20
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
--047d7b62244a78467604d45e6752
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 M=
on, Jan 28, 2013 at 4:21 PM, 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;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Mon, Jan 28, 2013 at 3:=
44 AM, Andrzej Krzemie=C5=84ski <<a href=3D"mailto:akrzemi1@gmail.com">a=
krzemi1@gmail.com</a>> wrote:<br>
><br>
> You can always build your type atop optional<T> and provide any =
comparison<br>
> you want:<br>
><br>
> struct MyOptional : std::optional<T><br>
> {<br>
> =C2=A0 using optional<T>::optional;<br>
> =C2=A0 bool operator<(MyOptional =C2=A0const&) const;<br>
> }<br>
><br>
><br>
<br>
</div>I'm hoping that is *not* necessary. =C2=A0If I have Price and<br>
optional<Price>, both essentially "my" types =C2=A0(optiona=
l<Price> is *my*<br>
type just as much as MyOptional is - they both just use template<br>
optional<> to build a type), I should be able to define the operators=
<br>
between them:<br>
<br>
bool operator<(optional<Price> const & opt, Price const & =
price)<br>
{<br>
=C2=A0 =C2=A0 return ...<br>
}<br>
//etc<br>
<br>
As long as I can do that without colliding with the pre-defined<br>
optional operators, I'm OK with mixed relational operators. =C2=A0And I=
<br>
*think* that should be fine since optional's operator will be<br>
templatized???<br>
<br></blockquote><div>Yes.<br></div><div>Your version will be a better matc=
h.<br>=C2=A0<br></div><br></div><br clear=3D"all"><br>-- <br>Fernando Cacci=
ola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-consult=
ing.com">http://www.scisoft-consulting.com</a>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--047d7b62244a78467604d45e6752--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Mon, 28 Jan 2013 14:38:36 -0500
Raw View
On Mon, Jan 28, 2013 at 8:03 AM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Mon, Jan 28, 2013 at 12:15 PM, Ville Voutilainen
>> I would expect people to also show real-world code where it's problematic
>> to have them. All we have so far from either side of the argument is concocted
>> examples. Anyway, sure, it would be helpful to look at real-world code before
>> making conclusions. However, I have made my conclusions - I trust my
>> judgement and my taste.
>
> Really? I don't think that's good enough for ISO standards.
>
At the end of the day, this is how standards work - a bunch of people
get together, use their judgement and taste, and decide.
And by "decide" I mean vote. It would be great if "decide" meant they
discussed and agreed and were unanimous, but that doesn't always
happen. At least they discuss. But it is still just judgement and
taste.
> --
> Olaf
>
Tony
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Tue, 29 Jan 2013 07:25:31 +1100
Raw View
On Mon, Jan 28, 2013 at 10:25 PM, Andrzej Krzemie=F1ski
<akrzemi1@gmail.com> wrote:
>
> W dniu poniedzia=B3ek, 28 stycznia 2013 12:15:25 UTC+1 u=BFytkownik Ville=
Voutilainen napisa=B3:
>>
>> On 28 January 2013 12:54, Olaf van der Spek <olafv...@gmail.com> wrote:
>> >> Very astute, but I think that's not problematic, as I see T and optio=
nal<T>
>> >> to be similar enough that optional<T> just adds the nullopt to the se=
t of valid
>> >> values. Mixed relops are practically just an optimization to avoid ha=
ving
>> >> to construct an optional<T> from a T and then do the comparison.
>> > There's no need to construct a temp optional, you could just use !opt
>> > && opt < 5 or so.
>>
>> Perhaps failing to write *opt < 5 there and using && instead of || is
>> an indication
>> that it would be simpler to have mixed relops? :)
>>
>> >> All in
>> >> all, the benefits of mixed relops for optional are convincing enough =
for me
>> >> that I think we should have them, I'm not convinced by the concerns t=
hat
>> >> people have about the potential problems.
>> > Shouldn't we be looking at real-world code before concluding that it's
>> > good to have them?
> ...
> On a slightly different subject, there are two "kinds" of arguments again=
st poisoning the relops.
> One is that "refactoring safety" is illegitimate expectation or that it i=
s less important that
> convenience. The other "kind" is that it is impossible to offer "refactor=
ing safety" for
> std::optional anyway because of optional's contextual conversion to bool,=
especially
> (but not only) in the case of optional<bool>. I find latter argument (sta=
ted already by
> a couple of people) stronger, because it must sound convincing even for p=
eople that
> value the "refactoring safety".
Well, these "arguments against poisoning the relops" that you mention
indeed seem to be the most expressed (or at least I seem to stumble
upon those more often). In all fairness, they are not exactly
"arguments against poisoning the relops". They are more like saying
"these arguments for poisoning the relops are not convincing/scary
enough for us to sacrifice the convenience of the mixed relops".
What I personally do find to be two serious arguments in favor of
poisoning the relops are that
1) those mixed relops are not essential to the optional interface and
2) refactoring or no refactoring, mixed relops cannot correctly
express programming logic.
I personally much prefer the explicitness and unambiguity of "opt &&
*opt < 5" to "opt < 5". However, that is probably a matter of style.
What is *really* important IMO is that "opt < 5" is not necessarily
correct. Allowing "opt < 5" sends the wrong message that nullopt is
handled correctly when it cannot. In general terms nullopt (disengaged
optional<T>) cannot be correctly treated by a mixed-relopt as nullopt
is not part of the available T range and must be evaluated separately
no matter how "inconvenient" that might feel. In many respect nullopt
is a kind of NaN for an arbitrary type. NaN is not only the "effect of
'erroneous' computation". It also used to represent missing values in
computations (then NaNs are explicitly assigned to variables), i.e.
exactly what 'optional' is for. Comparisons with NaN are undefined.
Consequently, now I feel that mixed relops have to be disabled as the
perceived convenience comes at the expense of correctness.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Mon, 28 Jan 2013 12:38:09 -0800 (PST)
Raw View
------=_Part_467_33435727.1359405489425
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu poniedzia=B3ek, 28 stycznia 2013 21:25:31 UTC+1 u=BFytkownik Vladimi=
r=20
Batov napisa=B3:
>
> On Mon, Jan 28, 2013 at 10:25 PM, Andrzej Krzemie=F1ski=20
> <akrz...@gmail.com <javascript:>> wrote:=20
> >=20
> > W dniu poniedzia=B3ek, 28 stycznia 2013 12:15:25 UTC+1 u=BFytkownik Vil=
le=20
> Voutilainen napisa=B3:=20
> >>=20
> >> On 28 January 2013 12:54, Olaf van der Spek <olafv...@gmail.com>=20
> wrote:=20
> >> >> Very astute, but I think that's not problematic, as I see T and=20
> optional<T>=20
> >> >> to be similar enough that optional<T> just adds the nullopt to the=
=20
> set of valid=20
> >> >> values. Mixed relops are practically just an optimization to avoid=
=20
> having=20
> >> >> to construct an optional<T> from a T and then do the comparison.=20
> >> > There's no need to construct a temp optional, you could just use !op=
t=20
> >> > && opt < 5 or so.=20
> >>=20
> >> Perhaps failing to write *opt < 5 there and using && instead of || is=
=20
> >> an indication=20
> >> that it would be simpler to have mixed relops? :)=20
> >>=20
> >> >> All in=20
> >> >> all, the benefits of mixed relops for optional are convincing enoug=
h=20
> for me=20
> >> >> that I think we should have them, I'm not convinced by the concerns=
=20
> that=20
> >> >> people have about the potential problems.=20
> >> > Shouldn't we be looking at real-world code before concluding that=20
> it's=20
> >> > good to have them?=20
> > ...=20
> > On a slightly different subject, there are two "kinds" of arguments=20
> against poisoning the relops.=20
> > One is that "refactoring safety" is illegitimate expectation or that it=
=20
> is less important that=20
> > convenience. The other "kind" is that it is impossible to offer=20
> "refactoring safety" for=20
> > std::optional anyway because of optional's contextual conversion to=20
> bool, especially=20
> > (but not only) in the case of optional<bool>. I find latter argument=20
> (stated already by=20
> > a couple of people) stronger, because it must sound convincing even for=
=20
> people that=20
> > value the "refactoring safety".=20
>
> Well, these "arguments against poisoning the relops" that you mention=20
> indeed seem to be the most expressed (or at least I seem to stumble=20
> upon those more often). In all fairness, they are not exactly=20
> "arguments against poisoning the relops". They are more like saying=20
> "these arguments for poisoning the relops are not convincing/scary=20
> enough for us to sacrifice the convenience of the mixed relops".=20
>
> What I personally do find to be two serious arguments in favor of=20
> poisoning the relops are that=20
> 1) those mixed relops are not essential to the optional interface and=20
> 2) refactoring or no refactoring, mixed relops cannot correctly=20
> express programming logic.=20
>
> I personally much prefer the explicitness and unambiguity of "opt &&=20
> *opt < 5" to "opt < 5". However, that is probably a matter of style.=20
> What is *really* important IMO is that "opt < 5" is not necessarily=20
> correct. Allowing "opt < 5" sends the wrong message that nullopt is=20
> handled correctly when it cannot. In general terms nullopt (disengaged=20
> optional<T>) cannot be correctly treated by a mixed-relopt as nullopt=20
> is not part of the available T range and must be evaluated separately=20
> no matter how "inconvenient" that might feel. In many respect nullopt=20
> is a kind of NaN for an arbitrary type. NaN is not only the "effect of=20
> 'erroneous' computation". It also used to represent missing values in=20
> computations (then NaNs are explicitly assigned to variables), i.e.=20
> exactly what 'optional' is for. Comparisons with NaN are undefined.=20
>
> Consequently, now I feel that mixed relops have to be disabled as the=20
> perceived convenience comes at the expense of correctness.=20
>
I understand this reasoning (not necessarily agree with it). But does the=
=20
root of this problem lay in mixed relops? "Homogenous" relational operators=
=20
of optional already display these "least of all values of T" semantics. And=
=20
together with implicit construction from T we get implicit mixed relops=20
(this is why we are considering poisoning them).
Do you find it a consistent approach to poison mixed relops and at the same=
=20
time keep current homogenous relops and implicit conversion from T?
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_467_33435727.1359405489425
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu poniedzia=B3ek, 28 stycznia 2013 21:25:31 UTC+1 u=BFytkownik=
Vladimir Batov napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On M=
on, Jan 28, 2013 at 10:25 PM, Andrzej Krzemie=F1ski
<br><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
UzXju5VHW2UJ">akrz...@gmail.com</a>> wrote:
<br>>
<br>> W dniu poniedzia=B3ek, 28 stycznia 2013 12:15:25 UTC+1 u=BFytkowni=
k Ville Voutilainen napisa=B3:
<br>>>
<br>>> On 28 January 2013 12:54, Olaf van der Spek <<a>olafv...@gm=
ail.com</a>> wrote:
<br>>> >> Very astute, but I think that's not problematic, as I=
see T and optional<T>
<br>>> >> to be similar enough that optional<T> just adds=
the nullopt to the set of valid
<br>>> >> values. Mixed relops are practically just an optimiza=
tion to avoid having
<br>>> >> to construct an optional<T> from a T and then d=
o the comparison.
<br>>> > There's no need to construct a temp optional, you could j=
ust use !opt
<br>>> > && opt < 5 or so.
<br>>>
<br>>> Perhaps failing to write *opt < 5 there and using &&=
; instead of || is
<br>>> an indication
<br>>> that it would be simpler to have mixed relops? :)
<br>>>
<br>>> >> All in
<br>>> >> all, the benefits of mixed relops for optional are co=
nvincing enough for me
<br>>> >> that I think we should have them, I'm not convinced b=
y the concerns that
<br>>> >> people have about the potential problems.
<br>>> > Shouldn't we be looking at real-world code before conclud=
ing that it's
<br>>> > good to have them?
<br>> ...
<br>> On a slightly different subject, there are two "kinds" of argument=
s against poisoning the relops.
<br>> One is that "refactoring safety" is illegitimate expectation or th=
at it is less important that
<br>> convenience. The other "kind" is that it is impossible to offer "r=
efactoring safety" for
<br>> std::optional anyway because of optional's contextual conversion t=
o bool, especially
<br>> (but not only) in the case of optional<bool>. I find latter =
argument (stated already by
<br>> a couple of people) stronger, because it must sound convincing eve=
n for people that
<br>> value the "refactoring safety".
<br>
<br>Well, these "arguments against poisoning the relops" that you mention
<br>indeed seem to be the most expressed (or at least I seem to stumble
<br>upon those more often). In all fairness, they are not exactly
<br>"arguments against poisoning the relops". They are more like saying
<br>"these arguments for poisoning the relops are not convincing/scary
<br>enough for us to sacrifice the convenience of the mixed relops".
<br>
<br>What I personally do find to be two serious arguments in favor of
<br>poisoning the relops are that
<br>1) those mixed relops are not essential to the optional interface and
<br>2) refactoring or no refactoring, mixed relops cannot correctly
<br>express programming logic.
<br>
<br>I personally much prefer the explicitness and unambiguity of "opt &=
&
<br>*opt < 5" to "opt < 5". However, that is probably a matter of sty=
le.
<br>What is *really* important IMO is that "opt < 5" is not necessarily
<br>correct. Allowing "opt < 5" sends the wrong message that nullopt is
<br>handled correctly when it cannot. In general terms nullopt (disengaged
<br>optional<T>) cannot be correctly treated by a mixed-relopt as nul=
lopt
<br>is not part of the available T range and must be evaluated separately
<br>no matter how "inconvenient" that might feel. In many respect nullopt
<br>is a kind of NaN for an arbitrary type. NaN is not only the "effect of
<br>'erroneous' computation". It also used to represent missing values in
<br>computations (then NaNs are explicitly assigned to variables), i.e.
<br>exactly what 'optional' is for. Comparisons with NaN are undefined.
<br>
<br>Consequently, now I feel that mixed relops have to be disabled as the
<br>perceived convenience comes at the expense of correctness.
<br></blockquote><div><br>I understand this reasoning (not necessarily agre=
e with it). But does the root of this problem lay in mixed relops? "Homogen=
ous" relational operators of optional already display these "least of all v=
alues of T" semantics. And together with implicit construction from T we ge=
t implicit mixed relops (this is why we are considering poisoning them).<br=
><br>Do you find it a consistent approach to poison mixed relops and at the=
same time keep current homogenous relops and implicit conversion from T?<b=
r></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_467_33435727.1359405489425--
.
Author: Vincent Jacquet <vjacquet@flowgroup.fr>
Date: Mon, 28 Jan 2013 13:00:46 -0800 (PST)
Raw View
------=_Part_759_1210289.1359406846313
Content-Type: text/plain; charset=ISO-8859-1
vector and valarray both holds an array of elements, yet vector emphasizes
the container interface while valarray emphasizes the mathematical
operations on the items.
There is 2 ways to say there is a value or not
struct S1
{
};
On Monday, January 28, 2013 7:22:23 PM UTC+1, Jeffrey Yasskin wrote:
>
> On Mon, Jan 28, 2013 at 10:03 AM, Vincent Jacquet <vjac...@flowgroup.fr<javascript:>>
> wrote:
> > The more I think about it, the more I wonder if we shouldn't define two
> > different representation of the same idea, because I can't decide if I
> want
> > a container-like interface or a pointer-like.
> > And if we want to have both in the same type, we might end up having
> > neither.
> >
> > Does the following make sense to you or is it just wasteful ?
>
> Just wasteful, IMO. We shouldn't provide two types that serve the same
> purpose.
>
> > Let's define "optional<T>" as a container of T with zero or one element,
> and
> > nullable<T>, as a type to add null semantics to a type that does not
> already
> > have it, so it can store either a value of type T or nullptr.
> > Both represents wether we have a value or not, but they have a different
> > interface.
> >
> >
> > By definition, optional<T> does not require a special value to indicate
> > whether it contains a value or to empty the container. Also, as "T" is
> one
> > element, T can be implicitly converted to optional<T>. And, as
> optional<T>
> > is a container, it is not implicitly converted to bool.
> >
> > optional<int> i; // default initialization, optional<T> is empty
> > assert(i.empty());
> >
> > optional<int> j { 5 }; // optional<T> contains 5
> > assert(!j.empty());
> > j.clear(); // removes the value
> > assert(j.empty());
> >
> > j = { 6 }; // optional<T> contains 6
> > i = j; // assignment performing deep copy
> > assert(!i.empty());
> >
> > i = 4; // 4 is implicitly converted to optional<T>(4), then deep-copy.
> >
> > // to get or set the value
> > int k;
> >
> > k = *i.begin(); // container interface
> > k = i.at(0); // container interface, with bound checking
> > k = i[0]; // container interface
> > k = i.val(); // helper method?
> > k = (int&)i; // why not casting? it makes the operation explicit
> >
> > k = *i; // WRONG, i is not a pointer, nor pointer-like. -> wouldn't work
> > either.
> >
> >
> > vector have relational operators, so does optional. As T can be
> implicitly
> > converted to optional<T>, mixed comparision would apply.
> > For those who are concerned, it could be possible to declare the mixed
> > operators as "poisonous" in a forbidding_of_mixed_optional_rel_ops
> > namespace.
> >
> > if(i < 5) { ... } // would work
> >
> > using namespace forbidding_of_mixed_optional_rel_ops;
> >
> > if(i < 5) { ... } // won't compile
> >
> >
> > Considering nullable<T>, by definition, it can be considered as a
> pointer.
> > Therefore T cannot be implicitly converted to nullable<T>, as you cannot
> > write int* p = 5; But, it can be implicitly be converted to bool or
> compared
> > to nullptr.
> >
> > nullable<int> i; // default initialization
> > assert(i == nullptr);
> >
> > nullable<int> j { 5 };
> > assert(j);
> > j = nullptr; // removes the value, same as j.reset();
> > assert(j == nullptr);
> >
> > j = make_nullable(6);
> > i = j; // asignment performing deep copy. It is a pointer-like
> interface,
> > not a pointer. shared_ptr increments the refcount, unique_ptr moves the
> > pointer...
> > assert(i);
> >
> > *i = 4; // sets the value, undefined if i == nullptr
> >
> > // to get or set the value
> > int k;
> >
> > k = i.get(); // smart pointer interface
> > k = *i; // pointer-like interface, -> would work too
> > k = i.val(); // helper method?
> >
> > // to set, we could define
> > i.reset();
> > i.val();
> >
> > Like unique_ptr and shared_ptr, nullable<T> has relational operators,
> that
> > can be mixed only with nullptr_t. We could provide also
> > template <class T, class U>
> > bool operator== (const nullable<T>& lhs, const nullable<U>& rhs)
> noexcept;
> > if T and U can compare.
> >
> >
> > And, finally, we could also provide explicit conversion from nullable<T>
> to
> > optional<T>, and vice-versa, so we can use both of them.
> >
> >
> > What do you think?
> >
> > Best regards,
> > Vincent
> >
> >
> > On Monday, January 28, 2013 11:28:00 AM UTC+1, Ville Voutilainen wrote:
> >>
> >> On 28 January 2013 12:15, Olaf van der Spek <olafv...@gmail.com>
> wrote:
> >> >> I don't think that's the core of this problem.
> >> >> Supporting mixed relops is a bit like answering "What is the color
> of
> >> >> this non-existing ball?" The color is undefined and I don't really
> >> >> know how to map undefined to bool.
> >> >> Even normal relops might suffer from this issue.
> >> > Let me also take this opportunity to request some links to real-world
> >> > client code using (mixed) relops.
> >> > Arguing about concrete code might be a bit easier.
> >>
> >> I suppose the boost people might know about such examples. Regarding
> mixed
> >> relops, I fail to see how they are any different for optional as they
> >> are for pointers
> >> when nullptr is involved, and that's already well-specified.
> >>
> >> People can also continue debating whether optional is pointer-like or
> >> container-like
> >> and whether it has operator* or whether it has X Y and Z. If we fail
> >> to provide a useful
> >> optional, I at least will continue expressing such things with
> >> pointers. If I get paid
> >> enough, I can express such things with a vector of 0-1 elements, but I
> >> certainly
> >> don't expect to do that. ;)
> >
> > --
> >
> > ---
> > You received this message because you are subscribed to the Google
> Groups
> > "ISO C++ Standard - Future Proposals" group.
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>
> > To unsubscribe from this group, send email to
> > std-proposal...@isocpp.org <javascript:>.
> > Visit this group at
> > http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
> >
> >
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_759_1210289.1359406846313
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>vector and valarray both holds an array of elements, yet vector emphas=
izes the container interface while valarray emphasizes the mathem=
atical operations on the items.<br></div><div><br></div><div>There is 2 way=
s to say there is a value or not</div><div>struct S1</div><div>{</div><div>=
<br></div><div>};</div><div><br></div><br>On Monday, January 28, 2013 7:22:=
23 PM UTC+1, Jeffrey Yasskin wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">On Mon, Jan 28, 2013 at 10:03 AM, Vincent Jacquet <<a href=3D"java=
script:" target=3D"_blank" gdf-obfuscated-mailto=3D"yYI8TL_KJFsJ">vjac...@f=
lowgroup.fr</a>> wrote:
<br>> The more I think about it, the more I wonder if we shouldn't defin=
e two
<br>> different representation of the same idea, because I can't decide =
if I want
<br>> a container-like interface or a pointer-like.
<br>> And if we want to have both in the same type, we might end up havi=
ng
<br>> neither.
<br>>
<br>> Does the following make sense to you or is it just wasteful ?
<br>
<br>Just wasteful, IMO. We shouldn't provide two types that serve the same =
purpose.
<br>
<br>> Let's define "optional<T>" as a container of T with zero or =
one element, and
<br>> nullable<T>, as a type to add null semantics to a type that =
does not already
<br>> have it, so it can store either a value of type T or nullptr.
<br>> Both represents wether we have a value or not, but they have a dif=
ferent
<br>> interface.
<br>>
<br>>
<br>> By definition, optional<T> does not require a special value =
to indicate
<br>> whether it contains a value or to empty the container. Also, as "T=
" is one
<br>> element, T can be implicitly converted to optional<T>. And, =
as optional<T>
<br>> is a container, it is not implicitly converted to bool.
<br>>
<br>> optional<int> i; // default initialization, optional<T>=
; is empty
<br>> assert(i.empty());
<br>>
<br>> optional<int> j { 5 }; // optional<T> contains 5
<br>> assert(!j.empty());
<br>> j.clear(); // removes the value
<br>> assert(j.empty());
<br>>
<br>> j =3D { 6 }; // optional<T> contains 6
<br>> i =3D j; // assignment performing deep copy
<br>> assert(!i.empty());
<br>>
<br>> i =3D 4; // 4 is implicitly converted to optional<T>(4), the=
n deep-copy.
<br>>
<br>> // to get or set the value
<br>> int k;
<br>>
<br>> k =3D *i.begin(); // container interface
<br>> k =3D <a href=3D"http://i.at" target=3D"_blank">i.at</a>(0); // co=
ntainer interface, with bound checking
<br>> k =3D i[0]; // container interface
<br>> k =3D i.val(); // helper method?
<br>> k =3D (int&)i; // why not casting? it makes the operation expl=
icit
<br>>
<br>> k =3D *i; // WRONG, i is not a pointer, nor pointer-like. -> wo=
uldn't work
<br>> either.
<br>>
<br>>
<br>> vector have relational operators, so does optional. As T can be im=
plicitly
<br>> converted to optional<T>, mixed comparision would apply.
<br>> For those who are concerned, it could be possible to declare the m=
ixed
<br>> operators as "poisonous" in a forbidding_of_mixed_optional_<wbr>re=
l_ops
<br>> namespace.
<br>>
<br>> if(i < 5) { ... } // would work
<br>>
<br>> using namespace forbidding_of_mixed_optional_<wbr>rel_ops;
<br>>
<br>> if(i < 5) { ... } // won't compile
<br>>
<br>>
<br>> Considering nullable<T>, by definition, it can be considered=
as a pointer.
<br>> Therefore T cannot be implicitly converted to nullable<T>, a=
s you cannot
<br>> write int* p =3D 5; But, it can be implicitly be converted to bool=
or compared
<br>> to nullptr.
<br>>
<br>> nullable<int> i; // default initialization
<br>> assert(i =3D=3D nullptr);
<br>>
<br>> nullable<int> j { 5 };
<br>> assert(j);
<br>> j =3D nullptr; // removes the value, same as j.reset();
<br>> assert(j =3D=3D nullptr);
<br>>
<br>> j =3D make_nullable(6);
<br>> i =3D j; // asignment performing deep copy. It is a pointer-like i=
nterface,
<br>> not a pointer. shared_ptr increments the refcount, unique_ptr move=
s the
<br>> pointer...
<br>> assert(i);
<br>>
<br>> *i =3D 4; // sets the value, undefined if i =3D=3D nullptr
<br>>
<br>> // to get or set the value
<br>> int k;
<br>>
<br>> k =3D i.get(); // smart pointer interface
<br>> k =3D *i; // pointer-like interface, -> would work too
<br>> k =3D i.val(); // helper method?
<br>>
<br>> // to set, we could define
<br>> i.reset();
<br>> i.val();
<br>>
<br>> Like unique_ptr and shared_ptr, nullable<T> has relational o=
perators, that
<br>> can be mixed only with nullptr_t. We could provide also
<br>> template <class T, class U>
<br>> bool operator=3D=3D (const nullable<T>& lhs, const nulla=
ble<U>& rhs) noexcept;
<br>> if T and U can compare.
<br>>
<br>>
<br>> And, finally, we could also provide explicit conversion from nulla=
ble<T> to
<br>> optional<T>, and vice-versa, so we can use both of them.
<br>>
<br>>
<br>> What do you think?
<br>>
<br>> Best regards,
<br>> Vincent
<br>>
<br>>
<br>> On Monday, January 28, 2013 11:28:00 AM UTC+1, Ville Voutilainen w=
rote:
<br>>>
<br>>> On 28 January 2013 12:15, Olaf van der Spek <<a>olafv...@gm=
ail.com</a>> wrote:
<br>>> >> I don't think that's the core of this problem.
<br>>> >> Supporting mixed relops is a bit like answering "What=
is the color of
<br>>> >> this non-existing ball?" The color is undefined and I=
don't really
<br>>> >> know how to map undefined to bool.
<br>>> >> Even normal relops might suffer from this issue.
<br>>> > Let me also take this opportunity to request some links t=
o real-world
<br>>> > client code using (mixed) relops.
<br>>> > Arguing about concrete code might be a bit easier.
<br>>>
<br>>> I suppose the boost people might know about such examples. Reg=
arding mixed
<br>>> relops, I fail to see how they are any different for optional =
as they
<br>>> are for pointers
<br>>> when nullptr is involved, and that's already well-specified.
<br>>>
<br>>> People can also continue debating whether optional is pointer-=
like or
<br>>> container-like
<br>>> and whether it has operator* or whether it has X Y and Z. If w=
e fail
<br>>> to provide a useful
<br>>> optional, I at least will continue expressing such things with
<br>>> pointers. If I get paid
<br>>> enough, I can express such things with a vector of 0-1 element=
s, but I
<br>>> certainly
<br>>> don't expect to do that. ;)
<br>>
<br>> --
<br>>
<br>> ---
<br>> You received this message because you are subscribed to the Google=
Groups
<br>> "ISO C++ Standard - Future Proposals" group.
<br>> To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"yYI8TL_KJFsJ">std-pr...@isocpp.org</a=
>.
<br>> To unsubscribe from this group, send email to
<br>> <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D=
"yYI8TL_KJFsJ">std-proposal...@<wbr>isocpp.org</a>.
<br>> Visit this group at
<br>> <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den" target=3D"_blank">http://groups.google.com/a/<wbr>isocpp.org/g=
roup/std-<wbr>proposals/?hl=3Den</a>.
<br>>
<br>>
<br></blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_759_1210289.1359406846313--
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Tue, 29 Jan 2013 08:32:57 +1100
Raw View
On Tue, Jan 29, 2013 at 7:38 AM, Andrzej Krzemie=F1ski <akrzemi1@gmail.com>=
wrote:
> W dniu poniedzia=B3ek, 28 stycznia 2013 21:25:31 UTC+1 u=BFytkownik Vladi=
mir
> Batov napisa=B3:
>> On Mon, Jan 28, 2013 at 10:25 PM, Andrzej Krzemie=F1ski
>> <akrz...@gmail.com> wrote:
>> >
>> > W dniu poniedzia=B3ek, 28 stycznia 2013 12:15:25 UTC+1 u=BFytkownik Vi=
lle
>> > Voutilainen napisa=B3:
>> >>
>> >> On 28 January 2013 12:54, Olaf van der Spek <olafv...@gmail.com> wrot=
e:
>> >> >> Very astute, but I think that's not problematic, as I see T and
>> >> >> optional<T>
>> >> >> to be similar enough that optional<T> just adds the nullopt to the
>> >> >> set of valid
>> >> >> values. Mixed relops are practically just an optimization to avoid
>> >> >> having
>> >> >> to construct an optional<T> from a T and then do the comparison.
>> >> > There's no need to construct a temp optional, you could just use !o=
pt
>> >> > && opt < 5 or so.
>> >>
>> >> Perhaps failing to write *opt < 5 there and using && instead of || is
>> >> an indication
>> >> that it would be simpler to have mixed relops? :)
>> >>
>> >> >> All in
>> >> >> all, the benefits of mixed relops for optional are convincing enou=
gh
>> >> >> for me
>> >> >> that I think we should have them, I'm not convinced by the concern=
s
>> >> >> that
>> >> >> people have about the potential problems.
>> >> > Shouldn't we be looking at real-world code before concluding that
>> >> > it's
>> >> > good to have them?
>> > ...
>> > On a slightly different subject, there are two "kinds" of arguments
>> > against poisoning the relops.
>> > One is that "refactoring safety" is illegitimate expectation or that i=
t
>> > is less important that
>> > convenience. The other "kind" is that it is impossible to offer
>> > "refactoring safety" for
>> > std::optional anyway because of optional's contextual conversion to
>> > bool, especially
>> > (but not only) in the case of optional<bool>. I find latter argument
>> > (stated already by
>> > a couple of people) stronger, because it must sound convincing even fo=
r
>> > people that
>> > value the "refactoring safety".
>>
>> Well, these "arguments against poisoning the relops" that you mention
>> indeed seem to be the most expressed (or at least I seem to stumble
>> upon those more often). In all fairness, they are not exactly
>> "arguments against poisoning the relops". They are more like saying
>> "these arguments for poisoning the relops are not convincing/scary
>> enough for us to sacrifice the convenience of the mixed relops".
>>
>> What I personally do find to be two serious arguments in favor of
>> poisoning the relops are that
>> 1) those mixed relops are not essential to the optional interface and
>> 2) refactoring or no refactoring, mixed relops cannot correctly
>> express programming logic.
>>
>> I personally much prefer the explicitness and unambiguity of "opt &&
>> *opt < 5" to "opt < 5". However, that is probably a matter of style.
>> What is *really* important IMO is that "opt < 5" is not necessarily
>> correct. Allowing "opt < 5" sends the wrong message that nullopt is
>> handled correctly when it cannot. In general terms nullopt (disengaged
>> optional<T>) cannot be correctly treated by a mixed-relopt as nullopt
>> is not part of the available T range and must be evaluated separately
>> no matter how "inconvenient" that might feel. In many respect nullopt
>> is a kind of NaN for an arbitrary type. NaN is not only the "effect of
>> 'erroneous' computation". It also used to represent missing values in
>> computations (then NaNs are explicitly assigned to variables), i.e.
>> exactly what 'optional' is for. Comparisons with NaN are undefined.
>>
>> Consequently, now I feel that mixed relops have to be disabled as the
>> perceived convenience comes at the expense of correctness.
>
> I understand this reasoning (not necessarily agree with it).
I thought you were *for* disabling/poisoning mixed relops? ;-)
> But does the root of this problem lay in mixed relops?
I might get convinced otherwise later (I am such a flip-flop) but at
the moment I suspect so. Because (as I see it now) mixed relops
compare "apples" (from the available T range) with "apples + orange".
The "orange" being NaN-T -- disengaged optional<T>... And the
comparison with the "orange" is invalid.
> "Homogenous" relational operators
> of optional already display these "least of all values of T" semantics.
There is a subtle but important IMO difference -- "Homogenous" relops
work with optionals. So, they, in fact, display "least of all
optional<T>" semantics. Indeed, the "least" part is somewhat
arbitrary. However, that decision belongs and is confined to the
optional class and you, as the class designer, can and do make that
choice. The optional designer cannot possibly (read "correctly")
impose that choice onto all possible T types. So, the only correct way
is to avoid/prohibit that comparison (as is the case with NaN).
> And
> together with implicit construction from T we get implicit mixed relops
> (this is why we are considering poisoning them).
Yes, I agree that that implicit construction back-door needs to be
closed via mixed-relops poisoning. Here, the more I think about "op <
5" the less I like it as it's not immediately obvious if it is
comparing optionals or it's comparing underlying objects... and those
are not the same thing. Optional does a very good job blurring that
distinction... maybe too good a job :-)... that's why we've spent so
much time discussing "op < 5"... which is *strictly* speaking "orange
< apple", i.e. invalid in the strict computational sense.
> Do you find it a consistent approach to poison mixed relops and at the sa=
me
> time keep current homogenous relops and implicit conversion from T?
I am personally very comfortable with that approach.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Mon, 28 Jan 2013 23:03:11 +0100
Raw View
On Mon, Jan 28, 2013 at 10:32 PM, Vladimir Batov <vb.mail.247@gmail.com> wrote:
>> And
>> together with implicit construction from T we get implicit mixed relops
>> (this is why we are considering poisoning them).
>
> Yes, I agree that that implicit construction back-door needs to be
> closed via mixed-relops poisoning. Here, the more I think about "op <
> 5" the less I like it as it's not immediately obvious if it is
> comparing optionals or it's comparing underlying objects... and those
> are not the same thing. Optional does a very good job blurring that
> distinction... maybe too good a job :-)... that's why we've spent so
> much time discussing "op < 5"... which is *strictly* speaking "orange
> < apple", i.e. invalid in the strict computational sense.
>
>> Do you find it a consistent approach to poison mixed relops and at the same
>> time keep current homogenous relops and implicit conversion from T?
>
> I am personally very comfortable with that approach.
How common are normal optional relops being used?
They basically suffer from the same problems.
Removing them would avoid the issue with implicit optional construction too.
--
Olaf
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Tue, 29 Jan 2013 09:15:29 +1100
Raw View
On Tue, Jan 29, 2013 at 9:03 AM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Mon, Jan 28, 2013 at 10:32 PM, Vladimir Batov <vb.mail.247@gmail.com> wrote:
>>> And
>>> together with implicit construction from T we get implicit mixed relops
>>> (this is why we are considering poisoning them).
>>
>> Yes, I agree that that implicit construction back-door needs to be
>> closed via mixed-relops poisoning. Here, the more I think about "op <
>> 5" the less I like it as it's not immediately obvious if it is
>> comparing optionals or it's comparing underlying objects... and those
>> are not the same thing. Optional does a very good job blurring that
>> distinction... maybe too good a job :-)... that's why we've spent so
>> much time discussing "op < 5"... which is *strictly* speaking "orange
>> < apple", i.e. invalid in the strict computational sense.
>>
>>> Do you find it a consistent approach to poison mixed relops and at the same
>>> time keep current homogenous relops and implicit conversion from T?
>>
>> I am personally very comfortable with that approach.
>
> How common are normal optional relops being used?
Aren't they essential for optional to be used with ass. containers?
> They basically suffer from the same problems.
I do not believe so (at present anyway). Because as I tried to explain
"homogeneous" relops compare the same types (legit and the behavior
are ultimately up for the developer's discretion).
> Removing them would avoid the issue with implicit optional construction too.
I am not sure how important might std::set<optional> might be. Seems
quite important.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Vincent Jacquet <vjacquet@flowgroup.fr>
Date: Mon, 28 Jan 2013 14:27:54 -0800 (PST)
Raw View
------=_Part_711_2020379.1359412074751
Content-Type: text/plain; charset=ISO-8859-1
vector and valarray both holds an array of elements, yet vector emphasizes
the container interface while valarray emphasizes the mathematical
operations on the items.
Personnally, if by defining two different types I can choose a
container-like or a pointer-like or interface, implicit conversion or not,
mixed relops or not, I wouldn't mind.
Regards,
Vincent
On Monday, January 28, 2013 7:22:23 PM UTC+1, Jeffrey Yasskin wrote:
>
> On Mon, Jan 28, 2013 at 10:03 AM, Vincent Jacquet <vjac...@flowgroup.fr<javascript:>>
> wrote:
> > The more I think about it, the more I wonder if we shouldn't define two
> > different representation of the same idea, because I can't decide if I
> want
> > a container-like interface or a pointer-like.
> > And if we want to have both in the same type, we might end up having
> > neither.
> >
> > Does the following make sense to you or is it just wasteful ?
>
> Just wasteful, IMO. We shouldn't provide two types that serve the same
> purpose.
>
> > Let's define "optional<T>" as a container of T with zero or one element,
> and
> > nullable<T>, as a type to add null semantics to a type that does not
> already
> > have it, so it can store either a value of type T or nullptr.
> > Both represents wether we have a value or not, but they have a different
> > interface.
> >
> >
> > By definition, optional<T> does not require a special value to indicate
> > whether it contains a value or to empty the container. Also, as "T" is
> one
> > element, T can be implicitly converted to optional<T>. And, as
> optional<T>
> > is a container, it is not implicitly converted to bool.
> >
> > optional<int> i; // default initialization, optional<T> is empty
> > assert(i.empty());
> >
> > optional<int> j { 5 }; // optional<T> contains 5
> > assert(!j.empty());
> > j.clear(); // removes the value
> > assert(j.empty());
> >
> > j = { 6 }; // optional<T> contains 6
> > i = j; // assignment performing deep copy
> > assert(!i.empty());
> >
> > i = 4; // 4 is implicitly converted to optional<T>(4), then deep-copy.
> >
> > // to get or set the value
> > int k;
> >
> > k = *i.begin(); // container interface
> > k = i.at(0); // container interface, with bound checking
> > k = i[0]; // container interface
> > k = i.val(); // helper method?
> > k = (int&)i; // why not casting? it makes the operation explicit
> >
> > k = *i; // WRONG, i is not a pointer, nor pointer-like. -> wouldn't work
> > either.
> >
> >
> > vector have relational operators, so does optional. As T can be
> implicitly
> > converted to optional<T>, mixed comparision would apply.
> > For those who are concerned, it could be possible to declare the mixed
> > operators as "poisonous" in a forbidding_of_mixed_optional_rel_ops
> > namespace.
> >
> > if(i < 5) { ... } // would work
> >
> > using namespace forbidding_of_mixed_optional_rel_ops;
> >
> > if(i < 5) { ... } // won't compile
> >
> >
> > Considering nullable<T>, by definition, it can be considered as a
> pointer.
> > Therefore T cannot be implicitly converted to nullable<T>, as you cannot
> > write int* p = 5; But, it can be implicitly be converted to bool or
> compared
> > to nullptr.
> >
> > nullable<int> i; // default initialization
> > assert(i == nullptr);
> >
> > nullable<int> j { 5 };
> > assert(j);
> > j = nullptr; // removes the value, same as j.reset();
> > assert(j == nullptr);
> >
> > j = make_nullable(6);
> > i = j; // asignment performing deep copy. It is a pointer-like
> interface,
> > not a pointer. shared_ptr increments the refcount, unique_ptr moves the
> > pointer...
> > assert(i);
> >
> > *i = 4; // sets the value, undefined if i == nullptr
> >
> > // to get or set the value
> > int k;
> >
> > k = i.get(); // smart pointer interface
> > k = *i; // pointer-like interface, -> would work too
> > k = i.val(); // helper method?
> >
> > // to set, we could define
> > i.reset();
> > i.val();
> >
> > Like unique_ptr and shared_ptr, nullable<T> has relational operators,
> that
> > can be mixed only with nullptr_t. We could provide also
> > template <class T, class U>
> > bool operator== (const nullable<T>& lhs, const nullable<U>& rhs)
> noexcept;
> > if T and U can compare.
> >
> >
> > And, finally, we could also provide explicit conversion from nullable<T>
> to
> > optional<T>, and vice-versa, so we can use both of them.
> >
> >
> > What do you think?
> >
> > Best regards,
> > Vincent
> >
> >
> > On Monday, January 28, 2013 11:28:00 AM UTC+1, Ville Voutilainen wrote:
> >>
> >> On 28 January 2013 12:15, Olaf van der Spek <olafv...@gmail.com>
> wrote:
> >> >> I don't think that's the core of this problem.
> >> >> Supporting mixed relops is a bit like answering "What is the color
> of
> >> >> this non-existing ball?" The color is undefined and I don't really
> >> >> know how to map undefined to bool.
> >> >> Even normal relops might suffer from this issue.
> >> > Let me also take this opportunity to request some links to real-world
> >> > client code using (mixed) relops.
> >> > Arguing about concrete code might be a bit easier.
> >>
> >> I suppose the boost people might know about such examples. Regarding
> mixed
> >> relops, I fail to see how they are any different for optional as they
> >> are for pointers
> >> when nullptr is involved, and that's already well-specified.
> >>
> >> People can also continue debating whether optional is pointer-like or
> >> container-like
> >> and whether it has operator* or whether it has X Y and Z. If we fail
> >> to provide a useful
> >> optional, I at least will continue expressing such things with
> >> pointers. If I get paid
> >> enough, I can express such things with a vector of 0-1 elements, but I
> >> certainly
> >> don't expect to do that. ;)
> >
> > --
> >
> > ---
> > You received this message because you are subscribed to the Google
> Groups
> > "ISO C++ Standard - Future Proposals" group.
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>
> > To unsubscribe from this group, send email to
> > std-proposal...@isocpp.org <javascript:>.
> > Visit this group at
> > http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
> >
> >
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_711_2020379.1359412074751
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>vector and valarray both holds an array of elements, yet vector emphas=
izes the container interface while valarray emphasizes the mathematical ope=
rations on the items.</div><div><br></div><div>Personnally, if by defining =
two different types I can choose a container-like or a pointer-like or =
;interface, implicit conversion or not, mixed relops or not, I wouldn't min=
d.</div><div><br></div><div>Regards,<br></div><div>Vincent</div><br>On Mond=
ay, January 28, 2013 7:22:23 PM UTC+1, Jeffrey Yasskin wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">On Mon, Jan 28, 2013 at 10:03 AM, Vincent Ja=
cquet <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"yYI8TL_KJFsJ">vjac...@flowgroup.fr</a>> wrote:
<br>> The more I think about it, the more I wonder if we shouldn't defin=
e two
<br>> different representation of the same idea, because I can't decide =
if I want
<br>> a container-like interface or a pointer-like.
<br>> And if we want to have both in the same type, we might end up havi=
ng
<br>> neither.
<br>>
<br>> Does the following make sense to you or is it just wasteful ?
<br>
<br>Just wasteful, IMO. We shouldn't provide two types that serve the same =
purpose.
<br>
<br>> Let's define "optional<T>" as a container of T with zero or =
one element, and
<br>> nullable<T>, as a type to add null semantics to a type that =
does not already
<br>> have it, so it can store either a value of type T or nullptr.
<br>> Both represents wether we have a value or not, but they have a dif=
ferent
<br>> interface.
<br>>
<br>>
<br>> By definition, optional<T> does not require a special value =
to indicate
<br>> whether it contains a value or to empty the container. Also, as "T=
" is one
<br>> element, T can be implicitly converted to optional<T>. And, =
as optional<T>
<br>> is a container, it is not implicitly converted to bool.
<br>>
<br>> optional<int> i; // default initialization, optional<T>=
; is empty
<br>> assert(i.empty());
<br>>
<br>> optional<int> j { 5 }; // optional<T> contains 5
<br>> assert(!j.empty());
<br>> j.clear(); // removes the value
<br>> assert(j.empty());
<br>>
<br>> j =3D { 6 }; // optional<T> contains 6
<br>> i =3D j; // assignment performing deep copy
<br>> assert(!i.empty());
<br>>
<br>> i =3D 4; // 4 is implicitly converted to optional<T>(4), the=
n deep-copy.
<br>>
<br>> // to get or set the value
<br>> int k;
<br>>
<br>> k =3D *i.begin(); // container interface
<br>> k =3D <a href=3D"http://i.at" target=3D"_blank">i.at</a>(0); // co=
ntainer interface, with bound checking
<br>> k =3D i[0]; // container interface
<br>> k =3D i.val(); // helper method?
<br>> k =3D (int&)i; // why not casting? it makes the operation expl=
icit
<br>>
<br>> k =3D *i; // WRONG, i is not a pointer, nor pointer-like. -> wo=
uldn't work
<br>> either.
<br>>
<br>>
<br>> vector have relational operators, so does optional. As T can be im=
plicitly
<br>> converted to optional<T>, mixed comparision would apply.
<br>> For those who are concerned, it could be possible to declare the m=
ixed
<br>> operators as "poisonous" in a forbidding_of_mixed_optional_<wbr>re=
l_ops
<br>> namespace.
<br>>
<br>> if(i < 5) { ... } // would work
<br>>
<br>> using namespace forbidding_of_mixed_optional_<wbr>rel_ops;
<br>>
<br>> if(i < 5) { ... } // won't compile
<br>>
<br>>
<br>> Considering nullable<T>, by definition, it can be considered=
as a pointer.
<br>> Therefore T cannot be implicitly converted to nullable<T>, a=
s you cannot
<br>> write int* p =3D 5; But, it can be implicitly be converted to bool=
or compared
<br>> to nullptr.
<br>>
<br>> nullable<int> i; // default initialization
<br>> assert(i =3D=3D nullptr);
<br>>
<br>> nullable<int> j { 5 };
<br>> assert(j);
<br>> j =3D nullptr; // removes the value, same as j.reset();
<br>> assert(j =3D=3D nullptr);
<br>>
<br>> j =3D make_nullable(6);
<br>> i =3D j; // asignment performing deep copy. It is a pointer-like i=
nterface,
<br>> not a pointer. shared_ptr increments the refcount, unique_ptr move=
s the
<br>> pointer...
<br>> assert(i);
<br>>
<br>> *i =3D 4; // sets the value, undefined if i =3D=3D nullptr
<br>>
<br>> // to get or set the value
<br>> int k;
<br>>
<br>> k =3D i.get(); // smart pointer interface
<br>> k =3D *i; // pointer-like interface, -> would work too
<br>> k =3D i.val(); // helper method?
<br>>
<br>> // to set, we could define
<br>> i.reset();
<br>> i.val();
<br>>
<br>> Like unique_ptr and shared_ptr, nullable<T> has relational o=
perators, that
<br>> can be mixed only with nullptr_t. We could provide also
<br>> template <class T, class U>
<br>> bool operator=3D=3D (const nullable<T>& lhs, const nulla=
ble<U>& rhs) noexcept;
<br>> if T and U can compare.
<br>>
<br>>
<br>> And, finally, we could also provide explicit conversion from nulla=
ble<T> to
<br>> optional<T>, and vice-versa, so we can use both of them.
<br>>
<br>>
<br>> What do you think?
<br>>
<br>> Best regards,
<br>> Vincent
<br>>
<br>>
<br>> On Monday, January 28, 2013 11:28:00 AM UTC+1, Ville Voutilainen w=
rote:
<br>>>
<br>>> On 28 January 2013 12:15, Olaf van der Spek <<a>olafv...@gm=
ail.com</a>> wrote:
<br>>> >> I don't think that's the core of this problem.
<br>>> >> Supporting mixed relops is a bit like answering "What=
is the color of
<br>>> >> this non-existing ball?" The color is undefined and I=
don't really
<br>>> >> know how to map undefined to bool.
<br>>> >> Even normal relops might suffer from this issue.
<br>>> > Let me also take this opportunity to request some links t=
o real-world
<br>>> > client code using (mixed) relops.
<br>>> > Arguing about concrete code might be a bit easier.
<br>>>
<br>>> I suppose the boost people might know about such examples. Reg=
arding mixed
<br>>> relops, I fail to see how they are any different for optional =
as they
<br>>> are for pointers
<br>>> when nullptr is involved, and that's already well-specified.
<br>>>
<br>>> People can also continue debating whether optional is pointer-=
like or
<br>>> container-like
<br>>> and whether it has operator* or whether it has X Y and Z. If w=
e fail
<br>>> to provide a useful
<br>>> optional, I at least will continue expressing such things with
<br>>> pointers. If I get paid
<br>>> enough, I can express such things with a vector of 0-1 element=
s, but I
<br>>> certainly
<br>>> don't expect to do that. ;)
<br>>
<br>> --
<br>>
<br>> ---
<br>> You received this message because you are subscribed to the Google=
Groups
<br>> "ISO C++ Standard - Future Proposals" group.
<br>> To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"yYI8TL_KJFsJ">std-pr...@isocpp.org</a=
>.
<br>> To unsubscribe from this group, send email to
<br>> <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D=
"yYI8TL_KJFsJ">std-proposal...@<wbr>isocpp.org</a>.
<br>> Visit this group at
<br>> <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den" target=3D"_blank">http://groups.google.com/a/<wbr>isocpp.org/g=
roup/std-<wbr>proposals/?hl=3Den</a>.
<br>>
<br>>
<br></blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_711_2020379.1359412074751--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Mon, 28 Jan 2013 15:03:20 -0800 (PST)
Raw View
------=_Part_1004_14954337.1359414200587
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu poniedzia=B3ek, 28 stycznia 2013 22:32:57 UTC+1 u=BFytkownik Vladimi=
r=20
Batov napisa=B3:
>
> On Tue, Jan 29, 2013 at 7:38 AM, Andrzej Krzemie=F1ski <akrz...@gmail.com=
<javascript:>>=20
> wrote:=20
> > W dniu poniedzia=B3ek, 28 stycznia 2013 21:25:31 UTC+1 u=BFytkownik Vla=
dimir=20
> > Batov napisa=B3:=20
> >> On Mon, Jan 28, 2013 at 10:25 PM, Andrzej Krzemie=F1ski=20
> >> <akrz...@gmail.com> wrote:=20
> >> >=20
> >> > W dniu poniedzia=B3ek, 28 stycznia 2013 12:15:25 UTC+1 u=BFytkownik =
Ville=20
> >> > Voutilainen napisa=B3:=20
> >> >>=20
> >> >> On 28 January 2013 12:54, Olaf van der Spek <olafv...@gmail.com>=20
> wrote:=20
> >> >> >> Very astute, but I think that's not problematic, as I see T and=
=20
> >> >> >> optional<T>=20
> >> >> >> to be similar enough that optional<T> just adds the nullopt to=
=20
> the=20
> >> >> >> set of valid=20
> >> >> >> values. Mixed relops are practically just an optimization to=20
> avoid=20
> >> >> >> having=20
> >> >> >> to construct an optional<T> from a T and then do the comparison.=
=20
> >> >> > There's no need to construct a temp optional, you could just use=
=20
> !opt=20
> >> >> > && opt < 5 or so.=20
> >> >>=20
> >> >> Perhaps failing to write *opt < 5 there and using && instead of ||=
=20
> is=20
> >> >> an indication=20
> >> >> that it would be simpler to have mixed relops? :)=20
> >> >>=20
> >> >> >> All in=20
> >> >> >> all, the benefits of mixed relops for optional are convincing=20
> enough=20
> >> >> >> for me=20
> >> >> >> that I think we should have them, I'm not convinced by the=20
> concerns=20
> >> >> >> that=20
> >> >> >> people have about the potential problems.=20
> >> >> > Shouldn't we be looking at real-world code before concluding that=
=20
> >> >> > it's=20
> >> >> > good to have them?=20
> >> > ...=20
> >> > On a slightly different subject, there are two "kinds" of arguments=
=20
> >> > against poisoning the relops.=20
> >> > One is that "refactoring safety" is illegitimate expectation or that=
=20
> it=20
> >> > is less important that=20
> >> > convenience. The other "kind" is that it is impossible to offer=20
> >> > "refactoring safety" for=20
> >> > std::optional anyway because of optional's contextual conversion to=
=20
> >> > bool, especially=20
> >> > (but not only) in the case of optional<bool>. I find latter argument=
=20
> >> > (stated already by=20
> >> > a couple of people) stronger, because it must sound convincing even=
=20
> for=20
> >> > people that=20
> >> > value the "refactoring safety".=20
> >>=20
> >> Well, these "arguments against poisoning the relops" that you mention=
=20
> >> indeed seem to be the most expressed (or at least I seem to stumble=20
> >> upon those more often). In all fairness, they are not exactly=20
> >> "arguments against poisoning the relops". They are more like saying=20
> >> "these arguments for poisoning the relops are not convincing/scary=20
> >> enough for us to sacrifice the convenience of the mixed relops".=20
> >>=20
> >> What I personally do find to be two serious arguments in favor of=20
> >> poisoning the relops are that=20
> >> 1) those mixed relops are not essential to the optional interface and=
=20
> >> 2) refactoring or no refactoring, mixed relops cannot correctly=20
> >> express programming logic.=20
> >>=20
> >> I personally much prefer the explicitness and unambiguity of "opt &&=
=20
> >> *opt < 5" to "opt < 5". However, that is probably a matter of style.=
=20
> >> What is *really* important IMO is that "opt < 5" is not necessarily=20
> >> correct. Allowing "opt < 5" sends the wrong message that nullopt is=20
> >> handled correctly when it cannot. In general terms nullopt (disengaged=
=20
> >> optional<T>) cannot be correctly treated by a mixed-relopt as nullopt=
=20
> >> is not part of the available T range and must be evaluated separately=
=20
> >> no matter how "inconvenient" that might feel. In many respect nullopt=
=20
> >> is a kind of NaN for an arbitrary type. NaN is not only the "effect of=
=20
> >> 'erroneous' computation". It also used to represent missing values in=
=20
> >> computations (then NaNs are explicitly assigned to variables), i.e.=20
> >> exactly what 'optional' is for. Comparisons with NaN are undefined.=20
> >>=20
> >> Consequently, now I feel that mixed relops have to be disabled as the=
=20
> >> perceived convenience comes at the expense of correctness.=20
> >=20
> > I understand this reasoning (not necessarily agree with it).=20
>
> I thought you were *for* disabling/poisoning mixed relops? ;-)=20
>
> > But does the root of this problem lay in mixed relops?=20
>
> I might get convinced otherwise later (I am such a flip-flop) but at=20
> the moment I suspect so. Because (as I see it now) mixed relops=20
> compare "apples" (from the available T range) with "apples + orange".=20
> The "orange" being NaN-T -- disengaged optional<T>... And the=20
> comparison with the "orange" is invalid.=20
>
I replied to this in a new thread:=20
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/j86CProQmoo/di=
scussion
This one is getting too long.
=20
>
> > "Homogenous" relational operators=20
> > of optional already display these "least of all values of T" semantics.=
=20
>
> There is a subtle but important IMO difference -- "Homogenous" relops=20
> work with optionals. So, they, in fact, display "least of all=20
> optional<T>" semantics. Indeed, the "least" part is somewhat=20
> arbitrary. However, that decision belongs and is confined to the=20
> optional class and you, as the class designer, can and do make that=20
> choice. The optional designer cannot possibly (read "correctly")=20
> impose that choice onto all possible T types. So, the only correct way=20
> is to avoid/prohibit that comparison (as is the case with NaN).=20
>
> > And=20
> > together with implicit construction from T we get implicit mixed relops=
=20
> > (this is why we are considering poisoning them).=20
>
> Yes, I agree that that implicit construction back-door needs to be=20
> closed via mixed-relops poisoning. Here, the more I think about "op <=20
> 5" the less I like it as it's not immediately obvious if it is=20
> comparing optionals or it's comparing underlying objects... and those=20
> are not the same thing. Optional does a very good job blurring that=20
> distinction... maybe too good a job :-)... that's why we've spent so=20
> much time discussing "op < 5"... which is *strictly* speaking "orange=20
> < apple", i.e. invalid in the strict computational sense.=20
>
> > Do you find it a consistent approach to poison mixed relops and at the=
=20
> same=20
> > time keep current homogenous relops and implicit conversion from T?=20
>
> I am personally very comfortable with that approach.=20
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_1004_14954337.1359414200587
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu poniedzia=B3ek, 28 stycznia 2013 22:32:57 UTC+1 u=BFytkownik=
Vladimir Batov napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On T=
ue, Jan 29, 2013 at 7:38 AM, Andrzej Krzemie=F1ski <<a href=3D"javascrip=
t:" target=3D"_blank" gdf-obfuscated-mailto=3D"6P4zUlRz7eEJ">akrz...@gmail.=
com</a>> wrote:
<br>> W dniu poniedzia=B3ek, 28 stycznia 2013 21:25:31 UTC+1 u=BFytkowni=
k Vladimir
<br>> Batov napisa=B3:
<br>>> On Mon, Jan 28, 2013 at 10:25 PM, Andrzej Krzemie=F1ski
<br>>> <<a>akrz...@gmail.com</a>> wrote:
<br>>> >
<br>>> > W dniu poniedzia=B3ek, 28 stycznia 2013 12:15:25 UTC+1 u=
=BFytkownik Ville
<br>>> > Voutilainen napisa=B3:
<br>>> >>
<br>>> >> On 28 January 2013 12:54, Olaf van der Spek <<a>ol=
afv...@gmail.com</a>> wrote:
<br>>> >> >> Very astute, but I think that's not problema=
tic, as I see T and
<br>>> >> >> optional<T>
<br>>> >> >> to be similar enough that optional<T> =
just adds the nullopt to the
<br>>> >> >> set of valid
<br>>> >> >> values. Mixed relops are practically just an=
optimization to avoid
<br>>> >> >> having
<br>>> >> >> to construct an optional<T> from a T a=
nd then do the comparison.
<br>>> >> > There's no need to construct a temp optional, yo=
u could just use !opt
<br>>> >> > && opt < 5 or so.
<br>>> >>
<br>>> >> Perhaps failing to write *opt < 5 there and using =
&& instead of || is
<br>>> >> an indication
<br>>> >> that it would be simpler to have mixed relops? :)
<br>>> >>
<br>>> >> >> All in
<br>>> >> >> all, the benefits of mixed relops for option=
al are convincing enough
<br>>> >> >> for me
<br>>> >> >> that I think we should have them, I'm not co=
nvinced by the concerns
<br>>> >> >> that
<br>>> >> >> people have about the potential problems.
<br>>> >> > Shouldn't we be looking at real-world code befor=
e concluding that
<br>>> >> > it's
<br>>> >> > good to have them?
<br>>> > ...
<br>>> > On a slightly different subject, there are two "kinds" of=
arguments
<br>>> > against poisoning the relops.
<br>>> > One is that "refactoring safety" is illegitimate expectat=
ion or that it
<br>>> > is less important that
<br>>> > convenience. The other "kind" is that it is impossible to=
offer
<br>>> > "refactoring safety" for
<br>>> > std::optional anyway because of optional's contextual con=
version to
<br>>> > bool, especially
<br>>> > (but not only) in the case of optional<bool>. I fin=
d latter argument
<br>>> > (stated already by
<br>>> > a couple of people) stronger, because it must sound convi=
ncing even for
<br>>> > people that
<br>>> > value the "refactoring safety".
<br>>>
<br>>> Well, these "arguments against poisoning the relops" that you =
mention
<br>>> indeed seem to be the most expressed (or at least I seem to st=
umble
<br>>> upon those more often). In all fairness, they are not exactly
<br>>> "arguments against poisoning the relops". They are more like s=
aying
<br>>> "these arguments for poisoning the relops are not convincing/s=
cary
<br>>> enough for us to sacrifice the convenience of the mixed relops=
".
<br>>>
<br>>> What I personally do find to be two serious arguments in favor=
of
<br>>> poisoning the relops are that
<br>>> 1) those mixed relops are not essential to the optional interf=
ace and
<br>>> 2) refactoring or no refactoring, mixed relops cannot correctl=
y
<br>>> express programming logic.
<br>>>
<br>>> I personally much prefer the explicitness and unambiguity of "=
opt &&
<br>>> *opt < 5" to "opt < 5". However, that is probably a matt=
er of style.
<br>>> What is *really* important IMO is that "opt < 5" is not nec=
essarily
<br>>> correct. Allowing "opt < 5" sends the wrong message that nu=
llopt is
<br>>> handled correctly when it cannot. In general terms nullopt (di=
sengaged
<br>>> optional<T>) cannot be correctly treated by a mixed-relo=
pt as nullopt
<br>>> is not part of the available T range and must be evaluated sep=
arately
<br>>> no matter how "inconvenient" that might feel. In many respect =
nullopt
<br>>> is a kind of NaN for an arbitrary type. NaN is not only the "e=
ffect of
<br>>> 'erroneous' computation". It also used to represent missing va=
lues in
<br>>> computations (then NaNs are explicitly assigned to variables),=
i.e.
<br>>> exactly what 'optional' is for. Comparisons with NaN are undef=
ined.
<br>>>
<br>>> Consequently, now I feel that mixed relops have to be disabled=
as the
<br>>> perceived convenience comes at the expense of correctness.
<br>>
<br>> I understand this reasoning (not necessarily agree with it).
<br>
<br>I thought you were *for* disabling/poisoning mixed relops? ;-)
<br>
<br>> But does the root of this problem lay in mixed relops?
<br>
<br>I might get convinced otherwise later (I am such a flip-flop) but at
<br>the moment I suspect so. Because (as I see it now) mixed relops
<br>compare "apples" (from the available T range) with "apples + orange".
<br>The "orange" being NaN-T -- disengaged optional<T>... And the
<br>comparison with the "orange" is invalid.
<br></blockquote><div><br>I replied to this in a new thread: https://groups=
..google.com/a/isocpp.org/d/topic/std-proposals/j86CProQmoo/discussion<br>Th=
is one is getting too long.<br> <br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;">
<br>> "Homogenous" relational operators
<br>> of optional already display these "least of all values of T" seman=
tics.
<br>
<br>There is a subtle but important IMO difference -- "Homogenous" relops
<br>work with optionals. So, they, in fact, display "least of all
<br>optional<T>" semantics. Indeed, the "least" part is somewhat
<br>arbitrary. However, that decision belongs and is confined to the
<br>optional class and you, as the class designer, can and do make that
<br>choice. The optional designer cannot possibly (read "correctly")
<br>impose that choice onto all possible T types. So, the only correct way
<br>is to avoid/prohibit that comparison (as is the case with NaN).
<br>
<br>> And
<br>> together with implicit construction from T we get implicit mixed r=
elops
<br>> (this is why we are considering poisoning them).
<br>
<br>Yes, I agree that that implicit construction back-door needs to be
<br>closed via mixed-relops poisoning. Here, the more I think about "op <=
;
<br>5" the less I like it as it's not immediately obvious if it is
<br>comparing optionals or it's comparing underlying objects... and those
<br>are not the same thing. Optional does a very good job blurring that
<br>distinction... maybe too good a job :-)... that's why we've spent so
<br>much time discussing "op < 5"... which is *strictly* speaking "orang=
e
<br>< apple", i.e. invalid in the strict computational sense.
<br>
<br>> Do you find it a consistent approach to poison mixed relops and at=
the same
<br>> time keep current homogenous relops and implicit conversion from T=
?
<br>
<br>I am personally very comfortable with that approach.
<br></blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1004_14954337.1359414200587--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Tue, 29 Jan 2013 22:19:57 +0100
Raw View
This is a multi-part message in MIME format.
--------------080206010005020000020003
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 22/01/13 22:18, Andrzej Krzemie=C5=84ski a =C3=A9crit :
> Hi Everyone,
> We are ready with the 3rd revision of std::optional proposal. The main=20
> changes:
>
> * |optional<T>| is hashable for hashable |T|'s.
> * Removed optional references --- they will be proposed separately.
> * |get_value_or| is now |optional|-specific member function.
> * |optional<T>| is a literal type.
> * Removed reference implementation. We now only provide the
> implementation of the parts that we consider non-trivial.
>
> We would appreciate your feedback and suggestions.
>
/Hello,
I have not read completely the proposal but I fill like the proposal is=20
over designed, that is there is more than I would expect. I don't find=20
answers to the following questions. Sorry if these has already been=20
discussed.
* What is the added value to have a nullopt?
optional<string> op{nullopt}; // disengaged
opt1 =3D nullopt;
if (opt1 =3D=3D nullopt) ...
run(nullopt);
versus
optional<string> op; // disengaged
opt1.reset();
if (!opt1) ...
run(optional<string>{}); // this is the single shorter expression
* I don't see a use case for mixed comparison of optional with=20
nullopt_t. Could you present a use case?
* What is the added value to make the constructor from T implicit? If it=20
is implicitly convertible, the example
bool MyPlan::exceedsCapacity() const
{
return passengerCount > availableSeats;
// availableSeats is of type unsigned int
}
will compile and suffer from the same issues as if the mixed operation=20
were defined
bool operator=3D=3D(const optional<T>& a, const T& b);
The example used to justify that conversion from U could risky could be=20
used to describe the same dangers for conversion from T.
// library
void fun(string const& s);
void fun(optional<const char*> const& s); // new overload
fun("hello"); // ERROR: ambiguity
Using make_optional seems to me a more robust interface, that could=20
seems less friendly at a first glance, but that prevents unexpected=20
behavior which would be more friendly at the end.
* Why the result of moving from optional is not a disengaged optional?=20
It seems to me that making it disengaed has minimal cost.
* optional<optional<T>>
The refactoring presented in the example is not motivating the current=20
design.
Anyway, if nullopt is not provided there is no confusion. Before the change
fun(optional<T>); // process() not called!
and after
fun(optional<optional<T>>{}); // external optional disengaged
fun(optional<optional<T>>{optional<T>{}}); // external optional engaged=20
with disengaged optional<T>
* It will be worth noting in the proposal that optional<bool> could be=20
used to represent a tribool. I find the implicit conversion to bool=20
somewhere confusing.
* I don't see the need for get_value_or in the standard as we don't have=20
it for pointer or smart pointers. Should the standard include a xxx_or=20
version for all the xxx functions that have a specific pre-condition?
E.g. should we have a front_or in case the container is empty?
* The choice for the ordering of disengaged optional and engaged ones=20
been arbitrary merits a deeper explanation of the alternatives to be=20
included on the proposal. What if the standard let this relation as=20
implementation defined? With the current proposal the following=20
implementation of find_bigest seems correct
/
//
optional<int> find_biggest( const vector<int>& vec )
{
optional<int> biggest;/// initialized to the SMALLEST/
for (int val : vec) {
if (biggest < val) { // ****** NOTE THE RELOP
biggest =3D val;
}
}
return biggest;
}
/
I would prefer that the user could not rely on whether disengaged=20
optional is less than or greater than any engaged optional. How would=20
you implement the find_smallest? Wouldn't the disengaged optional be=20
used as the biggest value in this case?//
//
* The explanation for a nested nullopt tag seems irrelevant as /
optional<int>::nullopt would be equivalent tooptional<int>{}, isn't it?
/Vicente ///
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
--------------080206010005020000020003
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DISO-8859-2"
http-equiv=3D"Content-Type">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 22/01/13 22:18, Andrzej Krzemie=C5=84=
ski
a =C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:569472df-1ea7-4597-a265-749376b237ea@isocpp.org"
type=3D"cite">Hi Everyone,<br>
We are ready with the 3rd revision of std::optional proposal. The
main changes:<br>
<ul>
<li><code>optional<T></code> is hashable for hashable <code>T=
</code>’s.</li>
<li>Removed optional references — they will be proposed
separately.</li>
<li><code>get_value_or</code> is now <code>optional</code>-specific
member function.</li>
<li><code>optional<T></code> is a literal type.</li>
<li>Removed reference implementation. We now only provide the
implementation of the parts that we consider non-trivial.</li>
</ul>
We would appreciate your feedback and suggestions.<br>
<br>
</blockquote>
<em>Hello,<br>
<br>
I have not read completely the proposal but I fill like the
proposal is over designed, that is there is more than I would
expect. I don't find answers to the following questions. Sorry if
these has already been discussed.<br>
<br>
<br>
* What is the added value to have a nullopt?<br>
<br>
=C2=A0 optional<string> op{nullopt};=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // disengaged<br>
=C2=A0 opt1 =3D nullopt;<br>
=C2=A0 if (opt1 =3D=3D nullopt) ...<br>
=C2=A0 run(nullopt);=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 <br>
<br>
versus<br>
<br>
=C2=A0 optional<string> op;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // disengaged<br>
=C2=A0 opt1.reset();<br>
=C2=A0 if (!opt1) ...<br>
=C2=A0 run(optional<string>{});=C2=A0=C2=A0=C2=A0 // this is th=
e single shorter
expression =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <br>
<br>
* I don't see a use case for mixed comparison of optional with
nullopt_t. Could you present a use case?<br>
<br>
* What is the added value to make the constructor from T implicit?
If it is implicitly convertible, the example<br>
<br>
bool=C2=A0 MyPlan::exceedsCapacity() const<br>
{<br>
=C2=A0 return passengerCount > availableSeats;<br>
=C2=A0 // availableSeats is of type unsigned int<br>
}<br>
<br>
will compile and suffer from the same issues as if the mixed
operation were defined<br>
=C2=A0<br>
bool operator=3D=3D(const optional<T>& a, const T& b);<=
br>
<br>
<br>
<br>
The example used to justify that conversion from U could risky
could be used to describe the same dangers for conversion from T.<br>
<br>
// library<br>
void fun(string const& s);<br>
void fun(optional<const char*> const& s);=C2=A0=C2=A0 // ne=
w
overload<br>
<br>
fun("hello");=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 // ERROR: ambiguity <br>
<br>
Using make_optional seems to me a more robust interface, that
could seems less friendly at a first glance, but that prevents
unexpected behavior which would be more friendly at the end.<br>
<br>
* Why the result of moving from optional is not a disengaged
optional? It seems to me that making it disengaed has minimal
cost.<br>
<br>
<br>
* optional<optional<T>><br>
<br>
The refactoring presented in the example is not motivating the
current design.<br>
<br>
Anyway, if nullopt is not provided there is no confusion. Before
the change<br>
<br>
fun(optional<T>); // process() not called!<br>
<br>
and after<br>
<br>
fun(optional<optional<T>>{}); // external optional
disengaged<br>
fun(optional<optional<T>>{optional<T>{}}); //
external optional engaged with disengaged optional<T><br>
=C2=A0<br>
<br>
* It will be worth noting in the proposal that
optional<bool> could be used to represent a tribool. I find
the implicit conversion to bool somewhere confusing.<br>
<br>
* I don't see the need for get_value_or in the standard as we
don't have it for pointer or smart pointers. Should the standard
include a xxx_or version for all the xxx functions that have a
specific pre-condition? <br>
E.g. should we have a front_or in case the container is empty?<br>
<br>
* The choice for the ordering of disengaged optional and engaged
ones been arbitrary merits a deeper explanation of the
alternatives to be included on the proposal. What if the standard
let this relation as implementation defined? With the current
proposal the following implementation of find_bigest seems correct<br=
>
</em><br>
<em>
<meta http-equiv=3D"content-type" content=3D"text/html;
charset=3DISO-8859-2">
</em>
<pre>optional<int> find_biggest( const vector<int>& vec=
)
{
optional<int> biggest; <em>// initialized to the SMALLEST</em>
for (int val : vec) {
if (biggest < val) { // ****** NOTE THE RELOP
biggest =3D val;
}
}
return biggest;
} </pre>
<em><br>
I would prefer that the user could not rely on whether disengaged
optional is less than or greater than any engaged optional. How
would you implement the find_smallest? Wouldn't the disengaged
optional be used as the biggest value in this case?</em><em> <br>
</em><em><br>
* The explanation for a nested nullopt tag seems irrelevant as=C2=A0<=
/em>
<pre>optional<int>::nullopt would be equivalent to <meta http-equ=
iv=3D"content-type" content=3D"text/html; charset=3DISO-8859-2">optional<=
;int>{}, isn't it?<pre></pre></pre>
<em>Vicente </em><em></em><br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--------------080206010005020000020003--
.
Author: Jeffrey Yasskin <jyasskin@googlers.com>
Date: Tue, 29 Jan 2013 13:39:35 -0800
Raw View
You should read the previous discussions on optional. Search this
list's archives.
On Tue, Jan 29, 2013 at 1:19 PM, Vicente J. Botet Escriba
<vicente.botet@wanadoo.fr> wrote:
> Le 22/01/13 22:18, Andrzej Krzemie=C5=84ski a =C3=A9crit :
>
> Hi Everyone,
> We are ready with the 3rd revision of std::optional proposal. The main
> changes:
>
> optional<T> is hashable for hashable T=E2=80=99s.
> Removed optional references =E2=80=94 they will be proposed separately.
> get_value_or is now optional-specific member function.
> optional<T> is a literal type.
> Removed reference implementation. We now only provide the implementation =
of
> the parts that we consider non-trivial.
>
> We would appreciate your feedback and suggestions.
>
> Hello,
>
> I have not read completely the proposal but I fill like the proposal is o=
ver
> designed, that is there is more than I would expect. I don't find answers=
to
> the following questions. Sorry if these has already been discussed.
>
>
> * What is the added value to have a nullopt?
>
> optional<string> op{nullopt}; // disengaged
> opt1 =3D nullopt;
> if (opt1 =3D=3D nullopt) ...
> run(nullopt);
>
> versus
>
> optional<string> op; // disengaged
> opt1.reset();
> if (!opt1) ...
> run(optional<string>{}); // this is the single shorter expression
>
> * I don't see a use case for mixed comparison of optional with nullopt_t.
> Could you present a use case?
>
> * What is the added value to make the constructor from T implicit? If it =
is
> implicitly convertible, the example
>
>
> bool MyPlan::exceedsCapacity() const
> {
> return passengerCount > availableSeats;
> // availableSeats is of type unsigned int
> }
>
> will compile and suffer from the same issues as if the mixed operation we=
re
> defined
>
> bool operator=3D=3D(const optional<T>& a, const T& b);
>
>
>
> The example used to justify that conversion from U could risky could be u=
sed
> to describe the same dangers for conversion from T.
>
> // library
> void fun(string const& s);
> void fun(optional<const char*> const& s); // new overload
>
> fun("hello"); // ERROR: ambiguity
>
> Using make_optional seems to me a more robust interface, that could seems
> less friendly at a first glance, but that prevents unexpected behavior wh=
ich
> would be more friendly at the end.
>
> * Why the result of moving from optional is not a disengaged optional? It
> seems to me that making it disengaed has minimal cost.
>
>
> * optional<optional<T>>
>
> The refactoring presented in the example is not motivating the current
> design.
>
> Anyway, if nullopt is not provided there is no confusion. Before the chan=
ge
>
> fun(optional<T>); // process() not called!
>
> and after
>
> fun(optional<optional<T>>{}); // external optional disengaged
> fun(optional<optional<T>>{optional<T>{}}); // external optional engaged w=
ith
> disengaged optional<T>
>
>
> * It will be worth noting in the proposal that optional<bool> could be us=
ed
> to represent a tribool. I find the implicit conversion to bool somewhere
> confusing.
>
> * I don't see the need for get_value_or in the standard as we don't have =
it
> for pointer or smart pointers. Should the standard include a xxx_or versi=
on
> for all the xxx functions that have a specific pre-condition?
> E.g. should we have a front_or in case the container is empty?
>
> * The choice for the ordering of disengaged optional and engaged ones bee=
n
> arbitrary merits a deeper explanation of the alternatives to be included =
on
> the proposal. What if the standard let this relation as implementation
> defined? With the current proposal the following implementation of
> find_bigest seems correct
>
> optional<int> find_biggest( const vector<int>& vec )
> {
> optional<int> biggest; // initialized to the SMALLEST
> for (int val : vec) {
> if (biggest < val) { // ****** NOTE THE RELOP
> biggest =3D val;
> }
> }
> return biggest;
> }
>
>
> I would prefer that the user could not rely on whether disengaged optiona=
l
> is less than or greater than any engaged optional. How would you implemen=
t
> the find_smallest? Wouldn't the disengaged optional be used as the bigges=
t
> value in this case?
>
> * The explanation for a nested nullopt tag seems irrelevant as
>
> optional<int>::nullopt would be equivalent to optional<int>{}, isn't it?
>
> Vicente
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=3Den.
>
>
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Tue, 29 Jan 2013 15:33:36 -0800 (PST)
Raw View
------=_Part_1995_31179320.1359502416330
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu wtorek, 29 stycznia 2013 22:19:57 UTC+1 u=BFytkownik Vicente J. Bote=
t=20
Escriba napisa=B3:
>
> Le 22/01/13 22:18, Andrzej Krzemie=EF=BF=BDski a =EF=BF=BDcrit=EF=BF=BD:
> =20
> Hi Everyone,
> We are ready with the 3rd revision of std::optional proposal. The main=20
> changes:
>
> - optional<T> is hashable for hashable T's.=20
> - Removed optional references -- they will be proposed separately.=20
> - get_value_or is now optional-specific member function.=20
> - optional<T> is a literal type.=20
> - Removed reference implementation. We now only provide the=20
> implementation of the parts that we consider non-trivial.=20
>
> We would appreciate your feedback and suggestions.
>
> *Hello,
>
> I have not read completely the proposal but I fill like the proposal is=
=20
> over designed, that is there is more than I would expect. I don't find=20
> answers to the following questions. Sorry if these has already been=20
> discussed.
>
>
> * What is the added value to have a nullopt?
>
> =EF=BF=BD optional<string> op{nullopt};=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=
=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=
=EF=BF=BD=20
> // disengaged
> =EF=BF=BD opt1 =3D nullopt;
> =EF=BF=BD if (opt1 =3D=3D nullopt) ...
> =EF=BF=BD run(nullopt);=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=
=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=20
>
> versus
>
> =EF=BF=BD optional<string> op;=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=
=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=
//=20
> disengaged
> =EF=BF=BD opt1.reset();
> =EF=BF=BD if (!opt1) ...
> =EF=BF=BD run(optional<string>{});=EF=BF=BD=EF=BF=BD=EF=BF=BD // this is =
the single shorter=20
> expression =EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=
=BD=20
> *
>
This is your answer. Also, if (opt =3D=3D nullopt) may be clearer than if=
=20
(!opt).
*=20
> * I don't see a use case for mixed comparison of optional with nullopt_t.=
=20
> Could you present a use case?
> *
>
if (opt =3D=3D nullopt) -- it looks like a good example. Of course, the=20
promotion from nullopt_t to optional<T>would do, but I am not sure about=20
the efficiency.
=20
> *=20
> * What is the added value to make the constructor from T implicit? If it=
=20
> is implicitly convertible, the example
>
> bool=EF=BF=BD MyPlan::exceedsCapacity() const
> {
> =EF=BF=BD return passengerCount > availableSeats;
> =EF=BF=BD // availableSeats is of type unsigned int
> }
>
> will compile and suffer from the same issues as if the mixed operation=20
> were defined
> =EF=BF=BD
> bool operator=3D=3D(const optional<T>& a, const T& b);
>
> *
>
Implicit conversion is needed to make the usage of optional function=20
arguments more convenient.
void fun(optional<int>);
fun(2);
fun(nullopt);
The problem with implied mixed relops can be handled by explicitly=20
"poisoning" them. THis is being discussed in a separate thread.
=20
> *=20
>
> The example used to justify that conversion from U could risky could be=
=20
> used to describe the same dangers for conversion from T.
>
> // library
> void fun(string const& s);
> void fun(optional<const char*> const& s);=EF=BF=BD=EF=BF=BD // new overlo=
ad
>
> fun("hello");=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=
=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=
=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=
=BF=BD=EF=BF=BD=20
> // ERROR: ambiguity=20
>
> Using make_optional seems to me a more robust interface, that could seems=
=20
> less friendly at a first glance, but that prevents unexpected behavior=20
> which would be more friendly at the end.
> *
>
We need some balance between safety and convenience. Our choice is somewhat=
=20
arbitrary. One could imagine optional with explicit convestion from T=20
though.
=20
> *=20
> * Why the result of moving from optional is not a disengaged optional? It=
=20
> seems to me that making it disengaed has minimal cost.
> *
>
Efficiency reasons. This is discussed in the proposal.
=20
> *=20
>
> * optional<optional<T>>
>
> The refactoring presented in the example is not motivating the current=20
> design.
>
> Anyway, if nullopt is not provided there is no confusion. Before the chan=
ge
>
> fun(optional<T>); // process() not called!
>
> and after
>
> fun(optional<optional<T>>{}); // external optional disengaged
> fun(optional<optional<T>>{optional<T>{}}); // external optional engaged=
=20
> with disengaged optional<T>
> =EF=BF=BD
> *
>
This is unambiguous, but may be considered scary.
=20
> *=20
> * It will be worth noting in the proposal that optional<bool> could be=20
> used to represent a tribool. I find the implicit conversion to bool=20
> somewhere confusing.
> *
>
Yes, in case of optional<bool> there exists a chance that you will confuse=
=20
asking for engagement with reading the stored value
=20
> *=20
> * I don't see the need for get_value_or in the standard as we don't have=
=20
> it for pointer or smart pointers. Should the standard include a xxx_or=20
> version for all the xxx functions that have a specific pre-condition?=20
> E.g. should we have a front_or in case the container is empty?
> *
>
We find this "strict uniformity" less important than practical=20
considerations. It is a common practice in other languages to support this=
=20
idiom. We do not want to add a feature that would appear to users as=20
deficient.
=20
> *=20
> * The choice for the ordering of disengaged optional and engaged ones bee=
n=20
> arbitrary merits a deeper explanation of the alternatives to be included =
on=20
> the proposal. What if the standard let this relation as implementation=20
> defined? With the current proposal the following implementation of=20
> find_bigest seems correct
> *
> * *=20
>
> optional<int> find_biggest( const vector<int>& vec )
> {
> optional<int> biggest; *// initialized to the SMALLEST*
> for (int val : vec) {
> if (biggest < val) { // ****** NOTE THE RELOP
> biggest =3D val;
> }
> }
> return biggest;
> }=20
>
> *
> I would prefer that the user could not rely on whether disengaged optiona=
l=20
> is less than or greater than any engaged optional. How would you implemen=
t=20
> the find_smallest? Wouldn't the disengaged optional be used as the bigges=
t=20
> value in this case?**=20
> *
>
I suggest you observe the other thread:=20
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/j86CProQmoo/di=
scussion
Mixed relops are being discussed in length=20
> * **
> * The explanation for a nested nullopt tag seems irrelevant as=EF=BF=BD*=
=20
>
> optional<int>::nullopt would be equivalent to optional<int>{}, isn't it?
>
>
In case of optional<int>, this is right, but it will not work for=20
non-moveable T's. =20
*Vicente ***
>
Thanks for the feedback.
Regards,
&rzej=20
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_1995_31179320.1359502416330
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu wtorek, 29 stycznia 2013 22:19:57 UTC+1 u=BFytkownik Vicente=
J. Botet Escriba napisa=B3:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 22/01/13 22:18, Andrzej Krzemie=EF=BF=BDski
a =EF=BF=BDcrit=EF=BF=BD:<br>
</div>
<blockquote type=3D"cite">Hi Everyone,<br>
We are ready with the 3rd revision of std::optional proposal. The
main changes:<br>
<ul>
<li><code>optional<T></code> is hashable for hashable <code>T=
</code>’s.</li>
<li>Removed optional references — they will be proposed
separately.</li>
<li><code>get_value_or</code> is now <code>optional</code>-specific
member function.</li>
<li><code>optional<T></code> is a literal type.</li>
<li>Removed reference implementation. We now only provide the
implementation of the parts that we consider non-trivial.</li>
</ul>
We would appreciate your feedback and suggestions.<br>
<br>
</blockquote>
<i>Hello,<br>
<br>
I have not read completely the proposal but I fill like the
proposal is over designed, that is there is more than I would
expect. I don't find answers to the following questions. Sorry if
these has already been discussed.<br>
<br>
<br>
* What is the added value to have a nullopt?<br>
<br>
=EF=BF=BD optional<string> op{nullopt};=EF=BF=BD=EF=BF=BD=EF=BF=
=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD<wbr>=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=
=BF=BD=EF=BF=BD=EF=BF=BD // disengaged<br>
=EF=BF=BD opt1 =3D nullopt;<br>
=EF=BF=BD if (opt1 =3D=3D nullopt) ...<br>
=EF=BF=BD run(nullopt);=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD<=
wbr>=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD <br>
<br>
versus<br>
<br>
=EF=BF=BD optional<string> op;=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=
=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD<wbr>=EF=BF=BD=EF=BF=BD=EF=
=BF=BD=EF=BF=BD // disengaged<br>
=EF=BF=BD opt1.reset();<br>
=EF=BF=BD if (!opt1) ...<br>
=EF=BF=BD run(optional<string>{});=EF=BF=BD=EF=BF=BD<wbr>=EF=BF=
=BD // this is the single shorter
expression =EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=
=BF=BD <br></i></div></blockquote><div><br>This is your answer. Also, if (o=
pt =3D=3D nullopt) may be clearer than if (!opt).<br><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">=
<i>
<br>
* I don't see a use case for mixed comparison of optional with
nullopt_t. Could you present a use case?<br></i></div></blockquote><d=
iv><br>if (opt =3D=3D nullopt) -- it looks like a good example. Of course, =
the promotion from nullopt_t to optional<T>would do, but I am not sur=
e about the efficiency.<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 bgcolor=3D"#FFFFFF" text=3D"#000000"><i>
<br>
* What is the added value to make the constructor from T implicit?
If it is implicitly convertible, the example<br>
<br>
bool=EF=BF=BD MyPlan::exceedsCapacity() const<br>
{<br>
=EF=BF=BD return passengerCount > availableSeats;<br>
=EF=BF=BD // availableSeats is of type unsigned int<br>
}<br>
<br>
will compile and suffer from the same issues as if the mixed
operation were defined<br>
=EF=BF=BD<br>
bool operator=3D=3D(const optional<T>& a, const T& b);<=
br>
<br></i></div></blockquote><div><br>Implicit conversion is needed to =
make the usage of optional function arguments more convenient.<br><div clas=
s=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-col=
or: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: =
break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> fun</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">optional</span><span style=3D"color: #080;=
" class=3D"styled-by-prettify"><int></span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>fun</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">(</span><span style=3D"color: #066;" class=3D"styled-b=
y-prettify">2</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>f=
un</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">nullopt</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></di=
v><br>The problem with implied mixed relops can be handled by explicitly "p=
oisoning" them. THis is being discussed in a separate thread.<br> <br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF"=
text=3D"#000000"><i>
<br>
<br>
The example used to justify that conversion from U could risky
could be used to describe the same dangers for conversion from T.<br>
<br>
// library<br>
void fun(string const& s);<br>
void fun(optional<const char*> const& s);=EF=BF=BD=EF=BF=BD=
// new
overload<br>
<br>
fun("hello");=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD<wbr>=EF=BF=
=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=
=EF=BF=BD<wbr>=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=
=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD // ERROR: ambiguity <br>
<br>
Using make_optional seems to me a more robust interface, that
could seems less friendly at a first glance, but that prevents
unexpected behavior which would be more friendly at the end.<br></i><=
/div></blockquote><div><br>We need some balance between safety and convenie=
nce. Our choice is somewhat arbitrary. One could imagine optional with expl=
icit convestion from T though.<br> <br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><i>
<br>
* Why the result of moving from optional is not a disengaged
optional? It seems to me that making it disengaed has minimal
cost.<br></i></div></blockquote><div><br>Efficiency reasons. This is =
discussed in the proposal.<br> <br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><i>
<br>
<br>
* optional<optional<T>><br>
<br>
The refactoring presented in the example is not motivating the
current design.<br>
<br>
Anyway, if nullopt is not provided there is no confusion. Before
the change<br>
<br>
fun(optional<T>); // process() not called!<br>
<br>
and after<br>
<br>
fun(optional<optional<T>>{}); // external optional
disengaged<br>
fun(optional<optional<T>>{<wbr>optional<T>{}}); //
external optional engaged with disengaged optional<T><br>
=EF=BF=BD<br></i></div></blockquote><div><br>This is unambiguous, but=
may be considered scary.<br> <br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><i>
<br>
* It will be worth noting in the proposal that
optional<bool> could be used to represent a tribool. I find
the implicit conversion to bool somewhere confusing.<br></i></div></b=
lockquote><div><br>Yes, in case of optional<bool> there exists a chan=
ce that you will confuse asking for engagement with reading the stored valu=
e<br> <br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgco=
lor=3D"#FFFFFF" text=3D"#000000"><i>
<br>
* I don't see the need for get_value_or in the standard as we
don't have it for pointer or smart pointers. Should the standard
include a xxx_or version for all the xxx functions that have a
specific pre-condition? <br>
E.g. should we have a front_or in case the container is empty?<br></i=
></div></blockquote><div><br>We find this "strict uniformity" less importan=
t than practical considerations. It is a common practice in other languages=
to support this idiom. We do not want to add a feature that would appear t=
o users as deficient.<br> <br></div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><i>
<br>
* The choice for the ordering of disengaged optional and engaged
ones been arbitrary merits a deeper explanation of the
alternatives to be included on the proposal. What if the standard
let this relation as implementation defined? With the current
proposal the following implementation of find_bigest seems correct<br=
>
</i><br>
<i>
=20
</i>
<pre>optional<int> find_biggest( const vector<int>& vec=
)
{
optional<int> biggest; <i>// initialized to the SMALLEST</i>
for (int val : vec) {
if (biggest < val) { // ****** NOTE THE RELOP
biggest =3D val;
}
}
return biggest;
} </pre>
<i><br>
I would prefer that the user could not rely on whether disengaged
optional is less than or greater than any engaged optional. How
would you implement the find_smallest? Wouldn't the disengaged
optional be used as the biggest value in this case?</i><i> <br></i></=
div></blockquote><div><br>I suggest you observe the other thread: https://g=
roups.google.com/a/isocpp.org/d/topic/std-proposals/j86CProQmoo/discussion<=
br>Mixed relops are being discussed in length <br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><i>
</i><i><br>
* The explanation for a nested nullopt tag seems irrelevant as=EF=BF=
=BD</i>
<pre>optional<int>::nullopt would be equivalent to optional<in=
t>{}, isn't it?</pre></div></blockquote><div><br>In case of optional<=
int>, this is right, but it will not work for non-moveable T's. <b=
r><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#F=
FFFFF" text=3D"#000000"><pre><pre></pre></pre>
<i>Vicente </i><i></i><br></div></blockquote><div><br>Thanks for the fe=
edback.<br><br>Regards,<br>&rzej <br></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1995_31179320.1359502416330--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 30 Jan 2013 07:59:05 +0100
Raw View
This is a multi-part message in MIME format.
--------------060504000901010505090204
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 30/01/13 00:33, Andrzej Krzemie=F1ski a =E9crit :
>
>
> W dniu wtorek, 29 stycznia 2013 22:19:57 UTC+1 u=BFytkownik Vicente J.=20
> Botet Escriba napisa=B3:
>
> Le 22/01/13 22:18, Andrzej Krzemie=EF=BF=BDski a =EF=BF=BDcrit=EF=BF=
=BD:
>> Hi Everyone,
>> We are ready with the 3rd revision of std::optional proposal. The
>> main changes:
>>
>> * |optional<T>| is hashable for hashable |T|'s.
>> * Removed optional references --- they will be proposed separately=
..
>> * |get_value_or| is now |optional|-specific member function.
>> * |optional<T>| is a literal type.
>> * Removed reference implementation. We now only provide the
>> implementation of the parts that we consider non-trivial.
>>
>> We would appreciate your feedback and suggestions.
>>
> /Hello,
>
> I have not read completely the proposal but I fill like the
> proposal is over designed, that is there is more than I would
> expect. I don't find answers to the following questions. Sorry if
> these has already been discussed.
>
>
> * What is the added value to have a nullopt?
>
> =EF=BF=BD optional<string>
> op{nullopt};=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=
=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD // disengaged
> =EF=BF=BD opt1 =3D nullopt;
> =EF=BF=BD if (opt1 =3D=3D nullopt) ...
> =EF=BF=BD run(nullopt);=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=
=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD
>
> versus
>
> =EF=BF=BD optional<string> op;=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=
=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=
=BD //
> disengaged
> =EF=BF=BD opt1.reset();
> =EF=BF=BD if (!opt1) ...
> =EF=BF=BD run(optional<string>{});=EF=BF=BD=EF=BF=BD=EF=BF=BD // this=
is the single
> shorter expression =EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=
=BF=BD=EF=BF=BD
> /
>
>
> This is your answer. Also, if (opt =3D=3D nullopt) may be clearer than if=
=20
> (!opt).
>
> /
> * I don't see a use case for mixed comparison of optional with
> nullopt_t. Could you present a use case?
> /
>
>
> if (opt =3D=3D nullopt) -- it looks like a good example. Of course, the=
=20
> promotion from nullopt_t to optional<T>would do, but I am not sure=20
> about the efficiency.
I was thinking on <,<=3D,>,>=3D comparisons.
/Best,
Vicente
P.S. Sorry for the format //=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=
=EF=BF=BD=EF=BF=BD/
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
--------------060504000901010505090204
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DISO-8859-2"
http-equiv=3D"Content-Type">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 30/01/13 00:33, Andrzej Krzemie=F1ski
a =E9crit=A0:<br>
</div>
<blockquote
cite=3D"mid:10934f4a-a0b9-491e-81a9-2287cb4df489@isocpp.org"
type=3D"cite"><br>
<br>
W dniu wtorek, 29 stycznia 2013 22:19:57 UTC+1 u=BFytkownik Vicente
J. Botet Escriba napisa=B3:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 22/01/13 22:18, Andrzej Krzemie=EF=BF=BDski a =EF=BF=BDcr=
it=EF=BF=BD:<br>
</div>
<blockquote type=3D"cite">Hi Everyone,<br>
We are ready with the 3rd revision of std::optional
proposal. The main changes:<br>
<ul>
<li><code>optional<T></code> is hashable for
hashable <code>T</code>’s.</li>
<li>Removed optional references — they will be proposed
separately.</li>
<li><code>get_value_or</code> is now <code>optional</code>-sp=
ecific
member function.</li>
<li><code>optional<T></code> is a literal type.</li>
<li>Removed reference implementation. We now only provide
the implementation of the parts that we consider
non-trivial.</li>
</ul>
We would appreciate your feedback and suggestions.<br>
<br>
</blockquote>
<i>Hello,<br>
<br>
I have not read completely the proposal but I fill like the
proposal is over designed, that is there is more than I
would expect. I don't find answers to the following
questions. Sorry if these has already been discussed.<br>
<br>
<br>
* What is the added value to have a nullopt?<br>
<br>
=EF=BF=BD optional<string> op{nullopt};=EF=BF=BD=EF=BF=BD=
=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD<wbr>=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=
=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD
// disengaged<br>
=EF=BF=BD opt1 =3D nullopt;<br>
=EF=BF=BD if (opt1 =3D=3D nullopt) ...<br>
=EF=BF=BD run(nullopt);=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=
=BF=BD<wbr>=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD <br>
<br>
versus<br>
<br>
=EF=BF=BD optional<string> op;=EF=BF=BD=EF=BF=BD=EF=BF=BD=
=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD<wbr>=EF=BF=BD=EF=BF=
=BD=EF=BF=BD=EF=BF=BD
// disengaged<br>
=EF=BF=BD opt1.reset();<br>
=EF=BF=BD if (!opt1) ...<br>
=EF=BF=BD run(optional<string>{});=EF=BF=BD=EF=BF=BD<wbr>=
=EF=BF=BD // this is
the single shorter expression =EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=
=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD <br>
</i></div>
</blockquote>
<div><br>
This is your answer. Also, if (opt =3D=3D nullopt) may be clearer
than if (!opt).<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 bgcolor=3D"#FFFFFF" text=3D"#000000"><i> <br>
* I don't see a use case for mixed comparison of optional
with nullopt_t. Could you present a use case?<br>
</i></div>
</blockquote>
<div><br>
if (opt =3D=3D nullopt) -- it looks like a good example. Of course,
the promotion from nullopt_t to optional<T>would do, but I
am not sure about the efficiency.<br>
</div>
</blockquote>
I was thinking on <,<=3D,>,>=3D comparisons.<br>
<br>
<i>Best,<br>
Vicente<br>
<br>
P.S. Sorry for the format </i><i>=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=
=EF=BF=BD=EF=BF=BD=EF=BF=BD</i>
</body>
</html>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--------------060504000901010505090204--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Wed, 30 Jan 2013 00:25:00 -0800 (PST)
Raw View
------=_Part_1802_6242030.1359534300996
Content-Type: text/plain; charset=ISO-8859-1
>
> *
>> * I don't see a use case for mixed comparison of optional with nullopt_t.
>> Could you present a use case?
>> *
>>
>
> if (opt == nullopt) -- it looks like a good example. Of course, the
> promotion from nullopt_t to optional<T>would do, but I am not sure about
> the efficiency.
>
> I was thinking on <,<=,>,>= comparisons.
>
Indeed, I do not see a use case for them either. I believe, at some point
it was suggested that they should be added for completeness' sake. I would
be fine with removing them if everyone here is ok with it.
Also, let me try to answer again some of the other questions you asked. I
was replying in the middle of the night and now that I have slept with it,
I believe I can offer a better answer.
*I fill like the proposal is over designed, that is there is more than I
> would expect. *
>
Indeed, the idea of the proposal is to satisfy the primary goal: a too l
that can be asked two questions "do you have the value?" and if so, "what
is it?". Apart from that, we tried to determine what other secondary and
similar goals it can help achieve, such as deferred initialization, the
"one additional value of T" semantics. We could have proposed a smaller one
with only the primary goal. Again, this is a matter of arbitrary choice. We
believed it is better to have a tool that is generally useful. Plus, we are
trying to standardize the existing practice.
* *
> ** What is the added value to have a nullopt?*
>
Again, optional<T> would work without it. Although some usages would
require more typing. nullopt enables the "one additional value of T"
semantics. And it is an existing practice in boost::optional.
** The choice for the ordering of disengaged optional and engaged ones been
> arbitrary merits a deeper explanation of the alternatives to be included on
> the proposal. What if the standard let this relation as implementation
> defined? With the current proposal the following implementation of
> find_bigest seems correct*
> * *
> * *
>
> optional<int> find_biggest( const vector<int>& vec )
> {
> optional<int> biggest; *// initialized to the SMALLEST*
> for (int val : vec) {
> if (biggest < val) { // ****** NOTE THE RELOP
> biggest = val;
> }
> }
> return biggest;
> }
>
> **
>
*I would prefer that the user could not rely on whether disengaged optional
> is less than or greater than any engaged optional. How would you implement
> the find_smallest? Wouldn't the disengaged optional be used as the biggest
> value in this case?** *
>
This is an interesting suggestion. As I understand it, the goal is not to
give the "experts" the possibility to write too clever things that would
confuse anyone else. Or to prevent situations where the reader does not
know if this is intentional or a mistake. Since you indicated the mixed
comparison between T and optional<T> in the example. Perhaps the problem
you see boils down to the same one we are currently discussing: should
mixed relops be allowed or banned?
On the other hand, making the order implementation defined may not
discourage users from relying on it. They may start working on assumptions:
"lets test how this works and rely on this", IO they will assume that if
nullopt is least for them it will also be least for others. This is similar
to people writing fun(i, ++i). I wonder what others think.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_1802_6242030.1359534300996
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" t=
ext=3D"#000000"><blockquote type=3D"cite"><div>
<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><i> <br>
* I don't see a use case for mixed comparison of optional
with nullopt_t. Could you present a use case?<br>
</i></div>
</blockquote>
<div><br>
if (opt =3D=3D nullopt) -- it looks like a good example. Of course,
the promotion from nullopt_t to optional<T>would do, but I
am not sure about the efficiency.<br>
</div>
</blockquote>
I was thinking on <,<=3D,>,>=3D comparisons.<br></div></blo=
ckquote><div><br>Indeed, I do not see a use case for them either. I believe=
, at some point it was suggested that they should be added for completeness=
' sake. I would be fine with removing them if everyone here is ok with it. =
<br><br>Also, let me try to answer again some of the other questions you as=
ked. I was replying in the middle of the night and now that I have slept wi=
th it, I believe I can offer a better answer.<br><br><br><blockquote style=
=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); p=
adding-left: 1ex;" class=3D"gmail_quote"><em>I fill like the
proposal is over designed, that is there is more than I would
expect. </em><br></blockquote><div><br>Indeed, the idea of the propos=
al is to satisfy the primary goal: a too l that can be asked two questions =
"do you have the value?" and if so, "what is it?". Apart from that, we trie=
d to determine what other secondary and similar goals it can help achieve, =
such as deferred initialization, the "one additional value of T" semantics.=
We could have proposed a smaller one with only the primary goal. Again, th=
is is a matter of arbitrary choice. We believed it is better to have a tool=
that is generally useful. Plus, we are trying to standardize the existing =
practice.<br></div><em>
</em><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left:=
1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">&n=
bsp;<i>* What is the added value to have a nullopt?</i><br></blockquote><di=
v><br>Again, optional<T> would work without it. Although some usages =
would require more typing. nullopt enables the "one additional value of T" =
semantics. And it is an existing practice in boost::optional.<br></div><br>=
<blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(=
204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote"><em>* The choice =
for the ordering of disengaged optional and engaged
ones been arbitrary merits a deeper explanation of the
alternatives to be included on the proposal. What if the standard
let this relation as implementation defined? With the current
proposal the following implementation of find_bigest seems correct</e=
m><br><em>
</em><br>
<em>
=20
</em>
<pre>optional<int> find_biggest( const vector<int>& vec=
)
{
optional<int> biggest; <em>// initialized to the SMALLEST</em>
for (int val : vec) {
if (biggest < val) { // ****** NOTE THE RELOP
biggest =3D val;
}
}
return biggest;
} </pre></blockquote><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border=
-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quo=
te">
<em></em><br></blockquote><blockquote style=3D"margin: 0px 0px 0px 0.8e=
x; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"=
gmail_quote"><em>I would prefer that the user could not rely on whether dis=
engaged
optional is less than or greater than any engaged optional. How
would you implement the find_smallest? Wouldn't the disengaged
optional be used as the biggest value in this case?</em><em> </em><br=
></blockquote><div><br>This is an interesting suggestion. As I understand i=
t, the goal is not to give the "experts" the possibility to write too cleve=
r things that would confuse anyone else. Or to prevent situations where the=
reader does not know if this is intentional or a mistake. Since you indica=
ted the mixed comparison between T and optional<T> in the example. Pe=
rhaps the problem you see boils down to the same one we are currently discu=
ssing: should mixed relops be allowed or banned? <br><br>On the other hand,=
making the order implementation defined may not discourage users from rely=
ing on it. They may start working on assumptions: "lets test how this works=
and rely on this", IO they will assume that if nullopt is least for them i=
t will also be least for others. This is similar to people writing fun(i, +=
+i). I wonder what others think.<br></div></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1802_6242030.1359534300996--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 30 Jan 2013 13:25:36 +0100
Raw View
This is a multi-part message in MIME format.
--------------000904090607000601090301
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 30/01/13 00:33, Andrzej Krzemie=F1ski a =E9crit :
>
>
> W dniu wtorek, 29 stycznia 2013 22:19:57 UTC+1 u=BFytkownik Vicente J.=20
> Botet Escriba napisa=B3:
>
> Le 22/01/13 22:18, Andrzej Krzemie=EF=BF=BDski a =EF=BF=BDcrit=EF=BF=
=BD:
>> Hi Everyone,
>> We are ready with the 3rd revision of std::optional proposal. The
>> main changes:
>>
>> * |optional<T>| is hashable for hashable |T|'s.
>> * Removed optional references --- they will be proposed separately=
..
>> * |get_value_or| is now |optional|-specific member function.
>> * |optional<T>| is a literal type.
>> * Removed reference implementation. We now only provide the
>> implementation of the parts that we consider non-trivial.
>>
>> We would appreciate your feedback and suggestions.
>>
> /Hello,
>
> I have not read completely the proposal but I fill like the
> proposal is over designed, that is there is more than I would
> expect. I don't find answers to the following questions. Sorry if
> these has already been discussed.
>
>
> * What is the added value to have a nullopt?
>
> optional<string> op{nullopt}; // disengaged
> opt1 =3D nullopt;
> if (opt1 =3D=3D nullopt) ...
> run(nullopt);
>
> versus
>
> optional<string> op; // disengaged
> opt1.reset();
> if (!opt1) ...
> run(optional<string>{}); // this is the single shorter expression
> /
>
>
> This is your answer. Also, if (opt =3D=3D nullopt) may be clearer than if=
=20
> (!opt).
Well in this case the library shouldn't provide conversion to bool.
If explicit conversion to bool is not provided I will prefer to have a=20
engaged/valid member function.
>
> //
>
> /
> * What is the added value to make the constructor from T implicit?
> If it is implicitly convertible, the example
>
> bool MyPlan::exceedsCapacity() const
> {
> return passengerCount > availableSeats;
> // availableSeats is of type unsigned int
> }
>
> will compile and suffer from the same issues as if the mixed
> operation were defined
>
> bool operator=3D=3D(const optional<T>& a, const T& b);
>
> /
>
>
> Implicit conversion is needed to make the usage of optional function=20
> arguments more convenient.
> |
> voidfun(optional<int>);
> fun(2);
> fun(nullopt);
> |
>
When possible the optional arguments could have a default making nullopt=20
shortcut not needed.
|
voidfun(optional<int>op=3D|optional<int>{}|);
fun(make_|optional(2)|);
fun();
|
>
> /
>
> The example used to justify that conversion from U could risky
> could be used to describe the same dangers for conversion from T.
>
> // library
> void fun(string const& s);
> void fun(optional<const char*> const& s); // new overload
>
> fun("hello"); // ERROR: ambiguity
>
> Using make_optional seems to me a more robust interface, that
> could seems less friendly at a first glance, but that prevents
> unexpected behavior which would be more friendly at the end.
> /
>
>
> We need some balance between safety and convenience. Our choice is=20
> somewhat arbitrary. One could imagine optional with explicit=20
> convestion from T though.
I would adhere to the explicit alternative.
>
> /
> * Why the result of moving from optional is not a disengaged
> optional? It seems to me that making it disengaed has minimal cost.
> /
>
>
> Efficiency reasons. This is discussed in the proposal.
Ok, I understand the corner cases. BTW, is optional<T> movable if T is=20
not Movable?
>
> /
>
> * optional<optional<T>>
>
> The refactoring presented in the example is not motivating the
> current design.
>
> Anyway, if nullopt is not provided there is no confusion. Before
> the change
>
> fun(optional<T>); // process() not called!
>
> and after
>
> fun(optional<optional<T>{}); // external optional disengaged
> fun(optional<optional<T>>{optional<T>{}}); // external optional
> engaged with disengaged optional<T>
>
> /
>
>
> This is unambiguous, but may be considered scary.
Would you consider less scary the use of make_optional as in
/fun(make_optional<T>());/
/fun(make_optional(make_optional<T>()));/
>
>
> /
> * I don't see the need for get_value_or in the standard as we
> don't have it for pointer or smart pointers. Should the standard
> include a xxx_or version for all the xxx functions that have a
> specific pre-condition?
> E.g. should we have a front_or in case the container is empty?
> /
>
>
> We find this "strict uniformity" less important than practical=20
> considerations. It is a common practice in other languages to support=20
> this idiom. We do not want to add a feature that would appear to users=20
> as deficient.
What would be the deficiency?
>
>
> ///
> * The explanation for a nested nullopt tag seems irrelevant as/
>
> optional<int>::nullopt would be equivalent to optional<int>{}, isn't =
it?
>
>
> In case of optional<int>, this is right, but it will not work for=20
> non-moveable T's.
>
>
I don't understand. Please could you elaborate?
Best,
Vicente
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
--------------000904090607000601090301
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DISO-8859-2"
http-equiv=3D"Content-Type">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 30/01/13 00:33, Andrzej Krzemie=F1ski
a =E9crit=A0:<br>
</div>
<blockquote
cite=3D"mid:10934f4a-a0b9-491e-81a9-2287cb4df489@isocpp.org"
type=3D"cite"><br>
<br>
W dniu wtorek, 29 stycznia 2013 22:19:57 UTC+1 u=BFytkownik Vicente
J. Botet Escriba napisa=B3:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 22/01/13 22:18, Andrzej Krzemie=EF=BF=BDski a =EF=BF=BDcr=
it=EF=BF=BD:<br>
</div>
<blockquote type=3D"cite">Hi Everyone,<br>
We are ready with the 3rd revision of std::optional
proposal. The main changes:<br>
<ul>
<li><code>optional<T></code> is hashable for
hashable <code>T</code>’s.</li>
<li>Removed optional references — they will be proposed
separately.</li>
<li><code>get_value_or</code> is now <code>optional</code>-sp=
ecific
member function.</li>
<li><code>optional<T></code> is a literal type.</li>
<li>Removed reference implementation. We now only provide
the implementation of the parts that we consider
non-trivial.</li>
</ul>
We would appreciate your feedback and suggestions.<br>
<br>
</blockquote>
<i>Hello,<br>
<br>
I have not read completely the proposal but I fill like the
proposal is over designed, that is there is more than I
would expect. I don't find answers to the following
questions. Sorry if these has already been discussed.<br>
<br>
<br>
* What is the added value to have a nullopt?<br>
<br>
=A0 optional<string> op{nullopt}; // disengaged<br>
=A0 opt1 =3D nullopt;<br>
=A0 if (opt1 =3D=3D nullopt) ...<br>
=A0 run(nullopt);<br>
<br>
versus<br>
<br>
=A0 optional<string> op; // disengaged<br>
=A0 opt1.reset();<br>
=A0 if (!opt1) ...<br>
=A0 run(optional<string>{}); // this is the single
shorter expression <br>
</i></div>
</blockquote>
<div><br>
This is your answer. Also, if (opt =3D=3D nullopt) may be clearer
than if (!opt).<br>
</div>
</blockquote>
Well in this case the library shouldn't provide conversion to bool.<br>
<br>
If explicit conversion to bool is not provided I will prefer to have
a engaged/valid member function.<br>
<blockquote
cite=3D"mid:10934f4a-a0b9-491e-81a9-2287cb4df489@isocpp.org"
type=3D"cite">
<div><br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div><i> </i><br>
=A0<br>
</div>
</blockquote>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><i> <br>
* What is the added value to make the constructor from T
implicit? If it is implicitly convertible, the example<br>
<br>
bool MyPlan::exceedsCapacity() const<br>
{<br>
=A0 return passengerCount > availableSeats;<br>
=A0 // availableSeats is of type unsigned int<br>
}<br>
<br>
will compile and suffer from the same issues as if the mixed
operation were defined<br>
<br>
bool operator=3D=3D(const optional<T>& a, const T&=
;
b);<br>
<br>
</i></div>
</blockquote>
<div><br>
Implicit conversion is needed to make the usage of optional
function arguments more convenient.<br>
<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"prettyprint">
<div class=3D"subprettyprint"><span style=3D"color: #008;"
class=3D"styled-by-prettify">void</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> fun</s=
pan><span
style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span
style=3D"color: #000;" class=3D"styled-by-prettify">optiona=
l</span><span
style=3D"color: #080;" class=3D"styled-by-prettify"><int=
></span><span
style=3D"color: #660;" class=3D"styled-by-prettify">);</spa=
n><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
fun</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">(</span><span style=3D"color:
#066;" class=3D"styled-by-prettify">2</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">);</spa=
n><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
fun</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">(</span><span style=3D"color:
#000;" class=3D"styled-by-prettify">nullopt</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">);</spa=
n><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
</span></div>
</code></div>
<br>
</div>
</blockquote>
When possible the optional arguments could have a default making
nullopt shortcut not needed.<br>
<br>
<br>
<code class=3D"prettyprint">
<div class=3D"subprettyprint"><span style=3D"color: #008;"
class=3D"styled-by-prettify">void</span><span style=3D"color:
#000;" class=3D"styled-by-prettify"> fun</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span
style=3D"color: #000;" class=3D"styled-by-prettify">optional</spa=
n><span
style=3D"color: #080;" class=3D"styled-by-prettify"><int></=
span><span
style=3D"color: #660;" class=3D"styled-by-prettify"> op=3D</span>=
<span
style=3D"color: #660;" class=3D"styled-by-prettify"><code
class=3D"prettyprint"><span style=3D"color: #660;"
class=3D"styled-by-prettify"></span><span style=3D"color:
#000;" class=3D"styled-by-prettify">optional</span><span
style=3D"color: #080;" class=3D"styled-by-prettify"><int&g=
t;</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">{}</span>=
</code>);</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
fun</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">(make_</span><code
class=3D"prettyprint"><span style=3D"color: #660;"
class=3D"styled-by-prettify"></span><span style=3D"color: #000;=
"
class=3D"styled-by-prettify">optional</span><span
style=3D"color: #080;" class=3D"styled-by-prettify">(2)</span><=
/code><span
style=3D"color: #066;" class=3D"styled-by-prettify"></span><span
style=3D"color: #660;" class=3D"styled-by-prettify">);</span><spa=
n
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
fun</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">(</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">);</span></div>
</code><br>
<blockquote
cite=3D"mid:10934f4a-a0b9-491e-81a9-2287cb4df489@isocpp.org"
type=3D"cite">
<div>=A0<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><i> <br>
<br>
The example used to justify that conversion from U could
risky could be used to describe the same dangers for
conversion from T.<br>
<br>
// library<br>
void fun(string const& s);<br>
void fun(optional<const char*> const& s); // new
overload<br>
<br>
fun("hello"); =A0 // ERROR: ambiguity <br>
<br>
Using make_optional seems to me a more robust interface,
that could seems less friendly at a first glance, but that
prevents unexpected behavior which would be more friendly at
the end.<br>
</i></div>
</blockquote>
<div><br>
We need some balance between safety and convenience. Our choice
is somewhat arbitrary. One could imagine optional with explicit
convestion from T though.<br>
</div>
</blockquote>
I would adhere to the explicit alternative.<br>
<blockquote
cite=3D"mid:10934f4a-a0b9-491e-81a9-2287cb4df489@isocpp.org"
type=3D"cite">
<div>=A0<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><i> <br>
* Why the result of moving from optional is not a disengaged
optional? It seems to me that making it disengaed has
minimal cost.<br>
</i></div>
</blockquote>
<div><br>
Efficiency reasons. This is discussed in the proposal.<br>
</div>
</blockquote>
Ok, I understand the corner cases. BTW, is optional<T> movable
if T is not Movable?<br>
<blockquote
cite=3D"mid:10934f4a-a0b9-491e-81a9-2287cb4df489@isocpp.org"
type=3D"cite">
<div>=A0<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><i> <br>
<br>
* optional<optional<T>><br>
<br>
The refactoring presented in the example is not motivating
the current design.<br>
<br>
Anyway, if nullopt is not provided there is no confusion.
Before the change<br>
<br>
fun(optional<T>); // process() not called!<br>
<br>
and after<br>
<br>
fun(optional<optional<T>{}); // external optional
disengaged<br>
fun(optional<optional<T>>{<wbr>optional<T>{}}=
);
// external optional engaged with disengaged
optional<T><br>
<br>
</i></div>
</blockquote>
<div><br>
This is unambiguous, but may be considered scary.<br>
</div>
</blockquote>
<br>
Would you consider less scary the use of make_optional as in<br>
<br>
<i>fun(make_<wbr>optional<T>());</i><br>
<i>fun(make_optional(make_<wbr>optional<T>()));</i><br>
<br>
<blockquote
cite=3D"mid:10934f4a-a0b9-491e-81a9-2287cb4df489@isocpp.org"
type=3D"cite"><br>
<div>=A0<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><i> <br>
* I don't see the need for get_value_or in the standard as
we don't have it for pointer or smart pointers. Should the
standard include a xxx_or version for all the xxx functions
that have a specific pre-condition? <br>
E.g. should we have a front_or in case the container is
empty?<br>
</i></div>
</blockquote>
<div><br>
We find this "strict uniformity" less important than practical
considerations. It is a common practice in other languages to
support this idiom. We do not want to add a feature that would
appear to users as deficient.<br>
</div>
</blockquote>
What would be the deficiency?<br>
<blockquote
cite=3D"mid:10934f4a-a0b9-491e-81a9-2287cb4df489@isocpp.org"
type=3D"cite">
<div>=A0<br>
</div>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><i> </i><i><br>
* The explanation for a nested nullopt tag seems irrelevant
as</i>
<pre>optional<int>::nullopt would be equivalent to optional=
<int>{}, isn't it?</pre>
</div>
</blockquote>
<div><br>
In case of optional<int>, this is right, but it will not
work for non-moveable T's.=A0 <br>
<br>
</div>
<br>
</blockquote>
I don't understand. Please could you elaborate?<br>
<br>
Best,<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--------------000904090607000601090301--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Wed, 30 Jan 2013 05:10:30 -0800 (PST)
Raw View
------=_Part_318_20147589.1359551430749
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
> * * What is the added value to have a nullopt?
>
> =C4=8F=C5=BC=CB=9D optional<string> op{nullopt}; // disengaged
> =C4=8F=C5=BC=CB=9D opt1 =3D nullopt;
> =C4=8F=C5=BC=CB=9D if (opt1 =3D=3D nullopt) ...
> =C4=8F=C5=BC=CB=9D run(nullopt);
>
> versus
>
> =C4=8F=C5=BC=CB=9D optional<string> op; // disengaged
> =C4=8F=C5=BC=CB=9D opt1.reset();
> =C4=8F=C5=BC=CB=9D if (!opt1) ...
> =C4=8F=C5=BC=CB=9D run(optional<string>{}); // this is the single shorter=
expression=20
> *
>
>
> This is your answer. Also, if (opt =3D=3D nullopt) may be clearer than if=
=20
> (!opt).
> =20
> Well in this case the library shouldn't provide conversion to bool.
>
> If explicit conversion to bool is not provided I will prefer to have a=20
> engaged/valid member function.
>
If I understand your reasoning correctly, you are opposed to being able to=
=20
express the same thing in two ways. Is that right? The way I see it, two=20
different tools for checking the engaged state offer convenience in=20
different use cases.
optional<int> getOptVal();
void let_me_demonstrate(optional<string> os)
{
if (os =3D=3D nullopt) ... // clearer than if(!os)
if (auto val =3D gtOptVal()) ... // more convenient than any alternative
}
=20
> =20
> * *
> =C4=8F=C5=BC=CB=9D
> =20
> *=20
> * What is the added value to make the constructor from T implicit? If it=
=20
> is implicitly convertible, the example
>
> bool MyPlan::exceedsCapacity() const
> {
> =C4=8F=C5=BC=CB=9D return passengerCount > availableSeats;
> =C4=8F=C5=BC=CB=9D // availableSeats is of type unsigned int
> }
>
> will compile and suffer from the same issues as if the mixed operation=20
> were defined
>
> bool operator=3D=3D(const optional<T>& a, const T& b);
>
> *
>
>
> Implicit conversion is needed to make the usage of optional function=20
> arguments more convenient.
> void fun(optional<int>);
> fun(2);
> fun(nullopt);
> =20
> When possible the optional arguments could have a default making nullopt=
=20
> shortcut not needed.
>
>
> void fun(optional<int> op=3Doptional<int>{});
> fun(make_optional(2));
> fun();
>
what if the user of fun() wants to be explicit and not rely on default=20
function parameters? Also what if fun() is overloaded?:
fun(string const& s);
fun(optional<int> const&);
We were going through these discussions in the past:
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/uK1HfW4YTEU/di=
scussion
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cXneqUj-5oo/di=
scussion
The proposed solution is the best compromise we could come up with given=20
the versatile and contradictory expectations.
*
>
> The example used to justify that conversion from U could risky could be=
=20
> used to describe the same dangers for conversion from T.
>
> // library
> void fun(string const& s);
> void fun(optional<const char*> const& s); // new overload
>
> fun("hello"); =C4=8F=C5=BC=CB=9D // ERROR: ambiguity=20
>
> Using make_optional seems to me a more robust interface, that could seems=
=20
> less friendly at a first glance, but that prevents unexpected behavior=20
> which would be more friendly at the end.
> *
>
>
> We need some balance between safety and convenience. Our choice is=20
> somewhat arbitrary. One could imagine optional with explicit convestion=
=20
> from T though.
> =20
> I would adhere to the explicit alternative.
>
I understand this position. Nonetheless, given that the current proposal is=
=20
the effect of a difficult compromise, I would be reluctant to change it=20
now; unless the majority of people here agrees with explicit conversion and=
=20
its consequences.
=C4=8F=C5=BC=CB=9D
> =20
> *=20
> * Why the result of moving from optional is not a disengaged optional? It=
=20
> seems to me that making it disengaed has minimal cost.
> *
>
>
> Efficiency reasons. This is discussed in the proposal.
> =20
> Ok, I understand the corner cases. BTW, is optional<T> movable if T is no=
t=20
> Movable?
>
No. And this probably addresses a couple of your other concerns.
*
> * optional<optional<T>>
>
> The refactoring presented in the example is not motivating the current=20
> design.
>
> Anyway, if nullopt is not provided there is no confusion. Before the chan=
ge
>
> fun(optional<T>); // process() not called!
>
> and after
>
> fun(optional<optional<T>{}); // external optional disengaged
> fun(optional<optional<T>>{optional<T>{}}); // external optional engaged=
=20
> with disengaged optional<T>
>
> *
>
>
> This is unambiguous, but may be considered scary.
> =20
>
> Would you consider less scary the use of make_optional as in
>
> *fun(make_optional<T>());*
> *fun(make_optional(make_optional<T>()));*
You are proposing a new overload of make_optional, right? I am not sure if=
=20
it would not be confused with optional<T>{emplace}
=20
>
> * * I don't see the need for get_value_or in the standard as we don't=20
> have it for pointer or smart pointers. Should the standard include a xxx_=
or=20
> version for all the xxx functions that have a specific pre-condition?=20
> E.g. should we have a front_or in case the container is empty?
> *
>
>
> We find this "strict uniformity" less important than practical=20
> considerations. It is a common practice in other languages to support thi=
s=20
> idiom. We do not want to add a feature that would appear to users as=20
> deficient.
> =20
> What would be the deficiency?
>
The surprising lack of the functionality offered by other languages.=20
=20
> =C4=8F=C5=BC=CB=9D
> =20
> * **
> * The explanation for a nested nullopt tag seems irrelevant as*=20
>
> optional<int>::nullopt would be equivalent to optional<int>{}, isn't it?
>
> =20
> In case of optional<int>, this is right, but it will not work for=20
> non-moveable T's.=C4=8F=C5=BC=CB=9D=20
>
> I don't understand. Please could you elaborate?
>
suppose that Guard is a type that is non-copyable and non-moveable:
optional<Guard> g1 =3D nullopt; // fine (and very explicit)
optional<Guard> g2; // fine, although less explicit=20
(unintended behavior?)
optional<Guard> g3 =3D optional<Guard>{}; // error: optional<Guard> is not=
=20
moveable
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_318_20147589.1359551430749
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><blockquote><blockquote st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div bgcolor=3D"#FFFFFF"><i>
* What is the added value to have a nullopt?<br>
<br>
=C4=8F=C5=BC=CB=9D optional<string> op{nullopt}; // disen=
gaged<br>
=C4=8F=C5=BC=CB=9D opt1 =3D nullopt;<br>
=C4=8F=C5=BC=CB=9D if (opt1 =3D=3D nullopt) ...<br>
=C4=8F=C5=BC=CB=9D run(nullopt);<br>
<br>
versus<br>
<br>
=C4=8F=C5=BC=CB=9D optional<string> op; // disengaged<br>
=C4=8F=C5=BC=CB=9D opt1.reset();<br>
=C4=8F=C5=BC=CB=9D if (!opt1) ...<br>
=C4=8F=C5=BC=CB=9D run(optional<string>{}); // this is th=
e single
shorter expression <br>
</i></div>
</blockquote>
<div><br>
This is your answer. Also, if (opt =3D=3D nullopt) may be clearer
than if (!opt).<br>
</div>
</blockquote>
Well in this case the library shouldn't provide conversion to bool.<br>
<br>
If explicit conversion to bool is not provided I will prefer to have
a engaged/valid member function.<br></blockquote><div><br></div><div>If=
I understand your reasoning correctly, you are opposed to being able to ex=
press the same thing in two ways. Is that right? The way I see it, two diff=
erent tools for checking the engaged state offer convenience in different u=
se cases.</div><div><br></div><div style=3D"background-color: rgb(250, 250,=
250); border: 1px solid rgb(187, 187, 187); word-wrap: break-word;" class=
=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #000;" class=3D"styled-by-prettify">optional</span><s=
pan style=3D"color: #080;" class=3D"styled-by-prettify"><int></span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> getOptVal</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br><br><br></span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> let_me_demonstrate</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">optional</span><span style=
=3D"color: #080;" class=3D"styled-by-prettify"><string></span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> os</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">if</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">os </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> nullopt</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">...</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// clearer than if(!os)</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"><br><br> </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">if</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> val </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> g=
tOptVal</span><span style=3D"color: #660;" class=3D"styled-by-prettify">())=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">...</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #800;" class=3D"styled-by-prettify">// more convenient than any alterna=
tive</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span></di=
v></code></div><div><br></div><div> </div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;">
<blockquote>
<div><br>
</div>
<blockquote style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<div><i> </i><br>
=C4=8F=C5=BC=CB=9D<br>
</div>
</blockquote>
<blockquote style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF"><i> <br>
* What is the added value to make the constructor from T
implicit? If it is implicitly convertible, the example<br>
<br>
bool MyPlan::exceedsCapacity() const<br>
{<br>
=C4=8F=C5=BC=CB=9D return passengerCount > availableSeats;<b=
r>
=C4=8F=C5=BC=CB=9D // availableSeats is of type unsigned int<br=
>
}<br>
<br>
will compile and suffer from the same issues as if the mixed
operation were defined<br>
<br>
bool operator=3D=3D(const optional<T>& a, const T&=
;
b);<br>
<br>
</i></div>
</blockquote>
<div><br>
Implicit conversion is needed to make the usage of optional
function arguments more convenient.<br>
<div style=3D"background-color:rgb(250,250,250);border-color:rgb(18=
7,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><code>
<div><span style=3D"color:#008">void</span><span style=3D"color=
:#000"> fun</span><span style=3D"color:#660">(</span><span style=3D"color:#=
000">optional</span><span style=3D"color:#080"><int></span><span styl=
e=3D"color:#660">);</span><span style=3D"color:#000"><br>
fun</span><span style=3D"color:#660">(</span><span style=3D=
"color:#066">2</span><span style=3D"color:#660">);</span><span style=3D"col=
or:#000"><br>
fun</span><span style=3D"color:#660">(</span><span style=3D=
"color:#000">nullopt</span><span style=3D"color:#660">);</span><span style=
=3D"color:#000"><br>
</span></div>
</code></div>
<br>
</div>
</blockquote>
When possible the optional arguments could have a default making
nullopt shortcut not needed.<br>
<br>
<br>
<code>
<div><span style=3D"color:#008">void</span><span style=3D"color:#000"=
> fun</span><span style=3D"color:#660">(</span><span style=3D"color:#000">o=
ptional</span><span style=3D"color:#080"><int></span><span style=3D"c=
olor:#660"> op=3D</span><span style=3D"color:#660"><code><span style=3D"col=
or:#660"></span><span style=3D"color:#000">optional</span><span style=3D"co=
lor:#080"><int></span><span style=3D"color:#660">{}</span></code>);</=
span><span style=3D"color:#000"><br>
fun</span><span style=3D"color:#660">(make_</span><code><span sty=
le=3D"color:#660"></span><span style=3D"color:#000">optional</span><span st=
yle=3D"color:#080">(2)</span></code><span style=3D"color:#066"></span><span=
style=3D"color:#660">);</span><span style=3D"color:#000"><br>
fun</span><span style=3D"color:#660">(</span><span style=3D"color=
:#660">);</span></div></code></blockquote><div><br></div><div>what if the u=
ser of fun() wants to be explicit and not rely on default function paramete=
rs? Also what if fun() is overloaded?:</div><div style=3D"background-color:=
rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break=
-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"sub=
prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">fun<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">string</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #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"> s</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>fun</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">optional</span><span style=3D"color: #080;" 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">&);</sp=
an></div></code></div><div><br></div><div>We were going through these discu=
ssions in the past:</div><div>https://groups.google.com/a/isocpp.org/d/topi=
c/std-proposals/uK1HfW4YTEU/discussion<br></div><div>https://groups.google.=
com/a/isocpp.org/d/topic/std-proposals/cXneqUj-5oo/discussion<br></div><div=
><br></div><div>The proposed solution is the best compromise we could come =
up with given the versatile and contradictory expectations.</div><div><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><blockquote><blockquote s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div bgcolor=3D"#FFFFFF"><i><br>
<br>
The example used to justify that conversion from U could
risky could be used to describe the same dangers for
conversion from T.<br>
<br>
// library<br>
void fun(string const& s);<br>
void fun(optional<const char*> const& s); // new
overload<br>
<br>
fun("hello"); =C4=8F=C5=BC=CB=9D // ERROR: ambiguity <br>
<br>
Using make_optional seems to me a more robust interface,
that could seems less friendly at a first glance, but that
prevents unexpected behavior which would be more friendly at
the end.<br>
</i></div>
</blockquote>
<div><br>
We need some balance between safety and convenience. Our choice
is somewhat arbitrary. One could imagine optional with explicit
convestion from T though.<br>
</div>
</blockquote>
I would adhere to the explicit alternative.<br></blockquote><div><br></=
div><div>I understand this position. Nonetheless, given that the current pr=
oposal is the effect of a difficult compromise, I would be reluctant to cha=
nge it now; unless the majority of people here agrees with explicit convers=
ion and its consequences.</div><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;">
<blockquote>
<div>=C4=8F=C5=BC=CB=9D<br>
</div>
<blockquote style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF"><i> <br>
* Why the result of moving from optional is not a disengaged
optional? It seems to me that making it disengaed has
minimal cost.<br>
</i></div>
</blockquote>
<div><br>
Efficiency reasons. This is discussed in the proposal.<br>
</div>
</blockquote>
Ok, I understand the corner cases. BTW, is optional<T> movable
if T is not Movable?<br></blockquote><div><br></div><div>No. And this p=
robably addresses a couple of your other concerns.</div><div><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><blockquote><blockquote style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
bgcolor=3D"#FFFFFF"><i><br>
* optional<optional<T>><br>
<br>
The refactoring presented in the example is not motivating
the current design.<br>
<br>
Anyway, if nullopt is not provided there is no confusion.
Before the change<br>
<br>
fun(optional<T>); // process() not called!<br>
<br>
and after<br>
<br>
fun(optional<optional<T>{}); // external optional
disengaged<br>
fun(optional<optional<T>>{<wbr>optional<T>{}}=
);
// external optional engaged with disengaged
optional<T><br>
<br>
</i></div>
</blockquote>
<div><br>
This is unambiguous, but may be considered scary.<br>
</div>
</blockquote>
<br>
Would you consider less scary the use of make_optional as in<br>
<br>
<i>fun(make_optional<T>());</i><br>
<i>fun(make_optional(make_<wbr>optional<T>()));</i></blockquote><=
div><br></div><div>You are proposing a new overload of make_optional, right=
? I am not sure if it would not be confused with <font face=3D"courier new,=
monospace">optional<T>{emplace}</font></div><div> </div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><br><blockquote><blockquote style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v bgcolor=3D"#FFFFFF"><i>
* I don't see the need for get_value_or in the standard as
we don't have it for pointer or smart pointers. Should the
standard include a xxx_or version for all the xxx functions
that have a specific pre-condition? <br>
E.g. should we have a front_or in case the container is
empty?<br>
</i></div>
</blockquote>
<div><br>
We find this "strict uniformity" less important than practical
considerations. It is a common practice in other languages to
support this idiom. We do not want to add a feature that would
appear to users as deficient.<br>
</div>
</blockquote>
What would be the deficiency?<br></blockquote><div><br></div><div>The s=
urprising lack of the functionality offered by other languages. </div>=
<div><br></div><div><br></div><div> </div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;">
<blockquote>
<div>=C4=8F=C5=BC=CB=9D<br>
</div>
<br>
<blockquote style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF"><i> </i><i><br>
* The explanation for a nested nullopt tag seems irrelevant
as</i>
<pre>optional<int>::nullopt would be equivalent to optional=
<int>{}, isn't it?</pre>
</div>
</blockquote>
<div><br>
In case of optional<int>, this is right, but it will not
work for non-moveable T's.=C4=8F=C5=BC=CB=9D <br>
</div></blockquote>I don't understand. Please could you elaborate?<br=
></blockquote><div><br></div><div>suppose that <font face=3D"courier new, m=
onospace">Guard </font>is a type that is non-copyable and non-moveable:</di=
v><div><br></div><div style=3D"background-color: rgb(250, 250, 250); border=
: 1px solid rgb(187, 187, 187); word-wrap: break-word;" class=3D"prettyprin=
t"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D=
"color: #000;" class=3D"styled-by-prettify">optional</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: =
#606;" class=3D"styled-by-prettify">Guard</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">></span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> g1 </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> nullopt</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #80=
0;" class=3D"styled-by-prettify">// fine (and very explicit)</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>optional</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Guard</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> g2</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">  =
; </span><span style=3D"color: #800;" class=3D"styled-b=
y-prettify">// fine, although less explicit (unintended behavior?)</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>optional</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span =
style=3D"color: #606;" class=3D"styled-by-prettify">Guard</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> g3 </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> optional</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify"><</span><span style=3D"color: #606;" class=3D=
"styled-by-prettify">Guard</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">>{};</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pretti=
fy">// error: optional<Guard> is not moveable</span></div></code></di=
v><div><br></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_318_20147589.1359551430749--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Fri, 01 Feb 2013 20:22:51 +0100
Raw View
Le 22/01/13 22:18, Andrzej Krzemie=F1ski a =E9crit :
> Hi Everyone,
> We are ready with the 3rd revision of std::optional proposal. The main=20
> changes:
> We would appreciate your feedback and suggestions.
>
Hi,
I see in the proposal
optional<vector<int>> ox{5, 6}; // creates 5-element vector
but I don't see any constructor on the reference that could support this=20
construction. After reading "Handling initializer_list" I have the=20
impression that this constructor is not supported.
Am I missing something?
Vicente
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Fri, 1 Feb 2013 12:33:01 -0800 (PST)
Raw View
------=_Part_673_28359694.1359750781484
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu pi=B1tek, 1 lutego 2013 20:22:51 UTC+1 u=BFytkownik Vicente J. Botet=
=20
Escriba napisa=B3:
>
> Le 22/01/13 22:18, Andrzej Krzemie=F1ski a =E9crit :=20
> > Hi Everyone,=20
> > We are ready with the 3rd revision of std::optional proposal. The main=
=20
> > changes:=20
> > We would appreciate your feedback and suggestions.=20
> >=20
> Hi,=20
>
> I see in the proposal=20
>
> optional<vector<int>> ox{5, 6}; // creates 5-element vector=20
>
> but I don't see any constructor on the reference that could support this=
=20
> construction. After reading "Handling initializer_list" I have the=20
> impression that this constructor is not supported.=20
>
> Am I missing something?=20
>
The above construction is illegal in our proposal. The proposal also=20
discusses alternative designs and why they were rejected. Some examples=20
therefore show invalid code. The block that contains the above example=20
starts with a comment saying "not proposed".
Regards,
&rzej
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_673_28359694.1359750781484
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu pi=B1tek, 1 lutego 2013 20:22:51 UTC+1 u=BFytkownik Vicente =
J. Botet Escriba napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Le =
22/01/13 22:18, Andrzej Krzemie=F1ski a =E9crit :
<br>> Hi Everyone,
<br>> We are ready with the 3rd revision of std::optional proposal. The =
main=20
<br>> changes:
<br>> We would appreciate your feedback and suggestions.
<br>>
<br>Hi,
<br>
<br>I see in the proposal
<br>
<br>optional<vector<int>> ox{5, 6}; // creates 5-element vector
<br>
<br>but I don't see any constructor on the reference that could support thi=
s=20
<br>construction. After reading "Handling initializer_list" I have the=20
<br>impression that this constructor is not supported.
<br>
<br>Am I missing something?
<br></blockquote><div><br>The above construction is illegal in our proposal=
.. The proposal also discusses alternative designs and why they were rejecte=
d. Some examples therefore show invalid code. The block that contains the a=
bove example starts with a comment saying "not proposed".<br><br>Regards,<b=
r>&rzej<br></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_673_28359694.1359750781484--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Fri, 01 Feb 2013 22:25:33 +0100
Raw View
This is a multi-part message in MIME format.
--------------070600020108010702050106
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 01/02/13 21:33, Andrzej Krzemie=F1ski a =E9crit :
>
>
> W dniu pi=B1tek, 1 lutego 2013 20:22:51 UTC+1 u=BFytkownik Vicente J.=20
> Botet Escriba napisa=B3:
>
> Le 22/01/13 22:18, Andrzej Krzemie=F1ski a =E9crit :
> > Hi Everyone,
> > We are ready with the 3rd revision of std::optional proposal.
> The main
> > changes:
> > We would appreciate your feedback and suggestions.
> >
> Hi,
>
> I see in the proposal
>
> optional<vector<int>> ox{5, 6}; // creates 5-element vector
>
> but I don't see any constructor on the reference that could
> support this
> construction. After reading "Handling initializer_list" I have the
> impression that this constructor is not supported.
>
> Am I missing something?
>
>
> The above construction is illegal in our proposal. The proposal also=20
> discusses alternative designs and why they were rejected. Some=20
> examples therefore show invalid code. The block that contains the=20
> above example starts with a comment saying "not proposed".
>
>
Sorry, I missed it.
Vicente
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
--------------070600020108010702050106
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DISO-8859-2"
http-equiv=3D"Content-Type">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 01/02/13 21:33, Andrzej Krzemie=F1ski
a =E9crit=A0:<br>
</div>
<blockquote
cite=3D"mid:5c3a8d7c-4073-4a6a-9606-2a0001fb432c@isocpp.org"
type=3D"cite"><br>
<br>
W dniu pi=B1tek, 1 lutego 2013 20:22:51 UTC+1 u=BFytkownik Vicente J.
Botet Escriba napisa=B3:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Le
22/01/13 22:18, Andrzej Krzemie=F1ski a =E9crit :
<br>
> Hi Everyone,
<br>
> We are ready with the 3rd revision of std::optional
proposal. The main <br>
> changes:
<br>
> We would appreciate your feedback and suggestions.
<br>
>
<br>
Hi,
<br>
<br>
I see in the proposal
<br>
<br>
optional<vector<int>> ox{5, 6}; // creates 5-element
vector
<br>
<br>
but I don't see any constructor on the reference that could
support this <br>
construction. After reading "Handling initializer_list" I have
the <br>
impression that this constructor is not supported.
<br>
<br>
Am I missing something?
<br>
</blockquote>
<div><br>
The above construction is illegal in our proposal. The proposal
also discusses alternative designs and why they were rejected.
Some examples therefore show invalid code. The block that
contains the above example starts with a comment saying "not
proposed".<br>
<br>
</div>
<br>
</blockquote>
Sorry, I missed it.<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--------------070600020108010702050106--
.