------=_Part_1225_1877930151.1540375766612
Content-Type: multipart/alternative;
 boundary="----=_Part_1226_325857050.1540375766613"

------=_Part_1226_325857050.1540375766613
Content-Type: text/plain; charset="UTF-8"

Hello, consider the following point of view

std::string is to char*, what is std::unique_ptr<T> to T* (minus copying)

To write an interface that accepts strings (pre C++17) it is acceptable to
write

void f(const char*);
void f(const std::string&);

To write an interface that accepts T it is acceptable to write

void f(const T*);
void f(const T&);

It is NOT acceptable to write void f(const std::unique_ptr<T>&); as the
interface becomes dependent on how the object is stored.

There are two problems here,
 - first we give advice that contradicts the string example (the interface
is depend on how the string is stored)
 - second writing a void f(const std::unique_ptr<T>&); *actually buys
something*, it buys us transparent interface - that is why people do it!.

Enter C++17

The string situation is *further *improved

void f(std::string_view);

We can do what we preach and have an interface that does not depend on how
the string is stored while at the same time keep the interface transparent
on the call site.

The situation with objects is unchanged.

But does it have to be that way? Why not have

void f(observer_ptr<const X>);

*instead of *

void f(const T*);

*AND*

let std::unique_ptr<X> *implicitly *convert to observer_ptr<X>

This will closely match the behavior of std::string -
Both will now have A) raw storage form B) managed storage form C) observing
form.

In both raw storage is explicit call, however observing is implicit
conversion.

Because observer_ptr does not convert to raw pointer, it will be safe to
use even with old APIs that might do manual lifetime management

void friendly(observer_ptr<C> c) { if(c) std::cout<<*c<<'\n'; }
void evil(C* c){ delete c; }

auto c = std::make_unique<C>();

friendly(c); //< happy, transparent usage

evil(c); //< nope

auto p = observer_ptr(c);

evil(p); //< nope


We will hit multiple birds
 - Have consistency with other std objects that do or will use a view form
 - Give perfect alternative for writing interfaces that take managing smart
pointers only to use the managed object
 - Find observer_ptr a meaning for existence, way and beyond "documenting
usage".

Thoughts? Any downsides I missed?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/81a04b52-e5cd-4543-86c5-5a0068f9647b%40isocpp.org.

------=_Part_1226_325857050.1540375766613
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello, consider the following point of view<div><br></div>=
<div><font face=3D"courier new, monospace">std::string </font>is to=C2=A0<f=
ont face=3D"courier new, monospace">char*</font>, what is <font face=3D"cou=
rier new, monospace">std::unique_ptr&lt;T&gt; </font>to <font face=3D"couri=
er new, monospace">T* </font><font face=3D"arial, sans-serif">(minus copyin=
g)</font></div><div><br></div><div>To write an interface that accepts strin=
gs (pre C++17) it is acceptable to write</div><div><br></div><div><font fac=
e=3D"courier new, monospace">void f(const char*);</font></div><div><font fa=
ce=3D"courier new, monospace">void f(const std::string&amp;);</font></div><=
div><br></div><div>To write an interface that accepts T it is acceptable to=
 write</div><div><font face=3D"courier new, monospace"><br></font></div><di=
v><div><font face=3D"courier new, monospace">void f(const T*);</font></div>=
<div><font face=3D"courier new, monospace">void f(const T&amp;);</font></di=
v></div><div><br></div><div><font face=3D"arial, sans-serif">It is NOT acce=
ptable to write=C2=A0</font><span style=3D"font-family: &quot;courier new&q=
uot;, monospace;">void f(const=C2=A0</span><span style=3D"font-family: &quo=
t;courier new&quot;, monospace;">std::unique_ptr&lt;T&gt;&amp;</span><span =
style=3D"font-family: &quot;courier new&quot;, monospace;">); </span><font =
face=3D"arial, sans-serif">as the interface becomes dependent on how the ob=
ject is stored.</font></div><div><font face=3D"arial, sans-serif"><br></fon=
t></div><div><font face=3D"arial, sans-serif">There are two problems here,=
=C2=A0</font></div><div><font face=3D"arial, sans-serif">=C2=A0- first we g=
ive advice that contradicts the string example (the interface is depend=C2=
=A0on how the string is stored)</font></div><div><font face=3D"arial, sans-=
serif">=C2=A0- second writing a=C2=A0</font><span style=3D"font-family: &qu=
ot;courier new&quot;, monospace;">void f(const=C2=A0</span><span style=3D"f=
ont-family: &quot;courier new&quot;, monospace;">std::unique_ptr&lt;T&gt;&a=
mp;</span><span style=3D"font-family: &quot;courier new&quot;, monospace;">=
); </span><font face=3D"arial, sans-serif"><i>actually buys something</i>, =
it buys us transparent interface - that is why people do it!.</font></div><=
div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"ar=
ial, sans-serif">Enter C++17</font></div><div><font face=3D"arial, sans-ser=
if"><br></font></div><div><font face=3D"arial, sans-serif">The string situa=
tion=C2=A0is <i>further </i>improved=C2=A0</font></div><div><font face=3D"a=
rial, sans-serif"><br></font></div><div><span style=3D"font-family: &quot;c=
ourier new&quot;, monospace;">void f(std::string_view);</span><font face=3D=
"arial, sans-serif"><br></font></div><div><span style=3D"font-family: &quot=
;courier new&quot;, monospace;"><br></span></div><div><font face=3D"arial, =
sans-serif">We can do what we preach and have an interface that does not de=
pend on how the string is stored while at the same time keep the interface =
transparent on the call site.</font></div><div><font face=3D"arial, sans-se=
rif"><br></font></div><div><font face=3D"arial, sans-serif">The situation w=
ith objects is unchanged.=C2=A0</font></div><div><font face=3D"arial, sans-=
serif"><br></font></div><div><font face=3D"arial, sans-serif">But does it h=
ave to be that way? Why not have=C2=A0</font></div><div><font face=3D"arial=
, sans-serif"><br></font></div><div><font face=3D"courier new, monospace">v=
oid f(observer_ptr&lt;const X&gt;);</font><font face=3D"arial, sans-serif">=
<br></font></div><div><font face=3D"courier new, monospace"><br></font></di=
v><font face=3D"arial, sans-serif"><i>instead of </i></font><div><font face=
=3D"arial, sans-serif"><i><br></i></font></div><div><span style=3D"font-fam=
ily: &quot;courier new&quot;, monospace;">void f(const T*);</span><font fac=
e=3D"arial, sans-serif"><i><br></i></font></div><div><span style=3D"font-fa=
mily: &quot;courier new&quot;, monospace;"><br></span></div><div><font face=
=3D"arial, sans-serif"><b>AND</b></font></div><div><span style=3D"font-fami=
ly: &quot;courier new&quot;, monospace;"><br></span></div><div><font face=
=3D"arial, sans-serif">let </font><font face=3D"courier new, monospace">std=
::unique_ptr&lt;X&gt;</font><font face=3D"arial, sans-serif"> <b>implicitly=
=C2=A0</b>convert to=C2=A0</font><span style=3D"font-family: &quot;courier =
new&quot;, monospace;">observer_ptr&lt;X&gt;</span></div><div><font face=3D=
"arial, sans-serif"><br></font></div><div><font face=3D"arial, sans-serif">=
This will closely=C2=A0match the behavior of </font><font face=3D"courier n=
ew, monospace">std::string -=C2=A0</font></div><div><font face=3D"arial, sa=
ns-serif">Both will now have A) raw storage form B) managed storage form C)=
 observing form.=C2=A0</font></div><div><font face=3D"arial, sans-serif"><b=
r></font></div><div><font face=3D"arial, sans-serif">In both=C2=A0raw stora=
ge is explicit call, however observing is implicit conversion.=C2=A0=C2=A0<=
/font></div><div><font face=3D"arial, sans-serif"><br></font></div><div><fo=
nt face=3D"arial, sans-serif">Because=C2=A0</font><span style=3D"font-famil=
y: &quot;courier new&quot;, monospace;">observer_ptr </span><font face=3D"a=
rial, sans-serif">does not convert to raw pointer, it will be safe to use e=
ven with old APIs that might do manual=C2=A0lifetime management</font></div=
><div><br></div><div><font face=3D"courier new, monospace">void friendly(ob=
server_ptr&lt;C&gt; c) { if(c) std::cout&lt;&lt;*c&lt;&lt;&#39;\n&#39;; }</=
font></div><div><font face=3D"courier new, monospace">void evil(C* c){ dele=
te c; }</font></div><div><font face=3D"courier new, monospace"><br></font><=
/div><div><font face=3D"courier new, monospace">auto c =3D std::make_unique=
&lt;C&gt;();</font></div><div><font face=3D"courier new, monospace"><br></f=
ont></div><div><span style=3D"font-family: &quot;courier new&quot;, monospa=
ce;">friendly(c); //&lt; happy, transparent usage</span><font face=3D"couri=
er new, monospace"><br></font></div><div><span style=3D"font-family: &quot;=
courier new&quot;, monospace;"><br></span></div><div><span style=3D"font-fa=
mily: &quot;courier new&quot;, monospace;">evil(c); //&lt; nope</span><span=
 style=3D"font-family: &quot;courier new&quot;, monospace;"><br></span></di=
v><div><br></div><div><span style=3D"font-family: &quot;courier new&quot;, =
monospace;">auto p =3D observer_ptr(c);</span><font face=3D"courier new, mo=
nospace"><br></font></div><div><span style=3D"font-family: &quot;courier ne=
w&quot;, monospace;"><br></span></div><div><span style=3D"font-family: &quo=
t;courier new&quot;, monospace;">evil(p); //&lt; nope</span><span style=3D"=
font-family: &quot;courier new&quot;, monospace;"><br></span></div><div><sp=
an style=3D"font-family: &quot;courier new&quot;, monospace;"><br></span></=
div><div><span style=3D"font-family: &quot;courier new&quot;, monospace;"><=
br></span></div><div><font face=3D"arial, sans-serif">We will hit multiple =
birds=C2=A0</font></div><div><font face=3D"arial, sans-serif">=C2=A0- Have =
consistency=C2=A0with other std objects that do or will use a view form</fo=
nt></div><div><font face=3D"arial, sans-serif">=C2=A0- Give perfect alterna=
tive for writing interfaces that take managing smart pointers only to use t=
he managed object</font></div><div><font face=3D"arial, sans-serif">=C2=A0-=
 Find observer_ptr a meaning for existence, way and beyond &quot;documentin=
g usage&quot;.=C2=A0</font></div><div><span style=3D"font-family: &quot;cou=
rier new&quot;, monospace;"><br></span></div><div><font face=3D"arial, sans=
-serif">Thoughts? Any downsides I missed?</font></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/81a04b52-e5cd-4543-86c5-5a0068f9647b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/81a04b52-e5cd-4543-86c5-5a0068f9647b=
%40isocpp.org</a>.<br />

------=_Part_1226_325857050.1540375766613--

------=_Part_1225_1877930151.1540375766612--

.

--0000000000007e61370578f7799b
Content-Type: text/plain; charset="UTF-8"

Any object that can be represented in a function call interface as
observer_ptr<T> can be equally correctly represented as T&.

Why wouldn't I just write my interfaces in terms of references? Wouldn't
that give me more flexibility? consider:

#include <optional>
#include <memory>

struct Foo
{
};

void foo_thing(Foo& f)
{
}

void test()
{
  auto a = std::optional<Foo>({});
  auto b = std::make_unique<Foo>();
  auto c = std::make_shared<Foo>();

  foo_thing(*a);
  foo_thing(*b);
  foo_thing(*c);
}

If I wanted to take copies of that reference, std::reference_wrapper<Foo>
would also be an acceptable argument type.



On Wed, 24 Oct 2018 at 12:09, <mihailnajdenov@gmail.com> wrote:

> Hello, consider the following point of view
>
> std::string is to char*, what is std::unique_ptr<T> to T* (minus copying)
>
> To write an interface that accepts strings (pre C++17) it is acceptable to
> write
>
> void f(const char*);
> void f(const std::string&);
>
> To write an interface that accepts T it is acceptable to write
>
> void f(const T*);
> void f(const T&);
>
> It is NOT acceptable to write void f(const std::unique_ptr<T>&); as the
> interface becomes dependent on how the object is stored.
>
> There are two problems here,
>  - first we give advice that contradicts the string example (the interface
> is depend on how the string is stored)
>  - second writing a void f(const std::unique_ptr<T>&); *actually buys
> something*, it buys us transparent interface - that is why people do it!.
>
> Enter C++17
>
> The string situation is *further *improved
>
> void f(std::string_view);
>
> We can do what we preach and have an interface that does not depend on how
> the string is stored while at the same time keep the interface transparent
> on the call site.
>
> The situation with objects is unchanged.
>
> But does it have to be that way? Why not have
>
> void f(observer_ptr<const X>);
>
> *instead of *
>
> void f(const T*);
>
> *AND*
>
> let std::unique_ptr<X> *implicitly *convert to observer_ptr<X>
>
> This will closely match the behavior of std::string -
> Both will now have A) raw storage form B) managed storage form C)
> observing form.
>
> In both raw storage is explicit call, however observing is implicit
> conversion.
>
> Because observer_ptr does not convert to raw pointer, it will be safe to
> use even with old APIs that might do manual lifetime management
>
> void friendly(observer_ptr<C> c) { if(c) std::cout<<*c<<'\n'; }
> void evil(C* c){ delete c; }
>
> auto c = std::make_unique<C>();
>
> friendly(c); //< happy, transparent usage
>
> evil(c); //< nope
>
> auto p = observer_ptr(c);
>
> evil(p); //< nope
>
>
> We will hit multiple birds
>  - Have consistency with other std objects that do or will use a view form
>  - Give perfect alternative for writing interfaces that take managing
> smart pointers only to use the managed object
>  - Find observer_ptr a meaning for existence, way and beyond "documenting
> usage".
>
> Thoughts? Any downsides I missed?
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/81a04b52-e5cd-4543-86c5-5a0068f9647b%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/81a04b52-e5cd-4543-86c5-5a0068f9647b%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3ha%3DUjXBOM4KnqC7G9Pk%2BmH_UmdPyW4EWNb0vwD4poLndQ%40mail.gmail.com.

--0000000000007e61370578f7799b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Any object that can be represented in a function call inte=
rface as observer_ptr&lt;T&gt; can be equally correctly represented as T&am=
p;.<div></div><div><br></div><div>Why wouldn&#39;t I just write my interfac=
es in terms of references? Wouldn&#39;t that give me more flexibility? cons=
ider:</div><div><br></div><div><div style=3D"color:rgb(0,0,0);background-co=
lor:rgb(255,255,254)"><div><font face=3D"monospace, monospace"><span style=
=3D"color:rgb(0,0,255)">#include</span> &lt;optional&gt;</font></div><div><=
font face=3D"monospace, monospace"><span style=3D"color:rgb(0,0,255)">#incl=
ude</span> &lt;memory&gt;</font></div><font face=3D"monospace, monospace"><=
br></font><div><font face=3D"monospace, monospace"><span style=3D"color:rgb=
(0,0,255)">struct</span> Foo</font></div><div><font face=3D"monospace, mono=
space">{</font></div><div><font face=3D"monospace, monospace">};</font></di=
v><font face=3D"monospace, monospace"><br></font><div><font face=3D"monospa=
ce, monospace"><span style=3D"color:rgb(0,0,255)">void</span> foo_thing(Foo=
&amp; f)</font></div><div><font face=3D"monospace, monospace">{</font></div=
><div><font face=3D"monospace, monospace">}</font></div><font face=3D"monos=
pace, monospace"><br></font><div><font face=3D"monospace, monospace"><span =
style=3D"color:rgb(0,0,255)">void</span> test()</font></div><div><font face=
=3D"monospace, monospace">{</font></div><div>    <font face=3D"monospace, m=
onospace"><span style=3D"color:rgb(0,0,255)">=C2=A0 auto</span> a =3D std::=
optional&lt;Foo&gt;({});</font></div><div>    <font face=3D"monospace, mono=
space"><span style=3D"color:rgb(0,0,255)">=C2=A0 auto</span> b =3D std::mak=
e_unique&lt;Foo&gt;();</font></div><div>    <font face=3D"monospace, monosp=
ace"><span style=3D"color:rgb(0,0,255)">=C2=A0 auto</span> c =3D std::make_=
shared&lt;Foo&gt;();</font></div><font face=3D"monospace, monospace"><br></=
font><div><font face=3D"monospace, monospace">=C2=A0 foo_thing(*a);</font><=
/div><div><font face=3D"monospace, monospace">=C2=A0 foo_thing(*b);</font><=
/div><div><font face=3D"monospace, monospace">=C2=A0 foo_thing(*c);</font><=
/div><div><font face=3D"monospace, monospace">}</font></div><br></div></div=
><div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,254)">If I wan=
ted to take copies of that reference, std::reference_wrapper&lt;Foo&gt; wou=
ld also be an acceptable argument type.</div><div style=3D"color:rgb(0,0,0)=
;background-color:rgb(255,255,254)"><br></div><div style=3D"color:rgb(0,0,0=
);background-color:rgb(255,255,254)"><br></div></div><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr">On Wed, 24 Oct 2018 at 12:09, &lt;<a href=3D"mail=
to:mihailnajdenov@gmail.com">mihailnajdenov@gmail.com</a>&gt; wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hello, consider the foll=
owing point of view<div><br></div><div><font face=3D"courier new, monospace=
">std::string </font>is to=C2=A0<font face=3D"courier new, monospace">char*=
</font>, what is <font face=3D"courier new, monospace">std::unique_ptr&lt;T=
&gt; </font>to <font face=3D"courier new, monospace">T* </font><font face=
=3D"arial, sans-serif">(minus copying)</font></div><div><br></div><div>To w=
rite an interface that accepts strings (pre C++17) it is acceptable to writ=
e</div><div><br></div><div><font face=3D"courier new, monospace">void f(con=
st char*);</font></div><div><font face=3D"courier new, monospace">void f(co=
nst std::string&amp;);</font></div><div><br></div><div>To write an interfac=
e that accepts T it is acceptable to write</div><div><font face=3D"courier =
new, monospace"><br></font></div><div><div><font face=3D"courier new, monos=
pace">void f(const T*);</font></div><div><font face=3D"courier new, monospa=
ce">void f(const T&amp;);</font></div></div><div><br></div><div><font face=
=3D"arial, sans-serif">It is NOT acceptable to write=C2=A0</font><span styl=
e=3D"font-family:&quot;courier new&quot;,monospace">void f(const=C2=A0</spa=
n><span style=3D"font-family:&quot;courier new&quot;,monospace">std::unique=
_ptr&lt;T&gt;&amp;</span><span style=3D"font-family:&quot;courier new&quot;=
,monospace">); </span><font face=3D"arial, sans-serif">as the interface bec=
omes dependent on how the object is stored.</font></div><div><font face=3D"=
arial, sans-serif"><br></font></div><div><font face=3D"arial, sans-serif">T=
here are two problems here,=C2=A0</font></div><div><font face=3D"arial, san=
s-serif">=C2=A0- first we give advice that contradicts the string example (=
the interface is depend=C2=A0on how the string is stored)</font></div><div>=
<font face=3D"arial, sans-serif">=C2=A0- second writing a=C2=A0</font><span=
 style=3D"font-family:&quot;courier new&quot;,monospace">void f(const=C2=A0=
</span><span style=3D"font-family:&quot;courier new&quot;,monospace">std::u=
nique_ptr&lt;T&gt;&amp;</span><span style=3D"font-family:&quot;courier new&=
quot;,monospace">); </span><font face=3D"arial, sans-serif"><i>actually buy=
s something</i>, it buys us transparent interface - that is why people do i=
t!.</font></div><div><font face=3D"arial, sans-serif"><br></font></div><div=
><font face=3D"arial, sans-serif">Enter C++17</font></div><div><font face=
=3D"arial, sans-serif"><br></font></div><div><font face=3D"arial, sans-seri=
f">The string situation=C2=A0is <i>further </i>improved=C2=A0</font></div><=
div><font face=3D"arial, sans-serif"><br></font></div><div><span style=3D"f=
ont-family:&quot;courier new&quot;,monospace">void f(std::string_view);</sp=
an><font face=3D"arial, sans-serif"><br></font></div><div><span style=3D"fo=
nt-family:&quot;courier new&quot;,monospace"><br></span></div><div><font fa=
ce=3D"arial, sans-serif">We can do what we preach and have an interface tha=
t does not depend on how the string is stored while at the same time keep t=
he interface transparent on the call site.</font></div><div><font face=3D"a=
rial, sans-serif"><br></font></div><div><font face=3D"arial, sans-serif">Th=
e situation with objects is unchanged.=C2=A0</font></div><div><font face=3D=
"arial, sans-serif"><br></font></div><div><font face=3D"arial, sans-serif">=
But does it have to be that way? Why not have=C2=A0</font></div><div><font =
face=3D"arial, sans-serif"><br></font></div><div><font face=3D"courier new,=
 monospace">void f(observer_ptr&lt;const X&gt;);</font><font face=3D"arial,=
 sans-serif"><br></font></div><div><font face=3D"courier new, monospace"><b=
r></font></div><font face=3D"arial, sans-serif"><i>instead of </i></font><d=
iv><font face=3D"arial, sans-serif"><i><br></i></font></div><div><span styl=
e=3D"font-family:&quot;courier new&quot;,monospace">void f(const T*);</span=
><font face=3D"arial, sans-serif"><i><br></i></font></div><div><span style=
=3D"font-family:&quot;courier new&quot;,monospace"><br></span></div><div><f=
ont face=3D"arial, sans-serif"><b>AND</b></font></div><div><span style=3D"f=
ont-family:&quot;courier new&quot;,monospace"><br></span></div><div><font f=
ace=3D"arial, sans-serif">let </font><font face=3D"courier new, monospace">=
std::unique_ptr&lt;X&gt;</font><font face=3D"arial, sans-serif"> <b>implici=
tly=C2=A0</b>convert to=C2=A0</font><span style=3D"font-family:&quot;courie=
r new&quot;,monospace">observer_ptr&lt;X&gt;</span></div><div><font face=3D=
"arial, sans-serif"><br></font></div><div><font face=3D"arial, sans-serif">=
This will closely=C2=A0match the behavior of </font><font face=3D"courier n=
ew, monospace">std::string -=C2=A0</font></div><div><font face=3D"arial, sa=
ns-serif">Both will now have A) raw storage form B) managed storage form C)=
 observing form.=C2=A0</font></div><div><font face=3D"arial, sans-serif"><b=
r></font></div><div><font face=3D"arial, sans-serif">In both=C2=A0raw stora=
ge is explicit call, however observing is implicit conversion.=C2=A0=C2=A0<=
/font></div><div><font face=3D"arial, sans-serif"><br></font></div><div><fo=
nt face=3D"arial, sans-serif">Because=C2=A0</font><span style=3D"font-famil=
y:&quot;courier new&quot;,monospace">observer_ptr </span><font face=3D"aria=
l, sans-serif">does not convert to raw pointer, it will be safe to use even=
 with old APIs that might do manual=C2=A0lifetime management</font></div><d=
iv><br></div><div><font face=3D"courier new, monospace">void friendly(obser=
ver_ptr&lt;C&gt; c) { if(c) std::cout&lt;&lt;*c&lt;&lt;&#39;\n&#39;; }</fon=
t></div><div><font face=3D"courier new, monospace">void evil(C* c){ delete =
c; }</font></div><div><font face=3D"courier new, monospace"><br></font></di=
v><div><font face=3D"courier new, monospace">auto c =3D std::make_unique&lt=
;C&gt;();</font></div><div><font face=3D"courier new, monospace"><br></font=
></div><div><span style=3D"font-family:&quot;courier new&quot;,monospace">f=
riendly(c); //&lt; happy, transparent usage</span><font face=3D"courier new=
, monospace"><br></font></div><div><span style=3D"font-family:&quot;courier=
 new&quot;,monospace"><br></span></div><div><span style=3D"font-family:&quo=
t;courier new&quot;,monospace">evil(c); //&lt; nope</span><span style=3D"fo=
nt-family:&quot;courier new&quot;,monospace"><br></span></div><div><br></di=
v><div><span style=3D"font-family:&quot;courier new&quot;,monospace">auto p=
 =3D observer_ptr(c);</span><font face=3D"courier new, monospace"><br></fon=
t></div><div><span style=3D"font-family:&quot;courier new&quot;,monospace">=
<br></span></div><div><span style=3D"font-family:&quot;courier new&quot;,mo=
nospace">evil(p); //&lt; nope</span><span style=3D"font-family:&quot;courie=
r new&quot;,monospace"><br></span></div><div><span style=3D"font-family:&qu=
ot;courier new&quot;,monospace"><br></span></div><div><span style=3D"font-f=
amily:&quot;courier new&quot;,monospace"><br></span></div><div><font face=
=3D"arial, sans-serif">We will hit multiple birds=C2=A0</font></div><div><f=
ont face=3D"arial, sans-serif">=C2=A0- Have consistency=C2=A0with other std=
 objects that do or will use a view form</font></div><div><font face=3D"ari=
al, sans-serif">=C2=A0- Give perfect alternative for writing interfaces tha=
t take managing smart pointers only to use the managed object</font></div><=
div><font face=3D"arial, sans-serif">=C2=A0- Find observer_ptr a meaning fo=
r existence, way and beyond &quot;documenting usage&quot;.=C2=A0</font></di=
v><div><span style=3D"font-family:&quot;courier new&quot;,monospace"><br></=
span></div><div><font face=3D"arial, sans-serif">Thoughts? Any downsides I =
missed?</font></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/81a04b52-e5cd-4543-86c5-5a0068f9647b%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/81a04b52-e5cd-=
4543-86c5-5a0068f9647b%40isocpp.org</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3ha%3DUjXBOM4KnqC7G9Pk%2BmH_UmdP=
yW4EWNb0vwD4poLndQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3ha%3DUj=
XBOM4KnqC7G9Pk%2BmH_UmdPyW4EWNb0vwD4poLndQ%40mail.gmail.com</a>.<br />

--0000000000007e61370578f7799b--

.

------=_Part_133_1142968382.1540417769286
Content-Type: multipart/alternative;
 boundary="----=_Part_134_877816140.1540417769286"

------=_Part_134_877816140.1540417769286
Content-Type: text/plain; charset="UTF-8"



> Any object that can be represented in a function call interface as
> observer_ptr<T> can be equally correctly represented as T&.
>
>
Unless you want it to be nullable, in which case I think you need to do
something like std::optional<std::reference_wrapper<Foo>>.

Related: I really wish std::optional<T&> was allowed.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/eb06dfa7-74f0-4986-9cd1-3f85c395541a%40isocpp.org.

------=_Part_134_877816140.1540417769286
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><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">Any object that can be represented in a function call interface as=
 observer_ptr&lt;T&gt; can be equally correctly represented as T&amp;.<div>=
</div></div><br></blockquote><div><br></div><div>Unless you want it to be n=
ullable, in which case I think you need to do something like std::optional&=
lt;std::reference_wrapper&lt;Foo&gt;&gt;.</div><div><br></div><div>Related:=
 I really wish std::optional&lt;T&amp;&gt; was allowed. <br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/eb06dfa7-74f0-4986-9cd1-3f85c395541a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/eb06dfa7-74f0-4986-9cd1-3f85c395541a=
%40isocpp.org</a>.<br />

------=_Part_134_877816140.1540417769286--

------=_Part_133_1142968382.1540417769286--

.

--000000000000ed914505790095eb
Content-Type: text/plain; charset="UTF-8"

On Wed, Oct 24, 2018 at 6:09 AM <mihailnajdenov@gmail.com> wrote:

> Hello, consider the following point of view
>
> std::string is to char*, what is std::unique_ptr<T> to T* (minus copying)
>
> To write an interface that accepts strings (pre C++17) it is acceptable to
> write
>
> void f(const char*);
> void f(const std::string&);
>
> To write an interface that accepts T it is acceptable to write
>
> void f(const T*);
> void f(const T&);
>
> It is NOT acceptable to write void f(const std::unique_ptr<T>&); as the
> interface becomes dependent on how the object is stored.
>
> There are two problems here,
>  - first we give advice that contradicts the string example (the interface
> is depend on how the string is stored)
>  - second writing a void f(const std::unique_ptr<T>&); *actually buys
> something*, it buys us transparent interface - that is why people do it!.
>
> Enter C++17
>
> The string situation is *further *improved
>
> void f(std::string_view);
>
> We can do what we preach and have an interface that does not depend on how
> the string is stored while at the same time keep the interface transparent
> on the call site.
>
> The situation with objects is unchanged.
>
> But does it have to be that way? Why not have
>
> void f(observer_ptr<const X>);
>
> *instead of *
>
> void f(const T*);
>
> *AND*
>
> let std::unique_ptr<X> *implicitly *convert to observer_ptr<X>
>
> This will closely match the behavior of std::string -
> Both will now have A) raw storage form B) managed storage form C)
> observing form.
>
> In both raw storage is explicit call, however observing is implicit
> conversion.
>
> Because observer_ptr does not convert to raw pointer, it will be safe to
> use even with old APIs that might do manual lifetime management
>
> void friendly(observer_ptr<C> c) { if(c) std::cout<<*c<<'\n'; }
> void evil(C* c){ delete c; }
>
> auto c = std::make_unique<C>();
>
> friendly(c); //< happy, transparent usage
>
> evil(c); //< nope
>
> auto p = observer_ptr(c);
>
> evil(p); //< nope
>
>
> We will hit multiple birds
>  - Have consistency with other std objects that do or will use a view form
>  - Give perfect alternative for writing interfaces that take managing
> smart pointers only to use the managed object
>  - Find observer_ptr a meaning for existence, way and beyond "documenting
> usage".
>
> Thoughts? Any downsides I missed?
>


I agree with all of this, and, to me, it makes observer_ptr worth
standardizing.

Only question: observer_ptr is a terrible name, what should we call it.

--
Be seeing you,
Tony

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuqHGogymYhCxDGmQWVPegmZQjoOy738k9Ey6J%3DarCe7A%40mail.gmail.com.

--000000000000ed914505790095eb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed=
, Oct 24, 2018 at 6:09 AM &lt;<a href=3D"mailto:mihailnajdenov@gmail.com">m=
ihailnajdenov@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr">Hello, consider the following point of view<div><br></=
div><div><font face=3D"courier new, monospace">std::string </font>is to=C2=
=A0<font face=3D"courier new, monospace">char*</font>, what is <font face=
=3D"courier new, monospace">std::unique_ptr&lt;T&gt; </font>to <font face=
=3D"courier new, monospace">T* </font><font face=3D"arial, sans-serif">(min=
us copying)</font></div><div><br></div><div>To write an interface that acce=
pts strings (pre C++17) it is acceptable to write</div><div><br></div><div>=
<font face=3D"courier new, monospace">void f(const char*);</font></div><div=
><font face=3D"courier new, monospace">void f(const std::string&amp;);</fon=
t></div><div><br></div><div>To write an interface that accepts T it is acce=
ptable to write</div><div><font face=3D"courier new, monospace"><br></font>=
</div><div><div><font face=3D"courier new, monospace">void f(const T*);</fo=
nt></div><div><font face=3D"courier new, monospace">void f(const T&amp;);</=
font></div></div><div><br></div><div><font face=3D"arial, sans-serif">It is=
 NOT acceptable to write=C2=A0</font><span style=3D"font-family:&quot;couri=
