------=_Part_22_20484053.1356091632501
Content-Type: text/plain; charset=ISO-8859-1


>
> (Personally, I think we should drop optional<T&> and adopt the rest of
>> optional<T>. The only argument for optional<T&> over just using T* is that
>> generic code might benefit (addressof and "maybe this raw pointer is owned"
>> aren't sufficient IMO), but optional<T&> is non-uniform in enough ways that
>> I'd expect template authors to have to consider references specially anyway
>> (otherwise, it might happen to work, but it might also happen to be a bug).
>> We could always add the specialization later if people wind up needing it,
>> and the requests that lead us to adopt it later would drive the interface.
>
>
> I must have said this a hundred times already but:
>
> (1) First off, I believe C++ is a fantastic language and I never
> minded it being complex and having some subtle rules. It's balance of
> control over runtime performance and source code beauty is
> unparalleled, and is the reason why I choose to use C++ whenever I
> can. Thus, I will always prefer to have a feature even if it has to be
> well understood over not have it. I if wanted to safely program
> without having to think too much about what I'm doing I'd use
> something else (and I did that several times)
>
> (2) IMO the only issue with optional<T&> and it's two possible
> semantics are expectations. There is nothing inherently wrong or even
> inconsistent *on itself* about it (for any of the two choices of
> semantics). Is just that we humans think by analogy and drawing one
> here is difficult, as if optional<T&> were a Platypus. If one insists
> on viewing it as either a duck or a beaver, there is a problem. But
> IMO the problem is in *doing that* as opposed to in optional<T&>
> itself. Personally, I never understood why it has to be "pointer-like"
> OR "value-like",  and can't just be one for some operations and the
> other for the rest.
>
> (3) Going back to (1), I fail even more to see why it's so important
> that optional<T&> be like this or like that, but never both, in the
> context of C++, because from all languages, C++ is itself hybrid, and
> by design. What is important to me is to have a feature that serves a
> general purpose, is well defined and works consistently *with respect
> to itself*
>

Hi Everybody,
We have decided to re-heat the discussion about optional references. It has
become the most (and only) controversial point in std::optional's proposal,
and we feel it needs to be addressed. Taking the lesson from the threads
proposal (which was adopted only after the controversial thread
interruption was removed from it), we are considering splitting the
proposal into two: one for optional values, the other for optional
references. The former appears clean, neat, well understood and very
useful. The latter is controversial, unintuitive and is needed less often.
This way we can guarantee the adoption of optional values early (perhaps
2014) and still buy some time for deciding on optional references'
semantics. Recent discussion on hashing showed that these semantics are
still unstable.

I can name the following options for optional references:

   1. Not provide them at all (this may in fact be the consequence of
   splitting the proposals)
   2. Provide them with a very limited interface (as in N3406<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3406.html>
   )
   3. Provide  rich interface for optional refs (equality, hash,
   assignment, etc...) with deep value semantics wherever possible
   4. Provide pointer-like semantics
   5. Provide some hybrid of 3 and 4.

I personally happened to use boost::optional<T&> at times and found it
useful for function arguments. In my usages I never needed comparison,
hashing, "genericity", or assignment, so option 2 is fine with me.

Feel free to express your preference, but please give your rationale and
practical use-cases with it. If we cannot reach an agreement, we will
resort to arbitrarily selecting either option 1 or 4.
I also enclose a couple of links to discussions on the same subject from
the past:

https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/cXneqUj-5oo
http://lists.boost.org/Archives/boost/2003/10/55549.php
http://lists.boost.org/Archives/boost/2005/03/81141.php
https://groups.google.com/forum/?fromgroups#!msg/boost-developers-archive/CgjtV0ZLw8c/0rNj66FxSXAJ
https://groups.google.com/d/msg/boost-developers-archive/CgjtV0ZLw8c/uS5vzzBVajoJ


Regards,
&rzej

--




------=_Part_22_20484053.1356091632501
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"><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">(Personally, I think we should dro=
p optional&lt;T&amp;&gt; and adopt the
 rest of optional&lt;T&gt;. The only argument for optional&lt;T&amp;&gt;
 over just using T* is that generic code might benefit (addressof and=20
"maybe this raw pointer is owned" aren't sufficient IMO), but=20
optional&lt;T&amp;&gt; is non-uniform in enough ways that I'd expect=20
template authors to have to consider references specially anyway=20
(otherwise, it might happen to work, but it might also happen to be a=20
bug). We could always add the specialization later if people wind up=20
needing it, and the requests that lead us to adopt it later would drive=20
the interface.</blockquote><div><br>I must have said this a hundred times a=
lready but:
<br>
<br>(1) First off, I believe C++ is a fantastic language and I never
<br>minded it being complex and having some subtle rules. It's balance of
<br>control over runtime performance and source code beauty is
<br>unparalleled, and is the reason why I choose to use C++ whenever I
<br>can. Thus, I will always prefer to have a feature even if it has to be
<br>well understood over not have it. I if wanted to safely program
<br>without having to think too much about what I'm doing I'd use
<br>something else (and I did that several times)
<br>
<br>(2) IMO the only issue with optional&lt;T&amp;&gt; and it's two possibl=
e
<br>semantics are expectations. There is nothing inherently wrong or even
<br>inconsistent *on itself* about it (for any of the two choices of
<br>semantics). Is just that we humans think by analogy and drawing one
<br>here is difficult, as if optional&lt;T&amp;&gt; were a Platypus. If one=
 insists
<br>on viewing it as either a duck or a beaver, there is a problem. But
<br>IMO the problem is in *doing that* as opposed to in optional&lt;T&amp;&=
gt;
<br>itself. Personally, I never understood why it has to be "pointer-like"
<br>OR "value-like", &nbsp;and can't just be one for some operations and th=
e
<br>other for the rest.
<br>
<br>(3) Going back to (1), I fail even more to see why it's so important
<br>that optional&lt;T&amp;&gt; be like this or like that, but never both, =
in the
<br>context of C++, because from all languages, C++ is itself hybrid, and
<br>by design. What is important to me is to have a feature that serves a
<br>general purpose, is well defined and works consistently *with respect
<br>to itself*&nbsp;
<br></div></blockquote><div><br>Hi Everybody,<br>We have decided to re-heat=
 the discussion about optional references. It has become the most (and only=
) controversial point in std::optional's proposal, and we feel it needs to =
be addressed. Taking the lesson from the threads proposal (which was adopte=
d only after the controversial thread interruption was removed from it), we=
 are considering splitting the proposal into two: one for optional values, =
the other for optional references. The former appears clean, neat, well und=
erstood and very useful. The latter is controversial, unintuitive and is ne=
eded less often. This way we can guarantee the adoption of optional values =
early (perhaps 2014) and still buy some time for deciding on optional refer=
ences' semantics. Recent discussion on hashing showed that these semantics =
are still unstable.<br><br>I can name the following options for optional re=
ferences:<br><ol><li>Not provide them at all (this may in fact be the conse=
quence of splitting the proposals)</li><li>Provide them with a very limited=
 interface (as in <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/pa=
pers/2012/n3406.html">N3406</a>)</li><li>Provide&nbsp; rich interface for o=
ptional refs (equality, hash, assignment, etc...) with deep value semantics=
 wherever possible</li><li>Provide pointer-like semantics</li><li>Provide s=
ome hybrid of 3 and 4.</li></ol><p>I personally happened to use boost::opti=
onal&lt;T&amp;&gt; at times and found it useful for function arguments. In =
my usages I never needed comparison, hashing, "genericity", or assignment, =
so option 2 is fine with me.</p><p>Feel free to express your preference, bu=
t please give your rationale and practical use-cases with it. If we cannot =
reach an agreement, we will resort to arbitrarily selecting either option 1=
 or 4.<br></p>I also enclose a couple of links to discussions on the same s=
ubject from the past:<br><br><a href=3D"https://groups.google.com/a/isocpp.=
org/forum/#%21topic/std-proposals/cXneqUj-5oo" target=3D"_blank">https://gr=
oups.google.com/a/<wbr>isocpp.org/forum/#!topic/std-<wbr>proposals/cXneqUj-=
5oo</a><br><a href=3D"http://lists.boost.org/Archives/boost/2003/10/55549.p=
hp" target=3D"_blank">http://lists.boost.org/<wbr>Archives/boost/2003/10/55=
549.<wbr>php</a><br><a href=3D"http://lists.boost.org/Archives/boost/2005/0=
3/81141.php" target=3D"_blank">http://lists.boost.org/<wbr>Archives/boost/2=
005/03/81141.<wbr>php</a><br><a href=3D"https://groups.google.com/forum/?fr=
omgroups#%21msg/boost-developers-archive/CgjtV0ZLw8c/0rNj66FxSXAJ" target=
=3D"_blank">https://groups.google.com/<wbr>forum/?fromgroups#!msg/boost-<wb=
r>developers-archive/<wbr>CgjtV0ZLw8c/0rNj66FxSXAJ</a><br><a href=3D"https:=
//groups.google.com/d/msg/boost-developers-archive/CgjtV0ZLw8c/uS5vzzBVajoJ=
" target=3D"_blank">https://groups.google.com/d/<wbr>msg/boost-developers-a=
rchive/<wbr>CgjtV0ZLw8c/uS5vzzBVajoJ</a>&nbsp; <br><br>Regards,<br>&amp;rze=
j<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_22_20484053.1356091632501--

.

On Fri, Dec 21, 2012 at 9:07 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:

> we are considering splitting the proposal into two:
> one for optional values, the other for optional references.

So we can all have our cake. Then maybe, but only maybe, we can eat it too.

We will be presenting three papers:

One with non-reference optionals. This is the feature we all want.

Then two for optional references:

One proposing pointer-like semantics, such as rebinding on assignment,
shallow comparisons and hashing
Then a second one proposing reference-like semantics, such as
assigning to the referenced object and having deep comparisons and
hashing.

Both reference optional papers will contain a rational for their
choice plus a comparative table of pros and cons.

The base paper will intentionally propose to disallow optional
references, with a note that this would be the case IFF the none of
the other papers are accepted.

From a software POV we think it would be scalable that we first have a
std that makes optional<T&> ill-formed then change that and allow it
in an eventual new std. NOT that I'd like that but like many others, I
rather have just that than nothing at all. AFAICT, this would only
mean that std::optional would not be usable in the cases where it
needs to accept references (such as a generic context), not initially
but maybe in the future.

Best

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--=20




.

This is awesome. Thank you!

I expect to be weakly against both optional<T&> papers in Bristol and
strongly-for the optional<T> paper, but I'm hopeful that just being
able to pick among those three options will increase the chances of
finding consensus. (On the other hand, if people come out of the
woodwork now to say that they're opposed to an
optional<T>-without-optional<T&> paper but would favor a combined
paper, I think you should be willing to consider recombining them.)

On Fri, Dec 21, 2012 at 5:27 AM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> On Fri, Dec 21, 2012 at 9:07 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail=
..com> wrote:
>
>> we are considering splitting the proposal into two:
>> one for optional values, the other for optional references.
>
> So we can all have our cake. Then maybe, but only maybe, we can eat it to=
o.
>
> We will be presenting three papers:
>
> One with non-reference optionals. This is the feature we all want.
>
> Then two for optional references:
>
> One proposing pointer-like semantics, such as rebinding on assignment,
> shallow comparisons and hashing
> Then a second one proposing reference-like semantics, such as
> assigning to the referenced object and having deep comparisons and
> hashing.
>
> Both reference optional papers will contain a rational for their
> choice plus a comparative table of pros and cons.
>
> The base paper will intentionally propose to disallow optional
> references, with a note that this would be the case IFF the none of
> the other papers are accepted.
>
> From a software POV we think it would be scalable that we first have a
> std that makes optional<T&> ill-formed then change that and allow it
> in an eventual new std. NOT that I'd like that but like many others, I
> rather have just that than nothing at all. AFAICT, this would only
> mean that std::optional would not be usable in the cases where it
> needs to accept references (such as a generic context), not initially
> but maybe in the future.
>
> Best
>
> --
> Fernando Cacciola
> SciSoft Consulting, Founder
> http://www.scisoft-consulting.com
>
> --
>
>
>

--=20




.

On 21 December 2012 21:13, Jeffrey Yasskin <jyasskin@googlers.com> wrote:
> This is awesome. Thank you!
> I expect to be weakly against both optional<T&> papers in Bristol and
> strongly-for the optional<T> paper, but I'm hopeful that just being
> able to pick among those three options will increase the chances of
> finding consensus. (On the other hand, if people come out of the
> woodwork now to say that they're opposed to an
> optional<T>-without-optional<T&> paper but would favor a combined
> paper, I think you should be willing to consider recombining them.)

I'm not alarmed about the possibility of an optional<T&> being ill-formed,
there's always optional<reference_wrapper<T>>, right?

--




.

------=_Part_484_16383492.1356124567948
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu pi=B1tek, 21 grudnia 2012 20:35:32 UTC+1 u=BFytkownik Ville Voutilai=
nen=20
napisa=B3:
>
> On 21 December 2012 21:13, Jeffrey Yasskin <jyas...@googlers.com<javascri=
pt:>>=20
> wrote:=20
> > This is awesome. Thank you!=20
> > I expect to be weakly against both optional<T&> papers in Bristol and=
=20
> > strongly-for the optional<T> paper, but I'm hopeful that just being=20
> > able to pick among those three options will increase the chances of=20
> > finding consensus. (On the other hand, if people come out of the=20
> > woodwork now to say that they're opposed to an=20
> > optional<T>-without-optional<T&> paper but would favor a combined=20
> > paper, I think you should be willing to consider recombining them.)=20
>
> I'm not alarmed about the possibility of an optional<T&> being ill-formed=
,=20
> there's always optional<reference_wrapper<T>>, right?=20
>
=20
Yes, and for those that require optional in these very generic contexts=20
there will be a workaround:

template <typename T>
struct uniform
{
  typedef T type;
};

template<typename U>
struct uniform<U&>
{
  typename std::reference_wrapper<U> type;
};

template <typename T>
using Uniform =3D typename uniform<T>::type;

template <typename X>
void fun()
{
  std::optional<Uniform<X>> op;
}



--=20




------=_Part_484_16383492.1356124567948
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu pi=B1tek, 21 grudnia 2012 20:35:32 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 21 De=
cember 2012 21:13, Jeffrey Yasskin &lt;<a href=3D"javascript:" target=3D"_b=
lank" gdf-obfuscated-mailto=3D"pT60FG7Zdp8J">jyas...@googlers.com</a>&gt; w=
rote:
<br>&gt; This is awesome. Thank you!
<br>&gt; I expect to be weakly against both optional&lt;T&amp;&gt; papers i=
n Bristol and
<br>&gt; strongly-for the optional&lt;T&gt; paper, but I'm hopeful that jus=
t being
<br>&gt; able to pick among those three options will increase the chances o=
f
<br>&gt; finding consensus. (On the other hand, if people come out of the
<br>&gt; woodwork now to say that they're opposed to an
<br>&gt; optional&lt;T&gt;-without-optional&lt;<wbr>T&amp;&gt; paper but wo=
uld favor a combined
<br>&gt; paper, I think you should be willing to consider recombining them.=
)
<br>
<br>I'm not alarmed about the possibility of an optional&lt;T&amp;&gt; bein=
g ill-formed,
<br>there's always optional&lt;reference_wrapper&lt;T&gt;&gt;<wbr>, right?
<br></blockquote><div>&nbsp;<br>Yes, and for those that require optional in=
 these very generic contexts there will be a workaround:<br><br><span style=
=3D"font-family: courier new,monospace;"><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: #008;=
" class=3D"styled-by-prettify">template</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">typename</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span><span style=3D"color: #008;" class=3D"styled-by-prettify">struct</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> uniform<br>=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">typedef</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> T type</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;" c=
lass=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">template</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">typename</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> U</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">stru=
ct</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> uniform=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">U</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">&amp;&gt;</span><span sty=
le=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: #0=
00;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">typename</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">reference_wrapper</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">U</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> type</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">template</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">using</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Un=
iform</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> uniform</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&gt;::</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">type</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">template</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">type=
name</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> X</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=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"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>&nbsp; std</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-p=
rettify">&lt;</span><span style=3D"color: #606;" class=3D"styled-by-prettif=
y">Uniform</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">X</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;&gt;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> op</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></div></code></div><br></span><=
br><br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_484_16383492.1356124567948--

.

------=_Part_485_10601258.1356217303802
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

Andrzej,

On Friday, December 21, 2012 11:07:12 PM UTC+11, Andrzej Krzemie=F1ski wrot=
e:
>
> We have decided to re-heat the discussion about optional references...=20
>
I can name the following options for optional references:
>
>    1. Not provide them at all (this may in fact be the consequence of=20
>    splitting the proposals)
>    2. Provide them with a very limited interface (as in N3406<http://www.=
open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3406.html>
>    )
>    3. Provide  rich interface for optional refs (equality, hash,=20
>    assignment, etc...) with deep value semantics wherever possible
>    4. Provide pointer-like semantics
>    5. Provide some hybrid of 3 and 4.
>
> 1. I am admittedly very late to this discussion and I promise to pour ove=
r=20
the links that you provided (once I recover from being force-fed that=20
Christmas pudding and turkey and what have you). Still, I dare to say that=
=20
a) I'd find #1 unfortunate and #3 quite desirable; b) #4 and, consequently,=
=20
#5 sound so wrong to me. If one needs the pointer-like semantics, then he'd=
=20
use... pause... drum roll... ta-da... pointers, right?

2. I am sure it's a naive question of a newcomer but is there any=20
correlation, overlap, functional differences between optional<T&> and=20
optional<boost::ref<T>>? If I were the 'optional', I would not mind to=20
state -- I am only handling values; if you want to handle references, talk=
=20
to boost::ref/reference_wrapper and take all your concerns there. That'd=20
take that whole debate out of the 'optional' camp and we'd enjoy peace and=
=20
quiet and clean/orthogonal implementation of 'optional'.=20

No? Too perfect a picture to be true? Forgive me as I am still under the=20
influence of pudding/turkey/... And Merry Christmas for those who celebrate=
=20
one.

--=20




------=_Part_485_10601258.1356217303802
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

Andrzej,<br><br>On Friday, December 21, 2012 11:07:12 PM UTC+11, Andrzej Kr=
zemie=F1ski wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>We have=
 decided to re-heat the discussion about optional references...&nbsp;</div>=
</blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>I can name t=
he following options for optional references:<br><ol><li>Not provide them a=
t all (this may in fact be the consequence of splitting the proposals)</li>=
<li>Provide them with a very limited interface (as in <a href=3D"http://www=
..open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3406.html" target=3D"_blank"=
>N3406</a>)</li><li>Provide&nbsp; rich interface for optional refs (equalit=
y, hash, assignment, etc...) with deep value semantics wherever possible</l=
i><li>Provide pointer-like semantics</li><li>Provide some hybrid of 3 and 4=
..</li></ol></div></blockquote><div>1. I am admittedly very late to this dis=
cussion and I promise to pour over the links that you provided (once I reco=
ver from being force-fed that Christmas pudding and turkey and what have yo=
u). Still, I dare to say that a) I'd find #1 unfortunate and #3 quite desir=
able; b) #4 and, consequently, #5 sound so wrong to me. If one needs the po=
inter-like semantics, then he'd use... pause... drum roll... ta-da... point=
ers, right?</div><div><br></div><div>2. I am sure it's a naive question of =
a newcomer but is there any correlation, overlap, functional differences be=
tween optional&lt;T&amp;&gt; and optional&lt;boost::ref&lt;T&gt;&gt;? If I =
were the 'optional', I would not mind to state -- I am only handling values=
; if you want to handle references, talk to boost::ref/reference_wrapper an=
d take all your concerns there. That'd take that whole debate out of the 'o=
ptional' camp and we'd enjoy peace and quiet and clean/orthogonal implement=
ation of 'optional'.&nbsp;</div><div><br></div><div>No? Too perfect a pictu=
re to be true? Forgive me as I am still under the influence of pudding/turk=
ey/... And Merry Christmas for those who celebrate one.</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_485_10601258.1356217303802--

.

------=_Part_681_15338257.1356250807831
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu niedziela, 23 grudnia 2012 00:01:43 UTC+1 u=BFytkownik Vladimir Bato=
v=20
napisa=B3:
>
> Andrzej,
>
> On Friday, December 21, 2012 11:07:12 PM UTC+11, Andrzej Krzemie=F1ski wr=
ote:
>>
>> We have decided to re-heat the discussion about optional references...=
=20
>>
> I can name the following options for optional references:
>>
>>    1. Not provide them at all (this may in fact be the consequence of=20
>>    splitting the proposals)
>>    2. Provide them with a very limited interface (as in N3406<http://www=
..open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3406.html>
>>    )
>>    3. Provide  rich interface for optional refs (equality, hash,=20
>>    assignment, etc...) with deep value semantics wherever possible
>>    4. Provide pointer-like semantics
>>    5. Provide some hybrid of 3 and 4.
>>
>> 1. I am admittedly very late to this discussion and I promise to pour=20
> over the links that you provided (once I recover from being force-fed tha=
t=20
> Christmas pudding and turkey and what have you). Still, I dare to say tha=
t=20
> a) I'd find #1 unfortunate and #3 quite desirable; b) #4 and, consequentl=
y,=20
> #5 sound so wrong to me. If one needs the pointer-like semantics, then he=
'd=20
> use... pause... drum roll... ta-da... pointers, right?
>

I am not quite sure why you would find #1 unfotunate. Down below you=20
yourself suggest how those that reqire optional references can "emulate"=20
them themselves using reference_wrapper. Also, for these that require the=
=20
uniform handling of optional references and optional values, there exists a=
=20
way to emulate them. See the following reply in the same thread:=20
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/rKjpmkeCSyo/DNcm=
7Y50HscJ

You did not mention #2. Do you find it acceptable? You find #3 desireable.=
=20
Can you think of an example (that looks practical) where this would be=20
useful? The most fundamental problem with #3 is the semantics of its=20
copy-assignment. Should it be deep (non-rebinding a reference) or shallow=
=20
(rebinding). Both cause some confusion.

2. I am sure it's a naive question of a newcomer but is there any=20
> correlation, overlap, functional differences between optional<T&> and=20
> optional<boost::ref<T>>? If I were the 'optional', I would not mind to=20
> state -- I am only handling values; if you want to handle references, tal=
k=20
> to boost::ref/reference_wrapper and take all your concerns there. That'd=
=20
> take that whole debate out of the 'optional' camp and we'd enjoy peace an=
d=20
> quiet and clean/orthogonal implementation of 'optional'.=20
>

Actually, boost::ref is a function (template), the corresponding class=20
template is boost::reference_wrapper. I am pretty sure=20
optional<boost::reference_wrapper<T>> would work, but Boost users need not=
=20
check it because they have boost::optional<T&> with exactly these semantics=
=20
(and rebinding copy-assignment). You are right here: optional refs can be=
=20
fairly easily emulated. So providing a cleaner interface for it is of=20
secondary importance (IMO), given optional refs will be used rarely.

No? Too perfect a picture to be true? Forgive me as I am still under the=20
> influence of pudding/turkey/... And Merry Christmas for those who celebra=
te=20
> one.
>

Not too perfect. I think this is our plans currently reflect: first only=20
propose optional values, then think of optional refs (if people think they=
=20
are still needed).

Regards,
&rzej  =20
=20

--=20




------=_Part_681_15338257.1356250807831
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu niedziela, 23 grudnia 2012 00:01: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;">Andrzej,<b=
r><br>On Friday, December 21, 2012 11:07:12 PM UTC+11, Andrzej Krzemie=F1sk=
i wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div>We have decided to re-=
heat the discussion about optional references...&nbsp;</div></blockquote><b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div>I can name the following options=
 for optional references:<br><ol><li>Not provide them at all (this may in f=
act be the consequence of splitting the proposals)</li><li>Provide them wit=
h a very limited interface (as in <a href=3D"http://www.open-std.org/jtc1/s=
c22/wg21/docs/papers/2012/n3406.html" target=3D"_blank">N3406</a>)</li><li>=
Provide&nbsp; rich interface for optional refs (equality, hash, assignment,=
 etc...) with deep value semantics wherever possible</li><li>Provide pointe=
r-like semantics</li><li>Provide some hybrid of 3 and 4.</li></ol></div></b=
lockquote><div>1. I am admittedly very late to this discussion and I promis=
e to pour over the links that you provided (once I recover from being force=
-fed that Christmas pudding and turkey and what have you). Still, I dare to=
 say that a) I'd find #1 unfortunate and #3 quite desirable; b) #4 and, con=
sequently, #5 sound so wrong to me. If one needs the pointer-like semantics=
, then he'd use... pause... drum roll... ta-da... pointers, right?</div></b=
lockquote><div><br>I am not quite sure why you would find #1 unfotunate. Do=
wn below you yourself suggest how those that reqire optional references can=
 "emulate" them themselves using reference_wrapper. Also, for these that re=
quire the uniform handling of optional references and optional values, ther=
e exists a way to emulate them. See the following reply in the same thread:=
 https://groups.google.com/a/isocpp.org/d/msg/std-proposals/rKjpmkeCSyo/DNc=
m7Y50HscJ<br><br>You did not mention #2. Do you find it acceptable? You fin=
d #3 desireable. Can you think of an example (that looks practical) where t=
his would be useful? The most fundamental problem with #3 is the semantics =
of its copy-assignment. Should it be deep (non-rebinding a reference) or sh=
allow (rebinding). Both cause some confusion.<br><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div>2. I am sure it's a naive question of a n=
ewcomer but is there any correlation, overlap, functional differences betwe=
en optional&lt;T&amp;&gt; and optional&lt;boost::ref&lt;T&gt;&gt;? If I wer=
e the 'optional', I would not mind to state -- I am only handling values; i=
f you want to handle references, talk to boost::ref/reference_wrapper and t=
ake all your concerns there. That'd take that whole debate out of the 'opti=
onal' camp and we'd enjoy peace and quiet and clean/orthogonal implementati=
on of 'optional'.&nbsp;</div></blockquote><div><br>Actually, boost::ref is =
a function (template), the corresponding class template is boost::reference=
_wrapper. I am pretty sure optional&lt;boost::reference_wrapper&lt;T&gt;&gt=
; would work, but Boost users need not check it because they have boost::op=
tional&lt;T&amp;&gt; with exactly these semantics (and rebinding copy-assig=
nment). You are right here: optional refs can be fairly easily emulated. So=
 providing a cleaner interface for it is of secondary importance (IMO), giv=
en optional refs will be used rarely.<br><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div>No? Too perfect a picture to be true? Forgive me =
as I am still under the influence of pudding/turkey/... And Merry Christmas=
 for those who celebrate one.</div></blockquote><div><br>Not too perfect. I=
 think this is our plans currently reflect: first only propose optional val=
ues, then think of optional refs (if people think they are still needed).<b=
r><br>Regards,<br>&amp;rzej &nbsp; <br></div><div>&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_681_15338257.1356250807831--

.

On Sun, Dec 23, 2012 at 7:20 PM, Andrzej Krzemie=F1ski <akrzemi1@gmail.com>=
 wrote:
> W dniu niedziela, 23 grudnia 2012 00:01:43 UTC+1 u=BFytkownik Vladimir Ba=
tov
> napisa=B3:
>> On Friday, December 21, 2012 11:07:12 PM UTC+11, Andrzej Krzemie=F1ski
>> wrote:
>>>
>>> We have decided to re-heat the discussion about optional references...
>>>
>>> I can name the following options for optional references:
>>>
>>> Not provide them at all (this may in fact be the consequence of splitti=
ng
>>> the proposals)
>>> Provide them with a very limited interface (as in N3406)
>>> Provide  rich interface for optional refs (equality, hash, assignment,
>>> etc...) with deep value semantics wherever possible
>>> Provide pointer-like semantics
>>> Provide some hybrid of 3 and 4.
>>
>> 1. I am admittedly very late to this discussion and I promise to pour ov=
er
>> the links that you provided (once I recover from being force-fed that
>> Christmas pudding and turkey and what have you). Still, I dare to say th=
at
>> a) I'd find #1 unfortunate and #3 quite desirable; b) #4 and, consequent=
ly,
>> #5 sound so wrong to me. If one needs the pointer-like semantics, then h=
e'd
>> use... pause... drum roll... ta-da... pointers, right?
>
> I am not quite sure why you would find #1 unfortunate. Down below you
> yourself suggest how those that require optional references can "emulate"
> them themselves using reference_wrapper. Also, for these that require the
> uniform handling of optional references and optional values, there exists=
 a
> way to emulate them. See the following reply in the same thread:
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/rKjpmkeCSyo/DN=
cm7Y50HscJ

First of, I have to make a confession that due to our project
specifics (classes of considerable size, overwhelmingly read-only,
pimpl/shared_ptr wrapped) I do not use optional much and I do not have
immediate deployment examples for optional<&>. So, pls take my
rumblings with a pinch of salt. Still, the examples I saw in the
proposal and the justifications looked and sounded like a potentially
interesting/useful/nice-to-have functionality. See my reply further
with regard to #3.

> You did not mention #2. Do you find it acceptable?

I did not mention #2 as my reading of it was  (forgive me if I got it
all wrong) that #2 was not a solution as such as there were/are still
concerns/discussions/unresolved issues about actual behavior. So, #2
was like "that's how far we've got so far".

> You find #3 desireable.
> Can you think of an example (that looks practical) where this would be
> useful?

That functionality is all new to me and admittedly I do not have any
industrial-strength deployment examples/needs. That said, the snippets
in the proposal

int j =3D 1;
optional<int&> orj =3D j;

looked quite interesting as I imagined using func(optional<foo
const&>) as an "optional" complement for the ubiquitous func(foo
const&) instead of resorting to func(foo const*) which is not as clean
and fool-proof. I certainly cannot agree with some insisting that
func(foo const*) does as good a job as func(optional<foo const&>).