er new&quot;,monospace">void f(const=C2=A0</span><span style=3D"font-family=
:&quot;courier new&quot;,monospace">std::unique_ptr&lt;T&gt;&amp;</span><sp=
an style=3D"font-family:&quot;courier new&quot;,monospace">); </span><font =
face=3D"arial, sans-serif">as the interface becomes dependent on how the ob=
ject is stored.</font></div><div><font face=3D"arial, sans-serif"><br></fon=
t></div><div><font face=3D"arial, sans-serif">There are two problems here,=
=C2=A0</font></div><div><font face=3D"arial, sans-serif">=C2=A0- first we g=
ive advice that contradicts the string example (the interface is depend=C2=
=A0on how the string is stored)</font></div><div><font face=3D"arial, sans-=
serif">=C2=A0- second writing a=C2=A0</font><span style=3D"font-family:&quo=
t;courier new&quot;,monospace">void f(const=C2=A0</span><span style=3D"font=
-family:&quot;courier new&quot;,monospace">std::unique_ptr&lt;T&gt;&amp;</s=
pan><span style=3D"font-family:&quot;courier new&quot;,monospace">); </span=
><font face=3D"arial, sans-serif"><i>actually buys something</i>, it buys u=
s transparent interface - that is why people do it!.</font></div><div><font=
 face=3D"arial, sans-serif"><br></font></div><div><font face=3D"arial, sans=
-serif">Enter C++17</font></div><div><font face=3D"arial, sans-serif"><br><=
/font></div><div><font face=3D"arial, sans-serif">The string situation=C2=
=A0is <i>further </i>improved=C2=A0</font></div><div><font face=3D"arial, s=
ans-serif"><br></font></div><div><span style=3D"font-family:&quot;courier n=
ew&quot;,monospace">void f(std::string_view);</span><font face=3D"arial, sa=
ns-serif"><br></font></div><div><span style=3D"font-family:&quot;courier ne=
w&quot;,monospace"><br></span></div><div><font face=3D"arial, sans-serif">W=
e can do what we preach and have an interface that does not depend on how t=
he string is stored while at the same time keep the interface transparent o=
n the call site.</font></div><div><font face=3D"arial, sans-serif"><br></fo=
nt></div><div><font face=3D"arial, sans-serif">The situation with objects i=
s unchanged.=C2=A0</font></div><div><font face=3D"arial, sans-serif"><br></=
font></div><div><font face=3D"arial, sans-serif">But does it have to be tha=
t way? Why not have=C2=A0</font></div><div><font face=3D"arial, sans-serif"=
><br></font></div><div><font face=3D"courier new, monospace">void f(observe=
r_ptr&lt;const X&gt;);</font><font face=3D"arial, sans-serif"><br></font></=
div><div><font face=3D"courier new, monospace"><br></font></div><font face=
=3D"arial, sans-serif"><i>instead of </i></font><div><font face=3D"arial, s=
ans-serif"><i><br></i></font></div><div><span style=3D"font-family:&quot;co=
urier new&quot;,monospace">void f(const T*);</span><font face=3D"arial, san=
s-serif"><i><br></i></font></div><div><span style=3D"font-family:&quot;cour=
ier new&quot;,monospace"><br></span></div><div><font face=3D"arial, sans-se=
rif"><b>AND</b></font></div><div><span style=3D"font-family:&quot;courier n=
ew&quot;,monospace"><br></span></div><div><font face=3D"arial, sans-serif">=
let </font><font face=3D"courier new, monospace">std::unique_ptr&lt;X&gt;</=
font><font face=3D"arial, sans-serif"> <b>implicitly=C2=A0</b>convert to=C2=
=A0</font><span style=3D"font-family:&quot;courier new&quot;,monospace">obs=
erver_ptr&lt;X&gt;</span></div><div><font face=3D"arial, sans-serif"><br></=
font></div><div><font face=3D"arial, sans-serif">This will closely=C2=A0mat=
ch the behavior of </font><font face=3D"courier new, monospace">std::string=
 -=C2=A0</font></div><div><font face=3D"arial, sans-serif">Both will now ha=
ve A) raw storage form B) managed storage form C) observing form.=C2=A0</fo=
nt></div><div><font face=3D"arial, sans-serif"><br></font></div><div><font =
face=3D"arial, sans-serif">In both=C2=A0raw storage is explicit call, howev=
er observing is implicit conversion.=C2=A0=C2=A0</font></div><div><font fac=
e=3D"arial, sans-serif"><br></font></div><div><font face=3D"arial, sans-ser=
if">Because=C2=A0</font><span style=3D"font-family:&quot;courier new&quot;,=
monospace">observer_ptr </span><font face=3D"arial, sans-serif">does not co=
nvert to raw pointer, it will be safe to use even with old APIs that might =
do manual=C2=A0lifetime management</font></div><div><br></div><div><font fa=
ce=3D"courier new, monospace">void friendly(observer_ptr&lt;C&gt; c) { if(c=
) std::cout&lt;&lt;*c&lt;&lt;&#39;\n&#39;; }</font></div><div><font face=3D=
"courier new, monospace">void evil(C* c){ delete c; }</font></div><div><fon=
t face=3D"courier new, monospace"><br></font></div><div><font face=3D"couri=
er new, monospace">auto c =3D std::make_unique&lt;C&gt;();</font></div><div=
><font face=3D"courier new, monospace"><br></font></div><div><span style=3D=
"font-family:&quot;courier new&quot;,monospace">friendly(c); //&lt; happy, =
transparent usage</span><font face=3D"courier new, monospace"><br></font></=
div><div><span style=3D"font-family:&quot;courier new&quot;,monospace"><br>=
</span></div><div><span style=3D"font-family:&quot;courier new&quot;,monosp=
ace">evil(c); //&lt; nope</span><span style=3D"font-family:&quot;courier ne=
w&quot;,monospace"><br></span></div><div><br></div><div><span style=3D"font=
-family:&quot;courier new&quot;,monospace">auto p =3D observer_ptr(c);</spa=
n><font face=3D"courier new, monospace"><br></font></div><div><span style=
=3D"font-family:&quot;courier new&quot;,monospace"><br></span></div><div><s=
pan style=3D"font-family:&quot;courier new&quot;,monospace">evil(p); //&lt;=
 nope</span><span style=3D"font-family:&quot;courier new&quot;,monospace"><=
br></span></div><div><span style=3D"font-family:&quot;courier new&quot;,mon=
ospace"><br></span></div><div><span style=3D"font-family:&quot;courier new&=
quot;,monospace"><br></span></div><div><font face=3D"arial, sans-serif">We =
will hit multiple birds=C2=A0</font></div><div><font face=3D"arial, sans-se=
rif">=C2=A0- Have consistency=C2=A0with other std objects that do or will u=
se a view form</font></div><div><font face=3D"arial, sans-serif">=C2=A0- Gi=
ve perfect alternative for writing interfaces that take managing smart poin=
ters only to use the managed object</font></div><div><font face=3D"arial, s=
ans-serif">=C2=A0- Find observer_ptr a meaning for existence, way and beyon=
d &quot;documenting usage&quot;.=C2=A0</font></div><div><span style=3D"font=
-family:&quot;courier new&quot;,monospace"><br></span></div><div><font face=
=3D"arial, sans-serif">Thoughts? Any downsides I missed?</font></div></div>=
</blockquote><div><br></div><div><br></div><div>I agree with all of this, a=
nd, to me, it makes observer_ptr worth standardizing.</div><div><br></div><=
div>Only question: observer_ptr is a terrible name, what should we call it.=
<br></div><div><br></div>-- <br></div><div dir=3D"ltr" class=3D"gmail_signa=
ture" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing yo=
u,<br></div>Tony<br></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuqHGogymYhCxDGmQWVPegmZQjoOy73=
8k9Ey6J%3DarCe7A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuqHGogym=
YhCxDGmQWVPegmZQjoOy738k9Ey6J%3DarCe7A%40mail.gmail.com</a>.<br />

--000000000000ed914505790095eb--

.

--000000000000fcd23f057900cc71
Content-Type: text/plain; charset="UTF-8"

On Wed, Oct 24, 2018 at 4:58 PM Tony V E <tvaneerd@gmail.com> wrote:

>
>
> On Wed, Oct 24, 2018 at 6:09 AM <mihailnajdenov@gmail.com> wrote:
>
>> Hello, consider the following point of view
>>
>> std::string is to char*, what is std::unique_ptr<T> to T* (minus copying)
>>
>> To write an interface that accepts strings (pre C++17) it is acceptable
>> to write
>>
>> void f(const char*);
>> void f(const std::string&);
>>
>> To write an interface that accepts T it is acceptable to write
>>
>> void f(const T*);
>> void f(const T&);
>>
>> It is NOT acceptable to write void f(const std::unique_ptr<T>&); as the
>> interface becomes dependent on how the object is stored.
>>
>> There are two problems here,
>>  - first we give advice that contradicts the string example (the
>> interface is depend on how the string is stored)
>>  - second writing a void f(const std::unique_ptr<T>&); *actually buys
>> something*, it buys us transparent interface - that is why people do it!.
>>
>> Enter C++17
>>
>> The string situation is *further *improved
>>
>> void f(std::string_view);
>>
>> We can do what we preach and have an interface that does not depend on
>> how the string is stored while at the same time keep the interface
>> transparent on the call site.
>>
>> The situation with objects is unchanged.
>>
>> But does it have to be that way? Why not have
>>
>> void f(observer_ptr<const X>);
>>
>> *instead of *
>>
>> void f(const T*);
>>
>> *AND*
>>
>> let std::unique_ptr<X> *implicitly *convert to observer_ptr<X>
>>
>> This will closely match the behavior of std::string -
>> Both will now have A) raw storage form B) managed storage form C)
>> observing form.
>>
>> In both raw storage is explicit call, however observing is implicit
>> conversion.
>>
>> Because observer_ptr does not convert to raw pointer, it will be safe to
>> use even with old APIs that might do manual lifetime management
>>
>> void friendly(observer_ptr<C> c) { if(c) std::cout<<*c<<'\n'; }
>> void evil(C* c){ delete c; }
>>
>> auto c = std::make_unique<C>();
>>
>> friendly(c); //< happy, transparent usage
>>
>> evil(c); //< nope
>>
>> auto p = observer_ptr(c);
>>
>> evil(p); //< nope
>>
>>
>> We will hit multiple birds
>>  - Have consistency with other std objects that do or will use a view form
>>  - Give perfect alternative for writing interfaces that take managing
>> smart pointers only to use the managed object
>>  - Find observer_ptr a meaning for existence, way and beyond "documenting
>> usage".
>>
>> Thoughts? Any downsides I missed?
>>
>
>
> I agree with all of this, and, to me, it makes observer_ptr worth
> standardizing.
>
> Only question: observer_ptr is a terrible name, what should we call it.
>

I feel like I've come around to the name observer_ptr, and we should
probably just put it in and the rest of the community will get used to it
too :P


>
> --
> Be seeing you,
> Tony
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuqHGogymYhCxDGmQWVPegmZQjoOy738k9Ey6J%3DarCe7A%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuqHGogymYhCxDGmQWVPegmZQjoOy738k9Ey6J%3DarCe7A%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>


--
*Brian Bi*

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMmfjbPaMxfRc2Sovieb%2BMWO%2By5gMnQyz9d%2BMQoLOvMjVS6_SA%40mail.gmail.com.

--000000000000fcd23f057900cc71
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed=
, Oct 24, 2018 at 4:58 PM Tony V E &lt;<a href=3D"mailto:tvaneerd@gmail.com=
">tvaneerd@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On We=
d, Oct 24, 2018 at 6:09 AM &lt;<a href=3D"mailto:mihailnajdenov@gmail.com" =
target=3D"_blank">mihailnajdenov@gmail.com</a>&gt; wrote:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">Hello, consider the following point=
 of view<div><br></div><div><font face=3D"courier new, monospace">std::stri=
ng </font>is to=C2=A0<font face=3D"courier new, monospace">char*</font>, wh=
at is <font face=3D"courier new, monospace">std::unique_ptr&lt;T&gt; </font=
>to <font face=3D"courier new, monospace">T* </font><font face=3D"arial, sa=
ns-serif">(minus copying)</font></div><div><br></div><div>To write an inter=
face that accepts strings (pre C++17) it is acceptable to write</div><div><=
br></div><div><font face=3D"courier new, monospace">void f(const char*);</f=
ont></div><div><font face=3D"courier new, monospace">void f(const std::stri=
ng&amp;);</font></div><div><br></div><div>To write an interface that accept=
s T it is acceptable to write</div><div><font face=3D"courier new, monospac=
e"><br></font></div><div><div><font face=3D"courier new, monospace">void f(=
const T*);</font></div><div><font face=3D"courier new, monospace">void f(co=
nst T&amp;);</font></div></div><div><br></div><div><font face=3D"arial, san=
s-serif">It is NOT acceptable to write=C2=A0</font><span style=3D"font-fami=
ly:&quot;courier new&quot;,monospace">void f(const=C2=A0</span><span style=
=3D"font-family:&quot;courier new&quot;,monospace">std::unique_ptr&lt;T&gt;=
&amp;</span><span style=3D"font-family:&quot;courier new&quot;,monospace">)=
; </span><font face=3D"arial, sans-serif">as the interface becomes dependen=
t on how the object is stored.</font></div><div><font face=3D"arial, sans-s=
erif"><br></font></div><div><font face=3D"arial, sans-serif">There are two =
problems here,=C2=A0</font></div><div><font face=3D"arial, sans-serif">=C2=
=A0- first we give advice that contradicts the string example (the interfac=
e is depend=C2=A0on how the string is stored)</font></div><div><font face=
=3D"arial, sans-serif">=C2=A0- second writing a=C2=A0</font><span style=3D"=
font-family:&quot;courier new&quot;,monospace">void f(const=C2=A0</span><sp=
an style=3D"font-family:&quot;courier new&quot;,monospace">std::unique_ptr&=
lt;T&gt;&amp;</span><span style=3D"font-family:&quot;courier new&quot;,mono=
space">); </span><font face=3D"arial, sans-serif"><i>actually buys somethin=
g</i>, it buys us transparent interface - that is why people do it!.</font>=
</div><div><font face=3D"arial, sans-serif"><br></font></div><div><font fac=
e=3D"arial, sans-serif">Enter C++17</font></div><div><font face=3D"arial, s=
ans-serif"><br></font></div><div><font face=3D"arial, sans-serif">The strin=
g situation=C2=A0is <i>further </i>improved=C2=A0</font></div><div><font fa=
ce=3D"arial, sans-serif"><br></font></div><div><span style=3D"font-family:&=
quot;courier new&quot;,monospace">void f(std::string_view);</span><font fac=
e=3D"arial, sans-serif"><br></font></div><div><span style=3D"font-family:&q=
uot;courier new&quot;,monospace"><br></span></div><div><font face=3D"arial,=
 sans-serif">We can do what we preach and have an interface that does not d=
epend on how the string is stored while at the same time keep the interface=
 transparent on the call site.</font></div><div><font face=3D"arial, sans-s=
erif"><br></font></div><div><font face=3D"arial, sans-serif">The situation =
with objects is unchanged.=C2=A0</font></div><div><font face=3D"arial, sans=
-serif"><br></font></div><div><font face=3D"arial, sans-serif">But does it =
have to be that way? Why not have=C2=A0</font></div><div><font face=3D"aria=
l, sans-serif"><br></font></div><div><font face=3D"courier new, monospace">=
void f(observer_ptr&lt;const X&gt;);</font><font face=3D"arial, sans-serif"=
><br></font></div><div><font face=3D"courier new, monospace"><br></font></d=
iv><font face=3D"arial, sans-serif"><i>instead of </i></font><div><font fac=
e=3D"arial, sans-serif"><i><br></i></font></div><div><span style=3D"font-fa=
mily:&quot;courier new&quot;,monospace">void f(const T*);</span><font face=
=3D"arial, sans-serif"><i><br></i></font></div><div><span style=3D"font-fam=
ily:&quot;courier new&quot;,monospace"><br></span></div><div><font face=3D"=
arial, sans-serif"><b>AND</b></font></div><div><span style=3D"font-family:&=
quot;courier new&quot;,monospace"><br></span></div><div><font face=3D"arial=
, sans-serif">let </font><font face=3D"courier new, monospace">std::unique_=
ptr&lt;X&gt;</font><font face=3D"arial, sans-serif"> <b>implicitly=C2=A0</b=
>convert to=C2=A0</font><span style=3D"font-family:&quot;courier new&quot;,=
monospace">observer_ptr&lt;X&gt;</span></div><div><font face=3D"arial, sans=
-serif"><br></font></div><div><font face=3D"arial, sans-serif">This will cl=
osely=C2=A0match the behavior of </font><font face=3D"courier new, monospac=
e">std::string -=C2=A0</font></div><div><font face=3D"arial, sans-serif">Bo=
th will now have A) raw storage form B) managed storage form C) observing f=
orm.=C2=A0</font></div><div><font face=3D"arial, sans-serif"><br></font></d=
iv><div><font face=3D"arial, sans-serif">In both=C2=A0raw storage is explic=
it call, however observing is implicit conversion.=C2=A0=C2=A0</font></div>=
<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=
rial, sans-serif">Because=C2=A0</font><span style=3D"font-family:&quot;cour=
ier new&quot;,monospace">observer_ptr </span><font face=3D"arial, sans-seri=
f">does not convert to raw pointer, it will be safe to use even with old AP=
Is that might do manual=C2=A0lifetime management</font></div><div><br></div=
><div><font face=3D"courier new, monospace">void friendly(observer_ptr&lt;C=
&gt; c) { if(c) std::cout&lt;&lt;*c&lt;&lt;&#39;\n&#39;; }</font></div><div=
><font face=3D"courier new, monospace">void evil(C* c){ delete c; }</font><=
/div><div><font face=3D"courier new, monospace"><br></font></div><div><font=
 face=3D"courier new, monospace">auto c =3D std::make_unique&lt;C&gt;();</f=
ont></div><div><font face=3D"courier new, monospace"><br></font></div><div>=
<span style=3D"font-family:&quot;courier new&quot;,monospace">friendly(c); =
//&lt; happy, transparent usage</span><font face=3D"courier new, monospace"=
><br></font></div><div><span style=3D"font-family:&quot;courier new&quot;,m=
onospace"><br></span></div><div><span style=3D"font-family:&quot;courier ne=
w&quot;,monospace">evil(c); //&lt; nope</span><span style=3D"font-family:&q=
uot;courier new&quot;,monospace"><br></span></div><div><br></div><div><span=
 style=3D"font-family:&quot;courier new&quot;,monospace">auto p =3D observe=
r_ptr(c);</span><font face=3D"courier new, monospace"><br></font></div><div=
><span style=3D"font-family:&quot;courier new&quot;,monospace"><br></span><=
/div><div><span style=3D"font-family:&quot;courier new&quot;,monospace">evi=
l(p); //&lt; nope</span><span style=3D"font-family:&quot;courier new&quot;,=
monospace"><br></span></div><div><span style=3D"font-family:&quot;courier n=
ew&quot;,monospace"><br></span></div><div><span style=3D"font-family:&quot;=
courier new&quot;,monospace"><br></span></div><div><font face=3D"arial, san=
s-serif">We will hit multiple birds=C2=A0</font></div><div><font face=3D"ar=
ial, sans-serif">=C2=A0- Have consistency=C2=A0with other std objects that =
do or will use a view form</font></div><div><font face=3D"arial, sans-serif=
">=C2=A0- Give perfect alternative for writing interfaces that take managin=
g smart pointers only to use the managed object</font></div><div><font face=
=3D"arial, sans-serif">=C2=A0- Find observer_ptr a meaning for existence, w=
ay and beyond &quot;documenting usage&quot;.=C2=A0</font></div><div><span s=
tyle=3D"font-family:&quot;courier new&quot;,monospace"><br></span></div><di=
v><font face=3D"arial, sans-serif">Thoughts? Any downsides I missed?</font>=
</div></div></blockquote><div><br></div><div><br></div><div>I agree with al=
l of this, and, to me, it makes observer_ptr worth standardizing.</div><div=
><br></div><div>Only question: observer_ptr is a terrible name, what should=
 we call it.<br></div></div></div></blockquote><div><br></div><div>I feel l=
ike I&#39;ve come around to the name observer_ptr, and we should probably j=
ust put it in and the rest of the community will get used to it too :P</div=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_quote"><div></div><div><br></div>-- <br></div><div dir=3D"ltr" c=
lass=3D"m_2659436895686533125gmail_signature" data-smartmail=3D"gmail_signa=
ture"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br></div></div></d=
iv>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuqHGogymYhCxDGmQWVPegmZQjoOy73=
8k9Ey6J%3DarCe7A%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAOHCbiuqHGogymYhCxDGmQWVPegmZQjoOy738k9Ey6J%3DarCe7A%40mail.gmail.c=
om</a>.<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"l=
tr"><div><div dir=3D"ltr"><font color=3D"#c0c0c0"><i>Brian Bi</i></font><br=
><div></div><div></div><div></div></div></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAMmfjbPaMxfRc2Sovieb%2BMWO%2By5gMnQy=
z9d%2BMQoLOvMjVS6_SA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMmfjbPaMx=
fRc2Sovieb%2BMWO%2By5gMnQyz9d%2BMQoLOvMjVS6_SA%40mail.gmail.com</a>.<br />

--000000000000fcd23f057900cc71--

.

On Thu, 25 Oct 2018 at 00:58, Tony V E <tvaneerd@gmail.com> wrote:

> I agree with all of this, and, to me, it makes observer_ptr worth standardizing.

You said that before, but the paper didn't materialize. :P

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZABEZobZ7aR6%3DiQU_yX-%2Bm_7jhCJ4BwVMaCxDPj%2BcTJw%40mail.gmail.com.

.

------=_Part_225_627316709.1540453795235
Content-Type: multipart/alternative;
 boundary="----=_Part_226_1040097062.1540453795236"

------=_Part_226_1040097062.1540453795236
Content-Type: text/plain; charset="UTF-8"



On Wednesday, October 24, 2018 at 2:06:16 PM UTC+3, Richard Hodges wrote:
>
> Any object that can be represented in a function call interface as
> observer_ptr<T> can be equally correctly represented as T&.
>

As others pointed out  - the difference is that observer_ptr can be null.

Ultimately one can have

void foo_thing(const Foo& f) {}
void foo_thing(observer_ptr<const Foo> f) { if(f) foo_thing(*f); }

And the clients will be beyond happy - completely transparent interface -
not get(), not operator* and works with stack variables.
And *no reason *to write foo_thing(const unique_ptr<const Foo>& f)


*That said*, you make a very interesting point - what about optional?

If our philosophy is - use the object without know knowing or caring how it
is stored, then it makes sense optional also to convert to observer_ptr

After all, optional is just a stack storage (in which an object might or
might not been stored).

This would allow us to exhaust all options.

void test()
{
  auto a = Foo{};
  auto b = std::make_unique<Foo>();
  auto c = std::make_shared<Foo>();
  auto d = std::optional<Foo>({});


  foo_thing(a); //< transparent access as in Java, old C++ and what not
  foo_thing(b); //
  foo_thing(c); //
  foo_thing(d); //
}


SIDEQUESTION: Why does observer_ptr have an explicit constructor? What is
guarding against?
After all it is the more constrained type (then raw pointer) and there is
the "is da thing" relationship.

I am asking because of

void f(observer_ptr<C>);

C c;
f(&c); //< not working, which is annoying as all hell and feels wrong



> Why wouldn't I just write my interfaces in terms of references? Wouldn't
> that give me more flexibility? consider:
>
> #include <optional>
> #include <memory>
>
> struct Foo
> {
> };
>
> void foo_thing(Foo& f)
> {
> }
>
> void test()
> {
>   auto a = std::optional<Foo>({});
>   auto b = std::make_unique<Foo>();
>   auto c = std::make_shared<Foo>();
>
>   foo_thing(*a);
>   foo_thing(*b);
>   foo_thing(*c);
> }
>
> If I wanted to take copies of that reference, std::reference_wrapper<Foo>
> would also be an acceptable argument type.
>
>
>
> On Wed, 24 Oct 2018 at 12:09, <mihailn...@gmail.com <javascript:>> wrote:
>
>> Hello, consider the following point of view
>>
>> std::string is to char*, what is std::unique_ptr<T> to T* (minus copying)
>>
>> To write an interface that accepts strings (pre C++17) it is acceptable
>> to write
>>
>> void f(const char*);
>> void f(const std::string&);
>>
>> To write an interface that accepts T it is acceptable to write
>>
>> void f(const T*);
>> void f(const T&);
>>
>> It is NOT acceptable to write void f(const std::unique_ptr<T>&); as the
>> interface becomes dependent on how the object is stored.
>>
>> There are two problems here,
>>  - first we give advice that contradicts the string example (the
>> interface is depend on how the string is stored)
>>  - second writing a void f(const std::unique_ptr<T>&); *actually buys
>> something*, it buys us transparent interface - that is why people do it!.
>>
>> Enter C++17
>>
>> The string situation is *further *improved
>>
>> void f(std::string_view);
>>
>> We can do what we preach and have an interface that does not depend on
>> how the string is stored while at the same time keep the interface
>> transparent on the call site.
>>
>> The situation with objects is unchanged.
>>
>> But does it have to be that way? Why not have
>>
>> void f(observer_ptr<const X>);
>>
>> *instead of *
>>
>> void f(const T*);
>>
>> *AND*
>>
>> let std::unique_ptr<X> *implicitly *convert to observer_ptr<X>
>>
>> This will closely match the behavior of std::string -
>> Both will now have A) raw storage form B) managed storage form C)
>> observing form.
>>
>> In both raw storage is explicit call, however observing is implicit
>> conversion.
>>
>> Because observer_ptr does not convert to raw pointer, it will be safe to
>> use even with old APIs that might do manual lifetime management
>>
>> void friendly(observer_ptr<C> c) { if(c) std::cout<<*c<<'\n'; }
>> void evil(C* c){ delete c; }
>>
>> auto c = std::make_unique<C>();
>>
>> friendly(c); //< happy, transparent usage
>>
>> evil(c); //< nope
>>
>> auto p = observer_ptr(c);
>>
>> evil(p); //< nope
>>
>>
>> We will hit multiple birds
>>  - Have consistency with other std objects that do or will use a view form
>>  - Give perfect alternative for writing interfaces that take managing
>> smart pointers only to use the managed object
>>  - Find observer_ptr a meaning for existence, way and beyond "documenting
>> usage".
>>
>> Thoughts? Any downsides I missed?
>>
>> --
>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/81a04b52-e5cd-4543-86c5-5a0068f9647b%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/81a04b52-e5cd-4543-86c5-5a0068f9647b%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f14858e6-d76a-41a6-868b-6af6e6a1d337%40isocpp.org.

------=_Part_226_1040097062.1540453795236
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, October 24, 2018 at 2:06:16 PM UTC+3=
, Richard Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr">Any object that can be represented in a function call interface a=
s observer_ptr&lt;T&gt; can be equally correctly represented as T&amp;.</di=
v></blockquote><div><br></div><div>As others pointed out=C2=A0 - the differ=
ence is that observer_ptr can be null.</div><div><br></div><div>Ultimately =
one can have</div><div><br></div><font face=3D"courier new, monospace">void=
 foo_thing(const Foo&amp; f) {}</font><div style=3D"color: rgb(0, 0, 0);"><=
font face=3D"courier new, monospace"><span style=3D"color: rgb(34, 34, 34);=
">void foo_thing(</span><span style=3D"color: rgb(34, 34, 34);">observer_pt=
r&lt;const Foo&gt;</span><span style=3D"color: rgb(34, 34, 34);">=C2=A0f) {=
 if(f)=C2=A0</span><span style=3D"color: rgb(34, 34, 34);">foo_thing(*f);</=
span><span style=3D"color: rgb(34, 34, 34);">=C2=A0}</span></font></div><di=
v><br></div><div>And the clients will be beyond happy - completely transpar=
ent interface - not get(), not operator* and works with stack variables.</d=
iv><div>And <i>no reason </i>to write=C2=A0<span style=3D"font-family: &quo=
t;courier new&quot;, monospace;">foo_thing(</span><span style=3D"font-famil=
y: &quot;courier new&quot;, monospace;">const unique_ptr&lt;const Foo&gt;&a=
mp;</span><span style=3D"font-family: &quot;courier new&quot;, monospace;">=
=C2=A0f)</span></div><div><font face=3D"courier new, monospace"><br></font>=
<div><br></div><div><div><i>That said</i>, you make a very interesting poin=
t - what about optional?</div><div><br></div><div>If our philosophy is - us=
e the object without know knowing or caring how it is stored, then it makes=
 sense optional also to convert to observer_ptr</div><div><br></div><div>Af=
ter all, optional is just a stack storage (in which an object might or migh=
t not been stored).</div><div><br></div><div>This would allow us to exhaust=
 all options.</div><font face=3D"courier new, monospace"><br>void test()<br=