> The most fundamental problem with #3 is the semantics of its
> copy-assignment. Should it be deep (non-rebinding a reference) or shallow
> (rebinding). Both cause some confusion.

My thinking'd be along the following lines. The value object inside
optional<T> behaves as a full-fledged value as it's expected from a
value object. Then, I'd fully expect the reference object inside
optional<T&> to behave as a reference, i.e. deep copy. I must be
missing something but I can not understand what possibly might be
confusing about a reference (inside optional) behaving like a
reference.

>> 2. I am sure it's a naive question of a newcomer but is there any
>> correlation, overlap, functional differences between optional<T&> and
>> optional<boost::ref<T>>? If I were the 'optional', I would not mind to s=
tate
>> -- I am only handling values; if you want to handle references, talk to
>> boost::ref/reference_wrapper and take all your concerns there. That'd ta=
ke
>> that whole debate out of the 'optional' camp and we'd enjoy peace and qu=
iet
>> and clean/orthogonal implementation of 'optional'.
>
> Actually, boost::ref is a function (template), the corresponding class
> template is boost::reference_wrapper.

Indeed. Well noted. Apologies for being lazy/inaccurate.

> I am pretty sure
> optional<boost::reference_wrapper<T>> would work, but Boost users need no=
t
> check it because they have boost::optional<T&> with exactly these semanti=
cs
> (and rebinding copy-assignment).