>{<br>=C2=A0 auto a =3D Foo{};<br>=C2=A0 auto b =3D std::make_unique&lt;Foo=
&gt;();<br>=C2=A0 auto c =3D std::make_shared&lt;Foo&gt;();<br>=C2=A0 auto =
d =3D std::optional&lt;Foo&gt;({});<br>=C2=A0<br><br>=C2=A0 foo_thing(a); /=
/&lt; transparent access as in Java, old C++ and what not<br>=C2=A0 foo_thi=
ng(b); //<br>=C2=A0 foo_thing(c); //<br>=C2=A0 foo_thing(d); //<br>}</font>=
<div><br></div><div><br></div><div>SIDEQUESTION: Why does observer_ptr have=
 an explicit constructor? What is guarding against?=C2=A0</div><div>After a=
ll it is the more constrained type (then raw pointer) and there is the &quo=
t;is da thing&quot; relationship.</div><div><br></div><div>I am asking beca=
use of</div><div><br></div><div><font face=3D"courier new, monospace">void =
f(observer_ptr&lt;C&gt;);</font></div><div><font face=3D"courier new, monos=
pace"><br></font></div><div><font face=3D"courier new, monospace">C c;</fon=
t></div><div><font face=3D"courier new, monospace">f(&amp;c); //&lt; not wo=
rking, which is annoying as all hell and feels wrong</font></div><div><br><=
/div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div></div><div><br></div><div>Why wouldn&#39;t I just write my in=
terfaces in terms of references? Wouldn&#39;t that give me more flexibility=
? consider:</div><div><br></div><div><div style=3D"color:rgb(0,0,0);backgro=
und-color:rgb(255,255,254)"><div><font face=3D"monospace, monospace"><span =
style=3D"color:rgb(0,0,255)">#include</span> &lt;optional&gt;</font></div><=
div><font face=3D"monospace, monospace"><span style=3D"color:rgb(0,0,255)">=
#include</span> &lt;memory&gt;</font></div><font face=3D"monospace, monospa=
ce"><br></font><div><font face=3D"monospace, monospace"><span style=3D"colo=
r:rgb(0,0,255)">struct</span> Foo</font></div><div><font face=3D"monospace,=
 monospace">{</font></div><div><font face=3D"monospace, monospace">};</font=
></div><font face=3D"monospace, monospace"><br></font><div><font face=3D"mo=
nospace, monospace"><span style=3D"color:rgb(0,0,255)">void</span> foo_thin=
g(Foo&amp; f)</font></div><div><font face=3D"monospace, monospace">{</font>=
</div><div><font face=3D"monospace, monospace">}</font></div><font face=3D"=
monospace, monospace"><br></font><div><font face=3D"monospace, monospace"><=
span style=3D"color:rgb(0,0,255)">void</span> test()</font></div><div><font=
 face=3D"monospace, monospace">{</font></div><div>    <font face=3D"monospa=
ce, monospace"><span style=3D"color:rgb(0,0,255)">=C2=A0 auto</span> a =3D =
std::optional&lt;Foo&gt;({});</font></div><div>    <font face=3D"monospace,=
 monospace"><span style=3D"color:rgb(0,0,255)">=C2=A0 auto</span> b =3D std=
::make_unique&lt;Foo&gt;();</font></div><div>    <font face=3D"monospace, m=
onospace"><span style=3D"color:rgb(0,0,255)">=C2=A0 auto</span> c =3D std::=
make_shared&lt;Foo&gt;();</font></div><font face=3D"monospace, monospace"><=
br></font><div><font face=3D"monospace, monospace">=C2=A0 foo_thing(*a);</f=
ont></div><div><font face=3D"monospace, monospace">=C2=A0 foo_thing(*b);</f=
ont></div><div><font face=3D"monospace, monospace">=C2=A0 foo_thing(*c);</f=
ont></div><div><font face=3D"monospace, monospace">}</font></div><br></div>=
</div><div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,254)">If =
I wanted to take copies of that reference, std::reference_wrapper&lt;Foo&gt=
; would also be an acceptable argument type.</div><div style=3D"color:rgb(0=
,0,0);background-color:rgb(255,255,254)"><br></div><div style=3D"color:rgb(=
0,0,0);background-color:rgb(255,255,254)"><br></div></div><br><div class=3D=
"gmail_quote"><div dir=3D"ltr">On Wed, 24 Oct 2018 at 12:09, &lt;<a href=3D=
"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"1z_6Y56OBQAJ" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;=
" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">mihailn...@gma=
il.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr">Hello, consider the following point of view<div><br></div><div><font fa=
ce=3D"courier new, monospace">std::string </font>is to=C2=A0<font face=3D"c=
ourier new, monospace">char*</font>, what is <font face=3D"courier new, mon=
ospace">std::unique_ptr&lt;T&gt; </font>to <font face=3D"courier new, monos=
pace">T* </font><font face=3D"arial, sans-serif">(minus copying)</font></di=
v><div><br></div><div>To write an interface that accepts strings (pre C++17=
) it is acceptable to write</div><div><br></div><div><font face=3D"courier =
new, monospace">void f(const char*);</font></div><div><font face=3D"courier=
 new, monospace">void f(const std::string&amp;);</font></div><div><br></div=
><div>To write an interface that accepts T it is acceptable to write</div><=
div><font face=3D"courier new, monospace"><br></font></div><div><div><font =
face=3D"courier new, monospace">void f(const T*);</font></div><div><font fa=
ce=3D"courier new, monospace">void f(const T&amp;);</font></div></div><div>=
<br></div><div><font face=3D"arial, sans-serif">It is NOT acceptable to wri=
te=C2=A0</font><span style=3D"font-family:&quot;courier new&quot;,monospace=
">void f(const=C2=A0</span><span style=3D"font-family:&quot;courier new&quo=
t;,monospace">std::unique_ptr&lt;T&gt;&amp;</span><span style=3D"font-famil=
y:&quot;courier new&quot;,monospace">); </span><font face=3D"arial, sans-se=
rif">as the interface becomes dependent on how the object is stored.</font>=
</div><div><font face=3D"arial, sans-serif"><br></font></div><div><font fac=
e=3D"arial, sans-serif">There are two problems here,=C2=A0</font></div><div=
><font face=3D"arial, sans-serif">=C2=A0- first we give advice that contrad=
icts the string example (the interface is depend=C2=A0on how the string is =
stored)</font></div><div><font face=3D"arial, sans-serif">=C2=A0- second wr=
iting a=C2=A0</font><span style=3D"font-family:&quot;courier new&quot;,mono=
space">void f(const=C2=A0</span><span style=3D"font-family:&quot;courier ne=
w&quot;,monospace">std::unique_ptr&lt;T&gt;&amp;</span><span style=3D"font-=
family:&quot;courier new&quot;,monospace">); </span><font face=3D"arial, sa=
ns-serif"><i>actually buys something</i>, it buys us transparent interface =
- that is why people do it!.</font></div><div><font face=3D"arial, sans-ser=
if"><br></font></div><div><font face=3D"arial, sans-serif">Enter C++17</fon=
t></div><div><font face=3D"arial, sans-serif"><br></font></div><div><font f=
ace=3D"arial, sans-serif">The string situation=C2=A0is <i>further </i>impro=
ved=C2=A0</font></div><div><font face=3D"arial, sans-serif"><br></font></di=
v><div><span style=3D"font-family:&quot;courier new&quot;,monospace">void f=
(std::string_view);</span><font face=3D"arial, sans-serif"><br></font></div=
><div><span style=3D"font-family:&quot;courier new&quot;,monospace"><br></s=
pan></div><div><font face=3D"arial, sans-serif">We can do what we preach an=
d have an interface that does not depend on how the string is stored while =
at the same time keep the interface transparent on the call site.</font></d=
iv><div><font face=3D"arial, sans-serif"><br></font></div><div><font face=
=3D"arial, sans-serif">The situation with objects is unchanged.=C2=A0</font=
></div><div><font face=3D"arial, sans-serif"><br></font></div><div><font fa=
ce=3D"arial, sans-serif">But does it have to be that way? Why not have=C2=
=A0</font></div><div><font face=3D"arial, sans-serif"><br></font></div><div=
><font face=3D"courier new, monospace">void f(observer_ptr&lt;const X&gt;);=
</font><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D=
"courier new, monospace"><br></font></div><font face=3D"arial, sans-serif">=
<i>instead of </i></font><div><font face=3D"arial, sans-serif"><i><br></i><=
/font></div><div><span style=3D"font-family:&quot;courier new&quot;,monospa=
ce">void f(const T*);</span><font face=3D"arial, sans-serif"><i><br></i></f=
ont></div><div><span style=3D"font-family:&quot;courier new&quot;,monospace=
"><br></span></div><div><font face=3D"arial, sans-serif"><b>AND</b></font><=
/div><div><span style=3D"font-family:&quot;courier new&quot;,monospace"><br=
></span></div><div><font face=3D"arial, sans-serif">let </font><font face=
=3D"courier new, monospace">std::unique_ptr&lt;X&gt;</font><font face=3D"ar=
ial, sans-serif"> <b>implicitly=C2=A0</b>convert to=C2=A0</font><span style=
=3D"font-family:&quot;courier new&quot;,monospace">observer_ptr&lt;X&gt;</s=
pan></div><div><font face=3D"arial, sans-serif"><br></font></div><div><font=
 face=3D"arial, sans-serif">This will closely=C2=A0match the behavior of </=
font><font face=3D"courier new, monospace">std::string -=C2=A0</font></div>=
<div><font face=3D"arial, sans-serif">Both will now have A) raw storage for=
m B) managed storage form C) observing form.=C2=A0</font></div><div><font f=
ace=3D"arial, sans-serif"><br></font></div><div><font face=3D"arial, sans-s=
erif">In both=C2=A0raw storage is explicit call, however observing is impli=
cit conversion.=C2=A0=C2=A0</font></div><div><font face=3D"arial, sans-seri=
f"><br></font></div><div><font face=3D"arial, sans-serif">Because=C2=A0</fo=
nt><span style=3D"font-family:&quot;courier new&quot;,monospace">observer_p=
tr </span><font face=3D"arial, sans-serif">does not convert to raw pointer,=
 it will be safe to use even with old APIs that might do manual=C2=A0lifeti=
me management</font></div><div><br></div><div><font face=3D"courier new, mo=
nospace">void friendly(observer_ptr&lt;C&gt; c) { if(c) std::cout&lt;&lt;*c=
&lt;&lt;&#39;\n&#39;; }</font></div><div><font face=3D"courier new, monospa=
ce">void evil(C* c){ delete c; }</font></div><div><font face=3D"courier new=
, monospace"><br></font></div><div><font face=3D"courier new, monospace">au=
to c =3D std::make_unique&lt;C&gt;();</font></div><div><font face=3D"courie=
r new, monospace"><br></font></div><div><span style=3D"font-family:&quot;co=
urier new&quot;,monospace">friendly(c); //&lt; happy, transparent usage</sp=
an><font face=3D"courier new, monospace"><br></font></div><div><span style=
=3D"font-family:&quot;courier new&quot;,monospace"><br></span></div><div><s=
pan style=3D"font-family:&quot;courier new&quot;,monospace">evil(c); //&lt;=
 nope</span><span style=3D"font-family:&quot;courier new&quot;,monospace"><=
br></span></div><div><br></div><div><span style=3D"font-family:&quot;courie=
r new&quot;,monospace">auto p =3D observer_ptr(c);</span><font face=3D"cour=
ier new, monospace"><br></font></div><div><span style=3D"font-family:&quot;=
courier new&quot;,monospace"><br></span></div><div><span style=3D"font-fami=
ly:&quot;courier new&quot;,monospace">evil(p); //&lt; nope</span><span styl=
e=3D"font-family:&quot;courier new&quot;,monospace"><br></span></div><div><=
span style=3D"font-family:&quot;courier new&quot;,monospace"><br></span></d=
iv><div><span style=3D"font-family:&quot;courier new&quot;,monospace"><br><=
/span></div><div><font face=3D"arial, sans-serif">We will hit multiple bird=
s=C2=A0</font></div><div><font face=3D"arial, sans-serif">=C2=A0- Have cons=
istency=C2=A0with other std objects that do or will use a view form</font><=
/div><div><font face=3D"arial, sans-serif">=C2=A0- Give perfect alternative=
 for writing interfaces that take managing smart pointers only to use the m=
anaged object</font></div><div><font face=3D"arial, sans-serif">=C2=A0- Fin=
d observer_ptr a meaning for existence, way and beyond &quot;documenting us=
age&quot;.=C2=A0</font></div><div><span style=3D"font-family:&quot;courier =
new&quot;,monospace"><br></span></div><div><font face=3D"arial, sans-serif"=
>Thoughts? Any downsides I missed?</font></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
1z_6Y56OBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"1z_6Y56OBQAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/81a04b52-e5cd-4543-86c5-5a0068f9647b%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/81a04b52-e5cd-4543-86c5-5a0068f9647b%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/81a04b52-e5cd-4543-86c5-5a0068f9647b%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/81a04b52-e5cd-4543-<wbr>86c5-=
5a0068f9647b%40isocpp.org</a><wbr>.<br>
</blockquote></div>
</blockquote></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f14858e6-d76a-41a6-868b-6af6e6a1d337%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f14858e6-d76a-41a6-868b-6af6e6a1d337=
%40isocpp.org</a>.<br />

------=_Part_226_1040097062.1540453795236--

------=_Part_225_627316709.1540453795235--

.

--00000000000061036e057909531d
Content-Type: text/plain; charset="UTF-8"

On Wed, 24 Oct 2018 at 23:49, <mutant.sheepdog@gmail.com> wrote:

>
> Any object that can be represented in a function call interface as
>> observer_ptr<T> can be equally correctly represented as T&.
>>
>>
> Unless you want it to be nullable, in which case I think you need to do
> something like std::optional<std::reference_wrapper<Foo>>.
>

I thought we had moved on from testing raw pointers for null 20 years ago?
Don't we write in terms of *semantic intent* these days? The use of
pointers implies addresses, which implies memory, and as we know, the idea
of objects actually existing as bit patterns in memory is considered a
thought crime. (am I joking? Sometimes when addressing people in this forum
I'm not sure...)


>
> Related: I really wish std::optional<T&> was allowed.
>

The committee failed the user base horribly when it decreed that it would
not adopt optional<T&>. It was an insane decision, which ought to be simple
to reverse.

After all, the most logical implementation of optional<T&> is a trivial
wrapper around a 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/eb06dfa7-74f0-4986-9cd1-3f85c395541a%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/eb06dfa7-74f0-4986-9cd1-3f85c395541a%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3has85bUTtdobXBop%2BXe3WDYZBPJ9x_GQmbESUa%2BhhqK_Q%40mail.gmail.com.

--00000000000061036e057909531d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed=
, 24 Oct 2018 at 23:49, &lt;<a href=3D"mailto:mutant.sheepdog@gmail.com">mu=
tant.sheepdog@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><br><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">Any object that can be represented in a function call interface as=
 observer_ptr&lt;T&gt; can be equally correctly represented as T&amp;.<div>=
</div></div><br></blockquote><div><br></div><div>Unless you want it to be n=
ullable, in which case I think you need to do something like std::optional&=
lt;std::reference_wrapper&lt;Foo&gt;&gt;.</div></div></blockquote><div><br>=
</div><div>I thought we had moved on from testing raw pointers for null 20 =
years ago? Don&#39;t we write in terms of <i>semantic intent</i> these days=
? The use of pointers implies addresses, which implies memory, and as we kn=
ow, the idea of objects actually existing as bit patterns in memory is cons=
idered a thought crime. (am I joking? Sometimes when addressing people in t=
his forum I&#39;m not sure...)</div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div><br></div><div>Related: I really wish std::o=
ptional&lt;T&amp;&gt; was allowed. <br></div></div></blockquote><div><br></=
div><div>The committee failed the user base horribly when it decreed that i=
t would not adopt optional&lt;T&amp;&gt;. It was an insane decision, which =
ought to be simple to reverse.</div><div><br></div><div>After all, the most=
 logical implementation of optional&lt;T&amp;&gt; is a trivial wrapper arou=
nd a pointer.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/eb06dfa7-74f0-4986-9cd1-3f85c395541a%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/eb06dfa7-74f0-=
4986-9cd1-3f85c395541a%40isocpp.org</a>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3has85bUTtdobXBop%2BXe3WDYZBPJ9x=
_GQmbESUa%2BhhqK_Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3has85bU=
TtdobXBop%2BXe3WDYZBPJ9x_GQmbESUa%2BhhqK_Q%40mail.gmail.com</a>.<br />

--00000000000061036e057909531d--

.

--0000000000004c3960057909bdf8
Content-Type: text/plain; charset="UTF-8"

On Thu, Oct 25, 2018 at 3:24 AM Richard Hodges <hodges.r@gmail.com> wrote:

> Related: I really wish std::optional<T&> was allowed.
>
> The committee failed the user base horribly when it decreed that it would
> not adopt optional<T&>. It was an insane decision, which ought to be simple
> to reverse.
>

The committee never decreed such a thing.  What actually happened:
https://stackoverflow.com/questions/26858034/stdoptional-specialization-for-reference-types/26895581#26895581

After all, the most logical implementation of optional<T&> is a trivial
> wrapper around a pointer.
>

That is not a description of what the *interface* should be.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BOiLJ24SoR1UsB3JuJ5jVj%3Dv2Sk_3pCQEKUezQhEJYwrA%40mail.gmail.com.

--0000000000004c3960057909bdf8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Thu, Oct 25, 2018 at 3:24 AM Richard H=
odges &lt;<a href=3D"mailto:hodges.r@gmail.com">hodges.r@gmail.com</a>&gt; =
wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid=
;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Rela=
ted: I really wish std::optional&lt;T&amp;&gt; was allowed.=C2=A0<br><div c=
lass=3D"gmail_quote"><div><br></div><div>The committee failed the user base=
 horribly when it decreed that it would not adopt optional&lt;T&amp;&gt;. I=
t was an insane decision, which ought to be simple to reverse.</div></div><=
/div></blockquote><div><br></div><div>The committee never decreed such a th=
ing.=C2=A0 What actually happened:=C2=A0<a href=3D"https://stackoverflow.co=
m/questions/26858034/stdoptional-specialization-for-reference-types/2689558=
1#26895581">https://stackoverflow.com/questions/26858034/stdoptional-specia=
lization-for-reference-types/26895581#26895581</a></div><div><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>After all, th=
e most logical implementation of optional&lt;T&amp;&gt; is a trivial wrappe=
r around a pointer.<br></div></div></div></blockquote><div><br></div><div>T=
hat is not a description of what the *interface* should be.</div></div>-- <=
br><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr"><div><div di=
r=3D"ltr"><div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=
=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com=
</a>&gt; =C2=A0+1-847-691-1404</div></div></div></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BOiLJ24SoR1UsB3JuJ5jVj%3Dv2Sk=
_3pCQEKUezQhEJYwrA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BOiLJ=
24SoR1UsB3JuJ5jVj%3Dv2Sk_3pCQEKUezQhEJYwrA%40mail.gmail.com</a>.<br />

--0000000000004c3960057909bdf8--

.

Hi =D0=9C=D0=B8=D1=85=D0=B0=D0=B8=D0=BB,

On Wed, Oct 24, 2018 at 12:09 PM <mihailnajdenov@gmail.com> wrote:
>
>  - second writing a void f(const std::unique_ptr<T>&); actually buys some=
thing, it buys us transparent interface - that is why people do it!.

What do you mean by "transparent interface"? Being able to call with
"c" instead of "*c"? Also, I am not sure I have seen that many code
passing around references to `unique_ptr`. Typically you want a
reference, no?

> The string situation is further improved
>
> void f(std::string_view);

That is kind of a special case, no? i.e. strings typically come in
many flavors (specially due to C APIs/libs), so we provide a wrapper
to abstract that issue. However, normal C++ objects aren't usually put
in a C array, for instance. We could have a "vector_view" or
"sequence_view" too, but I don't think it is that needed (and we have
iterators anyway).

> But does it have to be that way? Why not have
>
> void f(observer_ptr<const X>);
>
> instead of
>
> void f(const T*);
>
> AND
>
> let std::unique_ptr<X> implicitly convert to observer_ptr<X>

It is a fine idea, but again, in my view, the signature should contain
references.

Also, some people actually prefer to have an annotations like "*c" or
"&c" at call site instead of simply "c". For instance, to signal
output parameters, to be explicit about dereferences... Why would you
take an observer_ptr is what you really want is the object (optional
or not)?

I would even prefer an "optional references" proposal rather than an
observer_ptr, so that we could keep use references everywhere with
ease, instead of moving to raw pointers or std::pointer. In other
words, being able to write something like (image "optional" is a
keyword):

  void f(optional const T& value)
  {
    if (not optional value)
      return;
    // use value as usual
  }

  f(2); // reference with a value
  f(optional); // empty reference

Cheers,
Miguel

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CANiq72kjzhEDckOaenPSpQx%3DO38wrPkK%2BzgBtdc9ZHk=
8-yENDg%40mail.gmail.com.

.

------=_Part_285_1248941074.1540462316274
Content-Type: multipart/alternative;
 boundary="----=_Part_286_1111918631.1540462316275"

------=_Part_286_1111918631.1540462316275
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Thursday, October 25, 2018 at 11:58:06 AM UTC+3, Miguel Ojeda wrote:
>
> Hi =D0=9C=D0=B8=D1=85=D0=B0=D0=B8=D0=BB,=20
>
> On Wed, Oct 24, 2018 at 12:09 PM <mihailn...@gmail.com <javascript:>>=20
> wrote:=20
> >=20
> >  - second writing a void f(const std::unique_ptr<T>&); actually buys=20
> something, it buys us transparent interface - that is why people do it!.=
=20
>
> =20

> What do you mean by "transparent interface"? Being able to call with=20
> "c" instead of "*c"?=20


yes
=20

> Also, I am not sure I have seen that many code=20
> passing around references to `unique_ptr`.=20


Well, every two years (literally) there are talks that tell the people "do=
=20
not do that".
=20

> Typically you want a=20
> reference, no? =20


But if you use your object as smart pointer this becomes cumbersome and in=
=20
a way intuitive, though arguably correct
=20

>
> > The string situation is further improved=20
> >=20
> > void f(std::string_view);=20
>
> =20

> That is kind of a special case, no? i.e. strings typically come in=20
> many flavors (specially due to C APIs/libs), so we provide a wrapper=20
> to abstract that issue. However, normal C++ objects aren't usually put=20
> in a C array, for instance. We could have a "vector_view" or=20
> "sequence_view" too, but I don't think it is that needed (and we have=20
> iterators anyway).=20
>

The point is to not be a special case, but the default one (for observing)=
=20
and=20
vector_view is coming (in the from of span) and is already part of Core=20
Guidelines span.

Iterators are for templates, this is for concrete types - to have abstract=
=20
interface while still using concrete types (and interface / impl=20
separation). =20
=20

>
> > But does it have to be that way? Why not have=20
> >=20
> > void f(observer_ptr<const X>);=20
> >=20
> > instead of=20
> >=20
> > void f(const T*);=20
> >=20
> > AND=20
> >=20
> > let std::unique_ptr<X> implicitly convert to observer_ptr<X>=20
>
> =20

> It is a fine idea, but again, in my view, the signature should contain=20
> references.=20
>

It all depends how you want to present your interface to users - do you=20
want to have the null case handed for them or not
and do you want to have the interface be "natural", because ultimately with=
=20
get() and operator* you force the user to *adjust *to you interface.

This makes smart pointers second class citizens to both old pointers - the=
=20
good old times where you just use pointers like normal object handles -=20
and  to other languages where the handle is used as-is on the call site=20
without explicit call to a converting function.


> Also, some people actually prefer to have an annotations like "*c" or=20
> "&c" at call site instead of simply "c". For instance, to signal=20
> output parameters, to be explicit about dereferences...=20


As said, depends on what you want.=20
Right now the scenario "I just want to use my object, that is heap=20
allocated" is not handled naturally=20
and there is no way to do so outside accepting const smart_ptr<T>&=20

=20

> Why would you=20
> take an observer_ptr is what you really want is the object (optional=20
> or not)?=20
>

Because this is what the user has - he has pointer.=20
=20

>
> I would even prefer an "optional references" proposal rather than an=20
> observer_ptr, so that we could keep use references everywhere with=20
> ease, instead of moving to raw pointers or std::pointer. In other=20
> words, being able to write something like (image "optional" is a=20
> keyword):=20
>
>   void f(optional const T& value)=20
>   {=20
>     if (not optional value)=20
>       return;=20
>     // use value as usual=20
>   }=20
>
>   f(2); // reference with a value=20
>   f(optional); // empty reference=20
>


I sympathize with the idea, but this is very hard to implement if we don't=
=20
want it to model a pointer  (to not have indirections like operator* and=20
operator->)=20
=20
I also don't like observer_ptr name very much and I am also not big fan of=
=20
the fact it pretends to be a smart point with fancy API (though I could see=
=20
uses for that in generic code).

However if this gives us "view for objects" with most (but not all) of the=
=20
benefits, that makes things quite interesting.=20

Technically, yeah the smart reference you decried is "view for objects" and=
=20
it is what we want/need, but we don't have that and the attempts to get one=
=20
failed multiple times ("operator dot" and family)=20


> Cheers,=20
> Miguel=20
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/8c03b541-4b51-4741-a7d4-7cf74186bb02%40isocpp.or=
g.

------=_Part_286_1111918631.1540462316275
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, October 25, 2018 at 11:58:06 AM UTC+3=
, Miguel Ojeda wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi =D0=9C=
=D0=B8=D1=85=D0=B0=D0=B8=D0=BB,
<br>
<br>On Wed, Oct 24, 2018 at 12:09 PM &lt;<a href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"srGHkjTWBQAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D=
&#39;javascript:&#39;;return true;">mihailn...@gmail.com</a>&gt; wrote:
<br>&gt;
<br>&gt; =C2=A0- second writing a void f(const std::unique_ptr&lt;T&gt;&amp=
;); actually buys something, it buys us transparent interface - that is why=
 people do it!.
<br>
<br></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">What do you mean by &quot;transparent interface&quot;? Being able to =
call with
<br>&quot;c&quot; instead of &quot;*c&quot;? </blockquote><div><br></div><d=
iv>yes</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">A=
lso, I am not sure I have seen that many code
<br>passing around references to `unique_ptr`. </blockquote><div><br></div>=
<div><div>Well, every two years (literally) there are talks that tell the p=
eople &quot;do not do that&quot;.</div></div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;">Typically you want a
<br>reference, no?=C2=A0=C2=A0</blockquote><div><br></div><div>But if you u=
se your object as smart pointer this becomes cumbersome and in a way intuit=
ive, though arguably correct</div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;">
<br>&gt; The string situation is further improved
<br>&gt;
<br>&gt; void f(std::string_view);
<br>
<br></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">That is kind of a special case, no? i.e. strings typically come in
<br>many flavors (specially due to C APIs/libs), so we provide a wrapper
<br>to abstract that issue. However, normal C++ objects aren&#39;t usually =
put
<br>in a C array, for instance. We could have a &quot;vector_view&quot; or
<br>&quot;sequence_view&quot; too, but I don&#39;t think it is that needed =
(and we have
<br>iterators anyway).
<br></blockquote><div><br></div><div>The point is to not be a special case,=
 but the default one (for observing) and=C2=A0</div><div>vector_view is com=
ing (in the from of span) and is already part of Core Guidelines span.</div=
><div><br></div><div>Iterators are for templates, this is for concrete type=
s - to have abstract interface while still using concrete types (and interf=
ace / impl separation).=C2=A0=C2=A0<br></div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;">
<br>&gt; But does it have to be that way? Why not have
<br>&gt;
<br>&gt; void f(observer_ptr&lt;const X&gt;);
<br>&gt;
<br>&gt; instead of
<br>&gt;
<br>&gt; void f(const T*);
<br>&gt;
<br>&gt; AND
<br>&gt;
<br>&gt; let std::unique_ptr&lt;X&gt; implicitly convert to observer_ptr&lt=
;X&gt;
<br>
<br></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">It is a fine idea, but again, in my view, the signature should contai=
n
<br>references.
<br></blockquote><div><br></div><div>It all depends how you want to present=
 your interface to users - do you want to have the null case handed for the=
m or not</div><div>and do you want to have the interface be &quot;natural&q=
uot;, because ultimately with get() and operator* you force the user to <i>=
adjust </i>to you interface.</div><div><br></div><div>This makes smart poin=
ters second class citizens to both old pointers - the good old times where =
you just use pointers like normal object handles -=C2=A0</div><div>and=C2=
=A0 to other languages where the handle is used as-is on the call site with=
out explicit call to a converting function.</div><div><br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">
<br>Also, some people actually prefer to have an annotations like &quot;*c&=
quot; or
<br>&quot;&amp;c&quot; at call site instead of simply &quot;c&quot;. For in=
stance, to signal
<br>output parameters, to be explicit about dereferences... </blockquote><d=
iv><br></div><div>As said, depends on what you want.=C2=A0</div><div>Right =
now the scenario &quot;I just want to use my object, that is heap allocated=
&quot; is not handled naturally=C2=A0</div><div>and there is no way to do s=
o outside accepting <font face=3D"courier new, monospace">const smart_ptr&l=
t;T&gt;&amp;=C2=A0</font></div><div><font face=3D"arial, sans-serif"><br></=
font></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Wh=
y would you
<br>take an observer_ptr is what you really want is the object (optional
<br>or not)?
<br></blockquote><div><br></div><div>Because this is what the user has - he=
 has pointer.=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;">
<br>I would even prefer an &quot;optional references&quot; proposal rather =
than an
<br>observer_ptr, so that we could keep use references everywhere with
<br>ease, instead of moving to raw pointers or std::pointer. In other
<br>words, being able to write something like (image &quot;optional&quot; i=
s a
<br>keyword):
<br>
<br>=C2=A0 void f(optional const T&amp; value)
<br>=C2=A0 {
<br>=C2=A0 =C2=A0 if (not optional value)
<br>=C2=A0 =C2=A0 =C2=A0 return;
<br>=C2=A0 =C2=A0 // use value as usual
<br>=C2=A0 }
<br>
<br>=C2=A0 f(2); // reference with a value
<br>=C2=A0 f(optional); // empty reference
<br></blockquote><div><br></div><div><br></div><div>I sympathize with the i=
dea, but this is very hard to implement if we don&#39;t want it to model a =
pointer=C2=A0 (to not have indirections like operator* and operator-&gt;)=
=C2=A0</div><div>=C2=A0</div><div>I also don&#39;t like observer_ptr name v=
ery much and I am also not big fan of the fact it pretends to be a smart po=
int with fancy API (though I could see uses for that in generic code).</div=
><div><br></div><div>However if this gives us &quot;view for objects&quot; =
with most (but not all) of the benefits, that makes things quite interestin=
g.=C2=A0</div><div><br></div><div>Technically, yeah the smart reference you=
 decried is &quot;view for objects&quot; and it is what we want/need, but w=
e don&#39;t have that and the attempts to get one failed multiple times (&q=
uot;operator dot&quot; and family)=C2=A0</div><div><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">
<br>Cheers,
<br>Miguel
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8c03b541-4b51-4741-a7d4-7cf74186bb02%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8c03b541-4b51-4741-a7d4-7cf74186bb02=
%40isocpp.org</a>.<br />

------=_Part_286_1111918631.1540462316275--

------=_Part_285_1248941074.1540462316274--

.

------=_Part_150_1051251554.1540471486949
Content-Type: multipart/alternative;
 boundary="----=_Part_151_2017896062.1540471486949"

------=_Part_151_2017896062.1540471486949
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



2018. okt=C3=B3ber 24., szerda 23:58:28 UTC+2 id=C5=91pontban Tony V E a k=
=C3=B6vetkez=C5=91t=20
=C3=ADrta:
>
> I agree with all of this, and, to me, it makes observer_ptr worth=20
> standardizing.
>
> Only question: observer_ptr is a terrible name, what should we call it.
>

Why should we call it anything? Isn't observer the *default *genre of=20
pointers? There is some merit to have owner_ptr to mark the interface where=
=20
ownership is passed before it gets into a dedicated owner.  But who really=
=20
wants to noise up the codebase stating the (supposedly) obvious?
=20

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/464c2586-4d3f-43e1-b135-d4c51436d672%40isocpp.or=
g.

------=_Part_151_2017896062.1540471486949
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>2018. okt=C3=B3ber 24., szerda 23:58:28 UTC+2 id=
=C5=91pontban Tony V E a k=C3=B6vetkez=C5=91t =C3=ADrta:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr">I agree with all of this, and,=
 to me, it makes observer_ptr worth standardizing.<div class=3D"gmail_quote=