Uhm, forgive me but my reading of boost::reference_wrapper<T> is that
it does not provide rebinding copy-assignment. Providing that alters
behavior dramatically IMO and, therefore, quite far from "exactly
these semantics". I must be missing something fundamental but in all
honesty rebinding copy-assignment with regard to references sounds
quite sinful to me.

> You are right here: optional refs can be
> fairly easily emulated. So providing a cleaner interface for it is of
> secondary importance (IMO), given optional refs will be used rarely.

If it is indeed so, i.e. "optional refs can be fairly easily
emulated.", then why bother in the first place? Why not keep optional
lean, clean, minimal, functionally-orthogonal?.. for the time being
anyway... Easier to get through the committee. :-)

>> No? Too perfect a picture to be true? Forgive me as I am still under the
>> influence of pudding/turkey/... And Merry Christmas for those who celebr=
ate
>> one.
>
> Not too perfect. I think this is our plans currently reflect: first only
> propose optional values, then think of optional refs (if people think the=
y
> are still needed).

But you are not exactly proposing optional values only, are you? The
rev.2 proposal does contain "Optional references" chapter, does not
it? Given the situation with opt. refs (as I understand it) that
mentioning of opt. refs might be that loose end that, when pulled,
might unravel (make trouble for) the whole proposal. Just an old man
being overly cautious.

Best,
V.

--=20




.

------=_Part_6_15568709.1356280173701
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu niedziela, 23 grudnia 2012 11:13:55 UTC+1 u=BFytkownik Vladimir Bato=
v=20
napisa=B3:
>
>
>
> > You did not mention #2. Do you find it acceptable?=20
>
> I did not mention #2 as my reading of it was  (forgive me if I got it=20
> all wrong) that #2 was not a solution as such as there were/are still=20
> concerns/discussions/unresolved issues about actual behavior. So, #2=20
> was like "that's how far we've got so far".=20
>
> > You find #3 desireable.=20
> > Can you think of an example (that looks practical) where this would be=
=20
> > useful?=20
>
> That functionality is all new to me and admittedly I do not have any=20
> industrial-strength deployment examples/needs. That said, the snippets=20
> in the proposal=20
>
> int j =3D 1;=20
> optional<int&> orj =3D j;=20
>
> looked quite interesting as I imagined using func(optional<foo=20
> const&>) as an "optional" complement for the ubiquitous func(foo=20
> const&) instead of resorting to func(foo const*) which is not as clean=20
> and fool-proof. I certainly cannot agree with some insisting that=20
> func(foo const*) does as good a job as func(optional<foo const&>).=20
>

I did use optional references in production code exactly for this purpose:=
=20
optional arguments to functions. And I found that for this usage I never=20
needed optional<T&> to be assignable or comparable. Therefore I considered=
=20
#2 an acceptable choice. It is limited, but given the usage above, you=20
would never notice this fact.
=20