"><div><br></div><div>Only question: observer_ptr is a terrible name, what =
should we call it.<br></div></div></div></blockquote><div><br></div><div>Wh=
y should we call it anything? Isn&#39;t observer the <i>default </i>genre o=
f pointers? There is some merit to have owner_ptr to mark the interface whe=
re ownership is passed before it gets into a dedicated owner.=C2=A0 But who=
 really wants to noise up the codebase stating the (supposedly) obvious?<br=
></div><div>=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/464c2586-4d3f-43e1-b135-d4c51436d672%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/464c2586-4d3f-43e1-b135-d4c51436d672=
%40isocpp.org</a>.<br />

------=_Part_151_2017896062.1540471486949--

------=_Part_150_1051251554.1540471486949--

.

<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
 255, 255); line-height: initial;">                                        =
                                              <div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">When you have a raw pointer, ownership is not (typically) obvio=
us.</div>                                                                  =
                                                                   <div sty=
le=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', s=
ans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backgr=
ound-color: rgb(255, 255, 255);"><br style=3D"display:initial"></div>      =
                                                                           =
                                                                           =
                                       <div style=3D"font-size: initial; fo=
nt-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73,=
 125); text-align: initial; background-color: rgb(255, 255, 255);">Sent&nbs=
p;from&nbsp;my&nbsp;BlackBerry&nbsp;portable&nbsp;Babbage&nbsp;Device</div>=
                                                                           =
                                                                           =
                            <table width=3D"100%" style=3D"background-color=
:white;border-spacing:0px;"> <tbody><tr><td colspan=3D"2" style=3D"font-siz=
e: initial; text-align: initial; background-color: rgb(255, 255, 255);">   =
                        <div style=3D"border-style: solid none none; border=
-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding: 3pt 0in 0in=
; font-family: Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10pt;">  <d=
iv><b>From: </b>pasa@lib.hu</div><div><b>Sent: </b>Thursday, October 25, 20=
18 8:44 AM</div><div><b>To: </b>ISO C++ Standard - Future Proposals</div><d=
iv><b>Reply To: </b>std-proposals@isocpp.org</div><div><b>Subject: </b>Re: =
[std-proposals] shared_ptr and unique_ptr should both implicitly convert to=
 observer_ptr</div></div></td></tr></tbody></table><div style=3D"border-sty=
le: solid none none; border-top-color: rgb(186, 188, 209); border-top-width=
: 1pt; font-size: initial; text-align: initial; background-color: rgb(255, =
255, 255);"></div><br><div id=3D"_originalContent" style=3D""><div dir=3D"l=
tr"><br><br>2018. okt=C3=B3ber 24., szerda 23:58:28 UTC+2 id=C5=91pontban T=
ony V E a k=C3=B6vetkez=C5=91t =C3=ADrta:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr">I agree with all of this, and, to me, it makes =
observer_ptr worth standardizing.<div class=3D"gmail_quote"><div><br></div>=
<div>Only question: observer_ptr is a terrible name, what should we call it=
..<br></div></div></div></blockquote><div><br></div><div>Why should we call =
it anything? Isn't observer the <i>default </i>genre of pointers? There is =
some merit to have owner_ptr to mark the interface where ownership is passe=
d before it gets into a dedicated owner.&nbsp; But who really wants to nois=
e up the codebase stating the (supposedly) obvious?<br></div><div>&nbsp;</d=
iv></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/464c2586-4d3f-43e1-b135-d4c51436d672%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/464c2586-4d3f-43e1-b135-d4c51436=
d672%40isocpp.org</a>.<br>
<br><!--end of _originalContent --></div></body></html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/20181025125433.5218385.77798.64223%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/20181025125433.5218385.77798.64223%40gm=
ail.com</a>.<br />

.

--000000000000c630d405790d734e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 25, 2018 at 2:54 PM Tony V E <tvaneerd@gmail.com> wrote:

> When you have a raw pointer, ownership is not (typically) obvious.
>
>
Well... writing modern C++ (in my sense of modern) it is. A raw pointer is
newer owned.


> Sent from my BlackBerry portable Babbage Device
> *From: *pasa@lib.hu
> *Sent: *Thursday, October 25, 2018 8:44 AM
> *To: *ISO C++ Standard - Future Proposals
> *Reply To: *std-proposals@isocpp.org
> *Subject: *Re: [std-proposals] shared_ptr and unique_ptr should both
> implicitly convert to observer_ptr
>
>
>
> 2018. okt=C3=B3ber 24., szerda 23:58:28 UTC+2 id=C5=91pontban Tony V E a =
k=C3=B6vetkez=C5=91t
> =C3=ADrta:
>>
>> I agree with all of this, and, to me, it makes observer_ptr worth
>> standardizing.
>>
>> Only question: observer_ptr is a terrible name, what should we call it.
>>
>
> Why should we call it anything? Isn't observer the *default *genre of
> pointers? There is some merit to have owner_ptr to mark the interface whe=
re
> ownership is passed before it gets into a dedicated owner.  But who reall=
y
> wants to noise up the codebase stating the (supposedly) obvious?
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/464c2586-4d3=
f-43e1-b135-d4c51436d672%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/464c2586-4d=
3f-43e1-b135-d4c51436d672%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/201810251254=
33.5218385.77798.64223%40gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20181025125=
433.5218385.77798.64223%40gmail.com?utm_medium=3Demail&utm_source=3Dfooter>
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CANPtknxg98ZuW9jcVs%3De_hKYr3JF750vTRk%2B8m4hFWv=
m3imahw%40mail.gmail.com.

--000000000000c630d405790d734e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu=
, Oct 25, 2018 at 2:54 PM Tony V E &lt;<a href=3D"mailto:tvaneerd@gmail.com=
">tvaneerd@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rg=
b(204,204,204);border-left-width:1px;border-left-style:solid"><div lang=3D"=
en-US" style=3D"background-color:rgb(255,255,255)">                        =
                                                              <div style=3D=
"width:100%;color:rgb(31,73,125);font-family:Calibri,&quot;Slate Pro&quot;,=
sans-serif,sans-serif;background-color:rgb(255,255,255)">When you have a ra=
w pointer, ownership is not (typically) obvious.</div>                     =
                                                                           =
                                     <div style=3D"width:100%;color:rgb(31,=
73,125);font-family:Calibri,&quot;Slate Pro&quot;,sans-serif,sans-serif;bac=
kground-color:rgb(255,255,255)"><br></div></div></blockquote><div>=C2=A0</d=
iv><div>Well... writing modern C++=C2=A0(in my sense of modern) it is. A ra=
w pointer is newer owned.</div><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color=
:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div lang=
=3D"en-US" style=3D"background-color:rgb(255,255,255)"><div style=3D"width:=
100%;color:rgb(31,73,125);font-family:Calibri,&quot;Slate Pro&quot;,sans-se=
rif,sans-serif;background-color:rgb(255,255,255)"></div>                   =
                                                                           =
                                                                           =
                          <div style=3D"color:rgb(31,73,125);font-family:Ca=
libri,&quot;Slate Pro&quot;,sans-serif,sans-serif;background-color:rgb(255,=
255,255)">Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=
=C2=A0Device</div>                                                         =
                                                                           =
                                              <table width=3D"100%" style=
=3D"border-spacing:0px;background-color:white"> <tbody><tr><td style=3D"bac=
kground-color:rgb(255,255,255)" colspan=3D"2">                           <d=
iv style=3D"border-style:solid none none;padding:3pt 0in 0in;font-family:Ta=
homa,&quot;BB Alpha Sans&quot;,&quot;Slate Pro&quot;;font-size:10pt;border-=
top-color:rgb(181,196,223);border-top-width:1pt">  <div><b>From: </b><a hre=
f=3D"mailto:pasa@lib.hu" target=3D"_blank">pasa@lib.hu</a></div><div><b>Sen=
t: </b>Thursday, October 25, 2018 8:44 AM</div><div><b>To: </b>ISO C++ Stan=
dard - Future Proposals</div><div><b>Reply To: </b><a href=3D"mailto:std-pr=
oposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a></div><di=
v><b>Subject: </b>Re: [std-proposals] shared_ptr and unique_ptr should both=
 implicitly convert to observer_ptr</div></div></td></tr></tbody></table><d=
iv style=3D"border-style:solid none none;border-top-color:rgb(186,188,209);=
border-top-width:1pt;background-color:rgb(255,255,255)"></div><br><div id=
=3D"m_3621262056988043521_originalContent"><div dir=3D"ltr"><br><br>2018. o=
kt=C3=B3ber 24., szerda 23:58:28 UTC+2 id=C5=91pontban Tony V E a k=C3=B6ve=
tkez=C5=91t =C3=ADrta:<blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-l=
eft-width:1px;border-left-style:solid"><div dir=3D"ltr">I agree with all of=
 this, and, to me, it makes observer_ptr worth standardizing.<div class=3D"=
gmail_quote"><div><br></div><div>Only question: observer_ptr is a terrible =
name, what should we call it.<br></div></div></div></blockquote><div><br></=
div><div>Why should we call it anything? Isn&#39;t observer the <i>default =
</i>genre of pointers? There is some merit to have owner_ptr to mark the in=
terface where ownership is passed before it gets into a dedicated owner.=C2=
=A0 But who really wants to noise up the codebase stating the (supposedly) =
obvious?<br></div><div>=C2=A0</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/464c2586-4d3f-43e1-b135-d4c51436d672%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/464c2586-4d3f-=
43e1-b135-d4c51436d672%40isocpp.org</a>.<br>
<br></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/20181025125433.5218385.77798.64223%40=
gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20181025125433.52=
18385.77798.64223%40gmail.com</a>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANPtknxg98ZuW9jcVs%3De_hKYr3JF750vTR=
k%2B8m4hFWvm3imahw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANPtknxg98Zu=
W9jcVs%3De_hKYr3JF750vTRk%2B8m4hFWvm3imahw%40mail.gmail.com</a>.<br />

--000000000000c630d405790d734e--

.

On Thu, 25 Oct 2018 at 16:19, Peter Koch Larsen
<peter.koch.larsen@gmail.com> wrote:
>
>
>
> On Thu, Oct 25, 2018 at 2:54 PM Tony V E <tvaneerd@gmail.com> wrote:
>>
>> When you have a raw pointer, ownership is not (typically) obvious.
>>
>
> Well... writing modern C++ (in my sense of modern) it is. A raw pointer is newer owned.

This is, to me, a fairly astonishing part of what some call "modern"
C++. Instead of enforcing semantics with
a type, they are loosely agreed on by an unenforceable convention.
That seems like a massive
step backwards, instead of being modern.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYpP2AkfJeU_COZJSLo5A_LNXftkXm8hn2x8CGc8m_DGw%40mail.gmail.com.

.

<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
 255, 255); line-height: initial;">                                        =
                                              <div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">But then going back to the original post, do you allow shared_p=
tr to implicitly convert to T*?&nbsp;</div><div style=3D"width: 100%; font-=
size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; c=
olor: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255=
, 255);"><br></div><div style=3D"width: 100%; font-size: initial; font-fami=
ly: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); =
text-align: initial; background-color: rgb(255, 255, 255);">And thus allow =
`delete mySharedPtr;`?</div><div style=3D"width: 100%; font-size: initial; =
font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 7=
3, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></=
div><div style=3D"width: 100%; font-size: initial; font-family: Calibri, 'S=
late Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: ini=
tial; background-color: rgb(255, 255, 255);"><br></div>                    =
                                                                           =
                                      <div style=3D"width: 100%; font-size:=
 initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color:=
 rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255=
);"><br style=3D"display:initial"></div>                                   =
                                                                           =
                                                                           =
          <div style=3D"font-size: initial; font-family: Calibri, 'Slate Pr=
o', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; b=
ackground-color: rgb(255, 255, 255);">Sent&nbsp;from&nbsp;my&nbsp;BlackBerr=
y&nbsp;portable&nbsp;Babbage&nbsp;Device</div>                             =
                                                                           =
                                                                          <=
table width=3D"100%" style=3D"background-color:white;border-spacing:0px;"> =
<tbody><tr><td colspan=3D"2" style=3D"font-size: initial; text-align: initi=
al; background-color: rgb(255, 255, 255);">                           <div =
style=3D"border-style: solid none none; border-top-color: rgb(181, 196, 223=
); border-top-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Al=
pha Sans', 'Slate Pro'; font-size: 10pt;">  <div><b>From: </b>Peter Koch La=
rsen</div><div><b>Sent: </b>Thursday, October 25, 2018 9:19 AM</div><div><b=
>To: </b>std-proposals@isocpp.org</div><div><b>Reply To: </b>std-proposals@=
isocpp.org</div><div><b>Subject: </b>Re: [std-proposals] shared_ptr and uni=
que_ptr should both implicitly convert to observer_ptr</div></div></td></tr=
></tbody></table><div style=3D"border-style: solid none none; border-top-co=
lor: rgb(186, 188, 209); border-top-width: 1pt; font-size: initial; text-al=
ign: initial; background-color: rgb(255, 255, 255);"></div><br><div id=3D"_=
originalContent" style=3D""><div dir=3D"ltr"><br><br><div class=3D"gmail_qu=
ote"><div dir=3D"ltr">On Thu, Oct 25, 2018 at 2:54 PM Tony V E &lt;<a href=
=3D"mailto:tvaneerd@gmail.com">tvaneerd@gmail.com</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-=
left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-le=
ft-style:solid"><div lang=3D"en-US" style=3D"background-color:rgb(255,255,2=
55)">                                                                      =
                <div style=3D"width:100%;color:rgb(31,73,125);font-family:C=
alibri,&quot;Slate Pro&quot;,sans-serif,sans-serif;background-color:rgb(255=
,255,255)">When you have a raw pointer, ownership is not (typically) obviou=
s.</div>                                                                   =
                                                                  <div styl=
e=3D"width:100%;color:rgb(31,73,125);font-family:Calibri,&quot;Slate Pro&qu=
ot;,sans-serif,sans-serif;background-color:rgb(255,255,255)"><br></div></di=
v></blockquote><div>&nbsp;</div><div>Well... writing modern C++&nbsp;(in my=
 sense of modern) it is. A raw pointer is newer owned.</div><div>&nbsp;</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;paddi=
ng-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border=
-left-style:solid"><div lang=3D"en-US" style=3D"background-color:rgb(255,25=
5,255)"><div style=3D"width:100%;color:rgb(31,73,125);font-family:Calibri,&=
quot;Slate Pro&quot;,sans-serif,sans-serif;background-color:rgb(255,255,255=
)"></div>                                                                  =
                                                                           =
                                                      <div style=3D"color:r=
gb(31,73,125);font-family:Calibri,&quot;Slate Pro&quot;,sans-serif,sans-ser=
if;background-color:rgb(255,255,255)">Sent&nbsp;from&nbsp;my&nbsp;BlackBerr=
y&nbsp;portable&nbsp;Babbage&nbsp;Device</div>                             =
                                                                           =
                                                                          <=
table width=3D"100%" style=3D"border-spacing:0px;background-color:white"> <=
tbody><tr><td style=3D"background-color:rgb(255,255,255)" colspan=3D"2">   =
                        <div style=3D"border-style:solid none none;padding:=
3pt 0in 0in;font-family:Tahoma,&quot;BB Alpha Sans&quot;,&quot;Slate Pro&qu=
ot;;font-size:10pt;border-top-color:rgb(181,196,223);border-top-width:1pt">=
  <div><b>From: </b><a href=3D"mailto:pasa@lib.hu" target=3D"_blank">pasa@l=
ib.hu</a></div><div><b>Sent: </b>Thursday, October 25, 2018 8:44 AM</div><d=
iv><b>To: </b>ISO C++ Standard - Future Proposals</div><div><b>Reply To: </=
b><a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-proposa=
ls@isocpp.org</a></div><div><b>Subject: </b>Re: [std-proposals] shared_ptr =
and unique_ptr should both implicitly convert to observer_ptr</div></div></=
td></tr></tbody></table><div style=3D"border-style:solid none none;border-t=
op-color:rgb(186,188,209);border-top-width:1pt;background-color:rgb(255,255=
,255)"></div><br><div id=3D"m_3621262056988043521_originalContent"><div dir=
=3D"ltr"><br><br>2018. okt=C3=B3ber 24., szerda 23:58:28 UTC+2 id=C5=91pont=
ban Tony V E a k=C3=B6vetkez=C5=91t =C3=ADrta:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:r=
gb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir=3D"=
ltr">I agree with all of this, and, to me, it makes observer_ptr worth stan=
dardizing.<div class=3D"gmail_quote"><div><br></div><div>Only question: obs=
erver_ptr is a terrible name, what should we call it.<br></div></div></div>=
</blockquote><div><br></div><div>Why should we call it anything? Isn't obse=
rver the <i>default </i>genre of pointers? There is some merit to have owne=
r_ptr to mark the interface where ownership is passed before it gets into a=
 dedicated owner.&nbsp; But who really wants to noise up the codebase stati=
ng the (supposedly) obvious?<br></div><div>&nbsp;</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/464c2586-4d3f-43e1-b135-d4c51436d672%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/464c2586-4d3f-=
43e1-b135-d4c51436d672%40isocpp.org</a>.<br>
<br></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/20181025125433.5218385.77798.64223%40=
gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20181025125433.52=
18385.77798.64223%40gmail.com</a>.<br>
</blockquote></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANPtknxg98ZuW9jcVs%3De_hKYr3JF750vTR=
k%2B8m4hFWvm3imahw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANPtknxg=
98ZuW9jcVs%3De_hKYr3JF750vTRk%2B8m4hFWvm3imahw%40mail.gmail.com</a>.<br>
<br><!--end of _originalContent --></div></body></html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/20181025133153.5218385.87846.64230%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/20181025133153.5218385.87846.64230%40gm=
ail.com</a>.<br />

.

------=_Part_401_1823834295.1540479052241
Content-Type: multipart/alternative;
 boundary="----=_Part_402_21976327.1540479052242"

------=_Part_402_21976327.1540479052242
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

The more I think about it, the more I feel std::optional<X&> is better=20
suited to be "non owning null-ble handle"

This is, if we make a list with pros and cons, pros seems to win=20

*Mega wins*

 - Immune to ownership semantic issues
 - Explicit, by name, "might not be there" meaning

*Pros*

 - You can't even get() the pointer - it is as close to "object_view" as we=
=20
can get
 - It is better suited to be destination implicit conversion for other=20
things like, optional itself - optional<X> converts to optional</*const*/=
=20
X&>, the same way string does to a view
 - It is better to have a (smart) pointer convert to optional reference=20
then optional to a "observing pointer".
 - People don't like "pointer" to stand-in for an object (*even if  *
optional has the same interface!)
 - People want it (and request it) for other things

*Cons*

 - The only type in the std that will be either a reference type or a value=
=20
type, depending on param
 - The entire interface is developed around value container type
 - Construction and assignment from value might be debatable, *especially  =
*if=20
we push it to replace raw pointers as observers (or observer_ptr for that=
=20
matter)


On the other hand observer_ptr

*Pros*
=20
 - No implicit conversion to raw
 - Good fit to be implicit conversion target from smart and raw pointers =
=20
 - By name not owning
 - Little to no semantic problems - reference type, period

*Cons*
* - *Name and interface can be (very) misleading - "Observing what?=20
Lifetime?", "Observing, but not const, Wat?"
 - Not well suited to be implicit conversion from other, non-politer-like=
=20
objects.
 - It is still a pointer - people don't like them much
 - It is still a pointer - one can still delete get() or delete release()it=
=20


On Thursday, October 25, 2018 at 4:31:56 PM UTC+3, Tony V E wrote:
>
> But then going back to the original post, do you allow shared_ptr to=20
> implicitly convert to T*?=20
>
> And thus allow `delete mySharedPtr;`?
>
>
>
> Sent from my BlackBerry portable Babbage Device
> *From: *Peter Koch Larsen
> *Sent: *Thursday, October 25, 2018 9:19 AM
> *To: *std-pr...@isocpp.org <javascript:>
> *Reply To: *std-pr...@isocpp.org <javascript:>
> *Subject: *Re: [std-proposals] shared_ptr and unique_ptr should both=20
> implicitly convert to observer_ptr
>
>
>
> On Thu, Oct 25, 2018 at 2:54 PM Tony V E <tvan...@gmail.com <javascript:>=
>=20
> wrote:
>
>> When you have a raw pointer, ownership is not (typically) obvious.
>>
>> =20
> Well... writing modern C++ (in my sense of modern) it is. A raw pointer i=
s=20
> newer owned.
> =20
>
>> Sent from my BlackBerry portable Babbage Device
>> *From: *pa...@lib.hu <javascript:>
>> *Sent: *Thursday, October 25, 2018 8:44 AM
>> *To: *ISO C++ Standard - Future Proposals
>> *Reply To: *std-pr...@isocpp.org <javascript:>
>> *Subject: *Re: [std-proposals] shared_ptr and unique_ptr should both=20
>> implicitly convert to observer_ptr
>>
>>
>>
>> 2018. okt=C3=B3ber 24., szerda 23:58:28 UTC+2 id=C5=91pontban Tony V E a=
 k=C3=B6vetkez=C5=91t=20
>> =C3=ADrta:
>>>
>>> I agree with all of this, and, to me, it makes observer_ptr worth=20
>>> standardizing.
>>>
>>> Only question: observer_ptr is a terrible name, what should we call it.
>>>
>>
>> Why should we call it anything? Isn't observer the *default *genre of=20
>> pointers? There is some merit to have owner_ptr to mark the interface wh=
ere=20
>> ownership is passed before it gets into a dedicated owner.  But who real=
ly=20
>> wants to noise up the codebase stating the (supposedly) obvious?
>> =20
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/464c2586-4d=
3f-43e1-b135-d4c51436d672%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/464c2586-4=
d3f-43e1-b135-d4c51436d672%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20181025125=
433.5218385.77798.64223%40gmail.com=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2018102512=
5433.5218385.77798.64223%40gmail.com?utm_medium=3Demail&utm_source=3Dfooter=
>
>> .
>>
> --=20
> You received this message because you are subscribed to the Google Groups=
=20
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
=20
> email to std-proposal...@isocpp.org <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANPtknxg98Z=
uW9jcVs%3De_hKYr3JF750vTRk%2B8m4hFWvm3imahw%40mail.gmail.com=20
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANPtknxg98=
ZuW9jcVs%3De_hKYr3JF750vTRk%2B8m4hFWvm3imahw%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
> .
>
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1088074a-c9aa-4226-aaf6-0642de8e9a88%40isocpp.or=
g.

------=_Part_402_21976327.1540479052242
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The more I think about it, the more I feel <font face=3D"c=
ourier new, monospace">std::optional&lt;X&amp;&gt;</font> is better suited =
to be &quot;non owning null-ble handle&quot;<div><br></div><div>This is, if=
 we make a list with pros and cons, pros seems to win=C2=A0</div><div><br><=
/div><div><b>Mega wins</b></div><div><br></div><div>=C2=A0- Immune to owner=
ship semantic issues</div><div>=C2=A0- Explicit, by name, &quot;might not b=
e there&quot; meaning</div><div><br></div><div><b>Pros</b></div><div><br></=
div><div>=C2=A0- You can&#39;t even get() the pointer - it is as close to &=
quot;object_view&quot; as we can get</div><div>=C2=A0- It is better suited =
to be destination implicit conversion for other things like,=C2=A0<font fac=
e=3D"courier new, monospace">optional </font>itself - <font face=3D"courier=
 new, monospace">optional&lt;X&gt;</font> converts to <font face=3D"courier=
 new, monospace">optional&lt;/*const*/ X&amp;&gt;</font>, the same way stri=
ng does to a view</div><div>=C2=A0- It is better to have a (smart) pointer =
convert to optional reference then <font face=3D"courier new, monospace">op=
tional </font>to a &quot;observing pointer&quot;.</div><div>=C2=A0- People =
don&#39;t like &quot;pointer&quot; to stand-in for an object (<i>even if=C2=
=A0=C2=A0</i><font face=3D"courier new, monospace">optional</font>=C2=A0has=
 the same interface!)</div><div>=C2=A0- People want it (and request it) for=
 other things</div><div><br></div><div><b>Cons</b></div><div><b><br></b><di=
v>=C2=A0- The only type in the std that will be either a reference type or =
a value type, depending on param</div><div>=C2=A0- The entire interface is =
developed around value container type</div><div>=C2=A0- Construction and as=
signment from value might be debatable, <i>especially=C2=A0 </i>if we push =
it to replace raw pointers as observers (or observer_ptr for that matter)</=
div><div><br><br>On the other hand observer_ptr</div><div><br></div><div><b=
>Pros</b></div><div><b>=C2=A0</b></div><div>=C2=A0- No implicit conversion =
to raw</div><div>=C2=A0- Good fit to be implicit conversion target from sma=
rt and raw pointers=C2=A0=C2=A0</div><div>=C2=A0- By name not owning</div><=
div>=C2=A0- Little to no semantic problems - reference type, period</div><d=
iv><br></div><div><b>Cons</b></div><div><b>=C2=A0- </b>Name and interface c=
an be (very) misleading - &quot;Observing what? Lifetime?&quot;, &quot;Obse=
rving, but not const, Wat?&quot;</div><div>=C2=A0- Not well suited to be im=
plicit conversion from other, non-politer-like objects.</div><div>=C2=A0- I=
t is still a pointer - people don&#39;t like them much</div><div>=C2=A0- It=
 is still a pointer - one can still=C2=A0<font face=3D"courier new, monospa=
ce">delete get()</font>=C2=A0or <font face=3D"courier new, monospace">delet=
e release()</font><font face=3D"arial, sans-serif">it=C2=A0</font></div><di=
v><br><br>On Thursday, October 25, 2018 at 4:31:56 PM UTC+3, Tony V E wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div lang=3D"en-US" style=3D"=
background-color:rgb(255,255,255);line-height:initial">                    =
                                                                  <div styl=
e=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,s=
ans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-col=
or:rgb(255,255,255)">But then going back to the original post, do you allow=
 shared_ptr to implicitly convert to T*?=C2=A0</div><div style=3D"width:100=