>
> > The most fundamental problem with #3 is the semantics of its=20
> > copy-assignment. Should it be deep (non-rebinding a reference) or=20
> shallow=20
> > (rebinding). Both cause some confusion.=20
>
> My thinking'd be along the following lines. The value object inside=20
> optional<T> behaves as a full-fledged value as it's expected from a=20
> value object. Then, I'd fully expect the reference object inside=20
> optional<T&> to behave as a reference, i.e. deep copy. I must be=20
> missing something but I can not understand what possibly might be=20
> confusing about a reference (inside optional) behaving like a=20
> reference.=20
>

Given two optional references 'p' and 'q', you would expect:

p =3D q;



to have exactly same semantics as:

p =3D nullopt;
p =3D q;=20

This can only be achieved with rebinding semantics.


> >> 2. I am sure it's a naive question of a newcomer but is there any=20
> >> correlation, overlap, functional differences between optional<T&> and=
=20
> >> optional<boost::ref<T>>? If I were the 'optional', I would not mind to=
=20
> state=20
> >> -- I am only handling values; if you want to handle references, talk t=
o=20
> >> boost::ref/reference_wrapper and take all your concerns there. That'd=
=20
> take=20
> >> that whole debate out of the 'optional' camp and we'd enjoy peace and=
=20
> quiet=20
> >> and clean/orthogonal implementation of 'optional'.=20
> >=20
> > Actually, boost::ref is a function (template), the corresponding class=
=20
> > template is boost::reference_wrapper.=20
>
> Indeed. Well noted. Apologies for being lazy/inaccurate.=20
>
> > I am pretty sure=20
> > optional<boost::reference_wrapper<T>> would work, but Boost users need=
=20
> not=20
> > check it because they have boost::optional<T&> with exactly these=20
> semantics=20
> > (and rebinding copy-assignment).=20
>
> Uhm, forgive me but my reading of boost::reference_wrapper<T> is that=20
> it does not provide rebinding copy-assignment. Providing that alters=20
> behavior dramatically IMO and, therefore, quite far from "exactly=20
> these semantics". I must be missing something fundamental but in all=20
> honesty rebinding copy-assignment with regard to references sounds=20
> quite sinful to me.=20
>

Now I apologize. I was too quick in my reply. I checked and=20
boost::reference_wrapper does not provide copy assignment. (I am not sure=
=20
if T's copy-assignment) is used implicitly). However,=20
std::reference_wrapper does appear to have a rebinding copy-assignment (see=
=20
20.8.3.2).
=20

>
> > You are right here: optional refs can be=20
> > fairly easily emulated. So providing a cleaner interface for it is of=
=20
> > secondary importance (IMO), given optional refs will be used rarely.=20
>
> If it is indeed so, i.e. "optional refs can be fairly easily=20
> emulated.", then why bother in the first place? Why not keep optional=20
> lean, clean, minimal, functionally-orthogonal?.. for the time being=20
> anyway... Easier to get through the committee. :-)=20
>

This is our current plan: propose only optional values for now, and move=20
optional refs till later (which may turn out to be never). =20

>
> >> No? Too perfect a picture to be true? Forgive me as I am still under=
=20
> the=20
> >> influence of pudding/turkey/... And Merry Christmas for those who=20
> celebrate=20
> >> one.=20
> >=20
> > Not too perfect. I think this is our plans currently reflect: first onl=
y=20
> > propose optional values, then think of optional refs (if people think=
=20
> they=20
> > are still needed).=20
>
> But you are not exactly proposing optional values only, are you? The=20
> rev.2 proposal does contain "Optional references" chapter, does not=20
> it? Given the situation with opt. refs (as I understand it) that=20
> mentioning of opt. refs might be that loose end that, when pulled,=20
> might unravel (make trouble for) the whole proposal. Just an old man=20
> being overly cautious.=20
>

This is true for revision 2. Revision 3 will drop them.

Regards,
&rzej=20

--=20




------=_Part_6_15568709.1356280173701
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu niedziela, 23 grudnia 2012 11:13:55 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;"><br>
<br>&gt; You did not mention #2. Do you find it acceptable?
<br>
<br>I did not mention #2 as my reading of it was &nbsp;(forgive me if I got=
 it
<br>all wrong) that #2 was not a solution as such as there were/are still
<br>concerns/discussions/<wbr>unresolved issues about actual behavior. So, =
#2
<br>was like "that's how far we've got so far".
<br>
<br>&gt; You find #3 desireable.
<br>&gt; Can you think of an example (that looks practical) where this woul=
d be
<br>&gt; useful?
<br>
<br>That functionality is all new to me and admittedly I do not have any
<br>industrial-strength deployment examples/needs. That said, the snippets
<br>in the proposal
<br>
<br>int j =3D 1;
<br>optional&lt;int&amp;&gt; orj =3D j;
<br>
<br>looked quite interesting as I imagined using func(optional&lt;foo
<br>const&amp;&gt;) as an "optional" complement for the ubiquitous func(foo
<br>const&amp;) instead of resorting to func(foo const*) which is not as cl=
ean
<br>and fool-proof. I certainly cannot agree with some insisting that
<br>func(foo const*) does as good a job as func(optional&lt;foo const&amp;&=
gt;).
<br></blockquote><div><br>I did use optional references in production code =
exactly for this purpose: optional arguments to functions. And I found that=
 for this usage I never needed optional&lt;T&amp;&gt; to be assignable or c=
omparable. Therefore I considered #2 an acceptable choice. It is limited, b=
ut given the usage above, you would never notice this fact.<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;">
<br>&gt; The most fundamental problem with #3 is the semantics of its
<br>&gt; copy-assignment. Should it be deep (non-rebinding a reference) or =
shallow
<br>&gt; (rebinding). Both cause some confusion.
<br>
<br>My thinking'd be along the following lines. The value object inside
<br>optional&lt;T&gt; behaves as a full-fledged value as it's expected from=
 a
<br>value object. Then, I'd fully expect the reference object inside
<br>optional&lt;T&amp;&gt; to behave as a reference, i.e. deep copy. I must=
 be
<br>missing something but I can not understand what possibly might be
<br>confusing about a reference (inside optional) behaving like a
<br>reference.
<br></blockquote><div><br>Given two optional references 'p' and 'q', you wo=
uld expect:<br><br><div class=3D"prettyprint" style=3D"background-color: rg=
b(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bo=
rder-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div c=
lass=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">p </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> q</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code>=
</div><br><br><br>to have exactly same semantics as:<br><br><div class=3D"p=
rettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rg=
b(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-=
word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">p </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> nullopt</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>p </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> q</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>This can only be achieved with rebinding sem=
antics.<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;">
<br>&gt;&gt; 2. I am sure it's a naive question of a newcomer but is there =
any
<br>&gt;&gt; correlation, overlap, functional differences between optional&=
lt;T&amp;&gt; and
<br>&gt;&gt; optional&lt;boost::ref&lt;T&gt;&gt;? If I were the 'optional',=
 I would not mind to state
<br>&gt;&gt; -- I am only handling values; if you want to handle references=
, talk to
<br>&gt;&gt; boost::ref/reference_wrapper and take all your concerns there.=
 That'd take
<br>&gt;&gt; that whole debate out of the 'optional' camp and we'd enjoy pe=
ace and quiet
<br>&gt;&gt; and clean/orthogonal implementation of 'optional'.
<br>&gt;
<br>&gt; Actually, boost::ref is a function (template), the corresponding c=
lass
<br>&gt; template is boost::reference_wrapper.
<br>
<br>Indeed. Well noted. Apologies for being lazy/inaccurate.
<br>
<br>&gt; I am pretty sure
<br>&gt; optional&lt;boost::reference_<wbr>wrapper&lt;T&gt;&gt; would work,=
 but Boost users need not
<br>&gt; check it because they have boost::optional&lt;T&amp;&gt; with exac=
tly these semantics
<br>&gt; (and rebinding copy-assignment).
<br>
<br>Uhm, forgive me but my reading of boost::reference_wrapper&lt;T&gt; is =
that
<br>it does not provide rebinding copy-assignment. Providing that alters
<br>behavior dramatically IMO and, therefore, quite far from "exactly
<br>these semantics". I must be missing something fundamental but in all
<br>honesty rebinding copy-assignment with regard to references sounds
<br>quite sinful to me.
<br></blockquote><div><br>Now I apologize. I was too quick in my reply. I c=
hecked and boost::reference_wrapper does not provide copy assignment. (I am=
 not sure if T's copy-assignment) is used implicitly). However, std::refere=
nce_wrapper does appear to have a rebinding copy-assignment (see 20.8.3.2).=
<br>&nbsp;<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; You are right here: optional refs can be
<br>&gt; fairly easily emulated. So providing a cleaner interface for it is=
 of
<br>&gt; secondary importance (IMO), given optional refs will be used rarel=
y.
<br>
<br>If it is indeed so, i.e. "optional refs can be fairly easily
<br>emulated.", then why bother in the first place? Why not keep optional
<br>lean, clean, minimal, functionally-orthogonal?.. for the time being
<br>anyway... Easier to get through the committee. :-)
<br></blockquote><div><br>This is our current plan: propose only optional v=
alues for now, and move optional refs till later (which may turn out to be =
never).&nbsp; <br></div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt;&gt; No? Too perfect a picture to be true? Forgive me as I am still=
 under the
<br>&gt;&gt; influence of pudding/turkey/... And Merry Christmas for those =
who celebrate
<br>&gt;&gt; one.
<br>&gt;
<br>&gt; Not too perfect. I think this is our plans currently reflect: firs=
t only
<br>&gt; propose optional values, then think of optional refs (if people th=
ink they
<br>&gt; are still needed).
<br>
<br>But you are not exactly proposing optional values only, are you? The
<br>rev.2 proposal does contain "Optional references" chapter, does not
<br>it? Given the situation with opt. refs (as I understand it) that
<br>mentioning of opt. refs might be that loose end that, when pulled,
<br>might unravel (make trouble for) the whole proposal. Just an old man
<br>being overly cautious.
<br></blockquote><div><br>This is true for revision 2. Revision 3 will drop=
 them.<br><br>Regards,<br>&amp;rzej <br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_6_15568709.1356280173701--

.

On Mon, Dec 24, 2012 at 3:29 AM, Andrzej Krzemie=F1ski <akrzemi1@gmail.com>=
 wrote:
> W dniu niedziela, 23 grudnia 2012 11:13:55 UTC+1 u=BFytkownik Vladimir Ba=
tov
> napisa=B3:
>>
>> ... I imagined using func(optional<foo
>> const&>) as an "optional" complement for the ubiquitous func(foo
>> const&) instead of resorting to func(foo const*) which is not as clean
>> and fool-proof. I certainly cannot agree with some insisting that
>> func(foo const*) does as good a job as func(optional<foo const&>).
>
> I did use optional references in production code exactly for this purpose=
:
> optional arguments to functions. And I found that for this usage I never
> needed optional<T&> to be assignable or comparable. Therefore I considere=
d
> #2 an acceptable choice. It is limited, but given the usage above, you wo=
uld
> never notice this fact.

I've seen a lot and I am still seeing plenty of functions returning
values the Pascal-style -- func(T&). Like it or not it's here to stay.
If so, then for fun(optional<T&>) we'd need optional<T&>::operator=3D(T
const&), right? And with regard to that assignment's behavior you
summed it up (in the proposal v2) succinctly --  Optional reference
can be seen as a reference with postponed initialization. Although for
me an optional reference *is* a reference with postponed
initialization. To me the 'optional' class is all about "postponed
initialization". That is *the* quality/property that optional
specifically brings to the table. That property drives the behavior.
Therefore, optional<T> contains a value with postponed initialization
and optional<T&> contains a reference with postponed initialization.
Therefore, an optional<T&>::operator(T const&) to an engaged optional
reference should have deep copy semantics. IMO giving seemingly equal
weight (in the proposal v2) to the "alternative" view -- "an optional
reference can be seen as a pointer with different syntax" -- is wrong.

>> > The most fundamental problem with #3 is the semantics of its
>> > copy-assignment. Should it be deep (non-rebinding a reference) or
>> > shallow
>> > (rebinding). Both cause some confusion.
>>
>> My thinking'd be along the following lines. The value object inside
>> optional<T> behaves as a full-fledged value as it's expected from a
>> value object. Then, I'd fully expect the reference object inside
>> optional<T&> to behave as a reference, i.e. deep copy. I must be
>> missing something but I can not understand what possibly might be
>> confusing about a reference (inside optional) behaving like a
>> reference.
>
> Given two optional references 'p' and 'q', you would expect:
>
> p =3D q;
>
> to have exactly same semantics as:
>
> p =3D nullopt;
> p =3D q;
>
> This can only be achieved with rebinding semantics.

As you noted in one of your other posts a regular reference is shallow
created/initialized and deeply assigned/copied. I'd expect
optional<T&> to preserve that behavior... with regard to the
underlying object (which happens to be a reference)... but not with
regard to itself... because optional<T&> is not a reference but an
object. If so, then

int v1 =3D 1;
int v2 =3D 2;
optional<int&> o1; // an opt. ref with delayed initialization created
optional<int&> o2; // ditto
o1 =3D v1; // shallow initialization for the underlying reference as
regular refs do
o2 =3D v2; // ditto
o1 =3D v2; // deep assignment for the underlying reference as regular refs =
do
o1 =3D o2; // "bitwise copy" as objects do! Looks like shallow
assignment for the underlying reference.
o1 =3D nullopt; // there is nothing to rebind to; same as a regular ref.
going out of scope

The subtlety (surprise?) might be in "o1 =3D o2". Here optional<T&>
behaves as a regular object because that's what it is. We are not
rebinding o1. We are replacing it, i.e. the original content of o1 is
destroyed (as it's a reference, it's merely forgotten) and replaced
with the content of o2. With regard to the underlying reference it
appears (!) like a rebinding even though it is coincidental. What am I
missing?

>> > I am pretty sure
>> > optional<boost::reference_wrapper<T>> would work, but Boost users need
>> > not
>> > check it because they have boost::optional<T&> with exactly these
>> > semantics
>> > (and rebinding copy-assignment).
>>
>> ... my reading of boost::reference_wrapper<T> is that
>> it does not provide rebinding copy-assignment...
>
> ... However, std::reference_wrapper
> does appear to have a rebinding copy-assignment (see 20.8.3.2).

It does indeed! Since C++11!.. After initial shock :-) I calmed down,
thought about it and re-worked my replies above. Thank you for
pointing it out. IMO that is a subtle but important thing/distinction
to remember -- ref_wrapper (and optionalT&>) are actual real objects
(!) and behave as such in