%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans=
-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255=
,255)"><br></div><div style=3D"width:100%;font-size:initial;font-family:Cal=
ibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-al=
ign:initial;background-color:rgb(255,255,255)">And thus allow `delete mySha=
redPtr;`?</div><div style=3D"width:100%;font-size:initial;font-family:Calib=
ri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-alig=
n:initial;background-color:rgb(255,255,255)"><br></div><div style=3D"width:=
100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,s=
ans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,=
255,255)"><br></div>                                                       =
                                                                           =
   <div style=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slat=
e Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;ba=
ckground-color:rgb(255,255,255)"><br style=3D"display:initial"></div>      =
                                                                           =
                                                                           =
                                       <div style=3D"font-size:initial;font=
-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,1=
25);text-align:initial;background-color:rgb(255,255,255)">Sent=C2=A0from=C2=
=A0my=C2=A0BlackBerry=C2=A0<wbr>portable=C2=A0Babbage=C2=A0Device</div>    =
                                                                           =
                                                                           =
                        <table width=3D"100%" style=3D"background-color:whi=
te;border-spacing:0px"> <tbody><tr><td colspan=3D"2" style=3D"font-size:ini=
tial;text-align:initial;background-color:rgb(255,255,255)">                =
           <div style=3D"border-style:solid none none;border-top-color:rgb(=
181,196,223);border-top-width:1pt;padding:3pt 0in 0in;font-family:Tahoma,&#=
39;BB Alpha Sans&#39;,&#39;Slate Pro&#39;;font-size:10pt">  <div><b>From: <=
/b>Peter Koch Larsen</div><div><b>Sent: </b>Thursday, October 25, 2018 9:19=
 AM</div><div><b>To: </b><a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"z-J5-SXlBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:=
&#39;;return true;">std-pr...@isocpp.org</a></div><div><b>Reply To: </b><a =
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"z-J5-SXlBQA=
J" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return=
 true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">std-pr..=
..@isocpp.org</a></div><div><b>Subject: </b>Re: [std-proposals] shared_ptr a=
nd unique_ptr should both implicitly convert to observer_ptr</div></div></t=
d></tr></tbody></table><div style=3D"border-style:solid none none;border-to=
p-color:rgb(186,188,209);border-top-width:1pt;font-size:initial;text-align:=
initial;background-color:rgb(255,255,255)"></div><br><div><div dir=3D"ltr">=
<br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Oct 25, 2018 at=
 2:54 PM Tony V E &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"z-J5-SXlBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#3=
9;;return true;">tvan...@gmail.com</a>&gt; wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border=
-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"=
><div lang=3D"en-US" style=3D"background-color:rgb(255,255,255)">          =
                                                                           =
 <div style=3D"width:100%;color:rgb(31,73,125);font-family:Calibri,&quot;Sl=
ate Pro&quot;,sans-serif,sans-serif;background-color:rgb(255,255,255)">When=
 you have a raw pointer, ownership is not (typically) obvious.</div>       =
                                                                           =
                                                   <div style=3D"width:100%=
;color:rgb(31,73,125);font-family:Calibri,&quot;Slate Pro&quot;,sans-serif,=
sans-serif;background-color:rgb(255,255,255)"><br></div></div></blockquote>=
<div>=C2=A0</div><div>Well... writing modern C++=C2=A0(in my sense of moder=
n) it is. A raw pointer is newer owned.</div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;bor=
der-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:sol=
id"><div lang=3D"en-US" style=3D"background-color:rgb(255,255,255)"><div st=
yle=3D"width:100%;color:rgb(31,73,125);font-family:Calibri,&quot;Slate Pro&=
quot;,sans-serif,sans-serif;background-color:rgb(255,255,255)"></div>      =
                                                                           =
                                                                           =
                                       <div style=3D"color:rgb(31,73,125);f=
ont-family:Calibri,&quot;Slate Pro&quot;,sans-serif,sans-serif;background-c=
olor:rgb(255,255,255)">Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0<wbr>por=
table=C2=A0Babbage=C2=A0Device</div>                                       =
                                                                           =
                                                                <table widt=
h=3D"100%" style=3D"border-spacing:0px;background-color:white"> <tbody><tr>=
<td style=3D"background-color:rgb(255,255,255)" colspan=3D"2">             =
              <div style=3D"border-style:solid none none;padding:3pt 0in 0i=
n;font-family:Tahoma,&quot;BB Alpha Sans&quot;,&quot;Slate Pro&quot;;font-s=
ize:10pt;border-top-color:rgb(181,196,223);border-top-width:1pt">  <div><b>=
From: </b><a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"z-J5-SXlBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return =
true;">pa...@lib.hu</a></div><div><b>Sent: </b>Thursday, October 25, 2018 8=
:44 AM</div><div><b>To: </b>ISO C++ Standard - Future Proposals</div><div><=
b>Reply To: </b><a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"z-J5-SXlBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;java=
script:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;ret=
urn true;">std-pr...@isocpp.org</a></div><div><b>Subject: </b>Re: [std-prop=
osals] shared_ptr and unique_ptr should both implicitly convert to observer=
_ptr</div></div></td></tr></tbody></table><div style=3D"border-style:solid =
none none;border-top-color:rgb(186,188,209);border-top-width:1pt;background=
-color:rgb(255,255,255)"></div><br><div><div dir=3D"ltr"><br><br>2018. okt=
=C3=B3ber 24., szerda 23:58:28 UTC+2 id=C5=91pontban Tony V E a k=C3=B6vetk=
ez=C5=91t =C3=ADrta:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-lef=
t-width:1px;border-left-style:solid"><div dir=3D"ltr">I agree with all of t=
his, and, to me, it makes observer_ptr worth standardizing.<div class=3D"gm=
ail_quote"><div><br></div><div>Only question: observer_ptr is a terrible na=
me, what should we call it.<br></div></div></div></blockquote><div><br></di=
v><div>Why should we call it anything? Isn&#39;t observer the <i>default </=
i>genre of pointers? There is some merit to have owner_ptr to mark the inte=
rface where ownership is passed before it gets into a dedicated owner.=C2=
=A0 But who really wants to noise up the codebase stating the (supposedly) =
obvious?<br></div><div>=C2=A0</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
z-J5-SXlBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"z-J5-SXlBQAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/464c2586-4d3f-43e1-b135-d4c51436d672%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/464c2586-4d3f-43e1-b135-d4c51436d672%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/464c2586-4d3f-43e1-b135-d4c51436d672%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/464c2586-4d3f-43e1-<wbr>b135-=
d4c51436d672%40isocpp.org</a><wbr>.<br>
<br></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
z-J5-SXlBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"z-J5-SXlBQAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/20181025125433.5218385.77798.64223%40=
gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/a/i=
socpp.org/d/msgid/std-proposals/20181025125433.5218385.77798.64223%40gmail.=
com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick=
=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/20181025125433.5218385.77798.64223%40gmail.com?utm_medium\x3demail\x=
26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/a/<wbr>=
isocpp.org/d/msgid/std-<wbr>proposals/20181025125433.<wbr>5218385.77798.642=
23%40gmail.<wbr>com</a>.<br>
</blockquote></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
z-J5-SXlBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"z-J5-SXlBQAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANPtknxg98ZuW9jcVs%3De_hKYr3JF750vTR=
k%2B8m4hFWvm3imahw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANPtknxg98ZuW9jc=
Vs%3De_hKYr3JF750vTRk%2B8m4hFWvm3imahw%40mail.gmail.com?utm_medium\x3demail=
\x26utm_source\x3dfooter&#39;;return true;" onclick=3D"this.href=3D&#39;htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANPtknxg98ZuW9jc=
Vs%3De_hKYr3JF750vTRk%2B8m4hFWvm3imahw%40mail.gmail.com?utm_medium\x3demail=
\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/a/<wb=
r>isocpp.org/d/msgid/std-<wbr>proposals/CANPtknxg98ZuW9jcVs%<wbr>3De_hKYr3J=
F750vTRk%<wbr>2B8m4hFWvm3imahw%40mail.gmail.<wbr>com</a>.<br>
<br></div></div>
</blockquote></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1088074a-c9aa-4226-aaf6-0642de8e9a88%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1088074a-c9aa-4226-aaf6-0642de8e9a88=
%40isocpp.org</a>.<br />

------=_Part_402_21976327.1540479052242--

------=_Part_401_1823834295.1540479052241--

.

On Thu, Oct 25, 2018 at 12:11 PM <mihailnajdenov@gmail.com> wrote:
>
> Well, every two years (literally) there are talks that tell the people "do not do that".

Sure, people learning may do it, but that doesn't imply we need
something else, no?

> But if you use your object as smart pointer this becomes cumbersome and in a way intuitive, though arguably correct

[1] A function shouldn't take a shared_ptr<T> or unique_ptr<T> (or
observer_ptr<T>, for that matter), if the only thing required is the
T. Unless the function needs the pointer itself, for some reason, the
signature should be a T or a T& (possible const-qualified) if
possible. That actually makes the function more flexible, because it
does not care where the object is stored nor who is the owner.

> vector_view is coming (in the from of span) and is already part of Core Guidelines span.

Yeah, std::span is nice to abstract std::vectors away, but you can
achieve the same with iterators.

> Iterators are for templates, this is for concrete types - to have abstract interface while still using concrete types (and interface / impl separation).

I am not sure I understand. Iterators are an orthogonal concept to templates.

> It all depends how you want to present your interface to users - do you want to have the null case handed for them or not

Most of the functions I write do not need null/optional objects. For
those that do, I simply use T* (which has been the way of doing it
since forever! :-) because we do not have "optional references"
(otherwise I would use that instead).

> and do you want to have the interface be "natural", because ultimately with get() and operator* you force the user to adjust to you interface.

That is a different topic, indeed. If you want to call functions with
"c", you are basically asking that implicit conversions happen from
pointer types to their actual values.

> This makes smart pointers second class citizens to both old pointers - the good old times where you just use pointers like normal object handles -

See above [1].

> and  to other languages where the handle is used as-is on the call site without explicit call to a converting function.

It is not that there is no explicit conversion; rather, those
languages are always using references, so there is no conversion at
all. Basically, you can achieve the same thing in C++ by always,
always, always using a wrapper<T>, possibly with a GC. But then you
lose one key advantage of C++.

> As said, depends on what you want.
> Right now the scenario "I just want to use my object, that is heap allocated" is not handled naturally
> and there is no way to do so outside accepting const smart_ptr<T>&

See above [1]: you should be saying "I just want to use my object, no
matter where it is allocated" instead.

> I sympathize with the idea, but this is very hard to implement if we don't want it to model a pointer  (to not have indirections like operator* and operator->)

I am not sure I understand this part.

Cheers,
Miguel

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANiq72mUi67bNVh%2B5RRL10RZCtLik0wWrL_LV3_rTbTbJJV4Hw%40mail.gmail.com.

.

On Thu, Oct 25, 2018 at 3:28 PM Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
>
> On Thu, 25 Oct 2018 at 16:19, Peter Koch Larsen
> <peter.koch.larsen@gmail.com> wrote:
> >
> > On Thu, Oct 25, 2018 at 2:54 PM Tony V E <tvaneerd@gmail.com> wrote:
> >>
> >> When you have a raw pointer, ownership is not (typically) obvious.
> >>
> >
> > Well... writing modern C++ (in my sense of modern) it is. A raw pointer is newer owned.
>
> This is, to me, a fairly astonishing part of what some call "modern"
> C++. Instead of enforcing semantics with
> a type, they are loosely agreed on by an unenforceable convention.
> That seems like a massive
> step backwards, instead of being modern.

That has nothing to do with modern C++, though. T* is a perfectly
valid solution for optional references.

On top of that, the logic does not really follow: if you are writing
"modern C++", then you don't have any raw pointer owning anything.
Therefore, a raw pointer has to be an observer one.

Cheers,
Miguel

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANiq72kF%3Dt%2BOR4%3DbLLJbjppL1mt5V5Dmf1Es0kkuoLNe8fv%3DhQ%40mail.gmail.com.

.

--00000000000003ef1f05790ff761
Content-Type: text/plain; charset="UTF-8"

On Thu, Oct 25, 2018 at 1:20 AM Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On Thu, 25 Oct 2018 at 00:58, Tony V E <tvaneerd@gmail.com> wrote:
>
> > I agree with all of this, and, to me, it makes observer_ptr worth
> standardizing.
>
> You said that before, but the paper didn't materialize. :P
>


.... yet.

Hopefully next meeting.

--
Be seeing you,
Tony

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiv2HYLVs0s3M338aRdmGi5q-f-s3SA4jy1fLqMP0gmSmg%40mail.gmail.com.

--00000000000003ef1f05790ff761
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu=
, Oct 25, 2018 at 1:20 AM Ville Voutilainen &lt;<a href=3D"mailto:ville.vou=
tilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">On Thu, 25 Oct 2018 at 00:58, Tony V E &lt;<a h=
ref=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&=
gt; wrote:<br>
<br>
&gt; I agree with all of this, and, to me, it makes observer_ptr worth stan=
dardizing.<br>
<br>
You said that before, but the paper didn&#39;t materialize. :P<br></blockqu=
ote><div><br></div><div><br></div><div>... yet.</div><div><br></div><div>Ho=
pefully next meeting.</div><div><br></div></div>-- <br><div dir=3D"ltr" cla=
ss=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">=
<div>Be seeing you,<br></div>Tony<br></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbiv2HYLVs0s3M338aRdmGi5q-f-s3SA4=
jy1fLqMP0gmSmg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiv2HYLVs0s3=
M338aRdmGi5q-f-s3SA4jy1fLqMP0gmSmg%40mail.gmail.com</a>.<br />

--00000000000003ef1f05790ff761--

.

On Thu, 25 Oct 2018 at 19:19, Tony V E <tvaneerd@gmail.com> wrote:
>
>
>
> On Thu, Oct 25, 2018 at 1:20 AM Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>>
>> On Thu, 25 Oct 2018 at 00:58, Tony V E <tvaneerd@gmail.com> wrote:
>>
>> > I agree with all of this, and, to me, it makes observer_ptr worth standardizing.
>>
>> You said that before, but the paper didn't materialize. :P
>
>
>
> ... yet.
>
> Hopefully next meeting.

Alright; give me the gist of the changes you have in mind, and if you
can, any drafts of the paper and I'll give you
a regtested proper stdlib implementation that has passed the tests of
observer_ptr, modulo changes needed for the changes
we need to make.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYRmaYmc12EfaUiBHiO1_t-2z2fE7NvdnJvkcWEhCoNSg%40mail.gmail.com.

.

--0000000000000e7beb05791027fa
Content-Type: text/plain; charset="UTF-8"

On Thu, Oct 25, 2018 at 12:21 PM Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On Thu, 25 Oct 2018 at 19:19, Tony V E <tvaneerd@gmail.com> wrote:
> >
> >
> >
> > On Thu, Oct 25, 2018 at 1:20 AM Ville Voutilainen <
> ville.voutilainen@gmail.com> wrote:
> >>
> >> On Thu, 25 Oct 2018 at 00:58, Tony V E <tvaneerd@gmail.com> wrote:
> >>
> >> > I agree with all of this, and, to me, it makes observer_ptr worth
> standardizing.
> >>
> >> You said that before, but the paper didn't materialize. :P
> >
> >
> >
> > ... yet.
> >
> > Hopefully next meeting.
>
> Alright; give me the gist of the changes you have in mind, and if you
> can, any drafts of the paper and I'll give you
> a regtested proper stdlib implementation that has passed the tests of
> observer_ptr, modulo changes needed for the changes
> we need to make.
>


Cool, thanks.  Here's what I've got so far:
https://github.com/tvaneerd/isocpp/blob/master/observer_ptr.md#changes
I'm not sure it is worth making coding changes yet. Up to you of course.

Now that I think of it, the implicit conversions should probably be on
shared_ptr and unique_ptr cast operators, not on observer_ptr constructors.
(ie observer_ptr is the simpler class, it shouldn't depend on
shared/unique, they should depend on it)

Alternatively observer_ptr could have implicit conversion from anything
that "looks like" a smart pointer?  Not sure how "looks like" would be
safely defined.





> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYRmaYmc12EfaUiBHiO1_t-2z2fE7NvdnJvkcWEhCoNSg%40mail.gmail.com
> .
>


--
Be seeing you,
Tony

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivLHMKjNH8WQ9KU9Rwb%3DGa%3Dr2SZS%3DMb0gGEHgExAGYtJg%40mail.gmail.com.

--0000000000000e7beb05791027fa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr">On Thu, Oct 25, 2018 at 12:21 PM Ville Voutilainen &lt;<a href=
=3D"mailto:ville.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt;=
 wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, =
25 Oct 2018 at 19:19, Tony V E &lt;<a href=3D"mailto:tvaneerd@gmail.com" ta=
rget=3D"_blank">tvaneerd@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Thu, Oct 25, 2018 at 1:20 AM Ville Voutilainen &lt;<a href=3D"mailt=
o:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.co=
m</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Thu, 25 Oct 2018 at 00:58, Tony V E &lt;<a href=3D"mailto:tvane=
erd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; &gt; I agree with all of this, and, to me, it makes observer_ptr w=
orth standardizing.<br>
&gt;&gt;<br>
&gt;&gt; You said that before, but the paper didn&#39;t materialize. :P<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; ... yet.<br>
&gt;<br>
&gt; Hopefully next meeting.<br>
<br>
Alright; give me the gist of the changes you have in mind, and if you<br>
can, any drafts of the paper and I&#39;ll give you<br>
a regtested proper stdlib implementation that has passed the tests of<br>
observer_ptr, modulo changes needed for the changes<br>
we need to make.<br></blockquote><div><br></div><div><br></div><div>Cool, t=
hanks.=C2=A0 Here&#39;s what I&#39;ve got so far:=C2=A0 <a href=3D"https://=
github.com/tvaneerd/isocpp/blob/master/observer_ptr.md#changes">https://git=
hub.com/tvaneerd/isocpp/blob/master/observer_ptr.md#changes</a><br></div><d=
iv>I&#39;m not sure it is worth making coding changes yet. Up to you of cou=
rse.<br></div><div><br></div><div>Now that I think of it, the implicit conv=
ersions should probably be on shared_ptr and unique_ptr cast operators, not=
 on observer_ptr constructors.</div><div>(ie observer_ptr is the simpler cl=
ass, it shouldn&#39;t depend on shared/unique, they should depend on it)</d=
iv><div><br></div><div>Alternatively observer_ptr could have implicit conve=
rsion from anything that &quot;looks like&quot; a smart pointer?=C2=A0 Not =
sure how &quot;looks like&quot; would be safely defined.<br></div><div><br>=
</div><div><br></div><div><br></div><div> <br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex">
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYRmaYmc12EfaUiBHiO1_t-2z2fE7Nv=
dnJvkcWEhCoNSg%40mail.gmail.com" rel=3D"noreferrer" target=3D"_blank">https=
://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYRmaYmc12Efa=
UiBHiO1_t-2z2fE7NvdnJvkcWEhCoNSg%40mail.gmail.com</a>.<br>
</blockquote></div><br clear=3D"all"><br>-- <br><div dir=3D"ltr" class=3D"g=
mail_signature"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br></div=
></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbivLHMKjNH8WQ9KU9Rwb%3DGa%3Dr2SZ=
S%3DMb0gGEHgExAGYtJg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivLHM=
KjNH8WQ9KU9Rwb%3DGa%3Dr2SZS%3DMb0gGEHgExAGYtJg%40mail.gmail.com</a>.<br />

--0000000000000e7beb05791027fa--

.

On Thu, 25 Oct 2018 at 19:32, Tony V E <tvaneerd@gmail.com> wrote:
> Cool, thanks.  Here's what I've got so far:  https://github.com/tvaneerd/isocpp/blob/master/observer_ptr.md#changes
> I'm not sure it is worth making coding changes yet. Up to you of course.
>
> Now that I think of it, the implicit conversions should probably be on shared_ptr and unique_ptr cast operators, not on observer_ptr constructors.
> (ie observer_ptr is the simpler class, it shouldn't depend on shared/unique, they should depend on it)

If that's the rationale, then I don't think so - this proposal will
probably fare better the less it impacts the rest of the standard,
despite our newly-improved rationale for those conversions.

> Alternatively observer_ptr could have implicit conversion from anything that "looks like" a smart pointer?  Not sure how "looks like" would be safely defined.

Has a dereference-operator and supports the other operations that
observer_ptr will use?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUY80kVkGaWSr9Eu2cCr9R7g%2BQ_6TGivwcf6hQb82txKeg%40mail.gmail.com.

.

------=_Part_530_1169059261.1540488372387
Content-Type: multipart/alternative;
 boundary="----=_Part_531_2025310966.1540488372387"

------=_Part_531_2025310966.1540488372387
Content-Type: text/plain; charset="UTF-8"



On Thursday, October 25, 2018 at 7:32:46 PM UTC+3, Tony V E wrote:
>
>
>
> On Thu, Oct 25, 2018 at 12:21 PM Ville Voutilainen <ville.vo...@gmail.com
> <javascript:>> wrote:
>
>> On Thu, 25 Oct 2018 at 19:19, Tony V E <tvan...@gmail.com <javascript:>>
>> wrote:
>> >
>> >
>> >
>> > On Thu, Oct 25, 2018 at 1:20 AM Ville Voutilainen <
>> ville.vo...@gmail.com <javascript:>> wrote:
>> >>
>> >> On Thu, 25 Oct 2018 at 00:58, Tony V E <tvan...@gmail.com
>> <javascript:>> wrote:
>> >>
>> >> > I agree with all of this, and, to me, it makes observer_ptr worth
>> standardizing.
>> >>
>> >> You said that before, but the paper didn't materialize. :P
>> >
>> >
>> >
>> > ... yet.
>> >
>> > Hopefully next meeting.
>>
>> Alright; give me the gist of the changes you have in mind, and if you
>> can, any drafts of the paper and I'll give you
>> a regtested proper stdlib implementation that has passed the tests of
>> observer_ptr, modulo changes needed for the changes
>> we need to make.
>>
>
>

>
> Cool, thanks.  Here's what I've got so far:
> https://github.com/tvaneerd/isocpp/blob/master/observer_ptr.md#changes
> I'm not sure it is worth making coding changes yet. Up to you of course.
>
> Now that I think of it, the implicit conversions should probably be on
> shared_ptr and unique_ptr cast operators, not on observer_ptr constructors.
> (ie observer_ptr is the simpler class, it shouldn't depend on
> shared/unique, they should depend on it)
>

> Alternatively observer_ptr could have implicit conversion from anything
> that "looks like" a smart pointer?  Not sure how "looks like" would be
> safely defined.
>

As I said in my previous post - I am not sure any "ptr" is a good idea and
something people will be happy with.

For example will people reach for it when they want to have a reference to
a member, but the object itself might be in empty state?

Sure if they return a const ref and if the object is empty, they can return
a ref to a static empty object, but what about non-const ref?
The jump from a ref to a pointer is a big one and from a const ref to some
library pointer - even more so.

Compare that to optional<X&> - *anyone *will think of it first, *despite *it
has the same interface as pointer.

My point is - we should not let a room for optional<X&> if we have
observer_ptr as it is becoming ridiculous:
 - People will swear in "use raw pointer! In modern C++ raw is left for
that purpose"
 - People will swear in "use observer_ptr, it is designed for that, don't
listen to raw advocates - you can still delete it and has nasty pointer
arithmetics and what not! Abandon!"
 - People will swear in "I want ma optional<X&>! I want to deal with
objects, and references are for that! I want generic code with optional to
Just Work, don't want to switch type"

In any case, I believe there is no doubt that:
 - observer_ptr was *never *requested (as it is trivial to implement if one
wants it, *and by no mean all people want it*)
 - optional<X&> *is requested every single time one talks about optional*.
Like, seriously, no exaggeration.

If we move with observer_ptr we *must *reject optional<X&> first.

I am OK either way, but the decision must be weighted extremely carefully,
based on use cases and people needs and expectations.

For instance I doubt anyone can anticipate optional to turn into a pointer.
It is simply unexpected, learnable, but unexpected.
Where the reverse is not true - a pointer to turn into "an object that
might not be there" - this is completely expected,

mainly because people already see references as "the object" (and
rightfully so) and "might not there" is already established clearly by
optional itself.



>
>
>
>
>> --
>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYRmaYmc12EfaUiBHiO1_t-2z2fE7NvdnJvkcWEhCoNSg%40mail.gmail.com
>> .
>>
>
>
> --
> Be seeing you,
> Tony
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a965b8a7-9b3c-45e0-9cb5-736079ca4313%40isocpp.org.

------=_Part_531_2025310966.1540488372387
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, October 25, 2018 at 7:32:46 PM UTC+3,=
 Tony V E wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On =
Thu, Oct 25, 2018 at 12:21 PM Ville Voutilainen &lt;<a href=3D"javascript:"=
 target=3D"_blank" gdf-obfuscated-mailto=3D"-M4PMATvBQAJ" rel=3D"nofollow" =
onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"t=
his.href=3D&#39;javascript:&#39;;return true;">ville.vo...@gmail.com</a>&gt=
; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu,=
 25 Oct 2018 at 19:19, Tony V E &lt;<a href=3D"javascript:" target=3D"_blan=
k" gdf-obfuscated-mailto=3D"-M4PMATvBQAJ" rel=3D"nofollow" onmousedown=3D"t=
his.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;=
javascript:&#39;;return true;">tvan...@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Thu, Oct 25, 2018 at 1:20 AM Ville Voutilainen &lt;<a href=3D"javas=
cript:" target=3D"_blank" gdf-obfuscated-mailto=3D"-M4PMATvBQAJ" rel=3D"nof=
ollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" oncli=
ck=3D"this.href=3D&#39;javascript:&#39;;return true;">ville.vo...@gmail.com=
</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Thu, 25 Oct 2018 at 00:58, Tony V E &lt;<a href=3D"javascript:"=
 target=3D"_blank" gdf-obfuscated-mailto=3D"-M4PMATvBQAJ" rel=3D"nofollow" =
onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"t=
his.href=3D&#39;javascript:&#39;;return true;">tvan...@gmail.com</a>&gt; wr=
ote:<br>
&gt;&gt;<br>
&gt;&gt; &gt; I agree with all of this, and, to me, it makes observer_ptr w=
orth standardizing.<br>
&gt;&gt;<br>
&gt;&gt; You said that before, but the paper didn&#39;t materialize. :P<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; ... yet.<br>
&gt;<br>
&gt; Hopefully next meeting.<br>
<br>
Alright; give me the gist of the changes you have in mind, and if you<br>
can, any drafts of the paper and I&#39;ll give you<br>
a regtested proper stdlib implementation that has passed the tests of<br>
observer_ptr, modulo changes needed for the changes<br>
we need to make.<br></blockquote><div><br></div></div></div></div></blockqu=
ote><div>=C2=A0</div><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 dir=3D"ltr"><div class=3D"gmail_quote"><div></div><div><br></=
div><div>Cool, thanks.=C2=A0 Here&#39;s what I&#39;ve got so far:=C2=A0 <a =
href=3D"https://github.com/tvaneerd/isocpp/blob/master/observer_ptr.md#chan=
ges" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;htt=
ps://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Ftvaneerd%2Fisocpp%2=
Fblob%2Fmaster%2Fobserver_ptr.md%23changes\x26sa\x3dD\x26sntz\x3d1\x26usg\x=
3dAFQjCNHPh-HIv_ZAUVLj_Vz2m06hmPGNTg&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Ftvaneer=
d%2Fisocpp%2Fblob%2Fmaster%2Fobserver_ptr.md%23changes\x26sa\x3dD\x26sntz\x=
3d1\x26usg\x3dAFQjCNHPh-HIv_ZAUVLj_Vz2m06hmPGNTg&#39;;return true;">https:/=
/github.com/tvaneerd/<wbr>isocpp/blob/master/observer_<wbr>ptr.md#changes</=
a><br></div><div>I&#39;m not sure it is worth making coding changes yet. Up=
 to you of course.<br></div><div><br></div><div>Now that I think of it, the=
 implicit conversions should probably be on shared_ptr and unique_ptr cast =
operators, not on observer_ptr constructors.</div><div>(ie observer_ptr is =
the simpler class, it shouldn&#39;t depend on shared/unique, they should de=
pend on it)=C2=A0</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 dir=3D"ltr"><div class=3D"gma=
il_quote"><div><br></div><div>Alternatively observer_ptr could have implici=
t conversion from anything that &quot;looks like&quot; a smart pointer?=C2=
=A0 Not sure how &quot;looks like&quot; would be safely defined.<br></div><=
/div></div></div></blockquote><div><br></div><div>As I said in my previous =
post - I am not sure any &quot;ptr&quot; is a good idea and something peopl=
e will be happy with.</div><div><br></div><div>For example will people reac=
h for it when they want to have a reference to a member, but the object its=
elf might be in empty state?</div><div><br></div><div>Sure if they return a=
 const ref and if the object is empty, they can return a ref to a static em=
pty object, but what about non-const ref?</div><div>The jump from a ref to =
a pointer is a big one and from a const ref to some library pointer - even =
more so.</div><div><br></div><div>Compare that to optional&lt;X&amp;&gt; - =
<i>anyone </i>will think of it first, <i>despite </i>it has the same interf=
ace=C2=A0as pointer.</div><div><br></div><div>My point is - we should not l=
et a room for optional&lt;X&amp;&gt; if we have observer_ptr as it is becom=
ing ridiculous:=C2=A0</div><div>=C2=A0- People will swear in &quot;use raw =
pointer! In modern C++ raw is left for that purpose&quot;</div><div>=C2=A0-=
 People will swear in &quot;use observer_ptr, it is designed for that, don&=
#39;t listen to raw advocates - you can still delete it and has nasty point=
er arithmetics and what not! Abandon!&quot;</div><div>=C2=A0- People will s=
wear in=C2=A0&quot;I want ma optional&lt;X&amp;&gt;! I want to deal with ob=
jects, and references are for that! I want generic code with optional to Ju=
st Work, don&#39;t want to switch type&quot;</div><div><br></div><div>In an=
y case, I believe there is no doubt that:</div><div>=C2=A0- observer_ptr wa=
s <i>never </i>requested (as it is trivial to implement if one wants it, <i=
>and by no mean all people want it</i>)</div><div>=C2=A0- optional&lt;X&amp=
;&gt; <i>is requested every single time one talks about optional</i>. Like,=
 seriously, no exaggeration.</div><div>=C2=A0</div><div>If we move with obs=
erver_ptr we <i>must </i>reject optional&lt;X&amp;&gt; first.=C2=A0</div><d=
iv><br></div><div>I am OK either way, but the decision must be weighted ext=
remely carefully, based on use cases and people needs and expectations.</di=
v><div><br></div><div>For instance I doubt anyone can anticipate optional t=
o turn into a pointer. It is simply unexpected, learnable, but unexpected.=
=C2=A0</div><div>Where the reverse is not true - a pointer to turn into &qu=
ot;an object that might not be there&quot; - this is completely expected,=
=C2=A0</div><div><br></div><div>mainly because people already see reference=
s as &quot;the object&quot; (and rightfully so) and &quot;might not there&q=
uot; is already established clearly by optional itself.</div><div><br></div=
><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 dir=3D"lt=
r"><div dir=3D"ltr"><div class=3D"gmail_quote"><div></div><div><br></div><d=
iv><br></div><div><br></div><div> <br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
-M4PMATvBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"-M4PMATvBQAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYRmaYmc12EfaUiBHiO1_t-2z2fE7Nv=
dnJvkcWEhCoNSg%40mail.gmail.com" rel=3D"nofollow" target=3D"_blank" onmouse=
down=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/CAFk2RUYRmaYmc12EfaUiBHiO1_t-2z2fE7NvdnJvkcWEhCoNSg%40mail.gmail=
..com&#39;;return true;" onclick=3D"this.href=3D&#39;https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYRmaYmc12EfaUiBHiO1_t-2z2fE7Nv=
dnJvkcWEhCoNSg%40mail.gmail.com&#39;;return true;">https://groups.google.co=
m/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/<wbr>CAFk2RUYRmaYmc12EfaUiBH=
iO1_t-<wbr>2z2fE7NvdnJvkcWEhCoNSg%40mail.<wbr>gmail.com</a>.<br>
</blockquote></div><br clear=3D"all"><br>-- <br><div dir=3D"ltr"><div dir=
=3D"ltr"><div>Be seeing you,<br></div>Tony<br></div></div></div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a965b8a7-9b3c-45e0-9cb5-736079ca4313%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a965b8a7-9b3c-45e0-9cb5-736079ca4313=
%40isocpp.org</a>.<br />

------=_Part_531_2025310966.1540488372387--

------=_Part_530_1169059261.1540488372387--

.

On Thu, 25 Oct 2018 at 20:26, <mihailnajdenov@gmail.com> wrote:
> In any case, I believe there is no doubt that:
>  - observer_ptr was never requested (as it is trivial to implement if one wants it, and by no mean all people want it)

It appeared out of thin air? It was approved into the TS even though
nobody wants it?

> If we move with observer_ptr we must reject optional<X&> first.
>
> I am OK either way, but the decision must be weighted extremely carefully, based on use cases and people needs and expectations.
>
> For instance I doubt anyone can anticipate optional to turn into a pointer. It is simply unexpected, learnable, but unexpected.
> Where the reverse is not true - a pointer to turn into "an object that might not be there" - this is completely expected,
>
> mainly because people already see references as "the object" (and rightfully so) and "might not there" is already established clearly by optional itself.

An optional<T&> doesn't do what observer_ptr<T> does. The latter can
give you a null pointer when you ask its pointer value, so it can
model
"yes, I have a pointer, but it doesn't point to anything". The former
models "I may or may not have anything".

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYcVuz2WpDoC3rFOjpBvk85R1Wt2APhBdGJ2znETywmEA%40mail.gmail.com.

.

------=_Part_375_766288855.1540494341028
Content-Type: multipart/alternative;
 boundary="----=_Part_376_2021309341.1540494341028"

------=_Part_376_2021309341.1540494341028
Content-Type: text/plain; charset="UTF-8"



On Thursday, October 25, 2018 at 8:34:49 PM UTC+3, Ville Voutilainen wrote:
>
> On Thu, 25 Oct 2018 at 20:26, <mihailn...@gmail.com <javascript:>> wrote:
> > In any case, I believe there is no doubt that:
> >  - observer_ptr was never requested (as it is trivial to implement if
> one wants it, and by no mean all people want it)
>


> It appeared out of thin air? It was approved into the TS even though
> nobody wants it?
>

People requesting it? I have seen many people agreeing there is need for
such a thing, but have not seen requests for it, like real wishlist and
request "please, do this already".
I haven't said noone needs it, Just that people are not requesting it.
I have also seen plenty of *hate *against it though, and plenty request for
option reference.


>
> > If we move with observer_ptr we must reject optional<X&> first.
> >
> > I am OK either way, but the decision must be weighted extremely
> carefully, based on use cases and people needs and expectations.
> >
> > For instance I doubt anyone can anticipate optional to turn into a
> pointer. It is simply unexpected, learnable, but unexpected.
> > Where the reverse is not true - a pointer to turn into "an object that
> might not be there" - this is completely expected,
> >
> > mainly because people already see references as "the object" (and
> rightfully so) and "might not there" is already established clearly by
> optional itself.
>


> An optional<T&> doesn't do what observer_ptr<T> does. The latter can
> give you a null pointer when you ask its pointer value, so it can
> model
> "yes, I have a pointer, but it doesn't point to anything". The former
> models "I may or may not have anything".
>

Fair enough, question is do we need both?

If we have both, will optional convert to optional ref and pointers to
observer pointer?

If we don't have both, do we like the pointer model or the "has-a model"
(even with the looser definition of "has") to represent objects?


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/de70bdff-360f-49a7-a0ed-c635a15c2b05%40isocpp.org.

------=_Part_376_2021309341.1540494341028
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, October 25, 2018 at 8:34:49 PM UTC+3,=
 Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Th=
u, 25 Oct 2018 at 20:26, &lt;<a href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"U_Sr-WbyBQAJ" rel=3D"nofollow" onmousedown=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;">mihailn...@gmail.com</a>&gt; wrote:
<br>&gt; In any case, I believe there is no doubt that:
<br>&gt; =C2=A0- observer_ptr was never requested (as it is trivial to impl=
ement if one wants it, and by no mean all people want it)
<br></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">It appeared out of thin air? It was approved into the TS even though
<br>nobody wants it?
<br></blockquote><div><br></div><div>People requesting it? I have seen many=
 people agreeing there is need for such a thing, but have not seen requests=
 for it, like real wishlist and request &quot;please, do this already&quot;=
..</div><div>I haven&#39;t said noone needs it, Just that people are not req=
uesting it.=C2=A0=C2=A0</div><div>I have also seen plenty of <i>hate </i>ag=
ainst it though, and plenty request for option reference.=C2=A0</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; If we move with observer_ptr we must reject optional&lt;X&amp;&gt;=
 first.
<br>&gt;
<br>&gt; I am OK either way, but the decision must be weighted extremely ca=
refully, based on use cases and people needs and expectations.
<br>&gt;
<br>&gt; For instance I doubt anyone can anticipate optional to turn into a=
 pointer. It is simply unexpected, learnable, but unexpected.
<br>&gt; Where the reverse is not true - a pointer to turn into &quot;an ob=
ject that might not be there&quot; - this is completely expected,
<br>&gt;
<br>&gt; mainly because people already see references as &quot;the object&q=
uot; (and rightfully so) and &quot;might not there&quot; is already establi=
shed clearly by optional itself.
<br></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">An optional&lt;T&amp;&gt; doesn&#39;t do what observer_ptr&lt;T&gt; d=
oes. The latter can
<br>give you a null pointer when you ask its pointer value, so it can
<br>model
<br>&quot;yes, I have a pointer, but it doesn&#39;t point to anything&quot;=
.. The former
<br>models &quot;I may or may not have anything&quot;.
<br></blockquote><div><br></div><div>Fair enough, question is do we need bo=
th?=C2=A0</div><div><br></div><div>If we have both, will optional convert t=
o optional ref and pointers to observer pointer?</div><div><br></div><div><=
div>If we don&#39;t have both, do we like the pointer model or the &quot;ha=
s-a model&quot; (even with the looser definition of &quot;has&quot;) to rep=
resent objects?</div></div><div><br></div><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/de70bdff-360f-49a7-a0ed-c635a15c2b05%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/de70bdff-360f-49a7-a0ed-c635a15c2b05=
%40isocpp.org</a>.<br />

------=_Part_376_2021309341.1540494341028--

------=_Part_375_766288855.1540494341028--

.

On Thu, Oct 25, 2018 at 7:34 PM Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
>
> On Thu, 25 Oct 2018 at 20:26, <mihailnajdenov@gmail.com> wrote:
> > In any case, I believe there is no doubt that:
> >  - observer_ptr was never requested (as it is trivial to implement if one wants it, and by no mean all people want it)
>
> It appeared out of thin air? It was approved into the TS even though
> nobody wants it?
>
> > If we move with observer_ptr we must reject optional<X&> first.
> >
> > I am OK either way, but the decision must be weighted extremely carefully, based on use cases and people needs and expectations.
> >
> > For instance I doubt anyone can anticipate optional to turn into a pointer. It is simply unexpected, learnable, but unexpected.
> > Where the reverse is not true - a pointer to turn into "an object that might not be there" - this is completely expected,
> >
> > mainly because people already see references as "the object" (and rightfully so) and "might not there" is already established clearly by optional itself.
>
> An optional<T&> doesn't do what observer_ptr<T> does. The latter can
> give you a null pointer when you ask its pointer value, so it can
> model
> "yes, I have a pointer, but it doesn't point to anything". The former
> models "I may or may not have anything".

That is the same thing. Unless you want pointers pointing to invalid
addresses, and I am sure you don't :-)

Cheers,
Miguel

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANiq72mByDkQB3C0nfUegzYRD30T3B15HMw2_yiQvBPUH7D2%2Bw%40mail.gmail.com.

.

End pointers (like end iterators) point to non-objects.


Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce
=C2=A0 Original Message =C2=A0
From: Miguel Ojeda
Sent: Thursday, October 25, 2018 3:41 PM
To: std-proposals@isocpp.org
Reply To: std-proposals@isocpp.org
Subject: Re: [std-proposals] shared_ptr and unique_ptr should both implicit=
ly convert to observer_ptr

On Thu, Oct 25, 2018 at 7:34 PM Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
>
> On Thu, 25 Oct 2018 at 20:26, <mihailnajdenov@gmail.com> wrote:
> > In any case, I believe there is no doubt that:
> > - observer_ptr was never requested (as it is trivial to implement if on=
e wants it, and by no mean all people want it)
>
> It appeared out of thin air? It was approved into the TS even though
> nobody wants it?
>
> > If we move with observer_ptr we must reject optional<X&> first.
> >
> > I am OK either way, but the decision must be weighted extremely careful=
ly, based on use cases and people needs and expectations.
> >
> > For instance I doubt anyone can anticipate optional to turn into a poin=
ter. It is simply unexpected, learnable, but unexpected.
> > Where the reverse is not true - a pointer to turn into "an object that =
might not be there" - this is completely expected,
> >
> > mainly because people already see references as "the object" (and right=
fully so) and "might not there" is already established clearly by optional =
itself.
>
> An optional<T&> doesn't do what observer_ptr<T> does. The latter can
> give you a null pointer when you ask its pointer value, so it can
> model
> "yes, I have a pointer, but it doesn't point to anything". The former
> models "I may or may not have anything".

That is the same thing. Unless you want pointers pointing to invalid
addresses, and I am sure you don't :-)

Cheers,
Miguel

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CANiq72mByDkQB3C0nfUegzYRD30T3B15HMw2_yiQvBPUH7D=
2%2Bw%40mail.gmail.com.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/20181025194255.5218385.32854.64318%40gmail.com.

.

On Thu, Oct 25, 2018 at 9:42 PM Tony V E <tvaneerd@gmail.com> wrote:
>
> End pointers (like end iterators) point to non-objects.

Then it is not an observer_ptr, because it does not observe anything ;-)

Seriously: on one hand you argue "we need modern C++", on the other
hand, you want to go for yet another pointer type, when the actual
semantics you want is either optional references (as in built-in) or
optional of references (as in optional<T&>). Further, if you want
iterators, you should write an iterator class, not an observer_ptr and
use it as such.

To me, observer_ptr is going in the wrong direction, i.e. "older C++".
I agree that the idea on itself can help some projects (e.g. those
that are already passing everywhere smart pointers) and maybe you can
argue you want it in the standard "for completeness". However, I don't
agree it is the best approach.

Cheers,
Miguel

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANiq72k_C_SQMMzj1HWz%2B6N8xMx5LOuDk%3DbN%3Dj2mxq6NeoebWw%40mail.gmail.com.

.

On Thu, 25 Oct 2018 at 22:41, Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:

> > An optional<T&> doesn't do what observer_ptr<T> does. The latter can
> > give you a null pointer when you ask its pointer value, so it can
> > model
> > "yes, I have a pointer, but it doesn't point to anything". The former
> > models "I may or may not have anything".
>
> That is the same thing.

Yeah, except that it isn't, so feel free to try again.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYo3TZ-3Ngnid5ypgksLAshNXNf2GvFT-KEoHnDmCYNxg%40mail.gmail.com.

.

On Thu, Oct 25, 2018 at 9:49 PM Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
>
> On Thu, 25 Oct 2018 at 22:41, Miguel Ojeda
> <miguel.ojeda.sandonis@gmail.com> wrote:
>
> > > An optional<T&> doesn't do what observer_ptr<T> does. The latter can
> > > give you a null pointer when you ask its pointer value, so it can
> > > model
> > > "yes, I have a pointer, but it doesn't point to anything". The former
> > > models "I may or may not have anything".
> >
> > That is the same thing.
>
> Yeah, except that it isn't, so feel free to try again.

"Feel free to try again", excuse me? Being rude won't help your case.

Give an example where it would make a difference, or acknowledge there
isn't one. It is that simple.

Cheers,
Miguel

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANiq72%3D0kNTCSmRZ_gGHzoi_FhWMm_LspH5-b6cuXXOES%2BcKQQ%40mail.gmail.com.

.

On Thu, 25 Oct 2018 at 22:55, Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Thu, Oct 25, 2018 at 9:49 PM Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
> >
> > On Thu, 25 Oct 2018 at 22:41, Miguel Ojeda
> > <miguel.ojeda.sandonis@gmail.com> wrote:
> >
> > > > An optional<T&> doesn't do what observer_ptr<T> does. The latter can
> > > > give you a null pointer when you ask its pointer value, so it can
> > > > model
> > > > "yes, I have a pointer, but it doesn't point to anything". The former
> > > > models "I may or may not have anything".
> > >
> > > That is the same thing.
> >
> > Yeah, except that it isn't, so feel free to try again.
>
> "Feel free to try again", excuse me? Being rude won't help your case.
>
> Give an example where it would make a difference, or acknowledge there
> isn't one. It is that simple.

It is equally simple for you to show how they are the same,
apparently. If you want to complain
about rudeness, then stop making claims with zero evidence and then
complaining when they are not
blindly accepted.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYXCZ14eSO3VGMxWg%2B7A%2BWsa%3D1ogzqzGfL76bZWB77nfA%40mail.gmail.com.

.

------=_Part_523_1994002327.1540498427079
Content-Type: multipart/alternative;
 boundary="----=_Part_524_836855516.1540498427079"

------=_Part_524_836855516.1540498427079
Content-Type: text/plain; charset="UTF-8"



On Thursday, October 25, 2018 at 3:01:56 PM UTC-5, Ville Voutilainen wrote:
>
> On Thu, 25 Oct 2018 at 22:55, Miguel Ojeda
> <miguel.oje...@gmail.com <javascript:>> wrote:
> >
> > On Thu, Oct 25, 2018 at 9:49 PM Ville Voutilainen
> > <ville.vo...@gmail.com <javascript:>> wrote:
> > >
> > > On Thu, 25 Oct 2018 at 22:41, Miguel Ojeda
> > > <miguel.oje...@gmail.com <javascript:>> wrote:
> > >
> > > > > An optional<T&> doesn't do what observer_ptr<T> does. The latter
> can
> > > > > give you a null pointer when you ask its pointer value, so it can
> > > > > model
> > > > > "yes, I have a pointer, but it doesn't point to anything". The
> former
> > > > > models "I may or may not have anything".
> > > >
> > > > That is the same thing.
> > >
> > > Yeah, except that it isn't, so feel free to try again.
> >
> > "Feel free to try again", excuse me? Being rude won't help your case.
> >
> > Give an example where it would make a difference, or acknowledge there
> > isn't one. It is that simple.
>
> It is equally simple for you to show how they are the same,
> apparently. If you want to complain
> about rudeness, then stop making claims with zero evidence and then
> complaining when they are not
> blindly accepted.
>


Saying we don't need optional<T&> because we have observer_ptr<T> (or vice
versa) is roughly equivalent to saying we don't need string_view because we
already have pair<char const*, size_t>.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/45960c17-ed9a-46f2-ba05-af819e975a53%40isocpp.org.

------=_Part_524_836855516.1540498427079
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, October 25, 2018 at 3:01:56 PM UTC-5,=
 Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Th=
u, 25 Oct 2018 at 22:55, Miguel Ojeda
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
Rh4HDW76BQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">miguel.oje...@gmail.<wbr>com</a>&gt; wrote:
<br>&gt;
<br>&gt; On Thu, Oct 25, 2018 at 9:49 PM Ville Voutilainen
<br>&gt; &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"Rh4HDW76BQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">ville.vo...@gmail.com</a>&gt; wrote:
<br>&gt; &gt;
<br>&gt; &gt; On Thu, 25 Oct 2018 at 22:41, Miguel Ojeda
<br>&gt; &gt; &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"Rh4HDW76BQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;ja=
vascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;r=
eturn true;">miguel.oje...@gmail.<wbr>com</a>&gt; wrote:
<br>&gt; &gt;
<br>&gt; &gt; &gt; &gt; An optional&lt;T&amp;&gt; doesn&#39;t do what obser=
ver_ptr&lt;T&gt; does. The latter can
<br>&gt; &gt; &gt; &gt; give you a null pointer when you ask its pointer va=
lue, so it can
<br>&gt; &gt; &gt; &gt; model
<br>&gt; &gt; &gt; &gt; &quot;yes, I have a pointer, but it doesn&#39;t poi=
nt to anything&quot;. The former
<br>&gt; &gt; &gt; &gt; models &quot;I may or may not have anything&quot;.
<br>&gt; &gt; &gt;
<br>&gt; &gt; &gt; That is the same thing.
<br>&gt; &gt;
<br>&gt; &gt; Yeah, except that it isn&#39;t, so feel free to try again.
<br>&gt;
<br>&gt; &quot;Feel free to try again&quot;, excuse me? Being rude won&#39;=
t help your case.
<br>&gt;
<br>&gt; Give an example where it would make a difference, or acknowledge t=
here
<br>&gt; isn&#39;t one. It is that simple.
<br>
<br>It is equally simple for you to show how they are the same,
<br>apparently. If you want to complain
<br>about rudeness, then stop making claims with zero evidence and then
<br>complaining when they are not
<br>blindly accepted.
<br></blockquote><div><br></div><div><br></div><div>Saying we don&#39;t nee=
d optional&lt;T&amp;&gt; because we have observer_ptr&lt;T&gt; (or vice ver=
sa) is roughly equivalent to saying we don&#39;t need string_view because w=
e already have pair&lt;char const*, size_t&gt;.=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/45960c17-ed9a-46f2-ba05-af819e975a53%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/45960c17-ed9a-46f2-ba05-af819e975a53=
%40isocpp.org</a>.<br />

------=_Part_524_836855516.1540498427079--

------=_Part_523_1994002327.1540498427079--

.

On Thu, Oct 25, 2018 at 10:01 PM Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
>
> On Thu, 25 Oct 2018 at 22:55, Miguel Ojeda
> <miguel.ojeda.sandonis@gmail.com> wrote:
> >
> > "Feel free to try again", excuse me? Being rude won't help your case.
> >
> > Give an example where it would make a difference, or acknowledge there
> > isn't one. It is that simple.
>
> It is equally simple for you to show how they are the same,
> apparently.

Not at all. I claimed they are the same, since I don't know any
practical difference. You claimed you *do* know some difference, so I
simply asked that you state it, since you *already* know it -- as you
have claimed. Therefore, it should be simpler for you.

> If you want to complain
> about rudeness, then stop making claims with zero evidence and then
> complaining when they are not
> blindly accepted.

Even if it was true I gave "zero evidence" (which it isn't), that
doesn't mean I am being rude. However, you are being rude by stating
publicly "you are wrong; feel free to try again", as if I had to prove
something. No, sorry, the one making the proposal is you, so *you* are
the one that has to prove its validity.

Cheers,
Miguel

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANiq72n3rMda2GydaGyGkZgda8%3D0PfWqNEjRRMwuk-1DZiuoPA%40mail.gmail.com.

.

------=_Part_550_663009008.1540499944672
Content-Type: multipart/alternative;
 boundary="----=_Part_551_1145707963.1540499944672"

------=_Part_551_1145707963.1540499944672
Content-Type: text/plain; charset="UTF-8"



On Thursday, October 25, 2018 at 10:55:16 PM UTC+3, Miguel Ojeda wrote:
>
> On Thu, Oct 25, 2018 at 9:49 PM Ville Voutilainen
> <ville.vo...@gmail.com <javascript:>> wrote:
> >
> > On Thu, 25 Oct 2018 at 22:41, Miguel Ojeda
> > <miguel.oje...@gmail.com <javascript:>> wrote:
> >
> > > > An optional<T&> doesn't do what observer_ptr<T> does. The latter can
> > > > give you a null pointer when you ask its pointer value, so it can
> > > > model
> > > > "yes, I have a pointer, but it doesn't point to anything". The
> former
> > > > models "I may or may not have anything".
> > >
> > > That is the same thing.
> >
> > Yeah, except that it isn't, so feel free to try again.
>
> "Feel free to try again", excuse me? Being rude won't help your case.
>
> Give an example where it would make a difference, or acknowledge there
> isn't one. It is that simple.
>

Well, one is an object wrapper, the other is pointer wrapper.

If the pointer (as an object) is of importance then observer_ptr is more
logical.
For example if you store it in a set, you might reach for observer_ptr
first as it maps really well to the mental model of "a handle" that can be
hashed on its value.

optional ref is much more higher level - it tries to present a real object
it does not have that handle aspect of it and to get to the real pointer
would be hard and unintuitive.
People will reach for it to be a view of on object or sub-object, but when
they need to put it a set, they might wonder - will this hash on "the
pointer" or on the object.



Yet having both seems overkill and if we do, what we would recommend as a
go-to interface if one does not want to force normal reference on its users
and we advise against memory managing types in interfaces.



>
> Cheers,
> Miguel
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/eca87717-200c-419f-a8e5-f9850fdfe797%40isocpp.org.

------=_Part_551_1145707963.1540499944672
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, October 25, 2018 at 10:55:16 PM UTC+3=
, Miguel Ojeda wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thu, O=
ct 25, 2018 at 9:49 PM Ville Voutilainen
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
Ns0tEBH6BQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">ville.vo...@gmail.com</a>&gt; wrote:
<br>&gt;
<br>&gt; On Thu, 25 Oct 2018 at 22:41, Miguel Ojeda
<br>&gt; &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"Ns0tEBH6BQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">miguel.oje...@gmail.<wbr>com</a>&gt; wrote:
<br>&gt;
<br>&gt; &gt; &gt; An optional&lt;T&amp;&gt; doesn&#39;t do what observer_p=
tr&lt;T&gt; does. The latter can
<br>&gt; &gt; &gt; give you a null pointer when you ask its pointer value, =
so it can
<br>&gt; &gt; &gt; model
<br>&gt; &gt; &gt; &quot;yes, I have a pointer, but it doesn&#39;t point to=
 anything&quot;. The former
<br>&gt; &gt; &gt; models &quot;I may or may not have anything&quot;.
<br>&gt; &gt;
<br>&gt; &gt; That is the same thing.
<br>&gt;
<br>&gt; Yeah, except that it isn&#39;t, so feel free to try again.
<br>
<br>&quot;Feel free to try again&quot;, excuse me? Being rude won&#39;t hel=
p your case.
<br>
<br>Give an example where it would make a difference, or acknowledge there
<br>isn&#39;t one. It is that simple.
<br></blockquote><div><br></div><div>Well, one is an object wrapper, the ot=
her is pointer wrapper.=C2=A0</div><div><br></div><div>If the pointer (as a=
n object) is of importance then observer_ptr is more logical.=C2=A0</div><d=
iv>For example if you store it in a set, you might reach for observer_ptr f=
irst as it maps really well to the mental model of &quot;a handle&quot; tha=
t can be hashed on its value.</div><div><br></div><div>optional ref is much=
 more higher level - it tries to present a real object=C2=A0 it does not ha=
ve that handle aspect of it and to get to the real pointer would be hard an=
d unintuitive.=C2=A0</div><div>People will reach for it to be a view of on =
object or sub-object, but when they need to put it a set, they might wonder=
 - will this hash on &quot;the pointer&quot; or on the object.=C2=A0</div><=
div>=C2=A0</div><div><br></div><div><br></div><div>Yet having both seems ov=
erkill and if we do, what we would recommend as a go-to interface if one do=
es not want to force normal reference on its users and we advise against me=
mory managing types in interfaces.=C2=A0=C2=A0</div><div><br></div><div>=C2=
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Cheers,
<br>Miguel
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/eca87717-200c-419f-a8e5-f9850fdfe797%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/eca87717-200c-419f-a8e5-f9850fdfe797=
%40isocpp.org</a>.<br />

------=_Part_551_1145707963.1540499944672--

------=_Part_550_663009008.1540499944672--

.

On Thu, 25 Oct 2018 at 23:31, Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:

> Even if it was true I gave "zero evidence" (which it isn't), that
> doesn't mean I am being rude. However, you are being rude by stating
> publicly "you are wrong; feel free to try again", as if I had to prove
> something. No, sorry, the one making the proposal is you, so *you* are
> the one that has to prove its validity.

Let's repeat, then:

An optional<T&> doesn't do what observer_ptr<T> does. The latter can
give you a null pointer when you ask its pointer value, so it can
model
"yes, I have a pointer, but it doesn't point to anything". The former
models "I may or may not have anything".

I can always get the pointer value from an observer_ptr. I can't get a
value from an optional<T&> when it has none.

Furthermore,
1) I am not making a proposal.
2) If I were, I wouldn't waste my time explaining it here.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYdibw_0w%2BO0Cy49ZTBKq4ibo%3DpP2AocEWE_LE_zr%2Bx4g%40mail.gmail.com.

.

--000000000000148804057913fb5c
Content-Type: text/plain; charset="UTF-8"

On Thu, Oct 25, 2018 at 4:59 PM Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On Thu, 25 Oct 2018 at 23:31, Miguel Ojeda
> <miguel.ojeda.sandonis@gmail.com> wrote:
>
> > Even if it was true I gave "zero evidence" (which it isn't), that
> > doesn't mean I am being rude. However, you are being rude by stating
> > publicly "you are wrong; feel free to try again", as if I had to prove
> > something. No, sorry, the one making the proposal is you, so *you* are
> > the one that has to prove its validity.
>
> Let's repeat, then:
>
> An optional<T&> doesn't do what observer_ptr<T> does. The latter can
> give you a null pointer when you ask its pointer value, so it can
> model
> "yes, I have a pointer, but it doesn't point to anything". The former
> models "I may or may not have anything".
>
> I can always get the pointer value from an observer_ptr. I can't get a
> value from an optional<T&> when it has none.
>
> Furthermore,
> 1) I am not making a proposal.
> 2) If I were, I wouldn't waste my time explaining it here.
>
>
Also, a container of observer_ptrs would sort by the pointer value (ie
address).
I'm not sure how optional<T&> would sort, and if it would be sortable at
all.


--
Be seeing you,
Tony

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivJ%2B%2BPFDnTksQHqdQPMQWmocFuyoSzOzRxkHz0Jg-Dokw%40mail.gmail.com.

--000000000000148804057913fb5c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu=
, Oct 25, 2018 at 4:59 PM Ville Voutilainen &lt;<a href=3D"mailto:ville.vou=
tilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">On Thu, 25 Oct 2018 at 23:31, Miguel Ojeda<br>
&lt;<a href=3D"mailto:miguel.ojeda.sandonis@gmail.com" target=3D"_blank">mi=
guel.ojeda.sandonis@gmail.com</a>&gt; wrote:<br>
<br>
&gt; Even if it was true I gave &quot;zero evidence&quot; (which it isn&#39=
;t), that<br>
&gt; doesn&#39;t mean I am being rude. However, you are being rude by stati=
ng<br>
&gt; publicly &quot;you are wrong; feel free to try again&quot;, as if I ha=
d to prove<br>
&gt; something. No, sorry, the one making the proposal is you, so *you* are=
<br>
&gt; the one that has to prove its validity.<br>
<br>
Let&#39;s repeat, then:<br>
<br>
An optional&lt;T&amp;&gt; doesn&#39;t do what observer_ptr&lt;T&gt; does. T=
he latter can<br>
give you a null pointer when you ask its pointer value, so it can<br>
model<br>
&quot;yes, I have a pointer, but it doesn&#39;t point to anything&quot;. Th=
e former<br>
models &quot;I may or may not have anything&quot;.<br>
<br>
I can always get the pointer value from an observer_ptr. I can&#39;t get a<=
br>
value from an optional&lt;T&amp;&gt; when it has none.<br>
<br>
Furthermore,<br>
1) I am not making a proposal.<br>
2) If I were, I wouldn&#39;t waste my time explaining it here.<br>
<br></blockquote><div><br></div><div>Also, a container of observer_ptrs wou=
ld sort by the pointer value (ie address).</div><div>I&#39;m not sure how o=
ptional&lt;T&amp;&gt; would sort, and if it would be sortable at all.<br></=
div><br clear=3D"all"></div><br>-- <br><div dir=3D"ltr" class=3D"gmail_sign=
ature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing y=
ou,<br></div>Tony<br></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbivJ%2B%2BPFDnTksQHqdQPMQWmocFuy=
oSzOzRxkHz0Jg-Dokw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivJ%2B%=
2BPFDnTksQHqdQPMQWmocFuyoSzOzRxkHz0Jg-Dokw%40mail.gmail.com</a>.<br />

--000000000000148804057913fb5c--

.

On 10/25/2018 10:58 PM, Ville Voutilainen wrote:
> An optional<T&> doesn't do what observer_ptr<T> does. The latter can
> give you a null pointer when you ask its pointer value, so it can
> model
> "yes, I have a pointer, but it doesn't point to anything". The former
> models "I may or may not have anything".

May be a language problem but I still fail to see a practical
difference. Like one between "I do nothing"  and "I don't do anything".

The null pointer and the empty opt_ref both designate no object at the
other end while a non-null pointer and the nonempty ref does.

(really just weighing to to point out that the difference you see is not
at all evident, and the previous poster is not baffled alone)

> I can always get the pointer value from an observer_ptr. I can't get a
> value from an optional<T&> when it has none.

unless you use the value_or() interface -- but the whole usage makes
even less sense. observer_ptr looks superfluous enough being just a
pointer-wrapper compared to raw pointers (I assign low value to
protection from using + and [] with it), but okay, let's substitute our
pointers with that. So we will pass them around and use */-> and the
bool check.

What kind of system want to extract the raw pointer from it?

 From an earlier post:

 >>Well... writing modern C++ (in my sense of modern) it is. A raw
pointer is newer owned.
 >This is, to me, a fairly astonishing part of what some call "modern"
 >C++. Instead of enforcing semantics with
 >a type, they are loosely agreed on by an unenforceable convention.
 >That seems like a massive
 >step backwards, instead of being modern.

I somewhat agree with going against "modern" here, as that is IME one of
the most fundamental guides we use in C++ I use approaching 30 years.

Wasn't RAII the main feature of C++ from boot? Is "resource allocation"
it designates mean really *ownership*? Isn't owning pointer looking at a
resource that is supposed to stand out?  Granted immediately to care of
some handling type?

IMNSHO the guideline to not having raw pointers with ownership sitting
around in a program is one of the few universally agreed upon.

And if we put it to use, what the remaining pointers will be if not
non-owning observers?

Tony said upstream "When you have a raw pointer, ownership is not
(typically) obvious." -- I say if that holds for your project you are in
deep trouble.

I did join several such projects and one of the first tasks were to
address this very mess. And I did not expect the bug count go down
before that cleanup done.

Where "modern" C++ helped was adding the move semantics to the language,
so many typical owners now can revert to natural state, no longer
forcing shared_ptr or homemade refcounted pointers where we really never
meant sharing, just convenient way to pass a thing between 2 points in
code.











--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/10e5250e-6d56-6bc0-8d8f-3bb971312180%40lib.hu.

.

------=_Part_678_414412910.1540537682447
Content-Type: multipart/alternative;
 boundary="----=_Part_679_173420815.1540537682447"

------=_Part_679_173420815.1540537682447
Content-Type: text/plain; charset="UTF-8"



On Friday, October 26, 2018 at 12:35:42 AM UTC+3, Balog Pal wrote:
>
> On 10/25/2018 10:58 PM, Ville Voutilainen wrote:
> > An optional<T&> doesn't do what observer_ptr<T> does. The latter can
> > give you a null pointer when you ask its pointer value, so it can
> > model
> > "yes, I have a pointer, but it doesn't point to anything". The former
> > models "I may or may not have anything".
>
> May be a language problem but I still fail to see a practical
> difference. Like one between "I do nothing"  and "I don't do anything".
>
> The null pointer and the empty opt_ref both designate no object at the
> other end while a non-null pointer and the nonempty ref does.
>
> (really just weighing to to point out that the difference you see is not
> at all evident, and the previous poster is not baffled alone)
>
> > I can always get the pointer value from an observer_ptr. I can't get a
> > value from an optional<T&> when it has none.
>
> unless you use the value_or() interface -- but the whole usage makes
> even less sense. observer_ptr looks superfluous enough being just a
> pointer-wrapper compared to raw pointers (I assign low value to
> protection from using + and [] with it), but okay, let's substitute our
> pointers with that. So we will pass them around and use */-> and the
> bool check.
>
> What kind of system want to extract the raw pointer from it?
>

As pointed out - there is a difference in hashing and sorting.
One is wrapper of an object the other of a pointer object (and we use
trickery to pretend it is an object wrapped)

So, they are observably not the same.



>
>  From an earlier post:
>
>  >>Well... writing modern C++ (in my sense of modern) it is. A raw
> pointer is newer owned.
>  >This is, to me, a fairly astonishing part of what some call "modern"
>  >C++. Instead of enforcing semantics with
>  >a type, they are loosely agreed on by an unenforceable convention.
>  >That seems like a massive
>  >step backwards, instead of being modern.
>
> I somewhat agree with going against "modern" here, as that is IME one of
> the most fundamental guides we use in C++ I use approaching 30 years.
>
> Wasn't RAII the main feature of C++ from boot? Is "resource allocation"
> it designates mean really *ownership*? Isn't owning pointer looking at a
> resource that is supposed to stand out?  Granted immediately to care of
> some handling type?
>
> IMNSHO the guideline to not having raw pointers with ownership sitting
> around in a program is one of the few universally agreed upon.
>
> And if we put it to use, what the remaining pointers will be if not
> non-owning observers?


> Tony said upstream "When you have a raw pointer, ownership is not
> (typically) obvious." -- I say if that holds for your project you are in
> deep trouble.
>

The problem is that this relies on discipline.
Even if you have the discipline part, because the compiler can't
differentiate b/w owning and no-owning
you are forced into an explicit interface - you are forced to use get().

We are trading the simplicity of a convention for the fact a non-owning
pointer becomes
a form of "private implementation", something that one

 A) must request explicit permission to access
 B) must "proceed with caution" ones obtained

This is the issue an observing pointer solves - it promotes pointers again
to first class citizens.

To have something like this could help not just old codebases, but new
users as well.
We will be able to say "modern C++ pointers are safe" and prove it by
having implicit conversion from a smart pointer
(which we already recommend for memory management).

Raw pointers will be left for pointer arithmetics, interop and low level
private implementations.


Having said that, many if not the majority of people will prefer to have
optional reference as a nullable reference type to represent objects

At this point, I think we should have both and both should be implicitly
constructible from pointers, possibly from one another also.



>
> I did join several such projects and one of the first tasks were to
> address this very mess. And I did not expect the bug count go down
> before that cleanup done.
>
> Where "modern" C++ helped was adding the move semantics to the language,
> so many typical owners now can revert to natural state, no longer
> forcing shared_ptr or homemade refcounted pointers where we really never
> meant sharing, just convenient way to pass a thing between 2 points in
> code.
>
>
>
>
>
>
>
>
>
>
>
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8179c2b4-697f-4332-ad09-b482cc4d2692%40isocpp.org.

------=_Part_679_173420815.1540537682447
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, October 26, 2018 at 12:35:42 AM UTC+3, =
Balog Pal wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 10/25/2018 =
10:58 PM, Ville Voutilainen wrote:
<br>&gt; An optional&lt;T&amp;&gt; doesn&#39;t do what observer_ptr&lt;T&gt=
; does. The latter can
<br>&gt; give you a null pointer when you ask its pointer value, so it can
<br>&gt; model
<br>&gt; &quot;yes, I have a pointer, but it doesn&#39;t point to anything&=
quot;. The former
<br>&gt; models &quot;I may or may not have anything&quot;.
<br>
<br>May be a language problem but I still fail to see a practical=20
<br>difference. Like one between &quot;I do nothing&quot; =C2=A0and &quot;I=
 don&#39;t do anything&quot;.
<br>
<br>The null pointer and the empty opt_ref both designate no object at the=
=20
<br>other end while a non-null pointer and the nonempty ref does.
<br>
<br>(really just weighing to to point out that the difference you see is no=
t=20
<br>at all evident, and the previous poster is not baffled alone)
<br>
<br>&gt; I can always get the pointer value from an observer_ptr. I can&#39=
;t get a
<br>&gt; value from an optional&lt;T&amp;&gt; when it has none.
<br>
<br>unless you use the value_or() interface -- but the whole usage makes=20
<br>even less sense. observer_ptr looks superfluous enough being just a=20
<br>pointer-wrapper compared to raw pointers (I assign low value to=20
<br>protection from using + and [] with it), but okay, let&#39;s substitute=
 our=20
<br>pointers with that. So we will pass them around and use */-&gt; and the=
=20
<br>bool check.
<br>
<br>What kind of system want to extract the raw pointer from it?
<br></blockquote><div><br></div><div>As pointed out - there is a difference=
 in hashing and sorting.=C2=A0</div><div>One is wrapper of an object the ot=
her of a pointer object (and we use trickery to pretend it is an object wra=
pped)</div><div><br></div><div>So, they are observably not the same.=C2=A0<=
/div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;">
<br>=C2=A0From an earlier post:
<br>
<br>=C2=A0&gt;&gt;Well... writing modern C++ (in my sense of modern) it is.=
 A raw=20
<br>pointer is newer owned.
<br>=C2=A0&gt;This is, to me, a fairly astonishing part of what some call &=
quot;modern&quot;
<br>=C2=A0&gt;C++. Instead of enforcing semantics with
<br>=C2=A0&gt;a type, they are loosely agreed on by an unenforceable conven=
tion.
<br>=C2=A0&gt;That seems like a massive
<br>=C2=A0&gt;step backwards, instead of being modern.
<br>
<br>I somewhat agree with going against &quot;modern&quot; here, as that is=
 IME one of=20
<br>the most fundamental guides we use in C++ I use approaching 30 years.
<br>
<br>Wasn&#39;t RAII the main feature of C++ from boot? Is &quot;resource al=
location&quot;=20
<br>it designates mean really *ownership*? Isn&#39;t owning pointer looking=
 at a=20
<br>resource that is supposed to stand out? =C2=A0Granted immediately to ca=
re of=20
<br>some handling type?
<br>
<br>IMNSHO the guideline to not having raw pointers with ownership sitting=
=20
<br>around in a program is one of the few universally agreed upon.
<br>
<br>And if we put it to use, what the remaining pointers will be if not=20
<br>non-owning observers?=C2=A0</blockquote><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;">
<br>Tony said upstream &quot;When you have a raw pointer, ownership is not=
=20
<br>(typically) obvious.&quot; -- I say if that holds for your project you =
are in=20
<br>deep trouble.
<br></blockquote><div><br></div><div>The problem is that this relies on dis=
cipline.=C2=A0</div><div>Even if you have the discipline part, because the =
compiler can&#39;t differentiate b/w owning and no-owning</div><div>you are=
 forced into an explicit interface - you are forced to use get().</div><div=
><br></div><div>We are trading the simplicity of a convention for the fact =
a non-owning pointer becomes=C2=A0</div><div>a form of &quot;private implem=
entation&quot;, something that one</div><div><br></div><div>=C2=A0A) must r=
equest explicit permission to access=C2=A0</div><div>=C2=A0B) must &quot;pr=
oceed with caution&quot; ones obtained=C2=A0</div><div><br></div><div>This =
is the issue an observing pointer solves - it promotes pointers again to fi=
rst class citizens.</div><div><br></div><div>To have something like this co=
uld help not just old codebases, but new users as well.</div><div>We will b=
e able to say &quot;modern C++ pointers are safe&quot; and prove it by havi=
ng implicit conversion from a smart pointer=C2=A0</div><div>(which we alrea=
dy recommend for memory management).</div><div><br></div><div>Raw pointers =
will be left for pointer arithmetics, interop and low level private impleme=
ntations.=C2=A0</div><div><br></div><div><br></div><div>Having said that, m=
any if not the majority of people will prefer to have optional reference as=
 a nullable reference type to represent objects=C2=A0</div><div><br></div><=
div>At this point, I think we should have both and both should be implicitl=
y constructible from pointers, possibly from one another also.</div><div><b=
r></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>I did join several such projects and one of the first tasks were to=20
<br>address this very mess. And I did not expect the bug count go down=20
<br>before that cleanup done.
<br>
<br>Where &quot;modern&quot; C++ helped was adding the move semantics to th=
e language,=20
<br>so many typical owners now can revert to natural state, no longer=20
<br>forcing shared_ptr or homemade refcounted pointers where we really neve=
r=20
<br>meant sharing, just convenient way to pass a thing between 2 points in=
=20
<br>code.
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8179c2b4-697f-4332-ad09-b482cc4d2692%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8179c2b4-697f-4332-ad09-b482cc4d2692=
%40isocpp.org</a>.<br />

------=_Part_679_173420815.1540537682447--

------=_Part_678_414412910.1540537682447--

.

On Thu, Oct 25, 2018 at 10:59 PM Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
>
> On Thu, 25 Oct 2018 at 23:31, Miguel Ojeda
> <miguel.ojeda.sandonis@gmail.com> wrote:
>
> > Even if it was true I gave "zero evidence" (which it isn't), that
> > doesn't mean I am being rude. However, you are being rude by stating
> > publicly "you are wrong; feel free to try again", as if I had to prove
> > something. No, sorry, the one making the proposal is you, so *you* are
> > the one that has to prove its validity.
>
> Let's repeat, then:
>

That is not an example of a difference, sorry. If you can't come up
with an easy example, maybe you should consider there isn't any
practical difference. Which is *fine*, but it subtracts from the total
value of the proposal, in my view (i.e. it would be bloat).

>
> Furthermore,
> 1) I am not making a proposal.

You are suggesting that observer_ptr is a good idea. It doesn't need
to be a formal proposal to be one, specially in std-proposals, I would
say.

> 2) If I were, I wouldn't waste my time explaining it here.

That is interesting. Why is that? If you think, as a part of the
committee, that there is little of no value in discussing proposals
here (formal ones or not), it would be good to know.

Cheers,
Miguel

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANiq72mLgwMBmDJSOemQBKBjk%2B%2BczGRh3ZGDbmhDpa6g_DudGw%40mail.gmail.com.

.

On Thu, Oct 25, 2018 at 10:59 PM Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
>
> On Thu, 25 Oct 2018 at 23:31, Miguel Ojeda
> <miguel.ojeda.sandonis@gmail.com> wrote:
>
> I can always get the pointer value from an observer_ptr. I can't get a
> value from an optional<T&> when it has none.

[Forgot to reply to this]

That, again, is *no* difference. You can create a two-way function
that maps empty optional<T&> to a nullptr. The only cases which would
be impossible to represent with an optional<T&> are all the
non-nullptr & non-valid pointers/addresses, which is what I said in
the beginning and Tony replied to. Again: the nullptr case is not one
of those.

Cheers,
Miguel

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANiq72kOHDe28rHekVQ9Ov%2BOuXZ2wMnH-CQ__PRD4%2BnB_pLAEw%40mail.gmail.com.

.

On Thu, Oct 25, 2018 at 11:06 PM Tony V E <tvaneerd@gmail.com> wrote:
>
> On Thu, Oct 25, 2018 at 4:59 PM Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>
> Also, a container of observer_ptrs would sort by the pointer value (ie address).
> I'm not sure how optional<T&> would sort, and if it would be sortable at all.

Well, same as optional<T>, no? i.e. sort by the T, which seems to be
more useful than by address, i.e. you rarely need pointers/addresses
sorted; but sorting actual objects by their own defined order is
useful. So I would say it is an advantage for optional<T&> here.

A bit off-topic, but maybe you know the answer: I am not really sure
of what was the value of making (in general) _ptr's sortable,
specially considering you may provide the comparison function if
needed very easily (.get()). I guess it was made like that to make
them behave "more like pointers", but I don't think there are many use
cases...

Cheers,
Miguel

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANiq72%3DYkZAL6PvPWb9BO28O4%3Dia5JKqKZGLfA%3DEyjyCJfopSg%40mail.gmail.com.

.

--00000000000085e26b05791d1d63
Content-Type: text/plain; charset="UTF-8"

Differences:

void foo(T* x);

observer_ptr<T> p:
optional<T&> opt;

foo(p.get());
foo(opt?&*opt:nullptr);

plus, the hashing on observer pointers is the hash of the pointer value,
and in the case where I want a set of unique optional object references I
have to specify my own hash on the `&*opt`s again.

Basically, despite the fact that there is a bijection, they are not
equivalent in usage. We can very well have both, with good guidelines on
when to use each, and perhaps two-way conversions to boot.

G


On Fri, Oct 26, 2018 at 10:40 AM Miguel Ojeda <
miguel.ojeda.sandonis@gmail.com> wrote:

> On Thu, Oct 25, 2018 at 10:59 PM Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
> >
> > On Thu, 25 Oct 2018 at 23:31, Miguel Ojeda
> > <miguel.ojeda.sandonis@gmail.com> wrote:
> >
> > I can always get the pointer value from an observer_ptr. I can't get a
> > value from an optional<T&> when it has none.
>
> [Forgot to reply to this]
>
> That, again, is *no* difference. You can create a two-way function
> that maps empty optional<T&> to a nullptr. The only cases which would
> be impossible to represent with an optional<T&> are all the
> non-nullptr & non-valid pointers/addresses, which is what I said in
> the beginning and Tony replied to. Again: the nullptr case is not one
> of those.
>
> Cheers,
> Miguel
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANiq72kOHDe28rHekVQ9Ov%2BOuXZ2wMnH-CQ__PRD4%2BnB_pLAEw%40mail.gmail.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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkVVCnTpCRkFaG2X0%3DjYaDvQLDm7SDQT3WkTxXHktTXn0g%40mail.gmail.com.

--00000000000085e26b05791d1d63
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Differences:<div><br></div><div>void foo(T* x);</div><div>=
<br></div><div>observer_ptr&lt;T&gt; p:</div><div>optional&lt;T&amp;&gt; op=
t;</div><div><br></div><div>foo(p.get());</div><div>foo(opt?&amp;*opt:nullp=
tr);</div><div><br></div><div>plus, the hashing on observer pointers is the=
 hash of the pointer value, and in the case where I want a set of unique op=
tional object references I have to specify my own hash on the `&amp;*opt`s =
again.</div><div><br></div><div>Basically, despite the fact that there is a=
 bijection, they are not equivalent in usage. We can very well have both, w=
ith good guidelines on when to use each, and perhaps two-way conversions to=
 boot.</div><div><br></div><div>G</div><div><br></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr">On Fri, Oct 26, 2018 at 10:40 AM Miguel O=
jeda &lt;<a href=3D"mailto:miguel.ojeda.sandonis@gmail.com">miguel.ojeda.sa=
ndonis@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On =
Thu, Oct 25, 2018 at 10:59 PM Ville Voutilainen<br>
&lt;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.=
voutilainen@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Thu, 25 Oct 2018 at 23:31, Miguel Ojeda<br>
&gt; &lt;<a href=3D"mailto:miguel.ojeda.sandonis@gmail.com" target=3D"_blan=
k">miguel.ojeda.sandonis@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; I can always get the pointer value from an observer_ptr. I can&#39;t g=
et a<br>
&gt; value from an optional&lt;T&amp;&gt; when it has none.<br>
<br>
[Forgot to reply to this]<br>
<br>
That, again, is *no* difference. You can create a two-way function<br>
that maps empty optional&lt;T&amp;&gt; to a nullptr. The only cases which w=
ould<br>
be impossible to represent with an optional&lt;T&amp;&gt; are all the<br>
non-nullptr &amp; non-valid pointers/addresses, which is what I said in<br>
the beginning and Tony replied to. Again: the nullptr case is not one<br>
of those.<br>
<br>
Cheers,<br>
Miguel<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANiq72kOHDe28rHekVQ9Ov%2BOuXZ2wMnH-C=
Q__PRD4%2BnB_pLAEw%40mail.gmail.com" rel=3D"noreferrer" target=3D"_blank">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANiq72kOHDe28r=
HekVQ9Ov%2BOuXZ2wMnH-CQ__PRD4%2BnB_pLAEw%40mail.gmail.com</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkVVCnTpCRkFaG2X0%3DjYaDvQLDm7=
SDQT3WkTxXHktTXn0g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkVVCn=
TpCRkFaG2X0%3DjYaDvQLDm7SDQT3WkTxXHktTXn0g%40mail.gmail.com</a>.<br />

--00000000000085e26b05791d1d63--

.

On Thu, Oct 25, 2018 at 10:39 PM <mihailnajdenov@gmail.com> wrote:
>
>
>
> On Thursday, October 25, 2018 at 10:55:16 PM UTC+3, Miguel Ojeda wrote:
>>
>> On Thu, Oct 25, 2018 at 9:49 PM Ville Voutilainen
>> <ville.vo...@gmail.com> wrote:
>> >
>> > On Thu, 25 Oct 2018 at 22:41, Miguel Ojeda
>> > <miguel.oje...@gmail.com> wrote:
>> >
>> > > > An optional<T&> doesn't do what observer_ptr<T> does. The latter can
>> > > > give you a null pointer when you ask its pointer value, so it can
>> > > > model
>> > > > "yes, I have a pointer, but it doesn't point to anything". The former
>> > > > models "I may or may not have anything".
>> > >
>> > > That is the same thing.
>> >
>> > Yeah, except that it isn't, so feel free to try again.
>>
>> "Feel free to try again", excuse me? Being rude won't help your case.
>>
>> Give an example where it would make a difference, or acknowledge there
>> isn't one. It is that simple.
>
>
> Well, one is an object wrapper, the other is pointer wrapper.
>
> If the pointer (as an object) is of importance then observer_ptr is more logical.
> For example if you store it in a set, you might reach for observer_ptr first as it maps really well to the mental model of "a handle" that can be hashed on its value.

I would agree with this if we thought pointers were the important part
of the construction. But I don't see how the pointer is the important
bit here. Yes, there are cases where pointers are "the" value you care
about (e.g. in a kernel), but in that case you should have a Pointer
class, not an observer_ptr. In other words: if you use an
observer_ptr, it is simply because you are modelling "I have a pointer
to access T"; what is important there is accessing the T, not the
actual value of the pointer.

> optional ref is much more higher level - it tries to present a real object  it does not have that handle aspect of it and to get to the real pointer would be hard and unintuitive.

Exactly!

> People will reach for it to be a view of on object or sub-object, but when they need to put it a set, they might wonder - will this hash on "the pointer" or on the object.

If you put it on a set, 99.9% of the time you care about the T, and
want the sorting on the T; not on pointer values, I would say.
Therefore, optional<T&> is the winner here, because observer_ptr would
be sorted by the pointer, which doesn't make sense in the majority of
cases.

Cheers,
Miguel

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANiq72kcUn%3DCgfAFiz6ahK5SsKLoQ-jiCGikNf%2BoTWh8k%3D90KA%40mail.gmail.com.

.

On Fri, Oct 26, 2018 at 10:00 AM Ga=C5=A1per A=C5=BEman <gasper.azman@gmail=
..com> wrote:
>
> Differences:
>
> void foo(T* x);
>
> observer_ptr<T> p:
> optional<T&> opt;
>
> foo(p.get());
> foo(opt?&*opt:nullptr);

I don't see the problem, you have some impedance one way or the other.
If we get "optional<T&>", it is reasonable to think we would also get
a "opt.as_ptr()" or similar for this case.

> plus, the hashing on observer pointers is the hash of the pointer value, =
and in the case where I want a set of unique optional object references I h=
ave to specify my own hash on the `&*opt`s again.

Ditto.

> Basically, despite the fact that there is a bijection, they are not equiv=
alent in usage. We can very well have both, with good guidelines on when to=
 use each, and perhaps two-way conversions to boot.

I agree we can have both, but not for that reason. I see observer_ptr
more as a completeness thing for C++, or for people that prefer that.
However, why do you say they are not equivalent in usage? (or rather:
why shouldn't they be?).

Cheers,
Miguel

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CANiq72m%2Bw9PF%3DF3mM1FR8_LCM6U5uB%3DAPf3ou8K8C=
uO0-2wkqA%40mail.gmail.com.

.

------=_Part_743_1316905100.1540543842137
Content-Type: multipart/alternative;
 boundary="----=_Part_744_227456815.1540543842137"

------=_Part_744_227456815.1540543842137
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Friday, October 26, 2018 at 11:10:40 AM UTC+3, Miguel Ojeda wrote:
>
> On Fri, Oct 26, 2018 at 10:00 AM Ga=C5=A1per A=C5=BEman <gasper...@gmail.=
com=20
> <javascript:>> wrote:=20
> >=20
> > Differences:=20
> >=20
> > void foo(T* x);=20
> >=20
> > observer_ptr<T> p:=20
> > optional<T&> opt;=20
> >=20
> > foo(p.get());=20
> > foo(opt?&*opt:nullptr);=20
>
> I don't see the problem, you have some impedance one way or the other.=20
> If we get "optional<T&>", it is reasonable to think we would also get=20
> a "opt.as_ptr()" or similar for this case.=20
>
> > plus, the hashing on observer pointers is the hash of the pointer value=
,=20
> and in the case where I want a set of unique optional object references I=
=20
> have to specify my own hash on the `&*opt`s again.=20
>
> Ditto.=20
>
> > Basically, despite the fact that there is a bijection, they are not=20
> equivalent in usage. We can very well have both, with good guidelines on=
=20
> when to use each, and perhaps two-way conversions to boot.=20
>
=20

> I agree we can have both, but not for that reason. I see observer_ptr=20
> more as a completeness thing for C++, or for people that prefer that.=20
> However, why do you say they are not equivalent in usage? (or rather:=20
> why shouldn't they be?).=20
>

You yourself agreed one must be hashed and compared on the pointed-to=20
object, the other on itself. This makes them not-equivalent in usage.

Why should one pay for expensive hash on object if the objects he has=20
interest in are already with unique address?=20
Likewise why should I pay for expansive compare if the objects I have=20
interest in have pointers that I can put in a vector, sort it, and binary=
=20
search with lighting speed.

And is it a good thing to go to all the trouble to have special hash and=20
compare to take advantage of this opt.as_ptr(), if you want the above=20
behavior?
Is this a good API?

No one is denying the need for optional ref, arguably even their=20
superiority for object representation, but to state they cover the need for=
=20
observer_pr is a stretch.

=20
=20

>
> Cheers,=20
> Miguel=20
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/ba622e7f-9a4a-4c48-914a-63b65a2f1c1c%40isocpp.or=
g.

------=_Part_744_227456815.1540543842137
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, October 26, 2018 at 11:10:40 AM UTC+3, =
Miguel Ojeda wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Oct=
 26, 2018 at 10:00 AM Ga=C5=A1per A=C5=BEman &lt;<a href=3D"javascript:" ta=
rget=3D"_blank" gdf-obfuscated-mailto=3D"RH0wdDIiBgAJ" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this=
..href=3D&#39;javascript:&#39;;return true;">gasper...@gmail.com</a>&gt; wro=
te:
<br>&gt;
<br>&gt; Differences:
<br>&gt;
<br>&gt; void foo(T* x);
<br>&gt;
<br>&gt; observer_ptr&lt;T&gt; p:
<br>&gt; optional&lt;T&amp;&gt; opt;
<br>&gt;
<br>&gt; foo(p.get());
<br>&gt; foo(opt?&amp;*opt:nullptr);
<br>
<br>I don&#39;t see the problem, you have some impedance one way or the oth=
er.
<br>If we get &quot;optional&lt;T&amp;&gt;&quot;, it is reasonable to think=
 we would also get
<br>a &quot;opt.as_ptr()&quot; or similar for this case.
<br>
<br>&gt; plus, the hashing on observer pointers is the hash of the pointer =
value, and in the case where I want a set of unique optional object referen=
ces I have to specify my own hash on the `&amp;*opt`s again.
<br>
<br>Ditto.
<br>
<br>&gt; Basically, despite the fact that there is a bijection, they are no=
t equivalent in usage. We can very well have both, with good guidelines on =
when to use each, and perhaps two-way conversions to boot.
<br></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">I agree we can have both, but not for that reason. I see observer_ptr
<br>more as a completeness thing for C++, or for people that prefer that.
<br>However, why do you say they are not equivalent in usage? (or rather:
<br>why shouldn&#39;t they be?).
<br></blockquote><div><br></div><div>You yourself agreed one must be hashed=
 and compared on the pointed-to object, the other on itself. This makes the=
m not-equivalent in usage.</div><div><br></div><div>Why should one pay for =
expensive hash on object if the objects he has interest in are already with=
 unique address?=C2=A0</div><div>Likewise why should I pay for expansive co=
mpare if the objects I have interest in have pointers that I can put in a v=
ector, sort it, and binary search with lighting speed.</div><div><br></div>=
<div>And is it a good thing to go to all the trouble to have special hash a=
nd compare to take advantage of this opt.as_ptr(), if you want the above be=
havior?</div><div>Is this a good API?</div><div><br></div><div>No one is de=
nying the need for optional ref, arguably even their superiority for object=
 representation, but to state they cover the need for observer_pr is a stre=
tch.</div><div><br></div><div>=C2=A0</div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;">
<br>Cheers,
<br>Miguel
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ba622e7f-9a4a-4c48-914a-63b65a2f1c1c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ba622e7f-9a4a-4c48-914a-63b65a2f1c1c=
%40isocpp.org</a>.<br />

------=_Part_744_227456815.1540543842137--

------=_Part_743_1316905100.1540543842137--

.

--000000000000d786dc057920b840
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

If shared_ptr and unique_ptr can be implicitly converted to observe_ptr (
what ever name is ) what is the point of weak_ptr?

Let me generalize this for a little bit?
Does this lead to inheritance hierarchy of smart pointers?

template < typename T, ... > class shared_ptr : public pure_ptr<T>{... };
template < typename T, ... >class unique_ptr : public pure_ptr<T>{... };
template < typename T, ... >class clone_ptr : public pure_ptr<T>{... };
template < typename T, ... >class whatever_ptr : public pure_ptr<T>{... };
void f( pure_ptr<T> & p ){ p->release();  }



So far I see two ways of developing *_ptr's?
1. Inheritance hierarchy like in above example?
2. Conversion from one class to another like what we have now.
Might be better solution if for some reason there is a need for
deprecation. We already have this situation with auto_ptr.







On Fri, Oct 26, 2018 at 10:50 AM <mihailnajdenov@gmail.com> wrote:

>
>
> On Friday, October 26, 2018 at 11:10:40 AM UTC+3, Miguel Ojeda wrote:
>>
>> On Fri, Oct 26, 2018 at 10:00 AM Ga=C5=A1per A=C5=BEman <gasper...@gmail=
..com>
>> wrote:
>> >
>> > Differences:
>> >
>> > void foo(T* x);
>> >
>> > observer_ptr<T> p:
>> > optional<T&> opt;
>> >
>> > foo(p.get());
>> > foo(opt?&*opt:nullptr);
>>
>> I don't see the problem, you have some impedance one way or the other.
>> If we get "optional<T&>", it is reasonable to think we would also get
>> a "opt.as_ptr()" or similar for this case.
>>
>> > plus, the hashing on observer pointers is the hash of the pointer
>> value, and in the case where I want a set of unique optional object
>> references I have to specify my own hash on the `&*opt`s again.
>>
>> Ditto.
>>
>> > Basically, despite the fact that there is a bijection, they are not
>> equivalent in usage. We can very well have both, with good guidelines on
>> when to use each, and perhaps two-way conversions to boot.
>>
>
>
>> I agree we can have both, but not for that reason. I see observer_ptr
>> more as a completeness thing for C++, or for people that prefer that.
>> However, why do you say they are not equivalent in usage? (or rather:
>> why shouldn't they be?).
>>
>
> You yourself agreed one must be hashed and compared on the pointed-to
> object, the other on itself. This makes them not-equivalent in usage.
>
> Why should one pay for expensive hash on object if the objects he has
> interest in are already with unique address?
> Likewise why should I pay for expansive compare if the objects I have
> interest in have pointers that I can put in a vector, sort it, and binary
> search with lighting speed.
>
> And is it a good thing to go to all the trouble to have special hash and
> compare to take advantage of this opt.as_ptr(), if you want the above
> behavior?
> Is this a good API?
>
> No one is denying the need for optional ref, arguably even their
> superiority for object representation, but to state they cover the need f=
or
> observer_pr is a stretch.
>
>
>
>
>>
>> Cheers,
>> Miguel
>>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ba622e7f-9a4=
a-4c48-914a-63b65a2f1c1c%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ba622e7f-9a=
4a-4c48-914a-63b65a2f1c1c%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAEfefmya90yshUgGSfDSoTbts%3D4bdRhgrsdKdsR0dR5b4=
cdsrg%40mail.gmail.com.

--000000000000d786dc057920b840
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div di=
r=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"lt=
r"><div dir=3D"ltr"><div><br></div><div>If shared_ptr and unique_ptr can be=
 implicitly converted to observe_ptr ( what ever name is ) what is the poin=
t of weak_ptr?</div><div><br></div><div>Let me generalize this for a little=
 bit?</div><div>Does=C2=A0this lead to=C2=A0inheritance hierarchy of smart =
pointers?</div><blockquote style=3D"margin-right:0px"><div><font face=3D"mo=
nospace,monospace">template &lt; typename T, ... &gt; class shared_ptr : pu=
blic pure_ptr&lt;T&gt;{... };</font></div><div><div><font face=3D"monospace=
,monospace">template &lt; typename T, ... &gt;class unique_ptr : public pur=
e_ptr&lt;T&gt;{... };</font></div></div><div><font face=3D"monospace,monosp=
ace">template &lt; typename T, ... &gt;class clone_ptr : public pure_ptr&lt=
;T&gt;{... };</font></div><div><font face=3D"monospace,monospace"><div><fon=
t face=3D"monospace,monospace">template &lt; typename T, ... &gt;class what=
ever_ptr : public pure_ptr&lt;T&gt;{... };</font></div></font><div><font fa=
ce=3D"monospace,monospace">void f(=C2=A0pure_ptr&lt;T&gt; &amp; p ){=C2=A0p=
-&gt;release(); =C2=A0}</font></div><div><font face=3D"Courier New"></font>=
<div><font face=3D"Courier New"></font>=C2=A0</div></div><div><font face=3D=
"Courier New"></font><div><font face=3D"Courier New"></font>=C2=A0</div></d=
iv></div></blockquote><p></p><div><font face=3D"arial,helvetica,sans-serif"=
>So far I see two ways of developing *_ptr&#39;s?</font></div><div><div><fo=
nt face=3D"arial,helvetica,sans-serif">1. Inheritance hierarchy like in abo=
ve example?<br><font face=3D"arial,helvetica,sans-serif">2. Conversion from=
 one class to another like what we have now. <br>Might be better solution i=
f for some reason there is a need for deprecation. We already have this sit=
uation with auto_ptr.</font></font></div></div><p></p><blockquote style=3D"=
margin-right:0px"><div><div><font face=3D"Courier New"></font>=C2=A0</div><=
/div></blockquote><div>=C2=A0</div><div><div>=C2=A0</div></div><div><div>=
=C2=A0</div></div></div></div></div></div></div></div></div></div></div></d=
iv><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Oct 26, 2018 at =
10:50 AM &lt;<a href=3D"mailto:mihailnajdenov@gmail.com">mihailnajdenov@gma=
il.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><br><br>On Friday, October 26, 2018 at 11:10:40 AM UTC+3, Miguel Ojeda =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex">On Fri, Oct 26, 2018 at 10:00=
 AM Ga=C5=A1per A=C5=BEman &lt;<a rel=3D"nofollow">gasper...@gmail.com</a>&=
gt; wrote:
<br>&gt;
<br>&gt; Differences:
<br>&gt;
<br>&gt; void foo(T* x);
<br>&gt;
<br>&gt; observer_ptr&lt;T&gt; p:
<br>&gt; optional&lt;T&amp;&gt; opt;
<br>&gt;
<br>&gt; foo(p.get());
<br>&gt; foo(opt?&amp;*opt:nullptr);
<br>
<br>I don&#39;t see the problem, you have some impedance one way or the oth=
er.
<br>If we get &quot;optional&lt;T&amp;&gt;&quot;, it is reasonable to think=
 we would also get
<br>a &quot;opt.as_ptr()&quot; or similar for this case.
<br>
<br>&gt; plus, the hashing on observer pointers is the hash of the pointer =
value, and in the case where I want a set of unique optional object referen=
ces I have to specify my own hash on the `&amp;*opt`s again.
<br>
<br>Ditto.
<br>
<br>&gt; Basically, despite the fact that there is a bijection, they are no=
t equivalent in usage. We can very well have both, with good guidelines on =
when to use each, and perhaps two-way conversions to boot.
<br></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>I agree we can have both, but not for that reason. I see observer_ptr
<br>more as a completeness thing for C++, or for people that prefer that.
<br>However, why do you say they are not equivalent in usage? (or rather:
<br>why shouldn&#39;t they be?).
<br></blockquote><div><br></div><div>You yourself agreed one must be hashed=
 and compared on the pointed-to object, the other on itself. This makes the=
m not-equivalent in usage.</div><div><br></div><div>Why should one pay for =
expensive hash on object if the objects he has interest in are already with=
 unique address?=C2=A0</div><div>Likewise why should I pay for expansive co=
mpare if the objects I have interest in have pointers that I can put in a v=
ector, sort it, and binary search with lighting speed.</div><div><br></div>=
<div>And is it a good thing to go to all the trouble to have special hash a=
nd compare to take advantage of this opt.as_ptr(), if you want the above be=
havior?</div><div>Is this a good API?</div><div><br></div><div>No one is de=
nying the need for optional ref, arguably even their superiority for object=
 representation, but to state they cover the need for observer_pr is a stre=
tch.</div><div><br></div><div>=C2=A0</div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<br>Cheers,
<br>Miguel
<br></blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ba622e7f-9a4a-4c48-914a-63b65a2f1c1c%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ba622e7f-9a4a-=
4c48-914a-63b65a2f1c1c%40isocpp.org</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEfefmya90yshUgGSfDSoTbts%3D4bdRhgrs=
dKdsR0dR5b4cdsrg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmya90yshU=
gGSfDSoTbts%3D4bdRhgrsdKdsR0dR5b4cdsrg%40mail.gmail.com</a>.<br />

--000000000000d786dc057920b840--

.

On Fri, Oct 26, 2018 at 10:50 AM <mihailnajdenov@gmail.com> wrote:
>
> On Friday, October 26, 2018 at 11:10:40 AM UTC+3, Miguel Ojeda wrote:
>>
>> I agree we can have both, but not for that reason. I see observer_ptr
>> more as a completeness thing for C++, or for people that prefer that.
>> However, why do you say they are not equivalent in usage? (or rather:
>> why shouldn't they be?).
>
> You yourself agreed one must be hashed and compared on the pointed-to object, the other on itself. This makes them not-equivalent in usage.

I talked about whether it is more useful to have comparison functions
that work on T, or on the "address". If I have a optional<T&>, I want
the comparison to be done based on T, not the address. If I have
observer_ptr<T>, I want it on the address. I think we agree on that.

> Why should one pay for expensive hash on object if the objects he has interest in are already with unique address?
> Likewise why should I pay for expansive compare if the objects I have interest in have pointers that I can put in a vector, sort it, and binary search with lighting speed.

No one pays for anything: as I said, a T*, a observer_ptr<T>, a
optional<T&> etc. can all be used for that; with more or less
impedance depending on the interface of each. What I simply tried to
say is that, if we are trying to solve the "optional references"
problem, we should maybe go for that, instead of adding more and more
types that represent the same thing (and only differ in the interface
they present).

By the way, note that the case you presented (binary search on
observer_ptr), it is quite dangerous. If I store raw pointers
anywhere, I would probably use a T* (nor optional<T&>, nor
observer_ptr<T>), to indicate they are precisely that :-) I would
probably only use optional<T&> or observer_ptr<T> for arguments to
functions.

Cheers,
Miguel

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANiq72nRGbX5h18Kfd6Ps6m0D%3DLQUoLvxB9GYypvGidW9bSfaQ%40mail.gmail.com.

.

--000000000000ba2c28057923e625
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 26 Oct 2018 at 14:18, Dejan Milosavljevic <dmilos@gmail.com> wrote:

>
> If shared_ptr and unique_ptr can be implicitly converted to observe_ptr (
> what ever name is ) what is the point of weak_ptr?
>

weak_ptr observes and locks lifetime. It is not de-referenceable. It's a
very different _ptr. In hindsight, it probably shouldn't be called weak
*_ptr* at all.

If I were to create the shared_*xxx* idea from scratch, I'd probably be
thinking in terms of shared_owner, weak_reference etc.

imagine please:

template<class T> struct shared_owner {
....
  operator T& () const;   // which would throw or abort if we weren't an
owner of anything.
  operator optional<T&> () const noexcept;   // query
....
};

template<class T> struct weak_reference {
....
  shared_owner<T> promote() const;   // as per std::shared_ptr::lock(), but
returning a reference type
....
};

which would then allow interfaces to be correctly written in terms of
semantics:

void something(T&);   // demands a T&
void something_else(optional<T&>);   // loudly stating that we may or may
not need a T&
void something_else_that_stores(shared_owner<T>);   // loudly stating that
we will share ownership

which would allow:

int main()
{
  shared_owner<Foo> foo =3D make_shared_owner<Foo>(...);

  if (foo) something(foo);
  try {
    something(foo);   // will loudly break here if foo is empty.
  } catch(empty_reference& e) {
    //
  }
  something_else(foo);   // always legal
}

No de-referencing, no noisy pointer stuff and provided we defer to
functions that require a Foo&, we can treat this type as a value and not a
pointer.

I can't think of any *semantic* reason to use pointers in a program. There
are practical reasons, such as interfacing with libraries and convenient
(for the writer) shortcuts for the *concepts* of references and
optionality. But not *conceptually defensible* reasons.

*Semantically,* there are iterators and there are [optional] references. We
have pointers because c++ came from c, and c is a handy macro-assembler.
For the first 20 or so years of C, *pointers* and *address or index
registers* were thought of as the same thing. They probably still are. This
is literally how I used to teach assembly programmers C:
 - "what's a pointer?"
- "it compiles down to an address register, which will spill into memory
allocated on the stack if you use too many of them, so never use more than
three in a function"
(this was in the days of the M68000)

C++ is trying to be a higher level close-to-the-metal language. In order to
do that we try to create classes that represent conceptual operations and
ideas, but which boil down to a few, or zero, machine instructions on a
release build.

I suspect when boost::shared_ptr was first conceived, this sea change in
thinking in c++ hadn't quite happened.



>
> Let me generalize this for a little bit?
> Does this lead to inheritance hierarchy of smart pointers?
>
> template < typename T, ... > class shared_ptr : public pure_ptr<T>{... };
> template < typename T, ... >class unique_ptr : public pure_ptr<T>{... };
> template < typename T, ... >class clone_ptr : public pure_ptr<T>{... };
> template < typename T, ... >class whatever_ptr : public pure_ptr<T>{... }=
;
> void f( pure_ptr<T> & p ){ p->release();  }
>
>
>
> So far I see two ways of developing *_ptr's?
> 1. Inheritance hierarchy like in above example?
> 2. Conversion from one class to another like what we have now.
> Might be better solution if for some reason there is a need for
> deprecation. We already have this situation with auto_ptr.
>
>
>
>
>
>
>
> On Fri, Oct 26, 2018 at 10:50 AM <mihailnajdenov@gmail.com> wrote:
>
>>
>>
>> On Friday, October 26, 2018 at 11:10:40 AM UTC+3, Miguel Ojeda wrote:
>>>
>>> On Fri, Oct 26, 2018 at 10:00 AM Ga=C5=A1per A=C5=BEman <gasper...@gmai=
l.com>
>>> wrote:
>>> >
>>> > Differences:
>>> >
>>> > void foo(T* x);
>>> >
>>> > observer_ptr<T> p:
>>> > optional<T&> opt;
>>> >
>>> > foo(p.get());
>>> > foo(opt?&*opt:nullptr);
>>>
>>> I don't see the problem, you have some impedance one way or the other.
>>> If we get "optional<T&>", it is reasonable to think we would also get
>>> a "opt.as_ptr()" or similar for this case.
>>>
>>> > plus, the hashing on observer pointers is the hash of the pointer
>>> value, and in the case where I want a set of unique optional object
>>> references I have to specify my own hash on the `&*opt`s again.
>>>
>>> Ditto.
>>>
>>> > Basically, despite the fact that there is a bijection, they are not
>>> equivalent in usage. We can very well have both, with good guidelines o=
n
>>> when to use each, and perhaps two-way conversions to boot.
>>>
>>
>>
>>> I agree we can have both, but not for that reason. I see observer_ptr
>>> more as a completeness thing for C++, or for people that prefer that.
>>> However, why do you say they are not equivalent in usage? (or rather:
>>> why shouldn't they be?).
>>>
>>
>> You yourself agreed one must be hashed and compared on the pointed-to
>> object, the other on itself. This makes them not-equivalent in usage.
>>
>> Why should one pay for expensive hash on object if the objects he has
>> interest in are already with unique address?
>> Likewise why should I pay for expansive compare if the objects I have
>> interest in have pointers that I can put in a vector, sort it, and binar=
y
>> search with lighting speed.
>>
>> And is it a good thing to go to all the trouble to have special hash and
>> compare to take advantage of this opt.as_ptr(), if you want the above
>> behavior?
>> Is this a good API?
>>
>> No one is denying the need for optional ref, arguably even their
>> superiority for object representation, but to state they cover the need =
for
>> observer_pr is a stretch.
>>
>>
>>
>>
>>>
>>> Cheers,
>>> Miguel
>>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ba622e7f-9a=
4a-4c48-914a-63b65a2f1c1c%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ba622e7f-9=
a4a-4c48-914a-63b65a2f1c1c%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmya90y=
shUgGSfDSoTbts%3D4bdRhgrsdKdsR0dR5b4cdsrg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmya90=
yshUgGSfDSoTbts%3D4bdRhgrsdKdsR0dR5b4cdsrg%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
> .
>


--=20
Richard Hodges
hodges.r@gmail.com
office: +442032898513
home: +376841522
mobile: +376380212 (this will be *expensive* outside Andorra!)
skype: madmongo
facebook: hodges.r

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CALvx3hZyTj9G9RybRz58y5qoX9Aky0Vt1yWDY18QAoSFqpv=
F%2Bw%40mail.gmail.com.

--000000000000ba2c28057923e625
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri=
, 26 Oct 2018 at 14:18, Dejan Milosavljevic &lt;<a href=3D"mailto:dmilos@gm=
ail.com" target=3D"_blank">dmilos@gmail.com</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">=
<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div di=
r=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div><br></div><div>If shared_p=
tr and unique_ptr can be implicitly converted to observe_ptr ( what ever na=
me is ) what is the point of weak_ptr?</div></div></div></div></div></div><=
/div></div></div></div></div></blockquote><div><br></div><div>weak_ptr obse=
rves and locks lifetime. It is not de-referenceable. It&#39;s a very differ=
ent <font face=3D"monospace, monospace">_ptr</font>. In hindsight, it proba=
bly shouldn&#39;t be called <font face=3D"monospace, monospace">weak<b>_ptr=
</b></font> at all.</div><div><br></div><div>If I were to create the <font =
face=3D"monospace, monospace">shared_<b>xxx</b></font> idea from scratch, I=
&#39;d probably be thinking in terms of <font face=3D"monospace, monospace"=
>shared_owner</font>, <font face=3D"monospace, monospace">weak_reference</f=
ont> etc.=C2=A0</div><div><br></div><div>imagine please:</div><div><br></di=
v><div><font face=3D"monospace, monospace">template&lt;class T&gt; struct s=
hared_owner {</font></div><div><font face=3D"monospace, monospace">...</fon=
t></div><div><font face=3D"monospace, monospace">=C2=A0 operator T&amp; () =
const;=C2=A0 =C2=A0// which would throw or abort if we weren&#39;t an owner=
 of anything.</font></div><div><font face=3D"monospace, monospace">=C2=A0 o=
perator optional&lt;T&amp;&gt; () const noexcept;=C2=A0 =C2=A0// query</fon=
t></div><div><font face=3D"monospace, monospace">...<br></font></div><div><=
font face=3D"monospace, monospace">};</font></div><div><font face=3D"monosp=
ace, monospace"><br></font></div><div><font face=3D"monospace, monospace">t=
emplate&lt;class T&gt; struct weak_reference {</font></div><div><font face=
=3D"monospace, monospace">...</font></div><div><font face=3D"monospace, mon=
ospace">=C2=A0 shared_owner&lt;T&gt; promote() const;=C2=A0 =C2=A0// as per=
 std::shared_ptr::lock(), but returning a reference type</font></div><div><=
font face=3D"monospace, monospace">...</font></div><div><font face=3D"monos=
pace, monospace">};</font></div><div><br></div><div>which would then allow =
interfaces to be correctly written in terms of semantics:</div><div><br></d=
iv><div><font face=3D"monospace, monospace">void something(T&amp;);=C2=A0 =
=C2=A0// demands a T&amp;</font></div><div><div><font face=3D"monospace, mo=
nospace">void something_else(optional&lt;T&amp;&gt;);=C2=A0 =C2=A0// loudly=
 stating that we may or may not need a T&amp;</font></div><div><font face=
=3D"monospace, monospace">void something_else_that_stores(shared_owner&lt;T=
&gt;);=C2=A0 =C2=A0// loudly stating that we will share ownership</font></d=
iv><br class=3D"gmail-Apple-interchange-newline"></div><div>which would all=
ow:</div><div><br></div><div><font face=3D"monospace, monospace">int main()=
</font></div><div><font face=3D"monospace, monospace">{</font></div><div><f=
ont face=3D"monospace, monospace">=C2=A0 shared_owner&lt;Foo&gt; foo =3D ma=
ke_shared_owner&lt;Foo&gt;(...);</font></div><div><font face=3D"monospace, =
monospace"><br></font></div><div><font face=3D"monospace, monospace">=C2=A0=
 if (foo) something(foo);</font></div><div><span style=3D"font-family:monos=
pace,monospace">=C2=A0 try {</span><br></div><div><font face=3D"monospace, =
monospace">=C2=A0 =C2=A0 something(foo);=C2=A0 =C2=A0// will loudly break h=
ere if foo is empty.</font></div><div><font face=3D"monospace, monospace">=
=C2=A0 } catch(empty_reference&amp; e) {</font></div><div><font face=3D"mon=
ospace, monospace">=C2=A0 =C2=A0 //=C2=A0</font></div><div><font face=3D"mo=
nospace, monospace">=C2=A0 }</font></div><div><font face=3D"monospace, mono=
space">=C2=A0 something_else(foo);=C2=A0 =C2=A0// always legal</font></div>=
<div><font face=3D"monospace, monospace">}</font></div><div><br></div><div>=
No de-referencing, no noisy pointer stuff and provided we defer to function=
s that require a Foo&amp;, we can treat this type as a value and not a poin=
ter.</div><div><br></div><div>I can&#39;t think of any <i><u>semantic</u></=
i> reason to use pointers in a program. There are practical reasons, such a=
s interfacing with libraries and convenient (for the writer) shortcuts for =
the <i>concepts</i> of references and optionality. But not <i>conceptually =
defensible</i> reasons.</div><div><br></div><div><i>Semantically,</i> there=
 are iterators and there are [optional] references. We have pointers becaus=
e c++ came from c, and c is a handy macro-assembler. For the first 20 or so=
 years of C, <i>pointers</i> and <i>address or index registers</i> were tho=
ught of as the same thing. They probably still are. This is literally how I=
 used to teach assembly programmers C:</div><div>=C2=A0- &quot;what&#39;s a=
 pointer?&quot;</div><div>- &quot;it compiles down to an address register, =
which will spill into memory allocated on the stack if you use too many of =
them, so never use more than three in a function&quot;</div><div>(this was =
in the days of the M68000)</div><div><br></div><div>C++ is trying to be a h=
igher level close-to-the-metal language. In order to do that we try to crea=
te classes that represent conceptual operations and ideas, but which boil d=
own to a few, or zero, machine instructions on a release build.</div><div><=
br></div><div>I suspect when <font face=3D"monospace, monospace">boost::sha=
red_ptr</font> was first conceived, this sea change in thinking in c++ hadn=
&#39;t quite happened.</div><div><br></div><div>=C2=A0=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><d=
iv dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=
=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div><br></div><div>Let me gener=
alize this for a little bit?</div><div>Does=C2=A0this lead to=C2=A0inherita=
nce hierarchy of smart pointers?</div><blockquote style=3D"margin-right:0px=
"><div><font face=3D"monospace,monospace">template &lt; typename T, ... &gt=
; class shared_ptr : public pure_ptr&lt;T&gt;{... };</font></div><div><div>=
<font face=3D"monospace,monospace">template &lt; typename T, ... &gt;class =
unique_ptr : public pure_ptr&lt;T&gt;{... };</font></div></div><div><font f=
ace=3D"monospace,monospace">template &lt; typename T, ... &gt;class clone_p=
tr : public pure_ptr&lt;T&gt;{... };</font></div><div><font face=3D"monospa=
ce,monospace"><div><font face=3D"monospace,monospace">template &lt; typenam=
e T, ... &gt;class whatever_ptr : public pure_ptr&lt;T&gt;{... };</font></d=
iv></font><div><font face=3D"monospace,monospace">void f(=C2=A0pure_ptr&lt;=
T&gt; &amp; p ){=C2=A0p-&gt;release(); =C2=A0}</font></div><div><font face=
=3D"Courier New"></font><div><font face=3D"Courier New"></font>=C2=A0</div>=
</div><div><font face=3D"Courier New"></font><div><font face=3D"Courier New=
"></font>=C2=A0</div></div></div></blockquote><p></p><div><font face=3D"ari=
al,helvetica,sans-serif">So far I see two ways of developing *_ptr&#39;s?</=
font></div><div><div><font face=3D"arial,helvetica,sans-serif">1. Inheritan=
ce hierarchy like in above example?<br><font face=3D"arial,helvetica,sans-s=
erif">2. Conversion from one class to another like what we have now. <br>Mi=
ght be better solution if for some reason there is a need for deprecation. =
We already have this situation with auto_ptr.</font></font></div></div><p><=
/p><blockquote style=3D"margin-right:0px"><div><div><font face=3D"Courier N=
ew"></font>=C2=A0</div></div></blockquote><div>=C2=A0</div><div><div>=C2=A0=
</div></div><div><div>=C2=A0</div></div></div></div></div></div></div></div=
></div></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On=
 Fri, Oct 26, 2018 at 10:50 AM &lt;<a href=3D"mailto:mihailnajdenov@gmail.c=
om" target=3D"_blank">mihailnajdenov@gmail.com</a>&gt; wrote:<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Friday, October 26, =
2018 at 11:10:40 AM UTC+3, Miguel Ojeda wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex">On Fri, Oct 26, 2018 at 10:00 AM Ga=C5=A1per A=C5=BEman &lt;<a r=
el=3D"nofollow">gasper...@gmail.com</a>&gt; wrote:
<br>&gt;
<br>&gt; Differences:
<br>&gt;
<br>&gt; void foo(T* x);
<br>&gt;
<br>&gt; observer_ptr&lt;T&gt; p:
<br>&gt; optional&lt;T&amp;&gt; opt;
<br>&gt;
<br>&gt; foo(p.get());
<br>&gt; foo(opt?&amp;*opt:nullptr);
<br>
<br>I don&#39;t see the problem, you have some impedance one way or the oth=
er.
<br>If we get &quot;optional&lt;T&amp;&gt;&quot;, it is reasonable to think=
 we would also get
<br>a &quot;opt.as_ptr()&quot; or similar for this case.
<br>
<br>&gt; plus, the hashing on observer pointers is the hash of the pointer =
value, and in the case where I want a set of unique optional object referen=
ces I have to specify my own hash on the `&amp;*opt`s again.
<br>
<br>Ditto.
<br>
<br>&gt; Basically, despite the fact that there is a bijection, they are no=
t equivalent in usage. We can very well have both, with good guidelines on =
when to use each, and perhaps two-way conversions to boot.
<br></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>I agree we can have both, but not for that reason. I see observer_ptr
<br>more as a completeness thing for C++, or for people that prefer that.
<br>However, why do you say they are not equivalent in usage? (or rather:
<br>why shouldn&#39;t they be?).
<br></blockquote><div><br></div><div>You yourself agreed one must be hashed=
 and compared on the pointed-to object, the other on itself. This makes the=
m not-equivalent in usage.</div><div><br></div><div>Why should one pay for =
expensive hash on object if the objects he has interest in are already with=
 unique address?=C2=A0</div><div>Likewise why should I pay for expansive co=
mpare if the objects I have interest in have pointers that I can put in a v=
ector, sort it, and binary search with lighting speed.</div><div><br></div>=
<div>And is it a good thing to go to all the trouble to have special hash a=
nd compare to take advantage of this opt.as_ptr(), if you want the above be=
havior?</div><div>Is this a good API?</div><div><br></div><div>No one is de=
nying the need for optional ref, arguably even their superiority for object=
 representation, but to state they cover the need for observer_pr is a stre=
tch.</div><div><br></div><div>=C2=A0</div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<br>Cheers,
<br>Miguel
<br></blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ba622e7f-9a4a-4c48-914a-63b65a2f1c1c%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ba622e7f-9a4a-=
4c48-914a-63b65a2f1c1c%40isocpp.org</a>.<br>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEfefmya90yshUgGSfDSoTbts%3D4bdRhgrs=
dKdsR0dR5b4cdsrg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAEfefmya90yshUgGSfDSoTbts%3D4bdRhgrsdKdsR0dR5b4cdsrg%40mail.gmail.c=
om</a>.<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"m_-1064687285854121469gmail_signature" data-smartmail=3D"gmail_si=
gnature"><div dir=3D"ltr">Richard Hodges<div><a href=3D"mailto:hodges.r@gma=
il.com" target=3D"_blank">hodges.r@gmail.com</a></div><div>office: +4420328=
98513</div><div>home: +376841522</div><div>mobile:=C2=A0+376380212 (this wi=
ll be *expensive* outside Andorra!)</div><div>skype: madmongo</div><div>fac=
ebook: hodges.r</div><div><br></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hZyTj9G9RybRz58y5qoX9Aky0Vt1yWD=
Y18QAoSFqpvF%2Bw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZyTj9G9R=
ybRz58y5qoX9Aky0Vt1yWDY18QAoSFqpvF%2Bw%40mail.gmail.com</a>.<br />

--000000000000ba2c28057923e625--

.

------=_Part_2610_1001279274.1541520186021
Content-Type: multipart/alternative;
 boundary="----=_Part_2611_1242133902.1541520186022"

------=_Part_2611_1242133902.1541520186022
Content-Type: text/plain; charset="UTF-8"

I have been playing around in my code with observer-like pointer and
honestly,
the verbosity is noticeable if are to compare with raw pointers and
references

The "issue" is that, in contrast to string_view, we have to also both name
a type and const-decorate

 So in the end

void func(const IccProfile* profile)
void func(const IccProfile& profile)

are quite less verbose then

void func(std::observer_ptr<const IccProfile> profile)

This *will* force users to typedef, which I don't think is good idea and
not a price people will be willing to pay

Controversial or not I believe std::ptr<> is a more realistic, in terms of
adoption, option.
And is not bad of name:
 - By omitting a name (like shared, weak, unique) it is implied it does
nothing.
 - By the fact it is an std:: object it is implied it is "the C++ (object)
pointer", in contrast to "the C pointer" (the raw one)



On Thursday, October 25, 2018 at 7:32:46 PM UTC+3, Tony V E wrote:
>
>
>
> On Thu, Oct 25, 2018 at 12:21 PM Ville Voutilainen <ville.vo...@gmail.com
> <javascript:>> wrote:
>
>> On Thu, 25 Oct 2018 at 19:19, Tony V E <tvan...@gmail.com <javascript:>>
>> wrote:
>> >
>> >
>> >
>> > On Thu, Oct 25, 2018 at 1:20 AM Ville Voutilainen <
>> ville.vo...@gmail.com <javascript:>> wrote:
>> >>
>> >> On Thu, 25 Oct 2018 at 00:58, Tony V E <tvan...@gmail.com
>> <javascript:>> wrote:
>> >>
>> >> > I agree with all of this, and, to me, it makes observer_ptr worth
>> standardizing.
>> >>
>> >> You said that before, but the paper didn't materialize. :P
>> >
>> >
>> >
>> > ... yet.
>> >
>> > Hopefully next meeting.
>>
>> Alright; give me the gist of the changes you have in mind, and if you
>> can, any drafts of the paper and I'll give you
>> a regtested proper stdlib implementation that has passed the tests of
>> observer_ptr, modulo changes needed for the changes
>> we need to make.
>>
>
>
> Cool, thanks.  Here's what I've got so far:
> https://github.com/tvaneerd/isocpp/blob/master/observer_ptr.md#changes
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Ftvaneerd%2Fisocpp%2Fblob%2Fmaster%2Fobserver_ptr.md%23changes&sa=D&sntz=1&usg=AFQjCNHPh-HIv_ZAUVLj_Vz2m06hmPGNTg>
> I'm not sure it is worth making coding changes yet. Up to you of course.
>
> Now that I think of it, the implicit conversions should probably be on
> shared_ptr and unique_ptr cast operators, not on observer_ptr constructors.
> (ie observer_ptr is the simpler class, it shouldn't depend on
> shared/unique, they should depend on it)
>
> Alternatively observer_ptr could have implicit conversion from anything
> that "looks like" a smart pointer?  Not sure how "looks like" would be
> safely defined.
>
>
>
>
>
>> --
>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYRmaYmc12EfaUiBHiO1_t-2z2fE7NvdnJvkcWEhCoNSg%40mail.gmail.com
>> .
>>
>
>
> --
> Be seeing you,
> Tony
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/523941a4-58ec-4a0c-8f89-b3ce16248ff2%40isocpp.org.

------=_Part_2611_1242133902.1541520186022
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I have been playing around in my code with observer-like p=
ointer and honestly,=C2=A0<div>the verbosity is noticeable if are to compar=
e with raw pointers and references</div><div><br></div><div>The &quot;issue=
&quot; is that, in contrast to string_view, we have to also both name a typ=
e and const-decorate</div><div><br></div><div>=C2=A0So in the end</div><div=
><br></div><div><font face=3D"courier new, monospace">void func(const IccPr=
ofile* profile)</font></div><div><font face=3D"courier new, monospace">void=
 func(const IccProfile&amp; profile)</font></div><div><br></div><div>are qu=
ite less verbose then</div><div><br></div><div><font face=3D"courier new, m=
onospace">void func(std::observer_ptr&lt;const IccProfile&gt; profile)</fon=
t></div><div><font face=3D"courier new, monospace"><br></font></div><div><f=
ont face=3D"arial, sans-serif">This <i>will</i>=C2=A0force users to typedef=
, which I don&#39;t think is good idea and not a price people will be willi=
ng to pay</font></div><div><font face=3D"arial, sans-serif"><br></font></di=
v><div><font face=3D"arial, sans-serif">Controversial=C2=A0or not I believe=
 </font><font face=3D"courier new, monospace">std::ptr&lt;&gt;</font><font =
face=3D"arial, sans-serif">=C2=A0is a more realistic, in terms of adoption,=
 option.</font></div><div><font face=3D"arial, sans-serif">And is not bad o=
f name:</font></div><div><font face=3D"arial, sans-serif">=C2=A0- By omitti=
ng=C2=A0a name (like shared, weak, unique)=C2=A0</font><span style=3D"font-=
family: arial, sans-serif;">it is implied it does nothing.</span></div><div=
><span style=3D"font-family: arial, sans-serif;">=C2=A0- By the fact it is =
an std:: object it is implied it is &quot;the C++ (object) pointer&quot;, i=
n contrast to &quot;the C pointer&quot; (the raw one)</span></div><div><fon=
t face=3D"arial, sans-serif"><br></font></div><div><br></div><div><br>On Th=
ursday, October 25, 2018 at 7:32:46 PM UTC+3, Tony V E wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div dir=3D"ltr"><br><br><d=
iv class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Oct 25, 2018 at 12:21 PM =
Ville Voutilainen &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"-M4PMATvBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#3=
9;;return true;">ville.vo...@gmail.com</a>&gt; wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex">On Thu, 25 Oct 2018 at 19:19, Tony V =
E &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"-M=
4PMATvBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#3=
9;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;"=
>tvan...@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Thu, Oct 25, 2018 at 1:20 AM Ville Voutilainen &lt;<a href=3D"javas=
cript:" target=3D"_blank" gdf-obfuscated-mailto=3D"-M4PMATvBQAJ" rel=3D"nof=
ollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" oncli=
ck=3D"this.href=3D&#39;javascript:&#39;;return true;">ville.vo...@gmail.com=
</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Thu, 25 Oct 2018 at 00:58, Tony V E &lt;<a href=3D"javascript:"=
 target=3D"_blank" gdf-obfuscated-mailto=3D"-M4PMATvBQAJ" rel=3D"nofollow" =
onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"t=
his.href=3D&#39;javascript:&#39;;return true;">tvan...@gmail.com</a>&gt; wr=
ote:<br>
&gt;&gt;<br>
&gt;&gt; &gt; I agree with all of this, and, to me, it makes observer_ptr w=
orth standardizing.<br>
&gt;&gt;<br>
&gt;&gt; You said that before, but the paper didn&#39;t materialize. :P<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; ... yet.<br>
&gt;<br>
&gt; Hopefully next meeting.<br>
<br>
Alright; give me the gist of the changes you have in mind, and if you<br>
can, any drafts of the paper and I&#39;ll give you<br>
a regtested proper stdlib implementation that has passed the tests of<br>
observer_ptr, modulo changes needed for the changes<br>
we need to make.<br></blockquote><div><br></div><div><br></div><div>Cool, t=
hanks.=C2=A0 Here&#39;s what I&#39;ve got so far:=C2=A0 <a href=3D"https://=
www.google.com/url?q=3Dhttps%3A%2F%2Fgithub.com%2Ftvaneerd%2Fisocpp%2Fblob%=
2Fmaster%2Fobserver_ptr.md%23changes&amp;sa=3DD&amp;sntz=3D1&amp;usg=3DAFQj=
CNHPh-HIv_ZAUVLj_Vz2m06hmPGNTg" target=3D"_blank" rel=3D"nofollow" onmoused=
own=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithu=
b.com%2Ftvaneerd%2Fisocpp%2Fblob%2Fmaster%2Fobserver_ptr.md%23changes\x26sa=
\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHPh-HIv_ZAUVLj_Vz2m06hmPGNTg&#39;;return=
 true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3=
A%2F%2Fgithub.com%2Ftvaneerd%2Fisocpp%2Fblob%2Fmaster%2Fobserver_ptr.md%23c=
hanges\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHPh-HIv_ZAUVLj_Vz2m06hmPGNTg=
&#39;;return true;">https://github.com/tvaneerd/<wbr>isocpp/blob/master/obs=
erver_<wbr>ptr.md#changes</a><br></div><div>I&#39;m not sure it is worth ma=
king coding changes yet. Up to you of course.<br></div><div><br></div><div>=
Now that I think of it, the implicit conversions should probably be on shar=
ed_ptr and unique_ptr cast operators, not on observer_ptr constructors.</di=
v><div>(ie observer_ptr is the simpler class, it shouldn&#39;t depend on sh=
ared/unique, they should depend on it)</div><div><br></div><div>Alternative=
ly observer_ptr could have implicit conversion from anything that &quot;loo=
ks like&quot; a smart pointer?=C2=A0 Not sure how &quot;looks like&quot; wo=
uld be safely defined.<br></div><div><br></div><div><br></div><div><br></di=
v><div> <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
-M4PMATvBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"-M4PMATvBQAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYRmaYmc12EfaUiBHiO1_t-2z2fE7Nv=
dnJvkcWEhCoNSg%40mail.gmail.com" rel=3D"nofollow" target=3D"_blank" onmouse=
down=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/CAFk2RUYRmaYmc12EfaUiBHiO1_t-2z2fE7NvdnJvkcWEhCoNSg%40mail.gmail=
..com&#39;;return true;" onclick=3D"this.href=3D&#39;https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYRmaYmc12EfaUiBHiO1_t-2z2fE7Nv=
dnJvkcWEhCoNSg%40mail.gmail.com&#39;;return true;">https://groups.google.co=
m/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/<wbr>CAFk2RUYRmaYmc12EfaUiBH=
iO1_t-<wbr>2z2fE7NvdnJvkcWEhCoNSg%40mail.<wbr>gmail.com</a>.<br>
</blockquote></div><br clear=3D"all"><br>-- <br><div dir=3D"ltr"><div dir=
=3D"ltr"><div>Be seeing you,<br></div>Tony<br></div></div></div></div>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/523941a4-58ec-4a0c-8f89-b3ce16248ff2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/523941a4-58ec-4a0c-8f89-b3ce16248ff2=
%40isocpp.org</a>.<br />

------=_Part_2611_1242133902.1541520186022--

------=_Part_2610_1001279274.1541520186021--

.