ref_wrapper(ref_wrapper const&)
ref_wrapper& operator=3D(ref_wrapper const&)

To re-phrase a beaten-up clich=E9 -- these classes are as close to the
real thing as possible but not closer. :-)

V.

--=20




.

On 21/12/12 07:07, Andrzej Krzemie=C5=84ski wrote:
> Hi Everybody,
> We have decided to re-heat the discussion about optional references. It
> has become the most (and only) controversial point in std::optional's
> proposal, and we feel it needs to be addressed. Taking the lesson from
> the threads proposal (which was adopted only after the controversial
> thread interruption was removed from it), we are considering splitting
> the proposal into two: one for optional values, the other for optional
> references. The former appears clean, neat, well understood and very
> useful. The latter is controversial, unintuitive and is needed less
> often. This way we can guarantee the adoption of optional values early
> (perhaps 2014) and still buy some time for deciding on optional
> references' semantics. Recent discussion on hashing showed that these
> semantics are still unstable.
>=20
> I can name the following options for optional references:
>=20
>  1. Not provide them at all (this may in fact be the consequence of
>     splitting the proposals)
>  2. Provide them with a very limited interface (as in N3406
>     <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3406.html>)
>  3. Provide  rich interface for optional refs (equality, hash,
>     assignment, etc...) with deep value semantics wherever possible
>  4. Provide pointer-like semantics
>  5. Provide some hybrid of 3 and 4.
>=20
> I personally happened to use boost::optional<T&> at times and found it
> useful for function arguments. In my usages I never needed comparison,
> hashing, "genericity", or assignment, so option 2 is fine with me.
>=20
> Feel free to express your preference, but please give your rationale and
> practical use-cases with it. If we cannot reach an agreement, we will
> resort to arbitrarily selecting either option 1 or 4.

My vote is for #2, as the maximal non-confusing interface, with an
option to extend if future use makes one of the later options obviously
preferable.

As mentioned elsewhere, this offers optional<T&> as a useful and clear
way to expose particular semantics in a function interface (in place of
the potentially confusing T*).  I have seen use cases for this in real
life, but have not yet encountered anything requiring assignment of
optional refs.

John Bytheway

--=20




.