------=_Part_238_560385694.1476785033287
Content-Type: multipart/alternative;
 boundary="----=_Part_239_1005529967.1476785033287"

------=_Part_239_1005529967.1476785033287
Content-Type: text/plain; charset=UTF-8

I was surprised to see
http://en.cppreference.com/w/cpp/experimental/observer_ptr

I though, it was settled, raw pointers will be serving as non-owning
pointers? (and use references, as well not_null<> and owner<> to cover
corner cases and legacy)

Also, observer_ptr is not without problems too.

For instance, it has lifetime management API (reset, release) although it
does not manage lifetime!

Right now if you see reset or release in code, it means the object lifetime
has been altered - either deleted, a ref dropped or no longer managed.
observer_ptr will change that for the worse - these will start to mean
something different.

Also, it can be well misleading, it monitors object lifetime - after all
other smart pointers *control *lifetime, this one is probably just
*observing* it.

--
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/8a6731f7-1c9b-482d-817e-c2374fc9ae1b%40isocpp.org.

------=_Part_239_1005529967.1476785033287
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I was surprised to see http://en.cppreference.com/w/c=
pp/experimental/observer_ptr </div><div><br></div><div>I though, it was set=
tled, raw pointers will be serving as non-owning pointers? (and use referen=
ces, as well not_null&lt;&gt; and=C2=A0owner&lt;&gt; to cover corner cases =
and legacy)<br></div><div><br></div><div>Also, observer_ptr is not without =
problems too.</div><div><br></div><div>For instance, it has lifetime manage=
ment API (reset, release) although it does not manage lifetime!</div><div><=
br></div><div>Right now if you=C2=A0see reset or release in=C2=A0code, it m=
eans the object lifetime has been altered - either deleted, a ref dropped o=
r no longer managed.</div><div>observer_ptr will change that for the worse =
- these will start to mean something different.</div><div>=C2=A0</div><div>=
Also,=C2=A0it can be well misleading, it monitors object lifetime - after a=
ll other smart pointers <i>control </i>lifetime, this one is probably just =
<i>observing</i> it.<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/8a6731f7-1c9b-482d-817e-c2374fc9ae1b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8a6731f7-1c9b-482d-817e-c2374fc9ae1b=
%40isocpp.org</a>.<br />

------=_Part_239_1005529967.1476785033287--

------=_Part_238_560385694.1476785033287--

.

On 18 October 2016 at 13:03,  <mihailnajdenov@gmail.com> wrote:
> I was surprised to see
> http://en.cppreference.com/w/cpp/experimental/observer_ptr
>
> I though, it was settled, raw pointers will be serving as non-owning
> pointers? (and use references, as well not_null<> and owner<> to cover
> corner cases and legacy)

I don't know what authority settled that point for every codebase on the planet.

> Also, observer_ptr is not without problems too.
>
> For instance, it has lifetime management API (reset, release) although it
> does not manage lifetime!
> Right now if you see reset or release in code, it means the object lifetime
> has been altered - either deleted, a ref dropped or no longer managed.
> observer_ptr will change that for the worse - these will start to mean
> something different.

I don't consider reset and release to necessarily manage lifetime.

> Also, it can be well misleading, it monitors object lifetime - after all
> other smart pointers control lifetime, this one is probably just observing
> it.

It doesn't observe lifetime.

--
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/CAFk2RUaKZCx2LvRcHWxff6Y_w0Jd0nwkagwLHc9aFQh9oxnxOw%40mail.gmail.com.

.

On 2016-10-18 12:03, mihailnajdenov@gmail.com wrote:
> I was surprised to see
> http://en.cppreference.com/w/cpp/experimental/observer_ptr
>
> I though, it was settled, raw pointers will be serving as non-owning
> pointers? (and use references, as well not_null<> and owner<> to cover
> corner cases and legacy)
>
> Also, observer_ptr is not without problems too.
>
> For instance, it has lifetime management API (reset, release) although
> it does not manage lifetime!
>
> Right now if you see reset or release in code, it means the object
> lifetime has been altered - either deleted, a ref dropped or no longer
> managed.
> observer_ptr will change that for the worse - these will start to mean
> something different.
>
> Also, it can be well misleading, it monitors object lifetime - after all
> other smart pointers /control /lifetime, this one is probably just
> /observing/ it.
>


Having similar functions use the same names as functions of the slighlty
smarter pointers, might help replacing those with an observer_pointer.
Changing "release" into "stop_observing" (or something) doesn't appeal
to me.


If we look at a similar problem in merging "optional", "variant", and
"any" into the draft standard, we ended up with two of them having a
"bool has_value()" function, while the third got a "bool
valueless_by_exception()".

Not only do they have different names, but also different true/false
return value for the same(?) condition - does it store anything.

I think the "release" function for the pointer types is similar enough -
give me the pointer, I'll take care of it!


    Bo Persson


--
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/nu53qp%24lvv%241%40blaine.gmane.org.

.

------=_Part_2446_1994381645.1476796084310
Content-Type: multipart/alternative;
 boundary="----=_Part_2447_1033507570.1476796084310"

------=_Part_2447_1033507570.1476796084310
Content-Type: text/plain; charset=UTF-8

In any case, for a smart pointer, reset and release *are* lifetime
management interfaces.

observer_ptr changes this.

Also note, owner<> and not_null<> do *not* have these also!

I don't propose changing the name, because I don't believe observer_ptr
existence is justified.
Not after 3+ years of evangelism how "row pointers are just fine, you
should use them for non-owners", something I *completely* agree!

--
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/7d817482-e7c3-4724-9501-738d4c9083d7%40isocpp.org.

------=_Part_2447_1033507570.1476796084310
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>In any case, for a smart pointer,=C2=A0reset and rele=
ase <i>are</i> lifetime management interfaces.</div><div><br></div><div>obs=
erver_ptr changes this. </div><div><br></div><div>Also note, owner&lt;&gt; =
and not_null&lt;&gt; do <b>not</b> have these also! </div><div><br></div><d=
iv>I don&#39;t propose changing the name, because I don&#39;t believe obser=
ver_ptr existence is justified. </div><div>Not after 3+ years of evangelism=
 how &quot;row=C2=A0pointers are just fine, you should use them for non-own=
ers&quot;, something I <i><b>completely</b></i> agree! </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/7d817482-e7c3-4724-9501-738d4c9083d7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7d817482-e7c3-4724-9501-738d4c9083d7=
%40isocpp.org</a>.<br />

------=_Part_2447_1033507570.1476796084310--

------=_Part_2446_1994381645.1476796084310--

.

On 18 October 2016 at 16:08,  <mihailnajdenov@gmail.com> wrote:
> In any case, for a smart pointer, reset and release are lifetime management
> interfaces.
>
> observer_ptr changes this.

But yet its users are unlikely to find this a problem, because some of
them don't consider
reset and release to be lifetime management interfaces.

> Also note, owner<> and not_null<> do not have these also!

Well, of course not, because they are raw pointers.

> I don't propose changing the name, because I don't believe observer_ptr
> existence is justified.

I have no trouble finding users who don't agree with that.

> Not after 3+ years of evangelism how "row pointers are just fine, you should
> use them for non-owners", something I completely agree!

...and it's your choice whether you take such evangelism to be the whole truth.

--
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/CAFk2RUYggLMwivpFr%2BthZmRBUXBgXC283iwAvyRQEnbT7xrqUA%40mail.gmail.com.

.

------=_Part_2282_462927410.1476798279657
Content-Type: multipart/alternative;
 boundary="----=_Part_2283_874870632.1476798279657"

------=_Part_2283_874870632.1476798279657
Content-Type: text/plain; charset=UTF-8



On Tuesday, October 18, 2016 at 4:17:29 PM UTC+3, Ville Voutilainen wrote:
>
> On 18 October 2016 at 16:08,  <mihailn...@gmail.com <javascript:>> wrote:
> > In any case, for a smart pointer, reset and release are lifetime
> management
> > interfaces.
> >
> > observer_ptr changes this.
>
> But yet its users are unlikely to find this a problem, because some of
> them don't consider
> reset and release to be lifetime management interfaces.
>

reset and release is lifetime interface in the context of a smart pointer
-  if you touch these, the lifetime of the object will change.
That's a fact, not a point a view.

observer_ptr pretends to be smart with risk of being harmful and/or
confusing.

is this safe?

p.reset(new int{});

Right now - yes!, with any smart pointer.

With observer_ptr into the picture we have to say - "it depends, go look up
the type of p".


>
> > Also note, owner<> and not_null<> do not have these also!
>
> Well, of course not, because they are raw pointers.
>
>
If you meant "raw" as in a C pointer, only owner<> is raw, not_null is a
class.
But yes, they are not lifetime managers... but observer is also not one.

--
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/f3d2848e-56f7-4ddd-a0a0-1a8c7b8db391%40isocpp.org.

------=_Part_2283_874870632.1476798279657
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, October 18, 2016 at 4:17:29 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 18 =
October 2016 at 16:08, =C2=A0&lt;<a onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfusca=
ted-mailto=3D"-LONwi-PBgAJ">mihailn...@gmail.com</a>&gt; wrote:
<br>&gt; In any case, for a smart pointer, reset and release are lifetime m=
anagement
<br>&gt; interfaces.
<br>&gt;
<br>&gt; observer_ptr changes this.
<br>
<br>But yet its users are unlikely to find this a problem, because some of
<br>them don&#39;t consider
<br>reset and release to be lifetime management interfaces.
<br></blockquote><div><br></div><div>reset and release is lifetime interfac=
e in the context of a smart pointer -=C2=A0 if you touch these, the lifetim=
e of the object will change. </div><div>That&#39;s a fact,=C2=A0not a point=
 a view.</div><div><br></div><div>observer_ptr pretends to be smart with ri=
sk of being harmful and/or confusing. </div><div><br></div><div>is this saf=
e?</div><div><br></div><div>p.reset(new int{});</div><div><br></div><div>Ri=
ght now - yes!,=C2=A0with any smart pointer.</div><div><br></div><div>With =
observer_ptr into the picture=C2=A0we have to say - &quot;it depends, go lo=
ok up the type of p&quot;.</div><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;">
<br>&gt; Also note, owner&lt;&gt; and not_null&lt;&gt; do not have these al=
so!
<br>
<br>Well, of course not, because they are raw pointers.
<br>
<br></blockquote><div><br></div><div>If you meant &quot;raw&quot; as in a=
=C2=A0C pointer, only owner&lt;&gt; is raw, not_null is a class. </div><div=
>But yes, they are not=C2=A0lifetime managers... but observer is also not o=
ne.</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/f3d2848e-56f7-4ddd-a0a0-1a8c7b8db391%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f3d2848e-56f7-4ddd-a0a0-1a8c7b8db391=
%40isocpp.org</a>.<br />

------=_Part_2283_874870632.1476798279657--

------=_Part_2282_462927410.1476798279657--

.

On 18 October 2016 at 16:44,  <mihailnajdenov@gmail.com> wrote:
> is this safe?
>
> p.reset(new int{});
>
> Right now - yes!, with any smart pointer.

No, because you have now given your shared_ptr an object with a
default deleter, which might
not be what your program expected. You have also decreased the
reference count of the original
object, which might again not be what your program expected.

It might not be safe for a unique_ptr either, depending on what your
deleter type is.

--
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/CAFk2RUatxD%3DB9-_P5yBRBrHqFvj123v6BQ%3DQFRpe9UNMGWH4Gw%40mail.gmail.com.

.

--001a114423427d5aed053f24ad82
Content-Type: text/plain; charset=UTF-8

On Tue, Oct 18, 2016 at 9:44 AM, <mihailnajdenov@gmail.com> wrote:

>
>
> On Tuesday, October 18, 2016 at 4:17:29 PM UTC+3, Ville Voutilainen wrote:
>>
>> On 18 October 2016 at 16:08,  <mihailn...@gmail.com> wrote:
>> > In any case, for a smart pointer, reset and release are lifetime
>> management
>> > interfaces.
>> >
>> > observer_ptr changes this.
>>
>> But yet its users are unlikely to find this a problem, because some of
>> them don't consider
>> reset and release to be lifetime management interfaces.
>>
>
> reset and release is lifetime interface in the context of a smart pointer
> -  if you touch these, the lifetime of the object will change.
> That's a fact, not a point a view.
>

release() doesn't change the object's lifetime for unique_ptr - it hands
the pointer back to you, still alive.  It does change the ownership. It
maybe should have been called detach(), if we wanted to have a distinction
here.  shared_ptr doesn't have a release().

unique_ptr's release appears to be an evolution of auto_ptr's.  Which also
"detached"

   - std::auto_ptr::release
   <http://en.cppreference.com/w/cpp/memory/auto_ptr/release>
   - std::unique_ptr::release
   <http://en.cppreference.com/w/cpp/memory/unique_ptr/release>
   - std::shared_lock::release
   <http://en.cppreference.com/w/cpp/thread/shared_lock/release>
   - std::unique_lock::release
   <http://en.cppreference.com/w/cpp/thread/unique_lock/release>


   - std::pmr::monotonic_buffer_resource::release
   <http://en.cppreference.com/w/cpp/memory/monotonic_buffer_resource/release>
   - std::pmr::unsynchronized_pool_resource::release
   <http://en.cppreference.com/w/cpp/memory/unsynchronized_pool_resource/release>


The first 4 "detach" - ie break the association, without changing the
underlying object lifetime/state/refcount
The last 2 actually release the memory.

This is unfortunate deviation of the word "release", maybe the last 2
should be changed?

Outside the standard, release() usually means free() or decr-refcount etc,
so auto_ptr didn't set a precedent outside the standard unfortunately :-(


(There's also memory_order_release but I think the context there is
different enough to not cause confusion)


--
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/CAOHCbiskO5DpTwym8nH%3Dyra%2BYpa-%2Bb-ycfSV%2B34JLjPqC8ST4g%40mail.gmail.com.

--001a114423427d5aed053f24ad82
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Oct 18, 2016 at 9:44 AM,  <span dir=3D"ltr">&lt;<a href=3D"mail=
to:mihailnajdenov@gmail.com" target=3D"_blank">mihailnajdenov@gmail.com</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><di=
v dir=3D"ltr"><br><br>On Tuesday, October 18, 2016 at 4:17:29 PM UTC+3, Vil=
le Voutilainen wrote:<span class=3D"gmail-"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">On 18 October 2016 at 16:08, =C2=A0&lt;<a rel=3D"nofollo=
w">mihailn...@gmail.com</a>&gt; wrote:
<br>&gt; In any case, for a smart pointer, reset and release are lifetime m=
anagement
<br>&gt; interfaces.
<br>&gt;
<br>&gt; observer_ptr changes this.
<br>
<br>But yet its users are unlikely to find this a problem, because some of
<br>them don&#39;t consider
<br>reset and release to be lifetime management interfaces.
<br></blockquote><div><br></div></span><div>reset and release is lifetime i=
nterface in the context of a smart pointer -=C2=A0 if you touch these, the =
lifetime of the object will change. </div><div>That&#39;s a fact,=C2=A0not =
a point a view.</div></div></blockquote><div><br></div><div>release() doesn=
&#39;t change the object&#39;s lifetime for unique_ptr - it hands the point=
er back to you, still alive.=C2=A0 It does change the ownership. It maybe s=
hould have been called detach(), if we wanted to have a distinction here.=
=C2=A0 shared_ptr doesn&#39;t have a release().<br><br></div><div><p>unique=
_ptr&#39;s release appears to be an evolution of auto_ptr&#39;s.=C2=A0 Whic=
h also &quot;detached&quot;</p><ul class=3D"gmail-mw-search-results"><li><d=
iv class=3D"gmail-mw-search-result-heading"><a href=3D"http://en.cppreferen=
ce.com/w/cpp/memory/auto_ptr/release" title=3D"cpp/memory/auto ptr/release"=
>std::auto_ptr::release</a></div>
</li><li><div class=3D"gmail-mw-search-result-heading"><a href=3D"http://en=
..cppreference.com/w/cpp/memory/unique_ptr/release" title=3D"cpp/memory/uniq=
ue ptr/release">std::unique_ptr::release</a></div>
</li><li><div class=3D"gmail-mw-search-result-heading"><a href=3D"http://en=
..cppreference.com/w/cpp/thread/shared_lock/release" title=3D"cpp/thread/sha=
red lock/release">std::shared_lock::release</a></div>
</li><li><div class=3D"gmail-mw-search-result-heading"><a href=3D"http://en=
..cppreference.com/w/cpp/thread/unique_lock/release" title=3D"cpp/thread/uni=
que lock/release">std::unique_lock::release</a></div></li></ul><ul class=3D=
"gmail-mw-search-results"><li><div class=3D"gmail-mw-search-result-heading"=
><a href=3D"http://en.cppreference.com/w/cpp/memory/monotonic_buffer_resour=
ce/release" title=3D"cpp/memory/monotonic buffer resource/release">std::pmr=
::monotonic_buffer_resource::release</a></div>
</li><li><div class=3D"gmail-mw-search-result-heading"><a href=3D"http://en=
..cppreference.com/w/cpp/memory/unsynchronized_pool_resource/release" title=
=3D"cpp/memory/unsynchronized pool resource/release">std::pmr::unsynchroniz=
ed_pool_resource::release</a></div>
</li></ul><p><br></p><p>The first 4 &quot;detach&quot; - ie break the assoc=
iation, without changing the underlying object lifetime/state/refcount</p>T=
he last 2 actually release the memory.<br></div><div><br></div><div>This is=
 unfortunate deviation of the word &quot;release&quot;, maybe the last 2 sh=
ould be changed?<br><br>Outside the standard, release() usually means free(=
) or decr-refcount etc, so auto_ptr didn&#39;t set a precedent outside the =
standard unfortunately :-(<br><br><br></div><div>(There&#39;s also memory_o=
rder_release but I think the context there is different enough to not cause=
 confusion)<br></div><div><br clear=3D"all"></div></div><br>-- <br><div cla=
ss=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<b=
r></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/CAOHCbiskO5DpTwym8nH%3Dyra%2BYpa-%2Bb=
-ycfSV%2B34JLjPqC8ST4g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbisk=
O5DpTwym8nH%3Dyra%2BYpa-%2Bb-ycfSV%2B34JLjPqC8ST4g%40mail.gmail.com</a>.<br=
 />

--001a114423427d5aed053f24ad82--

.

------=_Part_1906_483859536.1476804981583
Content-Type: multipart/alternative;
 boundary="----=_Part_1907_1576240247.1476804981583"

------=_Part_1907_1576240247.1476804981583
Content-Type: text/plain; charset=UTF-8



On Tuesday, October 18, 2016 at 5:40:47 PM UTC+3, Tony V E wrote:
>
>
>
> On Tue, Oct 18, 2016 at 9:44 AM, <mihailn...@gmail.com <javascript:>>
> wrote:
>
>>
>>
>> On Tuesday, October 18, 2016 at 4:17:29 PM UTC+3, Ville Voutilainen wrote:
>>>
>>> On 18 October 2016 at 16:08,  <mihailn...@gmail.com> wrote:
>>> > In any case, for a smart pointer, reset and release are lifetime
>>> management
>>> > interfaces.
>>> >
>>> > observer_ptr changes this.
>>>
>>> But yet its users are unlikely to find this a problem, because some of
>>> them don't consider
>>> reset and release to be lifetime management interfaces.
>>>
>>
>> reset and release is lifetime interface in the context of a smart pointer
>> -  if you touch these, the lifetime of the object will change.
>> That's a fact, not a point a view.
>>
>
> release() doesn't change the object's lifetime for unique_ptr - it hands
> the pointer back to you, still alive.
>

Well, release() changes the lifetime to "live until program termination."
and I don't have a problem with the name at all (or any problem with shared
or unique ptr).

About the many things called release - they are different set of
classes, they can have different meaning what release mean.
I have no problem, optional has reset for instance.

The problem is, until now, only the memory managing pointers have this
interface and this very interface already means something.
If you see today reset (on a pointer), it means only one thing, be it std,
Qt or any other smart pointer.

observer changes this, overloads what reset means, all that for no good
enough reason (by a long shot).

--
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/4d9aa487-c824-490a-ae3a-ac90e2a2db3d%40isocpp.org.

------=_Part_1907_1576240247.1476804981583
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, October 18, 2016 at 5:40:47 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"ltr=
"><br><div><br><div class=3D"gmail_quote">On Tue, Oct 18, 2016 at 9:44 AM, =
 <span dir=3D"ltr">&lt;<a onmousedown=3D"this.href=3D&#39;javascript:&#39;;=
return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;" hr=
ef=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=
=3D"GzdVgruTBgAJ">mihailn...@gmail.com</a>&gt;</span> wrote:<br><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br><br>On Tuesday,=
 October 18, 2016 at 4:17:29 PM UTC+3, Ville Voutilainen wrote:<span><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex">On 18 October 2016 at 16:08, =
=C2=A0&lt;<a rel=3D"nofollow">mihailn...@gmail.com</a>&gt; wrote: <br>&gt; =
In any case, for a smart pointer, reset and release are lifetime management=
 <br>&gt; interfaces. <br>&gt;<br>&gt; observer_ptr changes this. <br><br>B=
ut yet its users are unlikely to find this a problem, because some of <br>t=
hem don&#39;t consider <br>reset and release to be lifetime management inte=
rfaces. <br></blockquote><div><br></div></span><div>reset and release is li=
fetime interface in the context of a smart pointer -=C2=A0 if you touch the=
se, the lifetime of the object will change. </div><div>That&#39;s a fact,=
=C2=A0not a point a view.</div></div></blockquote><div><br></div><div>relea=
se() doesn&#39;t change the object&#39;s lifetime for unique_ptr - it hands=
 the pointer back to you, still alive.<br></div></div></div></div></blockqu=
ote><div><br></div><div>Well, release() changes the lifetime to &quot;live =
until program termination.&quot; and I don&#39;t have a problem with the na=
me at all (or any problem with shared or unique ptr). </div><div><br></div>=
<div>About the many things called release - they are different set of class=
es,=C2=A0they can have different meaning what release mean. </div><div>I ha=
ve no problem,=C2=A0optional has reset for instance.</div><div><br></div><d=
iv>The problem is, until now,=C2=A0only=C2=A0the memory managing=C2=A0point=
ers have this interface and this very interface=C2=A0already means somethin=
g. </div><div>If you=C2=A0see=C2=A0today=C2=A0reset (on a pointer), it mean=
s only one thing, be it std, Qt or any other smart pointer. </div><div><br>=
</div><div>observer changes this, overloads what reset means, all that for =
no good enough reason (by a long shot).</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/4d9aa487-c824-490a-ae3a-ac90e2a2db3d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4d9aa487-c824-490a-ae3a-ac90e2a2db3d=
%40isocpp.org</a>.<br />

------=_Part_1907_1576240247.1476804981583--

------=_Part_1906_483859536.1476804981583--

.

On 18 October 2016 at 18:36,  <mihailnajdenov@gmail.com> wrote:
>> release() doesn't change the object's lifetime for unique_ptr - it hands
>> the pointer back to you, still alive.
> Well, release() changes the lifetime to "live until program termination."

Depends on how the resource was acquired.

> The problem is, until now, only the memory managing pointers have this
> interface and this very interface already means something.
> If you see today reset (on a pointer), it means only one thing, be it std,
> Qt or any other smart pointer.

I can quite easily write such a deleter that reset() on a shared_ptr
and on a unique_ptr
will do exactly what observer_ptr's reset() does.

> observer changes this, overloads what reset means, all that for no good
> enough reason (by a long shot).

Well, reset() means what it always meant, it resets the handle to have
some other pointer or none.
The same logic applies to release(). As far as reasons go,
observer_ptr remains superior
to things like owner<T>, since it says nothing about ownership
semantics and is not a pointer.
The latter bit is the most useful characteristic of observer_ptr, and
while it has downsides for some
cases, that's a tolerable trade-off to make for quite many audiences.
The former bit is surprisingly
handy as well.

--
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/CAFk2RUZC6anr-MkMA37H3LKM235Uxh0Y6z58KyvRK-4h3R6%2BRw%40mail.gmail.com.

.

--001a1148e288073d69053f263282
Content-Type: text/plain; charset=UTF-8

On Tue, Oct 18, 2016 at 8:16 AM, Bo Persson <bop@gmb.dk> wrote:

>
>
> Having similar functions use the same names as functions of the slighlty
> smarter pointers, might help replacing those with an observer_pointer.
> Changing "release" into "stop_observing" (or something) doesn't appeal to
> me.
>
>
> If we look at a similar problem in merging "optional", "variant", and
> "any" into the draft standard, we ended up with two of them having a "bool
> has_value()" function, while the third got a "bool
> valueless_by_exception()".
>
> Not only do they have different names, but also different true/false
> return value for the same(?) condition - does it store anything.
>


This was very intentional.  optional and any are expected to be empty,
variant is not.  My personal suggestion is to never call
valueless_by_exception().  Depends on your codebase and type of product,
but in most cases, if your variant got into the valueless state, you have
bigger problems to worry about.



>    Bo Persson
>
>

--
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/CAOHCbivK2Hu5ch58FC9dPb5RfnKVDrd5Sj4b7hJMUKkTciZtng%40mail.gmail.com.

--001a1148e288073d69053f263282
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Oct 18, 2016 at 8:16 AM, Bo Persson <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:bop@gmb.dk" target=3D"_blank">bop@gmb.dk</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><br>
<br>
Having similar functions use the same names as functions of the slighlty sm=
arter pointers, might help replacing those with an observer_pointer. Changi=
ng &quot;release&quot; into &quot;stop_observing&quot; (or something) doesn=
&#39;t appeal to me.<br>
<br>
<br>
If we look at a similar problem in merging &quot;optional&quot;, &quot;vari=
ant&quot;, and &quot;any&quot; into the draft standard, we ended up with tw=
o of them having a &quot;bool has_value()&quot; function, while the third g=
ot a &quot;bool valueless_by_exception()&quot;.<br>
<br>
Not only do they have different names, but also different true/false return=
 value for the same(?) condition - does it store anything.<br></blockquote>=
<div><br></div><div><br>This was very intentional.=C2=A0 optional and any a=
re expected to be empty, variant is not.=C2=A0 My personal suggestion is to=
 never call valueless_by_exception().=C2=A0 Depends on your codebase and ty=
pe of product, but in most cases, if your variant got into the valueless st=
ate, you have bigger problems to worry about.<br><br><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">
<br>
=C2=A0 =C2=A0Bo Persson<span class=3D""><br>
</span><br></blockquote></div><br clear=3D"all"><br>-- <br><div class=3D"gm=
ail_signature" data-smartmail=3D"gmail_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/CAOHCbivK2Hu5ch58FC9dPb5RfnKVDrd5Sj4b=
7hJMUKkTciZtng%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivK2Hu5ch58=
FC9dPb5RfnKVDrd5Sj4b7hJMUKkTciZtng%40mail.gmail.com</a>.<br />

--001a1148e288073d69053f263282--

.

------=_Part_1231_1554030472.1476808407629
Content-Type: multipart/alternative;
 boundary="----=_Part_1232_1924318238.1476808407629"

------=_Part_1232_1924318238.1476808407629
Content-Type: text/plain; charset=UTF-8



On Tuesday, October 18, 2016 at 6:45:50 PM UTC+3, Ville Voutilainen wrote:
>
>
> > observer changes this, overloads what reset means, all that for no good
> > enough reason (by a long shot).
>
> Well, reset() means what it always meant, it resets the handle to have
> some other pointer or none.
>

It was never just about the handle,* it was always about the object
lifetime.*

Let me point of the irony here.

We can have unique_ptr to consume a row pointer just with assignment - we
have overloading for that.
But we don't do it. We invent a function.
This function is called reset
It is there to state intend.
It is there to say, "take this object and manage it for me, you are the
owner now".
And from this point onwards, every well behaved smart pointer library uses
this idiom.
You can read 10+ years old code and reset will be there, saying the same
thing.

Now comes a pointer which stops obeying this idiom.
It starts using reset() as operator=
From this point onwards when encountering reset (on a pointer) is code is
ambiguous -
"Does it transfer or does it not? Better dig out the definition of the
pointer?"

So we invited ourselves the reverse problem reset() solved decades ago.

*Where before we prevented the ambiguity of operator=(T*).*
*Now we introduce ambiguity in reset().*

All this for a dumb pointer trying to be smart.

--
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/080a6163-4350-4246-a2d6-a3ae7f6db473%40isocpp.org.

------=_Part_1232_1924318238.1476808407629
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, October 18, 2016 at 6:45:50 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;"><br>&g=
t; observer changes this, overloads what reset means, all that for no good
<br>&gt; enough reason (by a long shot).
<br>
<br>Well, reset() means what it always meant, it resets the handle to have
<br>some other pointer or none.
<br></blockquote><div><br></div><div>It was never just about the handle,<b>=
 it was always about the object lifetime.</b></div><div><br></div><div>Let =
me point of the irony here.</div><div><br></div><div>We can have unique_ptr=
 to consume a row pointer just with assignment - we have overloading for th=
at.</div><div>But we don&#39;t do it. We invent a function.</div><div>This =
function is called reset</div><div>It is there to state intend. </div><div>=
It is there to say, &quot;take this object and manage it for me, you are th=
e owner now&quot;.</div><div>And from this point onwards, every well behave=
d smart pointer library uses this idiom.</div><div>You can read 10+ years o=
ld code and reset will be there, saying the same thing.</div><div><br></div=
><div>Now comes a pointer which stops obeying this idiom. </div><div>It sta=
rts using reset() as operator=3D </div><div>From this point onwards when en=
countering reset (on a pointer)=C2=A0is code is ambiguous - </div><div>&quo=
t;Does it transfer or does it not? Better dig out=C2=A0the definition of th=
e pointer?&quot;</div><div><br></div><div>So we invited ourselves the rever=
se problem reset() solved decades ago. </div><div><br></div><div><i>Where b=
efore=C2=A0we prevented=C2=A0the ambiguity of operator=3D(T*).</i></div><di=
v><i>Now we introduce ambiguity in reset().</i> </div><div><br></div><div>A=
ll this for a dumb pointer trying to be smart.</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/080a6163-4350-4246-a2d6-a3ae7f6db473%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/080a6163-4350-4246-a2d6-a3ae7f6db473=
%40isocpp.org</a>.<br />

------=_Part_1232_1924318238.1476808407629--

------=_Part_1231_1554030472.1476808407629--

.

------=_Part_2628_1683252204.1476808554485
Content-Type: multipart/alternative;
 boundary="----=_Part_2629_1833196070.1476808554485"

------=_Part_2629_1833196070.1476808554485
Content-Type: text/plain; charset=UTF-8

On Tuesday, October 18, 2016 at 6:03:53 AM UTC-4, mihailn...@gmail.com
wrote:
>
> I was surprised to see
> http://en.cppreference.com/w/cpp/experimental/observer_ptr
>
> I though, it was settled, raw pointers will be serving as non-owning
> pointers? (and use references, as well not_null<> and owner<> to cover
> corner cases and legacy)
>

Who settled this? The C++ Core Guidelines? Does everyone follow those,
uniformly, across all applications?

Some people believe that a codebase should do away with raw pointers
entirely. For them, `observer_ptr` is the correct tool.

Now granted, I would much rather we had `owner` and `not_null` in the
standard library than `observer_ptr`. But right now, even the latter is
just part of Library Fundamentals v2, rather than the standard library. So
while it is "on the table", that's hardly a free ride into the standard
library.

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

------=_Part_2629_1833196070.1476808554485
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, October 18, 2016 at 6:03:53 AM UTC-4, mihailn.=
...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div>I was surprised to see <a href=3D"http://en.cppreference.com/w/c=
pp/experimental/observer_ptr" target=3D"_blank" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fen.cppref=
erence.com%2Fw%2Fcpp%2Fexperimental%2Fobserver_ptr\x26sa\x3dD\x26sntz\x3d1\=
x26usg\x3dAFQjCNFmufar7Hrkvsy5YyDqLXVg8UVzag&#39;;return true;" onclick=3D"=
this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fen.cppreferenc=
e.com%2Fw%2Fcpp%2Fexperimental%2Fobserver_ptr\x26sa\x3dD\x26sntz\x3d1\x26us=
g\x3dAFQjCNFmufar7Hrkvsy5YyDqLXVg8UVzag&#39;;return true;">http://en.cppref=
erence.com/w/<wbr>cpp/experimental/observer_ptr</a> </div><div><br></div><d=
iv>I though, it was settled, raw pointers will be serving as non-owning poi=
nters? (and use references, as well not_null&lt;&gt; and=C2=A0owner&lt;&gt;=
 to cover corner cases and legacy)<br></div></div></blockquote><div><br>Who=
 settled this? The C++ Core Guidelines? Does everyone follow those, uniform=
ly, across all applications?<br><br>Some people believe that a codebase sho=
uld do away with raw pointers entirely. For them, `observer_ptr` is the cor=
rect tool.</div><br>Now granted, I would much rather we had `owner` and `no=
t_null` in the standard library than `observer_ptr`. But right now, even th=
e latter is just part of Library Fundamentals v2, rather than the standard =
library. So while it is &quot;on the table&quot;, that&#39;s hardly a free =
ride into the standard library.<br></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/d2c78dce-5e68-4ff0-b9a3-29d3e9e7e475%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d2c78dce-5e68-4ff0-b9a3-29d3e9e7e475=
%40isocpp.org</a>.<br />

------=_Part_2629_1833196070.1476808554485--

------=_Part_2628_1683252204.1476808554485--

.

On 18 October 2016 at 19:33,  <mihailnajdenov@gmail.com> wrote:
>> > observer changes this, overloads what reset means, all that for no good
>> > enough reason (by a long shot).
>>
>> Well, reset() means what it always meant, it resets the handle to have
>> some other pointer or none.
>
>
> It was never just about the handle, it was always about the object lifetime.

I don't know how many times I need to point out that reset() on a
unique_ptr might have no
effect on the object lifetime, depending on the deleter.

--
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/CAFk2RUandxAXbCfBrF5VuuZif%3DZ8Y__OqDWZpTbaHEjyAPQNQA%40mail.gmail.com.

.

------=_Part_154_868948009.1476810167308
Content-Type: multipart/alternative;
 boundary="----=_Part_155_103732161.1476810167308"

------=_Part_155_103732161.1476810167308
Content-Type: text/plain; charset=UTF-8


On Tuesday, October 18, 2016 at 7:43:11 PM UTC+3, Ville Voutilainen wrote:
>
> ..
>
> I don't know how many times I need to point out that reset() on a
> unique_ptr might have no
> effect on the object lifetime, depending on the deleter.
>

 cppreference.com:

std::unique_ptr is a smart pointer that retains sole ownership of an object
> through a pointer and destroys that object when the unique_ptr goes out of
> scope. No two unique_ptr instances can manage the same object.
>
> The object is destroyed and its memory deallocated when either of the
> following happens:
>  the managing unique_ptr object is destroyed
>  the managing unique_ptr object is assigned another pointer via operator=
> or reset().
>
> The object is destroyed using a potentially user-supplied deleter by
> calling Deleter(ptr). The deleter calls the destructor of the object and
> dispenses the memory.
>

All else is a naughty corner case.

--
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/72ad1e5d-b7c0-414e-a9a1-ac56a43dd51c%40isocpp.org.

------=_Part_155_103732161.1476810167308
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Tuesday, October 18, 2016 at 7:43:11 PM UTC+3, Vill=
e Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">..<br>
<br>I don&#39;t know how many times I need to point out that reset() on a
<br>unique_ptr might have no
<br>effect on the object lifetime, depending on the deleter.
<br></blockquote><div><br></div><div>=C2=A0cppreference.com:</div><div><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-widt=
h: 1px; border-left-style: solid;"><div>std::unique_ptr is a smart pointer =
that retains sole ownership of an object through a pointer and destroys tha=
t object when the unique_ptr goes out of scope. No two unique_ptr instances=
 can manage the same object. </div><div><br></div><div>The object is destro=
yed and its memory deallocated when either of the following happens: <br>=
=C2=A0the managing unique_ptr object is destroyed <br>=C2=A0the managing un=
ique_ptr object is assigned another pointer via operator=3D or reset(). </d=
iv><div><br></div><div>The object is destroyed using a potentially user-sup=
plied deleter by calling Deleter(ptr). The deleter calls the destructor of =
the object and dispenses the memory. <br></div></blockquote><div><br></div>=
<div>All else is a naughty corner case.=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/72ad1e5d-b7c0-414e-a9a1-ac56a43dd51c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/72ad1e5d-b7c0-414e-a9a1-ac56a43dd51c=
%40isocpp.org</a>.<br />

------=_Part_155_103732161.1476810167308--

------=_Part_154_868948009.1476810167308--

.

On 18 October 2016 at 20:02,  <mihailnajdenov@gmail.com> wrote:
>
> On Tuesday, October 18, 2016 at 7:43:11 PM UTC+3, Ville Voutilainen wrote:
>>
>> ..
>>
>> I don't know how many times I need to point out that reset() on a
>> unique_ptr might have no
>> effect on the object lifetime, depending on the deleter.
>
>
>  cppreference.com:
>
>> std::unique_ptr is a smart pointer that retains sole ownership of an
>> object through a pointer and destroys that object when the unique_ptr goes
>> out of scope. No two unique_ptr instances can manage the same object.
>>
>> The object is destroyed and its memory deallocated when either of the
>> following happens:
>>  the managing unique_ptr object is destroyed
>>  the managing unique_ptr object is assigned another pointer via operator=
>> or reset().
>>
>> The object is destroyed using a potentially user-supplied deleter by
>> calling Deleter(ptr). The deleter calls the destructor of the object and
>> dispenses the memory.
>
>
> All else is a naughty corner case.


All else is subject to the semantics of any possible custom deleter
provided, and none of that nonsense
on cppreference applies to such custom deleters. The standard doesn't
make such incorrect claims about
how unique_ptr works.

--
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/CAFk2RUbk-%2BNuF0Vh0VggU6xPL-uzz_PXnuHVuM%3DKsSC3JQjGWA%40mail.gmail.com.

.

------=_Part_2611_1516409800.1476812881087
Content-Type: multipart/alternative;
 boundary="----=_Part_2612_1450826219.1476812881088"

------=_Part_2612_1450826219.1476812881088
Content-Type: text/plain; charset=UTF-8



On Tuesday, October 18, 2016 at 1:06:42 PM UTC-4, Ville Voutilainen wrote:
>
> On 18 October 2016 at 20:02,  <mihailn...@gmail.com <javascript:>> wrote:
> >
> > On Tuesday, October 18, 2016 at 7:43:11 PM UTC+3, Ville Voutilainen
> wrote:
> >>
> >> ..
> >>
> >> I don't know how many times I need to point out that reset() on a
> >> unique_ptr might have no
> >> effect on the object lifetime, depending on the deleter.
> >
> >
> >  cppreference.com:
> >
> >> std::unique_ptr is a smart pointer that retains sole ownership of an
> >> object through a pointer and destroys that object when the unique_ptr
> goes
> >> out of scope. No two unique_ptr instances can manage the same object.
> >>
> >> The object is destroyed and its memory deallocated when either of the
> >> following happens:
> >>  the managing unique_ptr object is destroyed
> >>  the managing unique_ptr object is assigned another pointer via
> operator=
> >> or reset().
> >>
> >> The object is destroyed using a potentially user-supplied deleter by
> >> calling Deleter(ptr). The deleter calls the destructor of the object
> and
> >> dispenses the memory.
> >
> >
> > All else is a naughty corner case.
>
>
> All else is subject to the semantics of any possible custom deleter
> provided, and none of that nonsense
> on cppreference applies to such custom deleters. The standard doesn't
> make such incorrect claims about
> how unique_ptr works.
>

Fixed, I think.

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

------=_Part_2612_1450826219.1476812881088
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, October 18, 2016 at 1:06:42 PM UTC-4, =
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 18 =
October 2016 at 20:02, =C2=A0&lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"89519rGbBgAJ" rel=3D"nofollow" onmousedown=3D"this=
..href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;">mihailn...@gmail.com</a>&gt; wrote:
<br>&gt;
<br>&gt; On Tuesday, October 18, 2016 at 7:43:11 PM UTC+3, Ville Voutilaine=
n wrote:
<br>&gt;&gt;
<br>&gt;&gt; ..
<br>&gt;&gt;
<br>&gt;&gt; I don&#39;t know how many times I need to point out that reset=
() on a
<br>&gt;&gt; unique_ptr might have no
<br>&gt;&gt; effect on the object lifetime, depending on the deleter.
<br>&gt;
<br>&gt;
<br>&gt; =C2=A0<a href=3D"http://cppreference.com" target=3D"_blank" rel=3D=
"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dh=
ttp%3A%2F%2Fcppreference.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFfMEVs=
riPdiSLWG49XWK9zX_c5Ug&#39;;return true;" onclick=3D"this.href=3D&#39;http:=
//www.google.com/url?q\x3dhttp%3A%2F%2Fcppreference.com\x26sa\x3dD\x26sntz\=
x3d1\x26usg\x3dAFQjCNFfMEVsriPdiSLWG49XWK9zX_c5Ug&#39;;return true;">cppref=
erence.com</a>:
<br>&gt;
<br>&gt;&gt; std::unique_ptr is a smart pointer that retains sole ownership=
 of an
<br>&gt;&gt; object through a pointer and destroys that object when the uni=
que_ptr goes
<br>&gt;&gt; out of scope. No two unique_ptr instances can manage the same =
object.
<br>&gt;&gt;
<br>&gt;&gt; The object is destroyed and its memory deallocated when either=
 of the
<br>&gt;&gt; following happens:
<br>&gt;&gt; =C2=A0the managing unique_ptr object is destroyed
<br>&gt;&gt; =C2=A0the managing unique_ptr object is assigned another point=
er via operator=3D
<br>&gt;&gt; or reset().
<br>&gt;&gt;
<br>&gt;&gt; The object is destroyed using a potentially user-supplied dele=
ter by
<br>&gt;&gt; calling Deleter(ptr). The deleter calls the destructor of the =
object and
<br>&gt;&gt; dispenses the memory.
<br>&gt;
<br>&gt;
<br>&gt; All else is a naughty corner case.
<br>
<br>
<br>All else is subject to the semantics of any possible custom deleter
<br>provided, and none of that nonsense
<br>on cppreference applies to such custom deleters. The standard doesn&#39=
;t
<br>make such incorrect claims about
<br>how unique_ptr works.
<br></blockquote><div><br></div><div>Fixed, I think.=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/df7f2588-4f7f-4cef-a337-fd186d4fef7f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/df7f2588-4f7f-4cef-a337-fd186d4fef7f=
%40isocpp.org</a>.<br />

------=_Part_2612_1450826219.1476812881088--

------=_Part_2611_1516409800.1476812881087--

.

------=_Part_2496_1070690112.1476818199825
Content-Type: multipart/alternative;
 boundary="----=_Part_2497_588594647.1476818199825"

------=_Part_2497_588594647.1476818199825
Content-Type: text/plain; charset=UTF-8



On Tuesday, October 18, 2016 at 8:06:42 PM UTC+3, Ville Voutilainen wrote:
>
> ...
>
> All else is subject to the semantics of any possible custom deleter
> provided, and none of that nonsense
> on cppreference applies to such custom deleters. The standard doesn't
> make such incorrect claims about
> how unique_ptr works.
>

*No matter* what the deleter does, reset is added to make it explicit, the
deleter will be called both on the old object (if any) and at some later
time on the new one (if any).

The sole reason reset, as a function, exist is to donate this
functionality. No other reason.
With shared ptr is practically the same similar, just the deleter call
might be delayed, again *no matter what the deleter does.*

This is, until observer_ptr comes and reintroduce the very same ambiguity,
reset solved - does it call my (magic) deleter or does it not.

--
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/c12566c2-5815-41ff-a57f-1cf7b5c49916%40isocpp.org.

------=_Part_2497_588594647.1476818199825
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, October 18, 2016 at 8:06:42 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;">...<br=
><br>All else is subject to the semantics of any possible custom deleter <b=
r>provided, and none of that nonsense <br>on cppreference applies to such c=
ustom deleters. The standard doesn&#39;t <br>make such incorrect claims abo=
ut <br>how unique_ptr works. <br></blockquote><div><br></div><div><i>No mat=
ter</i> what the deleter does, reset is added to make it explicit,=C2=A0the=
 deleter will be called both=C2=A0on the old object (if any)=C2=A0and at so=
me later time on the new one (if any).</div><div><br></div><div>The sole re=
ason=C2=A0reset, as a function,=C2=A0exist is to donate this functionality.=
 No other reason.</div><div>With shared ptr is=C2=A0practically the same=C2=
=A0similar, just the deleter call might be delayed, again <i>no matter what=
 the deleter does.</i></div><div><br></div><div>This is, until observer_ptr=
 comes and reintroduce the very same ambiguity, reset solved - does it call=
 my (magic) deleter=C2=A0or does it not.<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/c12566c2-5815-41ff-a57f-1cf7b5c49916%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c12566c2-5815-41ff-a57f-1cf7b5c49916=
%40isocpp.org</a>.<br />

------=_Part_2497_588594647.1476818199825--

------=_Part_2496_1070690112.1476818199825--

.

------=_Part_1563_1074292619.1476821388357
Content-Type: multipart/alternative;
 boundary="----=_Part_1564_2015910521.1476821388357"

------=_Part_1564_2015910521.1476821388357
Content-Type: text/plain; charset=UTF-8

On Tuesday, October 18, 2016 at 9:44:40 AM UTC-4, mihailn...@gmail.com
wrote:
>
> On Tuesday, October 18, 2016 at 4:17:29 PM UTC+3, Ville Voutilainen wrote:
>>
>> On 18 October 2016 at 16:08,  <mihailn...@gmail.com> wrote:
>> > In any case, for a smart pointer, reset and release are lifetime
>> management
>> > interfaces.
>> >
>> > observer_ptr changes this.
>>
>> But yet its users are unlikely to find this a problem, because some of
>> them don't consider
>> reset and release to be lifetime management interfaces.
>>
>
> reset and release is lifetime interface in the context of a smart pointer
> -  if you touch these, the lifetime of the object will change.
> That's a fact, not a point a view.
>

No, it is a point of view.

To hold onto a smart pointer object means that you expect the object
pointed to by the smart pointer to continue to exist, pursuant to the smart
pointer's contract. A `weak_ptr` does not ensure the lifetime of the
pointed-to object. What it does ensure is that, if that lifetime has ended,
you'll know about it. You may get a NULL pointer, but you'll never get an
invalid one.

When you `reset` a smart pointer, you are saying that you no longer expect
that object to exist. Whether or not it is actually destoryed is
smart-pointer specific. `shared_ptr::reset` doesn't guarantee the object
will be destroyed. `weak_ptr::reset` doesn't destroy anything at all.

By calling `reset`, you are making a contract with the smart pointer. From
that point forward, you will not do anything to access the object
referenced by that smart pointer, nor any object who's lifetime depends on
it, *unless* you have a guarantee from some other object. That is, as far
as this particular smart pointer is concerned, it is not going to ensure
anything.

`release` isn't even a function that most smart pointers have.

observer_ptr pretends to be smart with risk of being harmful and/or
> confusing.
>

To whom is it harmful or confusing? Are you actually trying to claim that
someone is going to assume that a smart pointer with the word "observer" in
it is going to manage memory?

Anyone who does that *deserves* what they get.

The point of `observer_ptr` is to represent when a function is being given
a pointer it does not have ownership of.

--
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/986ffd0c-7466-476a-96af-525aaf8b24ea%40isocpp.org.

------=_Part_1564_2015910521.1476821388357
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, October 18, 2016 at 9:44:40 AM UTC-4, mihailn.=
...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">On Tuesday, October 18, 2016 at 4:17:29 PM UTC+3, Ville Voutilainen w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex">On 18 October 2016 at 16:08, =
=C2=A0&lt;<a rel=3D"nofollow">mihailn...@gmail.com</a>&gt; wrote:
<br>&gt; In any case, for a smart pointer, reset and release are lifetime m=
anagement
<br>&gt; interfaces.
<br>&gt;
<br>&gt; observer_ptr changes this.
<br>
<br>But yet its users are unlikely to find this a problem, because some of
<br>them don&#39;t consider
<br>reset and release to be lifetime management interfaces.
<br></blockquote><div><br></div><div>reset and release is lifetime interfac=
e in the context of a smart pointer -=C2=A0 if you touch these, the lifetim=
e of the object will change. </div><div>That&#39;s a fact,=C2=A0not a point=
 a view.</div></div></blockquote><div><br>No, it is a point of view.<br><br=
>To hold onto a smart pointer object means that you expect the object point=
ed to by the smart pointer to continue to exist, pursuant to the smart poin=
ter&#39;s contract. A `weak_ptr` does not ensure the lifetime of the pointe=
d-to object. What it does ensure is that, if that lifetime has ended, you&#=
39;ll know about it. You may get a NULL pointer, but you&#39;ll never get a=
n invalid one.<br><br>When you `reset` a smart pointer, you are saying that=
 you no longer expect that object to exist. Whether or not it is actually d=
estoryed is smart-pointer specific. `shared_ptr::reset` doesn&#39;t guarant=
ee the object will be destroyed. `weak_ptr::reset` doesn&#39;t destroy anyt=
hing at all.<br><br>By calling `reset`, you are making a contract with the =
smart pointer. From that point forward, you will not do anything to access =
the object referenced by that smart pointer, nor any object who&#39;s lifet=
ime depends on it, <i>unless</i> you have a guarantee from some other objec=
t. That is, as far as this particular smart pointer is concerned, it is not=
 going to ensure anything.<br><br>`release` isn&#39;t even a function that =
most smart pointers have.<br><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><div></div><div>observer_ptr pretends to be smart=
 with risk of being harmful and/or confusing. </div></div></blockquote><div=
 dir=3D"ltr"><br>To whom is it harmful or confusing? Are you actually tryin=
g to claim that someone is going to assume that a smart pointer with the wo=
rd &quot;observer&quot; in it is going to manage memory?<br><br>Anyone who =
does that <i>deserves</i> what they get.<br><br>The point of `observer_ptr`=
 is to represent when a function is being given a pointer it does not have =
ownership of.<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/986ffd0c-7466-476a-96af-525aaf8b24ea%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/986ffd0c-7466-476a-96af-525aaf8b24ea=
%40isocpp.org</a>.<br />

------=_Part_1564_2015910521.1476821388357--

------=_Part_1563_1074292619.1476821388357--

.

------=_Part_2655_868486689.1476826676949
Content-Type: multipart/alternative;
 boundary="----=_Part_2656_123745053.1476826676950"

------=_Part_2656_123745053.1476826676950
Content-Type: text/plain; charset=UTF-8



On Tuesday, October 18, 2016 at 11:09:48 PM UTC+3, Nicol Bolas wrote:
>
> On Tuesday, October 18, 2016 at 9:44:40 AM UTC-4, mihailn...@gmail.com
> wrote:
>>
>> ...
>> No, it is a point of view.
>>
>> To hold onto a smart pointer object means that you expect the object
>> pointed to by the smart pointer to continue to exist, pursuant to the smart
>> pointer's contract. A `weak_ptr` does not ensure the lifetime of the
>> pointed-to object. What it does ensure is that, if that lifetime has ended,
>> you'll know about it. You may get a NULL pointer, but you'll never get an
>> invalid one.
>>
>> When you `reset` a smart pointer, you are saying that you no longer
>> expect that object to exist. Whether or not it is actually destoryed is
>> smart-pointer specific. `shared_ptr::reset` doesn't guarantee the object
>> will be destroyed. `weak_ptr::reset` doesn't destroy anything at all.
>>
>
reset on a waek_ptr does not take a pointer! It does not overload the
meaning of reset!


>
>> By calling `reset`, you are making a contract with the smart pointer.
>> From that point forward, you will not do anything to access the object
>> referenced by that smart pointer, nor any object who's lifetime depends on
>> it, *unless* you have a guarantee from some other object. That is, as
>> far as this particular smart pointer is concerned, it is not going to
>> ensure anything.
>>
>
reset purpose is to re-set the smart pointer to a new value.

reset always, to this point, controls the deleter call - *one way or
another* (right away call, pointer dtor call, use_count etc, etc does not
matter).
This is what a smart pointer ensures, this is what is designed for.

Same with release - touching it, means you are touch the deleter call, when
and if it runs.

So, right now and for many, many years, these *are* lifetime management
APIs.


>
>> `release` isn't even a function that most smart pointers have.
>>
>> observer_ptr pretends to be smart with risk of being harmful and/or
>> confusing.
>>
>
> To whom is it harmful or confusing? Are you actually trying to claim that
> someone is going to assume that a smart pointer with the word "observer" in
> it is going to manage memory?
>

O, yes I do. The moment a lib typedefs these, you are left to wonder what's
up with all those reset-s and release-s.

And what about *auto*? The explicit  type is less and less visible in
modern code.

*Even if* not typedefed, even if you learn the types, you will have to
constantly remind yourself, "is this is observer or is it not".

You look a function and an observer is used.
Then you switch to another function, you see exactly the same code, but
this time it is not an observer and you forgot to look up the type.
You spend 10 min consuming the code in the wrong way, thinking it does one
thing, but it does something different.

This has the exact same problem as if one overloads a smart
pointer operator= on the managed type.

Two completely different actions (pointer copy and deleter management) are
expressed by visually the same code.
Sure, the type is different, but in this case this is not enough - you
better use different language for different things.

reset is that different language.


> Anyone who does that *deserves* what they get.
>
> The point of `observer_ptr` is to represent when a function is being given
> a pointer it does not have ownership of.
>

As commented, raw pointers are left for that use, and that use only. No
confusion if owner<> is used instead. No overloading of operations. No new
concepts.

And BTW owner<> is better, because it signals the *unordinary* (in modern
code) case, it is labeled, because* it is special*.
Raw pointer is *not labeled*, he is *not special*.

--
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/eb8e8936-fa1b-4087-8dc0-1a76e4f0c6a5%40isocpp.org.

------=_Part_2656_123745053.1476826676950
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, October 18, 2016 at 11:09:48 PM UTC+3,=
 Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">On Tuesday, October 18, 2016 at 9:44:40 AM UTC-4, <a>mihailn...@gmail=
..com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">...=
<br>No, it is a point of view.<br><br>To hold onto a smart pointer object m=
eans that you expect the object pointed to by the smart pointer to continue=
 to exist, pursuant to the smart pointer&#39;s contract. A `weak_ptr` does =
not ensure the lifetime of the pointed-to object. What it does ensure is th=
at, if that lifetime has ended, you&#39;ll know about it. You may get a NUL=
L pointer, but you&#39;ll never get an invalid one.<br><br>When you `reset`=
 a smart pointer, you are saying that you no longer expect that object to e=
xist. Whether or not it is actually destoryed is smart-pointer specific. `s=
hared_ptr::reset` doesn&#39;t guarantee the object will be destroyed. `weak=
_ptr::reset` doesn&#39;t destroy anything at all.<br></div></blockquote></d=
iv></blockquote><div><br></div><div><div>reset on a waek_ptr does not take =
a pointer! It does not overload the meaning of reset!</div><div>=C2=A0</div=
></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>By calling `reset`, =
you are making a contract with the smart pointer. From that point forward, =
you will not do anything to access the object referenced by that smart poin=
ter, nor any object who&#39;s lifetime depends on it, <i>unless</i> you hav=
e a guarantee from some other object. That is, as far as this particular sm=
art pointer is concerned, it is not going to ensure anything.<br></div></bl=
ockquote></div></blockquote><div><br></div><div>reset purpose is to re-set =
the smart pointer to a new value. </div><div><br></div><div>reset always, t=
o=C2=A0this=C2=A0point, controls the deleter call - <i>one way or another</=
i> (right away call, pointer dtor call, use_count etc, etc=C2=A0does not ma=
tter). </div><div>This is=C2=A0what a smart pointer ensures, this is what i=
s designed for.=C2=A0=C2=A0</div><div><br></div><div>Same with release - to=
uching it, means you are=C2=A0touch the deleter call, when and if it runs. =
=C2=A0</div><div><br></div><div>So, right now and for many, many years, the=
se <i>are</i> lifetime management APIs. <br></div><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><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"><br>`release` isn&#39;t even a function=
 that most smart pointers have.<br><br></div></blockquote><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>observer_ptr preten=
ds to be smart with risk of being harmful and/or confusing. </div></div></b=
lockquote><div dir=3D"ltr"><br>To whom is it harmful or confusing? Are you =
actually trying to claim that someone is going to assume that a smart point=
er with the word &quot;observer&quot; in it is going to manage memory?<br><=
/div></div></blockquote><div><br></div><div>O, yes I do. The moment a lib t=
ypedefs these, you are left to wonder what&#39;s up with all those reset-s =
and release-s.</div><div><br></div><div>And what about <b>auto</b>? The exp=
licit=C2=A0 type is less and less visible in modern code.</div><div><br></d=
iv><div><i>Even if</i> not typedefed, even if you learn the types, you will=
 have to constantly remind yourself, &quot;is this is observer or is it not=
&quot;.</div><div><br></div><div>You look a function and=C2=A0an observer i=
s used.</div><div>Then you switch to another function, you see exactly the =
same code, but this time it is not an observer and you forgot to look up th=
e type. </div><div>You spend 10 min consuming the code in the wrong way, th=
inking it does one thing, but it does something different.</div><div><br></=
div><div>This has the exact same problem as if one overloads a smart pointe=
r=C2=A0operator=3D on the managed=C2=A0type. </div><div><br></div><div>Two =
completely different actions (pointer copy and deleter management)=C2=A0are=
 expressed by visually=C2=A0the same code. </div><div>Sure, the type=C2=A0i=
s different, but in this case this is not enough - you better use different=
 language for different things.</div><div><br></div><div>reset=C2=A0is that=
 different language.</div><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><div dir=3D"ltr"><br>Anyone who does that <i>de=
serves</i> what they get.<br><br>The point of `observer_ptr` is to represen=
t when a function is being given a pointer it does not have ownership of.<b=
r></div></div></blockquote><div><br></div><div>As commented, raw pointers a=
re left for that use, and that use=C2=A0only. No confusion if owner&lt;&gt;=
 is used instead. No overloading of operations. No new concepts.</div><div>=
<br></div><div>And BTW owner&lt;&gt; is better, because it signals the <i>u=
nordinary</i> (in modern code) case,=C2=A0it is labeled, because<i> it is s=
pecial</i>. </div><div>Raw pointer is <i>not labeled</i>, he is <i>not spec=
ial</i>. </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/eb8e8936-fa1b-4087-8dc0-1a76e4f0c6a5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/eb8e8936-fa1b-4087-8dc0-1a76e4f0c6a5=
%40isocpp.org</a>.<br />

------=_Part_2656_123745053.1476826676950--

------=_Part_2655_868486689.1476826676949--

.

------=_Part_534_625940248.1476829874016
Content-Type: multipart/alternative;
 boundary="----=_Part_535_1547406836.1476829874016"

------=_Part_535_1547406836.1476829874016
Content-Type: text/plain; charset=UTF-8

On Tuesday, October 18, 2016 at 5:37:57 PM UTC-4, mihailn...@gmail.com
wrote:
>
> On Tuesday, October 18, 2016 at 11:09:48 PM UTC+3, Nicol Bolas wrote:
>>
>> On Tuesday, October 18, 2016 at 9:44:40 AM UTC-4, mihailn...@gmail.com
>> wrote:
>>>
>>> ...
>>> No, it is a point of view.
>>>
>>> To hold onto a smart pointer object means that you expect the object
>>> pointed to by the smart pointer to continue to exist, pursuant to the smart
>>> pointer's contract. A `weak_ptr` does not ensure the lifetime of the
>>> pointed-to object. What it does ensure is that, if that lifetime has ended,
>>> you'll know about it. You may get a NULL pointer, but you'll never get an
>>> invalid one.
>>>
>>> When you `reset` a smart pointer, you are saying that you no longer
>>> expect that object to exist. Whether or not it is actually destoryed is
>>> smart-pointer specific. `shared_ptr::reset` doesn't guarantee the object
>>> will be destroyed. `weak_ptr::reset` doesn't destroy anything at all.
>>>
>>
> reset on a waek_ptr does not take a pointer! It does not overload the
> meaning of reset!
>

`reset` on all pointer types doesn't have to be given a pointer. The
parameter is optional; if you pass nothing, then the value of the pointer
becomes NULL.

By calling `reset`, you are making a contract with the smart pointer. From
>>> that point forward, you will not do anything to access the object
>>> referenced by that smart pointer, nor any object who's lifetime depends on
>>> it, *unless* you have a guarantee from some other object. That is, as
>>> far as this particular smart pointer is concerned, it is not going to
>>> ensure anything.
>>>
>>
> reset purpose is to re-set the smart pointer to a new value.
>

And in so doing, you can no longer use the old value.

Consider the following.

auto *ptr = smart_ptr_from_somewhere.get();
smart_ptr_from_somewhere.reset();
ptr->stuff();

Is this reasonable code? Regardless of the type of
`smart_ptr_from_somewhere`, I submit that it is *not reasonable*. It may
work, depending on the exact type of the smart pointer. But it is never
reasonable code.

If the smart pointer is `shared_ptr`, it might work. It might not. If the
smart pointer is an `observer_ptr`, then it will work. If the smart pointer
is a `unique_ptr`, it will almost certainly not work.

But regardless of whether it "works", doing this is a violation of the idea
of resetting a smart pointer. By resetting one, you are releasing your hold
over that object. Whether that *actually* destroys the object or not is
essentially irrelevant. You are saying that you can no longer access a
resource through a particular pointer anymore. And therefore, the smart
pointer is free to do any cleanup. Or not do any, whatever the case may be.

Your point of view is founded on what the code is actually doing. My point
of view is founded in what it means *conceptually*. And that's really what
a reader of this code cares about. `reset` means that the user isn't going
to use it anymore, not "delete this right now".

If the above code were submitted to code review, I would say that the
reader should reject it *regardless* of what kind of smart pointer it is.
The reader should not look up the pointer type, and check various other
things to see if the object is live or some such.

The problem is not that the code might be broken. The problem is that the
code *always* doesn't make sense.


> Same with release - touching it, means you are touch the deleter call,
> when and if it runs.
>

No. `unique_ptr::release` means that you are now in control of, and
therefore assume the responsibility of, releasing the resource managed by
the object.

Now, I agree that `observer_ptr` should not have such a function. But only
because it conceptually makes no more sense for an `observer_ptr` to be
able to release the pointer than it does for a `shared_ptr` to do so. It
cannot release ownership that it does not possess.

`release` isn't even a function that most smart pointers have.
>>>
>>> observer_ptr pretends to be smart with risk of being harmful and/or
>>> confusing.
>>>
>>
>> To whom is it harmful or confusing? Are you actually trying to claim that
>> someone is going to assume that a smart pointer with the word "observer" in
>> it is going to manage memory?
>>
>
> O, yes I do. The moment a lib typedefs these, you are left to wonder
> what's up with all those reset-s and release-s.
>

Even if I agree that `reset` on an observer_ptr creates confusion, I submit
that this confusion will be highly localized. Why?

Because at the end of the day, `reset` is not a commonly used function.

Really, how many times have you actually `reset` a smart pointer object
explicitly? Usually, you copy/move into them, typically from
`make_unique/shared` or with some other pointer you've been given. The most
common use is to create them on the stack/as member variables, initialize
them, and let the scope/destructor clean them up.

Oh sure, `reset` happens. But it's hardly the most common usage of smart
pointers. So I won't be wondering about "all those" calls to a rarely used
function.


> You look a function and an observer is used.
> Then you switch to another function, you see exactly the same code, but
> this time it is not an observer and you forgot to look up the type.
>
You spend 10 min consuming the code in the wrong way, thinking it does one
> thing, but it does something different.
>

It's no more different than wondering if `shared_ptr::reset` is destroying
the object or not.

This has the exact same problem as if one overloads a smart
> pointer operator= on the managed type.
>

No, it does not. That is about preventing the implicit adopting and
managing a pointer which was not meant to be managed. It has nothing to do
with the implicit ending of the management of the existing object.

Anyone who does that *deserves* what they get.
>>
>> The point of `observer_ptr` is to represent when a function is being
>> given a pointer it does not have ownership of.
>>
>
> As commented, raw pointers are left for that use, and that use only.
>

You declared this, but with no proof. Yes, the C++ core guidelines lays
this out, but they are *not* the Gods of All C++ Programming. They are not
a Holy Text brought down from the mountain top. They are not divinely
inspired wisdom. They're just a set of rules.

While I certainly prefer their use of raw pointers, if someone else has a
different use, that's up to them and their codebase. I lack the arrogance
to declare that they are *wrong* to want to go a different way.

--
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/5adf05e5-edb4-4706-816b-59b71d5c1a6f%40isocpp.org.

------=_Part_535_1547406836.1476829874016
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, October 18, 2016 at 5:37:57 PM UTC-4, mihailn.=
...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">On Tuesday, October 18, 2016 at 11:09:48 PM UTC+3, Nicol Bolas wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, Octobe=
r 18, 2016 at 9:44:40 AM UTC-4, <a>mihailn...@gmail.com</a> wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">...<br>No, it is a point of=
 view.<br><br>To hold onto a smart pointer object means that you expect the=
 object pointed to by the smart pointer to continue to exist, pursuant to t=
he smart pointer&#39;s contract. A `weak_ptr` does not ensure the lifetime =
of the pointed-to object. What it does ensure is that, if that lifetime has=
 ended, you&#39;ll know about it. You may get a NULL pointer, but you&#39;l=
l never get an invalid one.<br><br>When you `reset` a smart pointer, you ar=
e saying that you no longer expect that object to exist. Whether or not it =
is actually destoryed is smart-pointer specific. `shared_ptr::reset` doesn&=
#39;t guarantee the object will be destroyed. `weak_ptr::reset` doesn&#39;t=
 destroy anything at all.<br></div></blockquote></div></blockquote><div><br=
></div><div><div>reset on a waek_ptr does not take a pointer! It does not o=
verload the meaning of reset!</div></div></div></blockquote><div><br>`reset=
` on all pointer types doesn&#39;t have to be given a pointer. The paramete=
r is optional; if you pass nothing, then the value of the pointer becomes N=
ULL.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div><div></div></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><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">By callin=
g `reset`, you are making a contract with the smart pointer. From that poin=
t forward, you will not do anything to access the object referenced by that=
 smart pointer, nor any object who&#39;s lifetime depends on it, <i>unless<=
/i> you have a guarantee from some other object. That is, as far as this pa=
rticular smart pointer is concerned, it is not going to ensure anything.<br=
></div></blockquote></div></blockquote><div><br></div><div>reset purpose is=
 to re-set the smart pointer to a new value.</div></div></blockquote><div><=
br>And in so doing, you can no longer use the old value.<br><br>Consider th=
e following.<br><br><div style=3D"background-color: rgb(250, 250, 250); bor=
der-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; over=
flow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><=
div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">ptr </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> smart_ptr_from_somewhere=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">get</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>smart_ptr_from_somewhere</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">reset</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>ptr</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">-&gt;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">stuff</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">();</span></div></code></div><br>Is this reasona=
ble code? Regardless of the type of `smart_ptr_from_somewhere`, I submit th=
at it is <i>not reasonable</i>. It may work, depending on the exact type of=
 the smart pointer. But it is never reasonable code.<br><br>If the smart po=
inter is `shared_ptr`, it might work. It might not. If the smart pointer is=
 an `observer_ptr`, then it will work. If the smart pointer is a `unique_pt=
r`, it will almost certainly not work.<br><br>But regardless of whether it =
&quot;works&quot;, doing this is a violation of the idea of resetting a sma=
rt pointer. By resetting one, you are releasing your hold over that object.=
 Whether that <i>actually</i> destroys the object or not is essentially irr=
elevant. You are saying that you can no longer access a resource through a =
particular pointer anymore. And therefore, the smart pointer is free to do =
any cleanup. Or not do any, whatever the case may be.<br><br>Your point of =
view is founded on what the code is actually doing. My point of view is fou=
nded in what it means <i>conceptually</i>. And that&#39;s really what a rea=
der of this code cares about. `reset` means that the user isn&#39;t going t=
o use it anymore, not &quot;delete this right now&quot;.<br><br>If the abov=
e code were submitted to code review, I would say that the reader should re=
ject it <i>regardless</i> of what kind of smart pointer it is. The reader s=
hould not look up the pointer type, and check various other things to see i=
f the object is live or some such.<br><br>The problem is not that the code =
might be broken. The problem is that the code <i>always</i> doesn&#39;t mak=
e sense.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div></div><div>Same with release - touching it, means you are=
=C2=A0touch the deleter call, when and if it runs. =C2=A0</div></div></bloc=
kquote><div><br>No. `unique_ptr::release` means that you are now in control=
 of, and therefore assume the responsibility of, releasing the resource man=
aged by the object.<br><br>Now, I agree that `observer_ptr` should not have=
 such a function. But only because it conceptually makes no more sense for =
an `observer_ptr` to be able to release the pointer than it does for a `sha=
red_ptr` to do so. It cannot release ownership that it does not possess.<br=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><d=
iv></div><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">`release` isn&#3=
9;t even a function that most smart pointers have.<br><br></div></blockquot=
e><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>=
observer_ptr pretends to be smart with risk of being harmful and/or confusi=
ng. </div></div></blockquote><div dir=3D"ltr"><br>To whom is it harmful or =
confusing? Are you actually trying to claim that someone is going to assume=
 that a smart pointer with the word &quot;observer&quot; in it is going to =
manage memory?<br></div></div></blockquote><div><br></div><div>O, yes I do.=
 The moment a lib typedefs these, you are left to wonder what&#39;s up with=
 all those reset-s and release-s.</div></div></blockquote><div><br>Even if =
I agree that `reset` on an observer_ptr creates confusion, I submit that th=
is confusion will be highly localized. Why?<br><br>Because at the end of th=
e day, `reset` is not a commonly used function.<br><br>Really, how many tim=
es have you actually `reset` a smart pointer object explicitly? Usually, yo=
u copy/move into them, typically from `make_unique/shared` or with some oth=
er pointer you&#39;ve been given. The most common use is to create them on =
the stack/as member variables, initialize them, and let the scope/destructo=
r clean them up.<br><br>Oh sure, `reset` happens. But it&#39;s hardly the m=
ost common usage of smart pointers. So I won&#39;t be wondering about &quot=
;all those&quot; calls to a rarely used function.<br>=C2=A0</div><div></div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div></div></blockquote><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>Yo=
u look a function and=C2=A0an observer is used.</div><div>Then you switch t=
o another function, you see exactly the same code, but this time it is not =
an observer and you forgot to look up the type.</div></div></blockquote><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div> </div><div=
>You spend 10 min consuming the code in the wrong way, thinking it does one=
 thing, but it does something different.</div></div></blockquote><div><br>I=
t&#39;s no more different than wondering if `shared_ptr::reset` is destroyi=
ng the object or not.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div></div><div>This has the exact same problem as i=
f one overloads a smart pointer=C2=A0operator=3D on the managed=C2=A0type.<=
/div></div></blockquote><div><br>No, it does not. That is about preventing =
the implicit adopting and managing a pointer which was not meant to be mana=
ged. It has nothing to do with the implicit ending of the management of the=
 existing object.<br><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><div></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div dir=3D"ltr">Anyone who does that <i>deserves</i> what they =
get.<br><br>The point of `observer_ptr` is to represent when a function is =
being given a pointer it does not have ownership of.<br></div></div></block=
quote><div><br></div><div>As commented, raw pointers are left for that use,=
 and that use=C2=A0only.</div></div></blockquote><div><br>You declared this=
, but with no proof. Yes, the C++ core guidelines lays this out, but they a=
re <i>not</i> the Gods of All C++ Programming. They are not a Holy Text bro=
ught down from the mountain top. They are not divinely inspired wisdom. The=
y&#39;re just a set of rules.<br><br>While I certainly prefer their use of =
raw pointers, if someone else has a different use, that&#39;s up to them an=
d their codebase. I lack the arrogance to declare that they are <i>wrong</i=
> to want to go a different way.<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/5adf05e5-edb4-4706-816b-59b71d5c1a6f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5adf05e5-edb4-4706-816b-59b71d5c1a6f=
%40isocpp.org</a>.<br />

------=_Part_535_1547406836.1476829874016--

------=_Part_534_625940248.1476829874016--

.

------=_Part_10_677072121.1476843576524
Content-Type: multipart/alternative;
 boundary="----=_Part_11_56106407.1476843576524"

------=_Part_11_56106407.1476843576524
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=E5=9C=A8 2016=E5=B9=B410=E6=9C=8819=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UT=
C+8=E4=B8=8A=E5=8D=885:37:57=EF=BC=8Cmihailn...@gmail.com=E5=86=99=E9=81=93=
=EF=BC=9A
>
>
>
>>> By calling `reset`, you are making a contract with the smart pointer.=
=20
>>> From that point forward, you will not do anything to access the object=
=20
>>> referenced by that smart pointer, nor any object who's lifetime depends=
 on=20
>>> it, *unless* you have a guarantee from some other object. That is, as=
=20
>>> far as this particular smart pointer is concerned, it is not going to=
=20
>>> ensure anything.
>>>
>>
> reset purpose is to re-set the smart pointer to a new value.=20
>
> reset always, to this point, controls the deleter call - *one way or=20
> another* (right away call, pointer dtor call, use_count etc, etc does not=
=20
> matter).=20
> This is what a smart pointer ensures, this is what is designed for. =20
>
> The name `reset` is not only used on smart pointers. Literally, it has=20
nothing to do with lifetime of *other *objects. The additional meaning is=
=20
granted by the class type.
=20

> Same with release - touching it, means you are touch the deleter call,=20
> when and if it runs. =20
>
> So, right now and for many, many years, these *are* lifetime management=
=20
> APIs.=20
>

I agree `release` is a poor name here, it should have been `detach` or=20
something else to reduce confusion with genuine lifetime management.

But for smart pointers, it is not about lifetime management. Smart pointers=
=20
are even not necessarily involved with controlling the lifetime.

=20
>
>>
>>> `release` isn't even a function that most smart pointers have.
>>>
>>> observer_ptr pretends to be smart with risk of being harmful and/or=20
>>> confusing.=20
>>>
>>
>> To whom is it harmful or confusing? Are you actually trying to claim tha=
t=20
>> someone is going to assume that a smart pointer with the word "observer"=
 in=20
>> it is going to manage memory?
>>
>
> O, yes I do. The moment a lib typedefs these, you are left to wonder=20
> what's up with all those reset-s and release-s.
>
> And what about *auto*? The explicit  type is less and less visible in=20
> modern code.
>
> *Even if* not typedefed, even if you learn the types, you will have to=20
> constantly remind yourself, "is this is observer or is it not".
>
> You look a function and an observer is used.
> Then you switch to another function, you see exactly the same code, but=
=20
> this time it is not an observer and you forgot to look up the type.=20
> You spend 10 min consuming the code in the wrong way, thinking it does on=
e=20
> thing, but it does something different.
>
> This has the exact same problem as if one overloads a smart=20
> pointer operator=3D on the managed type.=20
>
> Two completely different actions (pointer copy and deleter management) ar=
e=20
> expressed by visually the same code.=20
> Sure, the type is different, but in this case this is not enough - you=20
> better use different language for different things.
>
> reset is that different language.
>
> You misread what is "smart".

It is "smart" because as a designer of the interface, you can attach=20
intended additional behavior to something already like pointers. That's=20
all. No magic about lifetime management is guaranteed existed; it is up to=
=20
the designer of the API.
=20

>
>> Anyone who does that *deserves* what they get.
>>
>> The point of `observer_ptr` is to represent when a function is being=20
>> given a pointer it does not have ownership of.
>>
>
> As commented, raw pointers are left for that use, and that use only. No=
=20
> confusion if owner<> is used instead. No overloading of operations. No ne=
w=20
> concepts.
>
> And BTW owner<> is better, because it signals the *unordinary* (in modern=
=20
> code) case, it is labeled, because* it is special*.=20
> Raw pointer is *not labeled*, he is *not special*.=20
>
Raw pointer is simply ill-designed in aspect of the need of a=20
general-purposed language. It is essentially a kind of the sum type of=20
random access iterators and non-owning smart pointer types. The rest thing=
=20
it provides is the ease of binary interops, which is a kind of leaked=20
abstraction from the underlying implementation, and not guaranteed to work=
=20
even in the current language design. Explicit address types may be better=
=20
for the last task.

The sin of raw pointer is, it is *too special*. It has coupled many=20
unrelated functionalities (as portable abstraction) as a bundle in the core=
=20
language (as well polluting the binary interface continuously). To label it=
=20
to get the right functionality is in the sorts of workaround, not the fix,=
=20
even this approach can easily play well with modern language=20
implementations. So there should be a place for the nominal (named)=20
non-owning pointer in a right interface design.

Another thing to be noted: you should normally fix the ownership=20
requirements statically during the design of API, and labeling some=20
non-owning pointers to change them as owning ones is essentially risky and=
=20
difficult to do correctly. Even you have to do so, `owner<>` is not=20
necessarily better. Anyway, to patch it with `owner<>` or convert it to=20
some owning pointer types to express ownership is the further step, based=
=20
on the fact that you have already precisely expressed non-onwership - and=
=20
raw pointer is not the correct type at the first place.


=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/c651cc1b-e3f6-4779-94eb-79749d8a25f8%40isocpp.or=
g.

------=_Part_11_56106407.1476843576524
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B410=E6=9C=8819=E6=97=A5=E6=
=98=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=885:37:57=EF=BC=8Cmihailn...@=
gmail.com=E5=86=99=E9=81=93=EF=BC=9A<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"><br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><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"><br>By ca=
lling `reset`, you are making a contract with the smart pointer. From that =
point forward, you will not do anything to access the object referenced by =
that smart pointer, nor any object who&#39;s lifetime depends on it, <i>unl=
ess</i> you have a guarantee from some other object. That is, as far as thi=
s particular smart pointer is concerned, it is not going to ensure anything=
..<br></div></blockquote></div></blockquote><div><br></div><div>reset purpos=
e is to re-set the smart pointer to a new value. </div><div><br></div><div>=
reset always, to=C2=A0this=C2=A0point, controls the deleter call - <i>one w=
ay or another</i> (right away call, pointer dtor call, use_count etc, etc=
=C2=A0does not matter). </div><div>This is=C2=A0what a smart pointer ensure=
s, this is what is designed for.=C2=A0=C2=A0</div><div><br></div></div></bl=
ockquote><div>The name `reset` is not only used on smart pointers. Literall=
y, it has nothing to do with lifetime of <i>other </i>objects. The addition=
al meaning is granted by the class type.<br>=C2=A0<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>Same with re=
lease - touching it, means you are=C2=A0touch the deleter call, when and if=
 it runs. =C2=A0</div><div><br></div><div>So, right now and for many, many =
years, these <i>are</i> lifetime management APIs. <br></div><div></div></di=
v></blockquote><div><br>I agree `release` is a poor name here, it should ha=
ve been `detach` or something else to reduce confusion with genuine lifetim=
e management.<br><br>But for smart pointers, it is not about lifetime manag=
ement. Smart pointers are even not necessarily involved with controlling th=
e lifetime.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><div>=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"><div d=
ir=3D"ltr"><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"><br>`re=
lease` isn&#39;t even a function that most smart pointers have.<br><br></di=
v></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v></div><div>observer_ptr pretends to be smart with risk of being harmful a=
nd/or confusing. </div></div></blockquote><div dir=3D"ltr"><br>To whom is i=
t harmful or confusing? Are you actually trying to claim that someone is go=
ing to assume that a smart pointer with the word &quot;observer&quot; in it=
 is going to manage memory?<br></div></div></blockquote><div><br></div><div=
>O, yes I do. The moment a lib typedefs these, you are left to wonder what&=
#39;s up with all those reset-s and release-s.</div><div><br></div><div>And=
 what about <b>auto</b>? The explicit=C2=A0 type is less and less visible i=
n modern code.</div><div><br></div><div><i>Even if</i> not typedefed, even =
if you learn the types, you will have to constantly remind yourself, &quot;=
is this is observer or is it not&quot;.</div><div><br></div><div>You look a=
 function and=C2=A0an observer is used.</div><div>Then you switch to anothe=
r function, you see exactly the same code, but this time it is not an obser=
ver and you forgot to look up the type. </div><div>You spend 10 min consumi=
ng the code in the wrong way, thinking it does one thing, but it does somet=
hing different.</div><div><br></div><div>This has the exact same problem as=
 if one overloads a smart pointer=C2=A0operator=3D on the managed=C2=A0type=
.. </div><div><br></div><div>Two completely different actions (pointer copy =
and deleter management)=C2=A0are expressed by visually=C2=A0the same code. =
</div><div>Sure, the type=C2=A0is different, but in this case this is not e=
nough - you better use different language for different things.</div><div><=
br></div><div>reset=C2=A0is that different language.</div><div><br></div></=
div></blockquote><div>You misread what is &quot;smart&quot;.<br><br>It is &=
quot;smart&quot; because as a designer of the interface, you can attach int=
ended additional behavior to something already like pointers. That&#39;s al=
l. No magic about lifetime management is guaranteed existed; it is up to th=
e designer of the API.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;"><div dir=3D"ltr"><div></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div dir=3D"ltr"><br>Anyone who does that <i>deserves=
</i> what they get.<br><br>The point of `observer_ptr` is to represent when=
 a function is being given a pointer it does not have ownership of.<br></di=
v></div></blockquote><div><br></div><div>As commented, raw pointers are lef=
t for that use, and that use=C2=A0only. No confusion if owner&lt;&gt; is us=
ed instead. No overloading of operations. No new concepts.</div><div><br></=
div><div>And BTW owner&lt;&gt; is better, because it signals the <i>unordin=
ary</i> (in modern code) case,=C2=A0it is labeled, because<i> it is special=
</i>. </div><div>Raw pointer is <i>not labeled</i>, he is <i>not special</i=
>. </div></div></blockquote><div>Raw pointer is simply ill-designed in aspe=
ct of the need of a general-purposed language. It is essentially a kind of =
the sum type of random access iterators and non-owning smart pointer types.=
 The rest thing it provides is the ease of binary interops, which is a kind=
 of leaked abstraction from the underlying implementation, and not guarante=
ed to work even in the current language design. Explicit address types may =
be better for the last task.<br><br>The sin of raw pointer is, it is <i>too=
 special</i>. It has coupled many unrelated functionalities (as portable ab=
straction) as a bundle in the core language (as well polluting the binary i=
nterface continuously). To label it to get the right functionality is in th=
e sorts of workaround, not the fix, even this approach can easily play well=
 with modern language implementations. So there should be a place for the n=
ominal (named) non-owning pointer in a right interface design.<br><br>Anoth=
er thing to be noted: you should normally fix the ownership requirements st=
atically during the design of API, and labeling some non-owning pointers to=
 change them as owning ones is essentially risky and difficult to do correc=
tly. Even you have to do so, `owner&lt;&gt;` is not necessarily better. Any=
way, to patch it with `owner&lt;&gt;` or convert it to some owning pointer =
types to express ownership is the further step, based on the fact that you =
have already precisely expressed non-onwership - and raw pointer is not the=
 correct type at the first place.<br><br><br>=C2=A0<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/c651cc1b-e3f6-4779-94eb-79749d8a25f8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c651cc1b-e3f6-4779-94eb-79749d8a25f8=
%40isocpp.org</a>.<br />

------=_Part_11_56106407.1476843576524--

------=_Part_10_677072121.1476843576524--

.

------=_Part_70_1977316828.1476865836979
Content-Type: multipart/alternative;
 boundary="----=_Part_71_780092509.1476865836980"

------=_Part_71_780092509.1476865836980
Content-Type: text/plain; charset=UTF-8

Ok,
I hope we all agree reset(T*) and release() have new meaning in the context
of a observer_ptr. Ok?

For you, it is not a problem - the class is free to add whatever meaning it
wants to.

I simply argue, it can well be a problem and potentially adding a confusion.

auto p = foo();

if(cond(p))
 p.reset(hello.getBar());



All I am saying, this code above, for current smart pointers, meant - p now
*has* the bar object.

With observer_ptr into the picture, it might also mean - p now *points to*
a bar.

There is some overloading, which I personally find unfortunate and not well
justified.

That's all.

-

Now lets look at release, which has also a different problem.

std::unique_ptr::release
std::shared_lock::release
std::unique_lock::release
std::pmr::monotonic_buffer_resource::release
std::pmr::unsynchronized_pool_resource::release


What is common b/w these all?

They all give up a resource, which affects other objects in the system.

In general, right now, when you see release() in code, something quite
important, worth noting is happening.
Something possibly requiring some other actions to take care of.

None of these are trivial operation.

observer_ptr makes it trivial.
It makes it only about *itself*, it does not affect other objects and state.

Ok, for you it might not be a problem.

I only argue, it might well be - release() statement in code loses from its
importance.

*The important uses of release() will be accompanied of trivial uses of it.*
Not a good thing.


--
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/3241f484-0d5a-4363-8ddd-d3813a54fcb1%40isocpp.org.

------=_Part_71_780092509.1476865836980
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Ok, </div><div>I hope we all agree reset(T*) and rele=
ase() have new meaning in the context of a observer_ptr. Ok?</div><div><br>=
</div><div>For you, it is not a problem - the class is free to add whatever=
 meaning it wants to.</div><div><br></div><div>I simply argue, it can well =
be a problem and potentially adding a confusion.</div><div><br></div><div c=
lass=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wr=
ap: break-word; background-color: rgb(250, 250, 250);"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><span class=3D"styled-by-prettify" st=
yle=3D"color: #008;">auto</span><span class=3D"styled-by-prettify" style=3D=
"color: #000;"> p </span><span class=3D"styled-by-prettify" style=3D"color:=
 #660;">=3D</span><span class=3D"styled-by-prettify" style=3D"color: #000;"=
> foo</span><span class=3D"styled-by-prettify" style=3D"color: #660;">();</=
span><span class=3D"styled-by-prettify" style=3D"color: #000;"><br><br></sp=
an><span class=3D"styled-by-prettify" style=3D"color: #008;">if</span><span=
 class=3D"styled-by-prettify" style=3D"color: #660;">(</span><span class=3D=
"styled-by-prettify" style=3D"color: #000;">cond</span><span class=3D"style=
d-by-prettify" style=3D"color: #660;">(</span><span class=3D"styled-by-pret=
tify" style=3D"color: #000;">p</span><span class=3D"styled-by-prettify" sty=
le=3D"color: #660;">))</span><span class=3D"styled-by-prettify" style=3D"co=
lor: #000;"><br>=C2=A0p</span><span class=3D"styled-by-prettify" style=3D"c=
olor: #660;">.</span><span class=3D"styled-by-prettify" style=3D"color: #00=
0;">reset</span><span class=3D"styled-by-prettify" style=3D"color: #660;">(=
</span><span class=3D"styled-by-prettify" style=3D"color: #000;">hello</spa=
n><span class=3D"styled-by-prettify" style=3D"color: #660;">.</span><span c=
lass=3D"styled-by-prettify" style=3D"color: #000;">getBar</span><span class=
=3D"styled-by-prettify" style=3D"color: #660;">());</span><span class=3D"st=
yled-by-prettify" style=3D"color: #000;"><br><br></span></div></code></div>=
<div><br></div><div><br></div><div>All I am saying, this code above, for cu=
rrent smart pointers, meant - p now <i>has</i> the bar object.</div><div><b=
r></div><div>With observer_ptr into the picture, it might also mean - p now=
 <i>points to</i> a bar.</div><div><br></div><div>There is some=C2=A0overlo=
ading, which I personally find unfortunate and not well justified. </div><d=
iv><br></div><div>That&#39;s all.</div><div><br></div><div>-</div><div><br>=
</div><div>Now lets look at release, which has also=C2=A0a=C2=A0different p=
roblem.</div><div><br></div><div>std::unique_ptr::release<br>std::shared_lo=
ck::release</div><div>std::unique_lock::release</div><div>std::pmr::monoton=
ic_buffer_resource::release</div><div>std::pmr::unsynchronized_pool_resourc=
e::release</div><div><br></div><div><br></div><div>What is common b/w these=
 all? </div><div><br></div><div>They all give up a resource, which affects =
other objects in the system.</div><div><br></div><div>In general, right now=
, when you see release() in code, something quite important, worth noting i=
s happening. </div><div>Something possibly requiring some other actions to =
take care of.</div><div><br></div><div>None of these are=C2=A0trivial opera=
tion. </div><div><br></div><div>observer_ptr makes it trivial. </div><div>I=
t makes it only about <i>itself</i>, it does not affect other objects and s=
tate.</div><div><br></div><div>Ok, for you it might not be a problem.</div>=
<div><br></div><div>I only argue, it might well be - release() statement in=
 code=C2=A0loses from its importance.</div><div><br></div><div><i>The impor=
tant uses of release() will be accompanied of trivial uses of it.</i></div>=
<div>Not a good thing.</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/3241f484-0d5a-4363-8ddd-d3813a54fcb1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3241f484-0d5a-4363-8ddd-d3813a54fcb1=
%40isocpp.org</a>.<br />

------=_Part_71_780092509.1476865836980--

------=_Part_70_1977316828.1476865836979--

.

------=_Part_22_1099345371.1476869910284
Content-Type: multipart/alternative;
 boundary="----=_Part_23_1012790129.1476869910284"

------=_Part_23_1012790129.1476869910284
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=E5=9C=A8 2016=E5=B9=B410=E6=9C=8819=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UT=
C+8=E4=B8=8B=E5=8D=884:30:37=EF=BC=8Cmihailn...@gmail.com=E5=86=99=E9=81=93=
=EF=BC=9A
>
> Ok,=20
> I hope we all agree reset(T*) and release() have new meaning in the=20
> context of a observer_ptr. Ok?
>
> For you, it is not a problem - the class is free to add whatever meaning=
=20
> it wants to.
>
> I simply argue, it can well be a problem and potentially adding a=20
> confusion.
>
> auto p =3D foo();
>
> if(cond(p))
>  p.reset(hello.getBar());
>
>
>
> All I am saying, this code above, for current smart pointers, meant - p=
=20
> now *has* the bar object.
>
> With observer_ptr into the picture, it might also mean - p now *points to=
*=20
> a bar.
>
> For current smart pointers in the standard, it is also true. The=20
assumption is just further weaken (correctly).
=20

> There is some overloading, which I personally find unfortunate and not=20
> well justified.=20
>
> If you do need the meaning you want, you can introduce a non-member=20
function template only for smart pointers having such property, with a=20
clearer, unambiguous name, e.g. `change_owning`, rather than `reset`.


=20

> That's all.
>
> -
>
> Now lets look at release, which has also a different problem.
>
> std::unique_ptr::release
> std::shared_lock::release
> std::unique_lock::release
> std::pmr::monotonic_buffer_resource::release
> std::pmr::unsynchronized_pool_resource::release
>
>
> What is common b/w these all?=20
>
> They all give up a resource, which affects other objects in the system.
>
> In general, right now, when you see release() in code, something quite=20
> important, worth noting is happening.=20
> Something possibly requiring some other actions to take care of.
>
> None of these are trivial operation.=20
>
> observer_ptr makes it trivial.=20
> It makes it only about *itself*, it does not affect other objects and=20
> state.
>
> Ok, for you it might not be a problem.
>
> I only argue, it might well be - release() statement in code loses from=
=20
> its importance.
>
> *The important uses of release() will be accompanied of trivial uses of=
=20
> it.*
> Not a good thing.
>
> The problem here is the name clashes within different use cases, whether=
=20
taking observer_ptr into account or not. You have to do further (on the=20
returned value from the smart pointers' `release()`) to make them similar,=
=20
that's already somewhat awful (error-prone) if both styles are used in the=
=20
same codebase.

I do want to "detach" smart pointers or locks. But for backward=20
compatibility, perhaps it is easier to rename the latter ones.

=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/a17356b2-2545-444a-9db5-98c36d90c6f4%40isocpp.or=
g.

------=_Part_23_1012790129.1476869910284
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B410=E6=9C=8819=E6=97=A5=E6=
=98=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8B=E5=8D=884:30:37=EF=BC=8Cmihailn...@=
gmail.com=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div>Ok, </div><div>I hope we all agree reset(T*) an=
d release() have new meaning in the context of a observer_ptr. Ok?</div><di=
v><br></div><div>For you, it is not a problem - the class is free to add wh=
atever meaning it wants to.</div><div><br></div><div>I simply argue, it can=
 well be a problem and potentially adding a confusion.</div><div><br></div>=
<div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;backgr=
ound-color:rgb(250,250,250)"><code><div><span style=3D"color:#008">auto</sp=
an><span style=3D"color:#000"> p </span><span style=3D"color:#660">=3D</spa=
n><span style=3D"color:#000"> foo</span><span style=3D"color:#660">();</spa=
n><span style=3D"color:#000"><br><br></span><span style=3D"color:#008">if</=
span><span style=3D"color:#660">(</span><span style=3D"color:#000">cond</sp=
an><span style=3D"color:#660">(</span><span style=3D"color:#000">p</span><s=
pan style=3D"color:#660">))</span><span style=3D"color:#000"><br>=C2=A0p</s=
pan><span style=3D"color:#660">.</span><span style=3D"color:#000">reset</sp=
an><span style=3D"color:#660">(</span><span style=3D"color:#000">hello</spa=
n><span style=3D"color:#660">.</span><span style=3D"color:#000">getBar</spa=
n><span style=3D"color:#660">());</span><span style=3D"color:#000"><br><br>=
</span></div></code></div><div><br></div><div><br></div><div>All I am sayin=
g, this code above, for current smart pointers, meant - p now <i>has</i> th=
e bar object.</div><div><br></div><div>With observer_ptr into the picture, =
it might also mean - p now <i>points to</i> a bar.</div><div><br></div></di=
v></blockquote><div>For current smart pointers in the standard, it is also =
true. The assumption is just further weaken (correctly).<br>=C2=A0<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><=
div>There is some=C2=A0overloading, which I personally find unfortunate and=
 not well justified. </div><div><br></div></div></blockquote><div>If you do=
 need the meaning you want, you can introduce a non-member function templat=
e only for smart pointers having such property, with a clearer, unambiguous=
 name, e.g. `change_owning`, rather than `reset`.<br><br><br>=C2=A0<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div>=
<div>That&#39;s all.</div><div><br></div><div>-</div><div><br></div><div>No=
w lets look at release, which has also=C2=A0a=C2=A0different problem.</div>=
<div><br></div><div>std::unique_ptr::release<br>std::shared_lock::release</=
div><div>std::unique_lock::release</div><div>std::pmr::monotonic_buffer_<wb=
r>resource::release</div><div>std::pmr::unsynchronized_pool_<wbr>resource::=
release</div><div><br></div><div><br></div><div>What is common b/w these al=
l? </div><div><br></div><div>They all give up a resource, which affects oth=
er objects in the system.</div><div><br></div><div>In general, right now, w=
hen you see release() in code, something quite important, worth noting is h=
appening. </div><div>Something possibly requiring some other actions to tak=
e care of.</div><div><br></div><div>None of these are=C2=A0trivial operatio=
n. </div><div><br></div><div>observer_ptr makes it trivial. </div><div>It m=
akes it only about <i>itself</i>, it does not affect other objects and stat=
e.</div><div><br></div><div>Ok, for you it might not be a problem.</div><di=
v><br></div><div>I only argue, it might well be - release() statement in co=
de=C2=A0loses from its importance.</div><div><br></div><div><i>The importan=
t uses of release() will be accompanied of trivial uses of it.</i></div><di=
v>Not a good thing.</div><div><br></div></div></blockquote><div>The problem=
 here is the name clashes within different use cases, whether taking observ=
er_ptr into account or not. You have to do further (on the returned value f=
rom the smart pointers&#39; `release()`) to make them similar, that&#39;s a=
lready somewhat awful (error-prone) if both styles are used in the same cod=
ebase.<br><br>I do want to &quot;detach&quot; smart pointers or locks. But =
for backward compatibility, perhaps it is easier to rename the latter ones.=
<br><br>=C2=A0<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/a17356b2-2545-444a-9db5-98c36d90c6f4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a17356b2-2545-444a-9db5-98c36d90c6f4=
%40isocpp.org</a>.<br />

------=_Part_23_1012790129.1476869910284--

------=_Part_22_1099345371.1476869910284--

.

------=_Part_91_1362306458.1476871135185
Content-Type: multipart/alternative;
 boundary="----=_Part_92_1781683060.1476871135185"

------=_Part_92_1781683060.1476871135185
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Wednesday, October 19, 2016 at 12:38:30 PM UTC+3, FrankHB1989 wrote:
>
>
>
> =E5=9C=A8 2016=E5=B9=B410=E6=9C=8819=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 =
UTC+8=E4=B8=8B=E5=8D=884:30:37=EF=BC=8Cmihailn...@gmail.com=E5=86=99=E9=81=
=93=EF=BC=9A
>>
>> Ok,=20
>> I hope we all agree reset(T*) and release() have new meaning in the=20
>> context of a observer_ptr. Ok?
>>
>> For you, it is not a problem - the class is free to add whatever meaning=
=20
>> it wants to.
>>
>> I simply argue, it can well be a problem and potentially adding a=20
>> confusion.
>>
>> auto p =3D foo();
>>
>> if(cond(p))
>>  p.reset(hello.getBar());
>>
>>
>>
>> All I am saying, this code above, for current smart pointers, meant - p=
=20
>> now *has* the bar object.
>>
>> With observer_ptr into the picture, it might also mean - p now *points=
=20
>> to* a bar.
>>
>> For current smart pointers in the standard, it is also true. The=20
> assumption is just further weaken (correctly).
>  ...
>

Is it, really? For both (all?) smart pointers today, the meaning is the=20
same - p is now master of bar. The only difference is, is this ownership=20
shared with other p clones or not.
Where in the observer case, it is something quite different.=20

Again, it might well not be a problem, but I don't believe it is a=20
difference to be taken lightly.=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/b445c725-6b63-4055-82f4-3e73fe045755%40isocpp.or=
g.

------=_Part_92_1781683060.1476871135185
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, October 19, 2016 at 12:38:30 PM UTC+=
3, FrankHB1989 wrote:<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"><br><br>=E5=9C=A8 2016=E5=B9=B410=E6=9C=8819=E6=97=A5=E6=98=9F=E6=
=9C=9F=E4=B8=89 UTC+8=E4=B8=8B=E5=8D=884:30:37=EF=BC=8C<a>mihailn...@<wbr>g=
mail.com</a>=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div>Ok, </div><div>I hope we all agree reset(T*) and =
release() have new meaning in the context of a observer_ptr. Ok?</div><div>=
<br></div><div>For you, it is not a problem - the class is free to add what=
ever meaning it wants to.</div><div><br></div><div>I simply argue, it can w=
ell be a problem and potentially adding a confusion.</div><div><br></div><d=
iv style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;backgrou=
nd-color:rgb(250,250,250)"><code><div><span style=3D"color:#008">auto</span=
><span style=3D"color:#000"> p </span><span style=3D"color:#660">=3D</span>=
<span style=3D"color:#000"> foo</span><span style=3D"color:#660">();</span>=
<span style=3D"color:#000"><br><br></span><span style=3D"color:#008">if</sp=
an><span style=3D"color:#660">(</span><span style=3D"color:#000">cond</span=
><span style=3D"color:#660">(</span><span style=3D"color:#000">p</span><spa=
n style=3D"color:#660">))</span><span style=3D"color:#000"><br>=C2=A0p</spa=
n><span style=3D"color:#660">.</span><span style=3D"color:#000">reset</span=
><span style=3D"color:#660">(</span><span style=3D"color:#000">hello</span>=
<span style=3D"color:#660">.</span><span style=3D"color:#000">getBar</span>=
<span style=3D"color:#660">());</span><span style=3D"color:#000"><br><br></=
span></div></code></div><div><br></div><div><br></div><div>All I am saying,=
 this code above, for current smart pointers, meant - p now <i>has</i> the =
bar object.</div><div><br></div><div>With observer_ptr into the picture, it=
 might also mean - p now <i>points to</i> a bar.</div><div><br></div></div>=
</blockquote><div>For current smart pointers in the standard, it is also tr=
ue. The assumption is just further weaken (correctly).<br>=C2=A0...<br></di=
v></div></blockquote><div><br></div><div>Is it, really? For=C2=A0both (all?=
)=C2=A0smart pointers today,=C2=A0the meaning is the same - p is now master=
 of bar. The only difference is, is this ownership shared with other p clon=
es or not.</div><div>Where in the observer case, it is something quite diff=
erent. </div><div><br></div><div>Again, it might well not be a problem, but=
 I don&#39;t believe it is a difference to be taken lightly. </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/b445c725-6b63-4055-82f4-3e73fe045755%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b445c725-6b63-4055-82f4-3e73fe045755=
%40isocpp.org</a>.<br />

------=_Part_92_1781683060.1476871135185--

------=_Part_91_1362306458.1476871135185--

.

------=_Part_35_123369952.1476872944656
Content-Type: multipart/alternative;
 boundary="----=_Part_36_1362698701.1476872944656"

------=_Part_36_1362698701.1476872944656
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=E5=9C=A8 2016=E5=B9=B410=E6=9C=8819=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UT=
C+8=E4=B8=8B=E5=8D=885:58:55=EF=BC=8Cmihailn...@gmail.com=E5=86=99=E9=81=93=
=EF=BC=9A
>
>
>
> On Wednesday, October 19, 2016 at 12:38:30 PM UTC+3, FrankHB1989 wrote:
>>
>>
>>
>> =E5=9C=A8 2016=E5=B9=B410=E6=9C=8819=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89=
 UTC+8=E4=B8=8B=E5=8D=884:30:37=EF=BC=8Cmihailn...@gmail.com=E5=86=99=E9=81=
=93=EF=BC=9A
>>>
>>> Ok,=20
>>> I hope we all agree reset(T*) and release() have new meaning in the=20
>>> context of a observer_ptr. Ok?
>>>
>>> For you, it is not a problem - the class is free to add whatever meanin=
g=20
>>> it wants to.
>>>
>>> I simply argue, it can well be a problem and potentially adding a=20
>>> confusion.
>>>
>>> auto p =3D foo();
>>>
>>> if(cond(p))
>>>  p.reset(hello.getBar());
>>>
>>>
>>>
>>> All I am saying, this code above, for current smart pointers, meant - p=
=20
>>> now *has* the bar object.
>>>
>>> With observer_ptr into the picture, it might also mean - p now *points=
=20
>>> to* a bar.
>>>
>>> For current smart pointers in the standard, it is also true. The=20
>> assumption is just further weaken (correctly).
>>  ...
>>
>
> Is it, really? For both (all?) smart pointers today, the meaning is the=
=20
> same - p is now master of bar. The only difference is, is this ownership=
=20
> shared with other p clones or not.
> Where in the observer case, it is something quite different.=20
>
> Again, it might well not be a problem, but I don't believe it is a=20
> difference to be taken lightly.=20
>
No. A smart pointer is not necessarily owning, even if all instances in the=
=20
current standard are owning. See also=20
https://en.wikipedia.org/wiki/Smart_pointer, esp. external links.
=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/0c7c0968-f1c2-46df-b787-631fdd9f2d6c%40isocpp.or=
g.

------=_Part_36_1362698701.1476872944656
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B410=E6=9C=8819=E6=97=A5=E6=
=98=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8B=E5=8D=885:58:55=EF=BC=8Cmihailn...@=
gmail.com=E5=86=99=E9=81=93=EF=BC=9A<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"><br><br>On Wednesday, October 19, 2016 at 12:38:30 P=
M UTC+3, FrankHB1989 wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B410=E6=9C=8819=E6=97=A5=E6=98=9F=E6=
=9C=9F=E4=B8=89 UTC+8=E4=B8=8B=E5=8D=884:30:37=EF=BC=8C<a>mihailn...@<wbr>g=
mail.com</a>=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div>Ok, </div><div>I hope we all agree reset(T*) and =
release() have new meaning in the context of a observer_ptr. Ok?</div><div>=
<br></div><div>For you, it is not a problem - the class is free to add what=
ever meaning it wants to.</div><div><br></div><div>I simply argue, it can w=
ell be a problem and potentially adding a confusion.</div><div><br></div><d=
iv style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;backgrou=
nd-color:rgb(250,250,250)"><code><div><span style=3D"color:#008">auto</span=
><span style=3D"color:#000"> p </span><span style=3D"color:#660">=3D</span>=
<span style=3D"color:#000"> foo</span><span style=3D"color:#660">();</span>=
<span style=3D"color:#000"><br><br></span><span style=3D"color:#008">if</sp=
an><span style=3D"color:#660">(</span><span style=3D"color:#000">cond</span=
><span style=3D"color:#660">(</span><span style=3D"color:#000">p</span><spa=
n style=3D"color:#660">))</span><span style=3D"color:#000"><br>=C2=A0p</spa=
n><span style=3D"color:#660">.</span><span style=3D"color:#000">reset</span=
><span style=3D"color:#660">(</span><span style=3D"color:#000">hello</span>=
<span style=3D"color:#660">.</span><span style=3D"color:#000">getBar</span>=
<span style=3D"color:#660">());</span><span style=3D"color:#000"><br><br></=
span></div></code></div><div><br></div><div><br></div><div>All I am saying,=
 this code above, for current smart pointers, meant - p now <i>has</i> the =
bar object.</div><div><br></div><div>With observer_ptr into the picture, it=
 might also mean - p now <i>points to</i> a bar.</div><div><br></div></div>=
</blockquote><div>For current smart pointers in the standard, it is also tr=
ue. The assumption is just further weaken (correctly).<br>=C2=A0...<br></di=
v></div></blockquote><div><br></div><div>Is it, really? For=C2=A0both (all?=
)=C2=A0smart pointers today,=C2=A0the meaning is the same - p is now master=
 of bar. The only difference is, is this ownership shared with other p clon=
es or not.</div><div>Where in the observer case, it is something quite diff=
erent. </div><div><br></div><div>Again, it might well not be a problem, but=
 I don&#39;t believe it is a difference to be taken lightly. </div></div></=
blockquote><div>No. A smart pointer is not necessarily owning, even if all =
instances in the current standard are owning. See also https://en.wikipedia=
..org/wiki/Smart_pointer, esp. external links.<br>=C2=A0<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/0c7c0968-f1c2-46df-b787-631fdd9f2d6c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0c7c0968-f1c2-46df-b787-631fdd9f2d6c=
%40isocpp.org</a>.<br />

------=_Part_36_1362698701.1476872944656--

------=_Part_35_123369952.1476872944656--

.

------=_Part_105_87061882.1476873723864
Content-Type: multipart/alternative;
 boundary="----=_Part_106_1229381732.1476873723864"

------=_Part_106_1229381732.1476873723864
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Wednesday, October 19, 2016 at 1:29:04 PM UTC+3, FrankHB1989 wrote:
>
>
>
> =E5=9C=A8 2016=E5=B9=B410=E6=9C=8819=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 =
UTC+8=E4=B8=8B=E5=8D=885:58:55=EF=BC=8Cmihailn...@gmail.com=E5=86=99=E9=81=
=93=EF=BC=9A
>>
>>
>>
>> On Wednesday, October 19, 2016 at 12:38:30 PM UTC+3, FrankHB1989 wrote:
>>>
>>>
>>>
>>> =E5=9C=A8 2016=E5=B9=B410=E6=9C=8819=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=
=89 UTC+8=E4=B8=8B=E5=8D=884:30:37=EF=BC=8Cmihailn...@gmail.com=E5=86=99=E9=
=81=93=EF=BC=9A
>>>>
>>>> Ok,=20
>>>> I hope we all agree reset(T*) and release() have new meaning in the=20
>>>> context of a observer_ptr. Ok?
>>>>
>>>> For you, it is not a problem - the class is free to add whatever=20
>>>> meaning it wants to.
>>>>
>>>> I simply argue, it can well be a problem and potentially adding a=20
>>>> confusion.
>>>>
>>>> auto p =3D foo();
>>>>
>>>> if(cond(p))
>>>>  p.reset(hello.getBar());
>>>>
>>>>
>>>>
>>>> All I am saying, this code above, for current smart pointers, meant - =
p=20
>>>> now *has* the bar object.
>>>>
>>>> With observer_ptr into the picture, it might also mean - p now *points=
=20
>>>> to* a bar.
>>>>
>>>> For current smart pointers in the standard, it is also true. The=20
>>> assumption is just further weaken (correctly).
>>>  ...
>>>
>>
>> Is it, really? For both (all?) smart pointers today, the meaning is the=
=20
>> same - p is now master of bar. The only difference is, is this ownership=
=20
>> shared with other p clones or not.
>> Where in the observer case, it is something quite different.=20
>>
>> Again, it might well not be a problem, but I don't believe it is a=20
>> difference to be taken lightly.=20
>>
> No. A smart pointer is not necessarily owning, even if all instances in=
=20
> the current standard are owning. See also=20
> https://en.wikipedia.org/wiki/Smart_pointer, esp. external links.
>
=20
Of course, but the case in point is all the code written against the=20
current notions, from both std and other implementations like Qt, and the=
=20
effect observer will have.
Mind you, I don't argue, observer does something wrong by itself, if taken=
=20
in isolation.
I only argue, in the context of older pointer types, this overload use of=
=20
the old interface is something rather questionable.=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/39f69270-f3f8-412c-82ac-f192d2642185%40isocpp.or=
g.

------=_Part_106_1229381732.1476873723864
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, October 19, 2016 at 1:29:04 PM UTC+3=
, FrankHB1989 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B410=E6=9C=8819=E6=97=A5=E6=98=9F=E6=
=9C=9F=E4=B8=89 UTC+8=E4=B8=8B=E5=8D=885:58:55=EF=BC=8C<a>mihailn...@<wbr>g=
mail.com</a>=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><br><br>On Wednesday, October 19, 2016 at 12:38:30 PM =
UTC+3, FrankHB1989 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"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B410=E6=9C=8819=E6=97=A5=E6=98=9F=E6=
=9C=9F=E4=B8=89 UTC+8=E4=B8=8B=E5=8D=884:30:37=EF=BC=8C<a>mihailn...@<wbr>g=
mail.com</a>=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div>Ok, </div><div>I hope we all agree reset(T*) and =
release() have new meaning in the context of a observer_ptr. Ok?</div><div>=
<br></div><div>For you, it is not a problem - the class is free to add what=
ever meaning it wants to.</div><div><br></div><div>I simply argue, it can w=
ell be a problem and potentially adding a confusion.</div><div><br></div><d=
iv style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;backgrou=
nd-color:rgb(250,250,250)"><code><div><span style=3D"color:#008">auto</span=
><span style=3D"color:#000"> p </span><span style=3D"color:#660">=3D</span>=
<span style=3D"color:#000"> foo</span><span style=3D"color:#660">();</span>=
<span style=3D"color:#000"><br><br></span><span style=3D"color:#008">if</sp=
an><span style=3D"color:#660">(</span><span style=3D"color:#000">cond</span=
><span style=3D"color:#660">(</span><span style=3D"color:#000">p</span><spa=
n style=3D"color:#660">))</span><span style=3D"color:#000"><br>=C2=A0p</spa=
n><span style=3D"color:#660">.</span><span style=3D"color:#000">reset</span=
><span style=3D"color:#660">(</span><span style=3D"color:#000">hello</span>=
<span style=3D"color:#660">.</span><span style=3D"color:#000">getBar</span>=
<span style=3D"color:#660">());</span><span style=3D"color:#000"><br><br></=
span></div></code></div><div><br></div><div><br></div><div>All I am saying,=
 this code above, for current smart pointers, meant - p now <i>has</i> the =
bar object.</div><div><br></div><div>With observer_ptr into the picture, it=
 might also mean - p now <i>points to</i> a bar.</div><div><br></div></div>=
</blockquote><div>For current smart pointers in the standard, it is also tr=
ue. The assumption is just further weaken (correctly).<br>=C2=A0...<br></di=
v></div></blockquote><div><br></div><div>Is it, really? For=C2=A0both (all?=
)=C2=A0smart pointers today,=C2=A0the meaning is the same - p is now master=
 of bar. The only difference is, is this ownership shared with other p clon=
es or not.</div><div>Where in the observer case, it is something quite diff=
erent. </div><div><br></div><div>Again, it might well not be a problem, but=
 I don&#39;t believe it is a difference to be taken lightly. </div></div></=
blockquote><div>No. A smart pointer is not necessarily owning, even if all =
instances in the current standard are owning. See also <a onmousedown=3D"th=
is.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fen.wikipedia.o=
rg%2Fwiki%2FSmart_pointer\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHTmVZBea2=
puxnrb_pdZDt3R4OhlA&#39;;return true;" onclick=3D"this.href=3D&#39;https://=
www.google.com/url?q\x3dhttps%3A%2F%2Fen.wikipedia.org%2Fwiki%2FSmart_point=
er\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHTmVZBea2puxnrb_pdZDt3R4OhlA&#39=
;;return true;" href=3D"https://en.wikipedia.org/wiki/Smart_pointer" target=
=3D"_blank" rel=3D"nofollow">https://en.wikipedia.org/wiki/<wbr>Smart_point=
er</a>, esp. external links.<br></div></div></blockquote><div>=C2=A0</div><=
div>Of course, but the case in point is all the code written=C2=A0against t=
he current notions, from both std and other implementations like Qt, and th=
e effect observer will have.</div><div>Mind you, I don&#39;t argue, observe=
r does something wrong by itself, if taken in isolation.</div><div>I only a=
rgue, in the context of older pointer types, this overload use of the old i=
nterface is something rather questionable. </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/39f69270-f3f8-412c-82ac-f192d2642185%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/39f69270-f3f8-412c-82ac-f192d2642185=
%40isocpp.org</a>.<br />

------=_Part_106_1229381732.1476873723864--

------=_Part_105_87061882.1476873723864--

.

------=_Part_535_1231100927.1476896707571
Content-Type: multipart/alternative;
 boundary="----=_Part_536_396352013.1476896707571"

------=_Part_536_396352013.1476896707571
Content-Type: text/plain; charset=UTF-8

Something like observer_ptr should exist. Use of raw pointers is simply too
overloaded. Even if you buy the argument that, in modern C++, raw pointers
have a single accepted use as non-owning references (and I don't**),
something like observer_ptr narrows the range of operations to what is
sensible for such a reference type (e.g. no pointer arithmetic). However, I
believe the design of observer_ptr is not well tailored to its purported
purpose:

   - *It is cumbersome to use*: any pointer can be "observed" safely, so
   why do I have to use make_observer or reset to change what I'm
   observing? This seems to be due to observer_ptr being based on unique_ptr
   (hence the inappropriate release function) which understandably wants to
   prevent accidental assignment of arbitrary raw pointers, since it takes
   ownership of whatever it holds. The API is appropriate for an owning
   pointer, not an observing pointer (p.s. the presence of a reset function
   would be a bike shed issue if direct assignment were possible).
   - *It has a null state*: this is sometimes desirable, but references are
   frequently used instead of pointers to "observe" something while precluding
   the possibility of not observing anything. Of course, pointers can be used,
   but care must be taken not to dereference a null pointer; it is better
   (IMO) to have compile-time assurance that your reference type cannot be
   null. Where the the null-less counterpart to observer_ptr?
   - *It is not const-correct*: pointers circumvent the "const-correct"
   nature of the C++ type system; a const pointer is not implicitly a pointer
   to const. This should be the default behaviour of any "observer" type. In
   fact, this should be the behaviour of any "owner" type as well; I feel as
   though unique_ptr and shared_ptr should have really been called
   unique_owner and shared_owner, and should have exhibited const-correct
   behaviour. That said, I can see value in the flexibility of pointer-like
   owning types, so perhaps we are in need of both sets of types (that is, if
   propagate_const cannot solve the issue satisfactorily; I'm not yet sure
   it can).

I am aware of the existence of not_null in the GSL, as well as the proposed
propagate_const wrapper. However, I'm not sure how I feel about littering
my code with these beauties:


  propagate_const<not_null<observer_ptr<T*>>> obs = make_observer(&obj);


Imagine the compiler errors. In addition, there are a number of other
issues:

   - not_null may not support smart pointers
   <https://github.com/isocpp/CppCoreGuidelines/issues/399>.
   - not_null isn't necessarily guaranteed to not be null, and may have
   run-time overhead if it is.
   - not_null isn't proposed for inclusion in the standard AFAIK.
   - propagate_const disables all copying, even when it is technically
   possible (e.g. T* to T* or T* const to T const*), which is hugely
   limiting when dealing with "observer" types.
   - propagate_const is designed with a very limited "pointer-like"
   interface; it is likely to be of limited use for "smart wrappers" which do
   not adhere to the pointer model (a problem if you want a null-less
   counterpart to observer_ptr).

What's more, you have to ask, why are we starting with a type which is
ill-fitting to model a const-correct, not-null observer type (T*) and then
layering it with various wrappers designed to mould it into something which
fits the bill? Wouldn't it be better to design separate wrapper types which
just do the job?


  observer<T> obs = obj;

  optional_observer<T> opt_obs = obj;


This is infinitely more desirable IMO. It's worth noting that, while is
dislike the idea of using not_null for anything other than sanitizing
legacy code (and the designers seem to agree, seeing as they want it to
support only raw pointers), I am aware (I think) of why propagate_const is
designed the way it is. If propagate_const could be redesigned to be more
general and flexible (and I believe it may, if the Smart References through
Delegation
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0352r0.pdf>
proposal were accepted), then *perhaps* it would make sense to leave it the
responsibility of applying const-correctness to a "smart wrapper" API.


  propagate_const<observer<T>> obs = obj;


Just my two cents.

** Raw pointers are used in low-level code for all sorts of uses; and
anyway, I assume it is better to be explicit that assume people know what
you mean.

--
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/21f90a12-3d1f-4f65-8974-66ee3a17f88d%40isocpp.org.

------=_Part_536_396352013.1476896707571
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Something like <span style=3D"font-family: courier new,mon=
ospace;">observer_ptr</span> should exist. Use of raw pointers is simply to=
o overloaded. Even if you buy the argument that, in modern C++, raw pointer=
s have a single accepted use as non-owning references (and I don&#39;t**), =
something like <span style=3D"font-family: courier new,monospace;">observer=
_ptr</span> narrows the range of operations to what is sensible for such a =
reference type (e.g. no pointer arithmetic). However, I believe the design =
of <span style=3D"font-family: courier new,monospace;">observer_ptr</span> =
is not well tailored to its purported purpose:<br><ul><li><i>It is cumberso=
me to use</i>:<span class=3D"_Tgc"> any pointer can be &quot;observed&quot;=
 safely, so why do I have to use <span style=3D"font-family: courier new,mo=
nospace;">make_observer</span> or <span style=3D"font-family: courier new,m=
onospace;">reset</span> to change what I&#39;m observing? This seems to be =
due to <span style=3D"font-family: courier new,monospace;">observer_ptr</sp=
an> being based on <span style=3D"font-family: courier new,monospace;">uniq=
ue_ptr</span> (hence the inappropriate <span style=3D"font-family: courier =
new,monospace;">release</span> function) which understandably wants to prev=
ent accidental assignment of arbitrary raw pointers, since it takes ownersh=
ip of whatever it holds. The API is appropriate for an owning pointer, not =
an observing pointer (p.s. the presence of a <span style=3D"font-family: co=
urier new,monospace;">reset</span> function would be a bike shed issue if d=
irect assignment were possible).</span></li><li><span class=3D"_Tgc"><i>It =
has a null state</i>: this is sometimes desirable, but references are frequ=
ently used instead of pointers to &quot;observe&quot; something while precl=
uding the possibility of not observing anything. Of course, pointers can be=
 used, but care must be taken not to dereference a null pointer; it is bett=
er (IMO) to have compile-time assurance that your reference type cannot be =
null. Where the the null-less counterpart to <span style=3D"font-family: co=
urier new,monospace;">observer_ptr</span>?</span></li><li><span class=3D"_T=
gc"><i>It is not const-correct</i>: pointers circumvent the &quot;const-cor=
rect&quot; nature of the C++ type system; a const pointer is not implicitly=
 a pointer to const. This should be the default behaviour of any &quot;obse=
rver&quot; type. In fact, this should be the behaviour of any &quot;owner&q=
uot; type as well; I feel as though <span style=3D"font-family: courier new=
,monospace;">unique_ptr</span> and <span style=3D"font-family: courier new,=
monospace;">shared_ptr</span> should have really been called <span style=3D=
"font-family: courier new,monospace;">unique_owner</span> and <span style=
=3D"font-family: courier new,monospace;">shared_owner</span>, and should ha=
ve exhibited const-correct behaviour. That said, I can see value in the fle=
xibility of pointer-like owning types, so perhaps we are in need of both se=
ts of types (that is, if <span style=3D"font-family: courier new,monospace;=
">propagate_const</span> cannot solve the issue satisfactorily; I&#39;m not=
 yet sure it can).</span></li></ul><p>I am aware of the existence of <span =
style=3D"font-family: courier new,monospace;">not_null</span> in the GSL, a=
s well as the proposed <span style=3D"font-family: courier new,monospace;">=
propagate_const</span> wrapper. However, I&#39;m not sure how I feel about =
littering my code with these beauties:<br></p><p><br></p><p><span style=3D"=
font-family: courier new,monospace;">=C2=A0 propagate_const&lt;not_null&lt;=
observer_ptr&lt;T*&gt;&gt;&gt; obs =3D make_observer(&amp;obj);</span><br><=
/p><p><br></p>Imagine the compiler errors. In addition, there are a number =
of other issues:<br><ul><li><span style=3D"font-family: courier new,monospa=
ce;">not_null</span> may <a href=3D"https://github.com/isocpp/CppCoreGuidel=
ines/issues/399">not support smart pointers</a><span style=3D"font-family: =
courier new,monospace;"><span style=3D"font-family: arial,sans-serif;">.</s=
pan></span></li><li><span style=3D"font-family: courier new,monospace;">not=
_null</span> isn&#39;t necessarily guaranteed to not be null, and may have =
run-time overhead if it is.</li><li><span style=3D"font-family: courier new=
,monospace;">not_null</span> isn&#39;t proposed for inclusion in the standa=
rd AFAIK.</li><li><span style=3D"font-family: courier new,monospace;">propa=
gate_const</span> disables all copying, even when it is technically possibl=
e (e.g. <span style=3D"font-family: courier new,monospace;">T*</span> to <s=
pan style=3D"font-family: courier new,monospace;">T*</span> or <span style=
=3D"font-family: courier new,monospace;">T* const</span> to <span style=3D"=
font-family: courier new,monospace;">T const*</span>), which is hugely limi=
ting when dealing with &quot;observer&quot; types.</li><li><span style=3D"f=
ont-family: courier new,monospace;">propagate_const</span> is designed with=
 a very limited &quot;pointer-like&quot; interface; it is likely to be of l=
imited use for &quot;smart wrappers&quot; which do not adhere to the pointe=
r model (a problem if you want a null-less counterpart to <span style=3D"fo=
nt-family: courier new,monospace;">observer_ptr</span>).</li></ul><p>What&#=
39;s more, you have to ask, why are we starting with a type which is ill-fi=
tting to model a const-correct, not-null observer type (<span style=3D"font=
-family: courier new,monospace;">T*</span>) and then layering it with vario=
us wrappers designed to mould it into something which fits the bill? Wouldn=
&#39;t it be better to design separate wrapper types which just do the job?=
</p><p><br></p><p><span style=3D"font-family: courier new,monospace;">=C2=
=A0 observer&lt;T&gt; obs =3D obj;</span><br></p><p><span style=3D"font-fam=
ily: courier new,monospace;">=C2=A0 optional_observer&lt;T&gt; opt_obs =3D =
obj;</span><br></p><p><br></p>This is infinitely more desirable IMO. It&#39=
;s worth noting that, while is dislike the idea of using <span style=3D"fon=
t-family: courier new,monospace;">not_null</span> for anything other than s=
anitizing legacy code (and the designers seem to agree, seeing as they want=
 it to support only raw pointers), I am aware (I think) of why <span style=
=3D"font-family: courier new,monospace;">propagate_const</span> is designed=
 the way it is. If <span style=3D"font-family: courier new,monospace;">prop=
agate_const</span> could be redesigned to be more general and flexible (and=
 I believe it may, if the <a href=3D"http://www.open-std.org/jtc1/sc22/wg21=
/docs/papers/2016/p0352r0.pdf">Smart References through Delegation</a> prop=
osal were accepted), then <i>perhaps</i> it would make sense to leave it th=
e responsibility of applying const-correctness to a &quot;smart wrapper&quo=
t; API. <br><span style=3D"font-family: courier new,monospace;"></span><p><=
br></p><p><span style=3D"font-family: courier new,monospace;">=C2=A0 propag=
ate_const&lt;observer&lt;T&gt;&gt; obs =3D obj;</span><br></p><p><br></p>Ju=
st my two cents.<br><br>** Raw pointers are used in low-level code for all =
sorts of uses; and=20
anyway, I assume it is better to be explicit that assume people know=20
what you mean.<br></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/21f90a12-3d1f-4f65-8974-66ee3a17f88d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/21f90a12-3d1f-4f65-8974-66ee3a17f88d=
%40isocpp.org</a>.<br />

------=_Part_536_396352013.1476896707571--

------=_Part_535_1231100927.1476896707571--

.

------=_Part_416_837381758.1476901386221
Content-Type: multipart/alternative;
 boundary="----=_Part_417_2011720556.1476901386221"

------=_Part_417_2011720556.1476901386221
Content-Type: text/plain; charset=UTF-8



On Wednesday, October 19, 2016 at 8:05:07 PM UTC+3, joseph....@gmail.com
wrote:
>
> ...
>
>    - *It is cumbersome to use*: any pointer can be "observed" safely, so
>    why do I have to use make_observer or reset to change what I'm
>    observing? This seems to be due to observer_ptr being based on
>    unique_ptr (hence the inappropriate release function) which
>    understandably wants to prevent accidental assignment of arbitrary raw
>    pointers, since it takes ownership of whatever it holds. The API is
>    appropriate for an owning pointer, not an observing pointer (p.s. the
>    presence of a reset function would be a bike shed issue if direct
>    assignment were possible).
>    - *It has a null state*: this is sometimes desirable, but references
>    are frequently used instead of pointers to "observe" something while
>    precluding the possibility of not observing anything. Of course, pointers
>    can be used, but care must be taken not to dereference a null pointer; it
>    is better (IMO) to have compile-time assurance that your reference type
>    cannot be null. Where the the null-less counterpart to observer_ptr?
>    - *It is not const-correct*: pointers circumvent the "const-correct"
>    nature of the C++ type system; a const pointer is not implicitly a pointer
>    to const. This should be the default behaviour of any "observer" type. In
>    fact, this should be the behaviour of any "owner" type as well; I feel as
>    though unique_ptr and shared_ptr should have really been called
>    unique_owner and shared_owner, and should have exhibited const-correct
>    behaviour. That said, I can see value in the flexibility of pointer-like
>    owning types, so perhaps we are in need of both sets of types (that is, if
>    propagate_const cannot solve the issue satisfactorily; I'm not yet
>    sure it can).
>
> The irony is, raw pointer + not_null OR (preferably) reference covers all
3.

 - It is trivial to use, nothing new to learn, age-old and simple proven
concept, fast as hell, terse syntax
 - null state acts as an optional pointer. Else - references or not_null.
And BTW not_null<> is not for sanitizing legacy code. owner<> is, but
not_null is legit decoration even for modern code because there is no
new alternative.
 - it is const correct - const S* will not let you call non-const
functions.

Yes, it is a problem, it does much more.
But the idea is to cover all other cases with some other pointer type and
leave the good old pointer only for certain scenarios.
I do understand, people will disagree - they don't want raws in upper
level, in day to day object management, I get that.



--
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/6ddbccaf-a7eb-4193-86d0-31300fd2f9ae%40isocpp.org.

------=_Part_417_2011720556.1476901386221
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, October 19, 2016 at 8:05:07 PM UTC+3=
, joseph....@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr">...<br><ul><li><i>It is cumbersome to use</i>:<span> any po=
inter can be &quot;observed&quot; safely, so why do I have to use <span sty=
le=3D"font-family:courier new,monospace">make_observer</span> or <span styl=
e=3D"font-family:courier new,monospace">reset</span> to change what I&#39;m=
 observing? This seems to be due to <span style=3D"font-family:courier new,=
monospace">observer_ptr</span> being based on <span style=3D"font-family:co=
urier new,monospace">unique_ptr</span> (hence the inappropriate <span style=
=3D"font-family:courier new,monospace">release</span> function) which under=
standably wants to prevent accidental assignment of arbitrary raw pointers,=
 since it takes ownership of whatever it holds. The API is appropriate for =
an owning pointer, not an observing pointer (p.s. the presence of a <span s=
tyle=3D"font-family:courier new,monospace">reset</span> function would be a=
 bike shed issue if direct assignment were possible).</span></li><li><span>=
<i>It has a null state</i>: this is sometimes desirable, but references are=
 frequently used instead of pointers to &quot;observe&quot; something while=
 precluding the possibility of not observing anything. Of course, pointers =
can be used, but care must be taken not to dereference a null pointer; it i=
s better (IMO) to have compile-time assurance that your reference type cann=
ot be null. Where the the null-less counterpart to <span style=3D"font-fami=
ly:courier new,monospace">observer_ptr</span>?</span></li><li><span><i>It i=
s not const-correct</i>: pointers circumvent the &quot;const-correct&quot; =
nature of the C++ type system; a const pointer is not implicitly a pointer =
to const. This should be the default behaviour of any &quot;observer&quot; =
type. In fact, this should be the behaviour of any &quot;owner&quot; type a=
s well; I feel as though <span style=3D"font-family:courier new,monospace">=
unique_ptr</span> and <span style=3D"font-family:courier new,monospace">sha=
red_ptr</span> should have really been called <span style=3D"font-family:co=
urier new,monospace">unique_owner</span> and <span style=3D"font-family:cou=
rier new,monospace">shared_owner</span>, and should have exhibited const-co=
rrect behaviour. That said, I can see value in the flexibility of pointer-l=
ike owning types, so perhaps we are in need of both sets of types (that is,=
 if <span style=3D"font-family:courier new,monospace">propagate_const</span=
> cannot solve the issue satisfactorily; I&#39;m not yet sure it can).</spa=
n></li></ul></div></blockquote><div>The irony is, raw pointer + not_null OR=
 (preferably) reference=C2=A0covers all 3. </div><div><br></div><div>=C2=A0=
- It is trivial to use, nothing new to learn, age-old and=C2=A0simple=C2=A0=
proven concept, fast as hell, terse syntax</div><div>=C2=A0- null state=C2=
=A0acts as an=C2=A0optional pointer. Else - references or not_null. And BTW=
 not_null&lt;&gt; is not for sanitizing legacy code. owner&lt;&gt; is, but =
not_null is legit decoration even for modern code because there is no new=
=C2=A0alternative.</div><div>=C2=A0- it is const correct - const S* will no=
t let you call non-const functions. </div><div><br></div><div>Yes,=C2=A0it =
is a=C2=A0problem, it=C2=A0does much more. </div><div>But the idea is=C2=A0=
to cover all other cases with some other pointer=C2=A0type and leave the go=
od old pointer only for=C2=A0certain scenarios. </div><div>I do understand,=
 people will disagree - they don&#39;t want raws in upper level, in day to =
day object management, I get that.=C2=A0=C2=A0</div><div><br></div><div>=C2=
=A0<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/6ddbccaf-a7eb-4193-86d0-31300fd2f9ae%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6ddbccaf-a7eb-4193-86d0-31300fd2f9ae=
%40isocpp.org</a>.<br />

------=_Part_417_2011720556.1476901386221--

------=_Part_416_837381758.1476901386221--

.

------=_Part_87_1544532095.1476931048180
Content-Type: multipart/alternative;
 boundary="----=_Part_88_1789514544.1476931048180"

------=_Part_88_1789514544.1476931048180
Content-Type: text/plain; charset=UTF-8

On Thursday, 20 October 2016 02:23:06 UTC+8, mihailn...@gmail.com wrote:
>
>
>
> On Wednesday, October 19, 2016 at 8:05:07 PM UTC+3, joseph....@gmail.com
> wrote:
>>
>> ...
>>
>>    - *It is cumbersome to use*: any pointer can be "observed" safely, so
>>    why do I have to use make_observer or reset to change what I'm
>>    observing? This seems to be due to observer_ptr being based on
>>    unique_ptr (hence the inappropriate release function) which
>>    understandably wants to prevent accidental assignment of arbitrary raw
>>    pointers, since it takes ownership of whatever it holds. The API is
>>    appropriate for an owning pointer, not an observing pointer (p.s. the
>>    presence of a reset function would be a bike shed issue if direct
>>    assignment were possible).
>>    - *It has a null state*: this is sometimes desirable, but references
>>    are frequently used instead of pointers to "observe" something while
>>    precluding the possibility of not observing anything. Of course, pointers
>>    can be used, but care must be taken not to dereference a null pointer; it
>>    is better (IMO) to have compile-time assurance that your reference type
>>    cannot be null. Where the the null-less counterpart to observer_ptr?
>>    - *It is not const-correct*: pointers circumvent the "const-correct"
>>    nature of the C++ type system; a const pointer is not implicitly a pointer
>>    to const. This should be the default behaviour of any "observer" type. In
>>    fact, this should be the behaviour of any "owner" type as well; I feel as
>>    though unique_ptr and shared_ptr should have really been called
>>    unique_owner and shared_owner, and should have exhibited
>>    const-correct behaviour. That said, I can see value in the flexibility of
>>    pointer-like owning types, so perhaps we are in need of both sets of types
>>    (that is, if propagate_const cannot solve the issue satisfactorily;
>>    I'm not yet sure it can).
>>
>> The irony is, raw pointer + not_null OR (preferably) reference covers all
> 3.
>

I was just listing the problems with observer_ptr; raw pointers, references
and not_null each have shortcomings of their own:

   -  T* and not_null<T*> are *not* const-correct (i.e. const-propagating)
   despite your claim to the contrary
   - Depending on which pre-processor flags are set, not_null either *can*
   enter a null state or incurs a run-time cost on construction; I am watching this
   issue <https://github.com/Microsoft/GSL/issues/396> which potentially
   fixes this problem by allowing construction from T& (though there are
   still issues with this design).
   - Raw pointers (without not_null) support operations which don't make
   sense for an observer type; this opens the door to programming errors, bugs
   and UB. Assuming a raw pointer, obs, acting as an observer, all the
   following compile, but are conceptually unsound:
   - delete obs;
      - obs++;
      - obs + some_int;
      - obs[1];
      - obs = some_array;
   - References cannot be rebound to "observe" something else after
   construction; this prevents them being stored in STL containers like
   std::vector. And std::reference_wrapper is only a solution if you want
   to have reference-like behaviour rather than observer-like behaviour (e.g.
   operator== compares the referenced values, not the addresses of the
   referenced objects).

 - It is trivial to use, nothing new to learn, age-old and simple proven
> concept, fast as hell, terse syntax
>

   - *"trivial to use"*: a well-designed set of observer wrapper types can
   be *at least* as, and probably more, trivial to use (terser, more
   natural syntax + added safety).
   - *"nothing new to learn"*: I believe that the potential benefits of
   observer wrappers outweigh the cost of learning something new.
   - *"age-old"*: and they are showing their age, which is why they are
   being increasingly replaced in modern C++; as I outlined, raw pointers have
   proven to be less than ideal for use in safe, modern C++ code,
   *including* where used as observers.
   - *"fast as hell"*: observer wrapper types can easily be designed with
   zero run-time overhead.
   - *"terse syntax"*: observer wrapper types can be designed with syntax
   that is terser in some cases than raw pointers and references; IMO, this is
   a natural result of them being designed for their specific purpose.

 - null state acts as an optional pointer. Else - references or not_null.
> And BTW not_null<> is not for sanitizing legacy code. owner<> is, but
> not_null is legit decoration even for modern code because there is no
> new alternative.
>

Raw pointers, references and not_null have issues; I won't repeat the
details.

If not_null is *not* for sanitizing legacy code and is designed to work
*only* with raw pointers, then its current design is not ideal:

  not_null<T*> obs = &obj;

The design can be simplified to prevent mis-parameterization (e.g. passing
unique_ptr<T>) and to guarantee the lack of a null state at run-time with
zero overhead (by taking a reference on construction):

  not_null<T> obs = obj;

Suddenly this is looking remarkably like a null-less observer_ptr. Now,
take a step back and consider how best to design these types to complement
each other, without being afraid to move away from the pointer/reference
paradigm, and you will probably end up with something like this:

  observer<T> obs = obj;
  optional_observer<T> opt_obs = obj;

Naming is an issue that can be hashed out behind the bike sheds; the
important thing is that we have ended up exactly where I said we should be.
This *is* the alternative to not_null you mentioned.

 - it is const correct - const S* will not let you call non-const
> functions.
>

When I say "const-correct" in the context of types which indirectly refer
to other objects, is that the constness of the wrapper should propagate to
the referenced object. This is the behaviour implemented by propagate_const.

Yes, it is a problem, it does much more.
> But the idea is to cover all other cases with some other pointer type and
> leave the good old pointer only for certain scenarios.
> I do understand, people will disagree - they don't want raws in upper
> level, in day to day object management, I get that.
>

Yup. And it isn't just a stylistic personal preference. I have practical
reasons for wanting something other than raw pointers and references, as I
hope I have made clear.

--
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/8c24951b-5d86-46e4-85c8-1a9372020dff%40isocpp.org.

------=_Part_88_1789514544.1476931048180
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, 20 October 2016 02:23:06 UTC+8, mihailn...@gm=
ail.com  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"ltr=
"><br><br>On Wednesday, October 19, 2016 at 8:05:07 PM UTC+3, <a>joseph....=
@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r">...<br><ul><li><i>It is cumbersome to use</i>:<span> any pointer can be =
&quot;observed&quot; safely, so why do I have to use <span style=3D"font-fa=
mily:courier new,monospace">make_observer</span> or <span style=3D"font-fam=
ily:courier new,monospace">reset</span> to change what I&#39;m observing? T=
his seems to be due to <span style=3D"font-family:courier new,monospace">ob=
server_ptr</span> being based on <span style=3D"font-family:courier new,mon=
ospace">unique_ptr</span> (hence the inappropriate <span style=3D"font-fami=
ly:courier new,monospace">release</span> function) which understandably wan=
ts to prevent accidental assignment of arbitrary raw pointers, since it tak=
es ownership of whatever it holds. The API is appropriate for an owning poi=
nter, not an observing pointer (p.s. the presence of a <span style=3D"font-=
family:courier new,monospace">reset</span> function would be a bike shed is=
sue if direct assignment were possible).</span></li><li><span><i>It has a n=
ull state</i>: this is sometimes desirable, but references are frequently u=
sed instead of pointers to &quot;observe&quot; something while precluding t=
he possibility of not observing anything. Of course, pointers can be used, =
but care must be taken not to dereference a null pointer; it is better (IMO=
) to have compile-time assurance that your reference type cannot be null. W=
here the the null-less counterpart to <span style=3D"font-family:courier ne=
w,monospace">observer_ptr</span>?</span></li><li><span><i>It is not const-c=
orrect</i>: pointers circumvent the &quot;const-correct&quot; nature of the=
 C++ type system; a const pointer is not implicitly a pointer to const. Thi=
s should be the default behaviour of any &quot;observer&quot; type. In fact=
, this should be the behaviour of any &quot;owner&quot; type as well; I fee=
l as though <span style=3D"font-family:courier new,monospace">unique_ptr</s=
pan> and <span style=3D"font-family:courier new,monospace">shared_ptr</span=
> should have really been called <span style=3D"font-family:courier new,mon=
ospace">unique_owner</span> and <span style=3D"font-family:courier new,mono=
space">shared_owner</span>, and should have exhibited const-correct behavio=
ur. That said, I can see value in the flexibility of pointer-like owning ty=
pes, so perhaps we are in need of both sets of types (that is, if <span sty=
le=3D"font-family:courier new,monospace">propagate_const</span> cannot solv=
e the issue satisfactorily; I&#39;m not yet sure it can).</span></li></ul><=
/div></blockquote><div>The irony is, raw pointer + not_null OR (preferably)=
 reference=C2=A0covers all 3. </div></div></blockquote><div>=C2=A0<br>I was=
 just listing the problems with <span style=3D"font-family: courier new,mon=
ospace;">observer_ptr</span>; raw pointers, references and <span style=3D"f=
ont-family: courier new,monospace;">not_null</span> each have shortcomings =
of their own:<br><ul><li>=C2=A0<span style=3D"font-family: courier new,mono=
space;">T*</span> and <span style=3D"font-family: courier new,monospace;">n=
ot_null&lt;T*&gt;</span> are <i>not</i> const-correct (i.e. const-propagati=
ng) despite your claim to the contrary<br></li><li>Depending on which pre-p=
rocessor flags are set, <span style=3D"font-family: courier new,monospace;"=
>not_null</span> either <i>can</i> enter a null state or incurs a run-time =
cost on construction; I am watching <a href=3D"https://github.com/Microsoft=
/GSL/issues/396">this issue</a> which potentially fixes this problem by all=
owing construction from <span style=3D"font-family: courier new,monospace;"=
>T&amp;</span> (though there are still issues with this design).</li><li>Ra=
w pointers (without <span style=3D"font-family: courier new,monospace;">not=
_null</span>) support operations which don&#39;t make sense for an observer=
 type; this opens the door to programming errors, bugs and UB. Assuming a r=
aw pointer, <span style=3D"font-family: courier new,monospace;">obs</span>,=
 acting as an observer, all the following compile, but are conceptually uns=
ound:<br></li><ul><li><span style=3D"font-family: courier new,monospace;">d=
elete obs;<br></span></li><li><span style=3D"font-family: courier new,monos=
pace;">obs++;</span></li><li><span style=3D"font-family: courier new,monosp=
ace;">obs + some_int;<br></span></li></ul><ul><li><span style=3D"font-famil=
y: courier new,monospace;">obs[1];</span></li><li><span style=3D"font-famil=
y: courier new,monospace;">obs =3D some_array;</span></li></ul><li>Referenc=
es cannot be rebound to &quot;observe&quot; something else after constructi=
on; this prevents them being stored in STL containers like <span style=3D"f=
ont-family: courier new,monospace;">std::vector</span>. And <span style=3D"=
font-family: courier new,monospace;">std::reference_wrapper</span> is only =
a solution if you want to have reference-like behaviour rather than observe=
r-like behaviour (e.g. <span style=3D"font-family: courier new,monospace;">=
operator=3D=3D</span> compares the referenced values, not the addresses of =
the referenced objects).<br></li></ul></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div></div><div>=C2=A0- It is trivial to use=
, nothing new to learn, age-old and=C2=A0simple=C2=A0proven concept, fast a=
s hell, terse syntax</div></div></blockquote><div><ul><li><i>&quot;trivial =
to use&quot;</i>: a well-designed set of observer wrapper types can be <i>a=
t least</i> as, and probably more, trivial to use (terser, more natural syn=
tax + added safety).</li><li><i>&quot;nothing new to learn&quot;</i>: I bel=
ieve that the potential benefits of observer wrappers outweigh the cost of =
learning something new.<br></li><li><i>&quot;age-old&quot;</i>: and they ar=
e showing their age, which is why they are being increasingly replaced in m=
odern C++; as I outlined, raw pointers have proven to be less than ideal fo=
r use in safe, modern C++ code, <i>including</i> where used as observers.</=
li><li><i>&quot;fast as hell&quot;</i>: observer wrapper types can easily b=
e designed with zero run-time overhead.</li><li><i>&quot;terse syntax&quot;=
</i>: observer wrapper types can be designed with syntax that is terser in =
some cases than raw pointers and references; IMO, this is a natural result =
of them being designed for their specific purpose.<br></li></ul></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>=C2=A0- null =
state=C2=A0acts as an=C2=A0optional pointer. Else - references or not_null.=
 And BTW not_null&lt;&gt; is not for sanitizing legacy code. owner&lt;&gt; =
is, but not_null is legit decoration even for modern code because there is =
no new=C2=A0alternative.</div></div></blockquote><div><br>Raw pointers, ref=
erences and <span style=3D"font-family: courier new,monospace;">not_null</s=
pan> have issues; I won&#39;t repeat the details.<br><br>If <span style=3D"=
font-family: courier new,monospace;">not_null</span> is <i>not</i> for sani=
tizing legacy code and is designed to work <i>only</i> with raw pointers, t=
hen its current design is not ideal:<br>=C2=A0<br><div style=3D"background-=
color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: =
solid; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"=
><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">=C2=A0 not_null</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">*&gt;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> obs </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">obj</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</s=
pan></div></code></div><br>The design can be simplified to prevent mis-para=
meterization (e.g. passing <span style=3D"font-family: courier new,monospac=
e;">unique_ptr&lt;T&gt;</span>) and to guarantee the lack of a null state a=
t run-time with zero overhead (by taking a reference on construction):<br><=
br><span style=3D"font-family: courier new,monospace;"><div style=3D"backgr=
ound-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-st=
yle: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyp=
rint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #000;" class=3D"styled-by-prettify">=C2=A0 not_null</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> obs </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> obj</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">;</span></div></code></div></span><br>Suddenly this is lookin=
g remarkably like a null-less <span style=3D"font-family: courier new,monos=
pace;">observer_ptr</span>. Now, take a step back and consider how best to =
design these types to complement each other, without being afraid to move a=
way from the pointer/reference paradigm, and you will probably end up with =
something like this:<br><br><span style=3D"font-family: courier new,monospa=
ce;"><div style=3D"background-color: rgb(250, 250, 250); border-color: rgb(=
187, 187, 187); border-style: solid; border-width: 1px; overflow-wrap: brea=
k-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"su=
bprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">=C2=
=A0 observer</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> obs </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> obj</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>=C2=A0 optional_observer</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> opt_obs </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> obj</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">;</span></div></code></div></span><br>Naming is an issue that c=
an be hashed out behind the bike sheds; the important thing is that we have=
 ended up exactly where I said we should be. This <i>is</i> the alternative=
 to <span style=3D"font-family: courier new,monospace;">not_null</span> you=
 mentioned.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><div>=C2=A0- it is const correct - const S* will not let you ca=
ll non-const functions. </div></div></blockquote><div>=C2=A0<br>When I say =
&quot;const-correct&quot; in the context of types which indirectly refer to=
 other objects, is that the constness of the wrapper should propagate to th=
e referenced object. This is the behaviour implemented by <span style=3D"fo=
nt-family: courier new,monospace;">propagate_const</span>.<br><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>=
Yes,=C2=A0it is a=C2=A0problem, it=C2=A0does much more. </div><div>But the =
idea is=C2=A0to cover all other cases with some other pointer=C2=A0type and=
 leave the good old pointer only for=C2=A0certain scenarios. </div><div>I d=
o understand, people will disagree - they don&#39;t want raws in upper leve=
l, in day to day object management, I get that.<br></div></div></blockquote=
><div><br>Yup. And it isn&#39;t just a stylistic personal preference. I hav=
e practical reasons for wanting something other than raw pointers and refer=
ences, as I hope I have made clear.<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/8c24951b-5d86-46e4-85c8-1a9372020dff%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8c24951b-5d86-46e4-85c8-1a9372020dff=
%40isocpp.org</a>.<br />

------=_Part_88_1789514544.1476931048180--

------=_Part_87_1544532095.1476931048180--

.

------=_Part_85_599529819.1476947356516
Content-Type: multipart/alternative;
 boundary="----=_Part_86_1269938340.1476947356516"

------=_Part_86_1269938340.1476947356516
Content-Type: text/plain; charset=UTF-8

My intentions are not to change your mind - we, as well as everyone else,
are perfectly aware of the pros and cons of both approaches - raw vs new
ptr.

In any case, I believe we both agree the solution lies outside of
observer_ptr. I have my reasons, you have your own.

We also agree, any "operator." (in quotes, not necessarily overloading it)
will dramatically change any possible implementation of such a wrapper
pointer type.
I also agree with you propagate_const should be integral part of such a
wrapper pointer type, not a cumbersome opt-in.
Lastly, as things like string_view / span become widely available and used,
they will become a good, real world testing ground for potential "view for
object"

As a result, I (still) strongly believe observer_ptr should *not* go into
the standard in its current form.
It will be half-assessed, and will rise as many issues/questions as it
solves and will be become the auto_ptr version of a much better view type.


--
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/2df66fdb-3586-4ccc-b589-558298b28a56%40isocpp.org.

------=_Part_86_1269938340.1476947356516
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>My intentions are not to change your mind=C2=A0- we, =
as well as everyone else, are perfectly aware of the=C2=A0pros and cons of =
both approaches - raw vs new ptr.</div><div><br></div><div>In any case, I b=
elieve we both agree the=C2=A0solution lies outside of observer_ptr. I have=
 my reasons, you have your own.</div><div><br></div><div>We also agree, any=
 &quot;operator.&quot; (in quotes, not necessarily overloading it) will dra=
matically change any possible implementation of=C2=A0such a wrapper pointer=
 type.</div><div>I also=C2=A0agree with you=C2=A0propagate_const should be =
integral part of such a wrapper pointer type, not a cumbersome opt-in.=C2=
=A0</div><div>Lastly, as things like string_view / span become widely avail=
able and used, they will become a good, real world testing ground for poten=
tial &quot;view for object&quot;=C2=A0</div><div><br></div><div>As a result=
, I (still)=C2=A0strongly believe=C2=A0observer_ptr=C2=A0should <b>not</b>=
=C2=A0go into the standard in its current form.</div><div>It will be half-a=
ssessed, and will rise as many issues/questions as it solves and will be be=
come=C2=A0the=C2=A0auto_ptr version of a much better view type. </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/2df66fdb-3586-4ccc-b589-558298b28a56%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2df66fdb-3586-4ccc-b589-558298b28a56=
%40isocpp.org</a>.<br />

------=_Part_86_1269938340.1476947356516--

------=_Part_85_599529819.1476947356516--

.

------=_Part_297_844154839.1476953110861
Content-Type: multipart/alternative;
 boundary="----=_Part_298_496775763.1476953110862"

------=_Part_298_496775763.1476953110862
Content-Type: text/plain; charset=UTF-8

On Thursday, 20 October 2016 15:09:16 UTC+8, mihailn...@gmail.com wrote:
>
> My intentions are not to change your mind - we, as well as everyone else,
> are perfectly aware of the pros and cons of both approaches - raw vs new
> ptr.
>

I think it helps to have these things written down. Even if everyone else
knows everything already, it helps me get my thoughts in order and realize
where my reasoning is flawed.

We also agree, any "operator." (in quotes, not necessarily overloading it)
> will dramatically change any possible implementation of such a wrapper
> pointer type.
>

I don't agree with this. I think "operator dot overloading" will have
limited to no application in this case. I believe it will have more of an
application with types that act to modify select parts of an API while
retaining the overall appearance of the underlying type like, for example,
propagate_const.


> I also agree with you propagate_const should be integral part of such a
> wrapper pointer type, not a cumbersome opt-in.
>

I'm in two minds about this. It may be better to keep const propagation
separate.

As a result, I (still) strongly believe observer_ptr should *not* go into
> the standard in its current form.
> It will be half-assessed, and will rise as many issues/questions as it
> solves and will be become the auto_ptr version of a much better view type.
>

Agreed.

--
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/10dd3035-5546-414c-980f-2a1b06b9dd5b%40isocpp.org.

------=_Part_298_496775763.1476953110862
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, 20 October 2016 15:09:16 UTC+8, mihailn...@gm=
ail.com  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"ltr=
"><div>My intentions are not to change your mind=C2=A0- we, as well as ever=
yone else, are perfectly aware of the=C2=A0pros and cons of both approaches=
 - raw vs new ptr.</div></div></blockquote><div>=C2=A0<br>I think it helps =
to have these things written down. Even if everyone else knows everything a=
lready, it helps me get my thoughts in order and realize where my reasoning=
 is flawed.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><div></div><div>We also agree, any &quot;operator.&quot; (in qu=
otes, not necessarily overloading it) will dramatically change any possible=
 implementation of=C2=A0such a wrapper pointer type.</div></div></blockquot=
e><div><br>I don&#39;t agree with this. I think &quot;operator dot overload=
ing&quot; will have limited to no application in this case. I believe it wi=
ll have more of an application with types that act to modify select parts o=
f an API while retaining the overall appearance of the underlying type like=
, for example, <span style=3D"font-family: courier new,monospace;">propagat=
e_const</span>.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><div>I also=C2=A0agree with you=C2=A0propagate_const shou=
ld be integral part of such a wrapper pointer type, not a cumbersome opt-in=
..=C2=A0</div></div></blockquote><div><br>I&#39;m in two minds about this. I=
t may be better to keep const propagation separate.<br><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">As a result, I (still)=
=C2=A0strongly believe=C2=A0observer_ptr=C2=A0should <b>not</b>=C2=A0go int=
o the standard in its current form.<div>It will be half-assessed, and will =
rise as many issues/questions as it solves and will be become=C2=A0the=C2=
=A0auto_ptr version of a much better view type. </div></div></blockquote><d=
iv><br>Agreed.<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/10dd3035-5546-414c-980f-2a1b06b9dd5b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/10dd3035-5546-414c-980f-2a1b06b9dd5b=
%40isocpp.org</a>.<br />

------=_Part_298_496775763.1476953110862--

------=_Part_297_844154839.1476953110861--

.

------=_Part_94_1564122504.1476957722193
Content-Type: multipart/alternative;
 boundary="----=_Part_95_966278194.1476957722193"

------=_Part_95_966278194.1476957722193
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=E5=9C=A8 2016=E5=B9=B410=E6=9C=8819=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UT=
C+8=E4=B8=8B=E5=8D=886:42:04=EF=BC=8Cmihailn...@gmail.com=E5=86=99=E9=81=93=
=EF=BC=9A
>
>
>
> On Wednesday, October 19, 2016 at 1:29:04 PM UTC+3, FrankHB1989 wrote:
>>
>>
>>
>> =E5=9C=A8 2016=E5=B9=B410=E6=9C=8819=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89=
 UTC+8=E4=B8=8B=E5=8D=885:58:55=EF=BC=8Cmihailn...@gmail.com=E5=86=99=E9=81=
=93=EF=BC=9A
>>>
>>>
>>>
>>> On Wednesday, October 19, 2016 at 12:38:30 PM UTC+3, FrankHB1989 wrote:
>>>>
>>>>
>>>>
>>>> =E5=9C=A8 2016=E5=B9=B410=E6=9C=8819=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=
=89 UTC+8=E4=B8=8B=E5=8D=884:30:37=EF=BC=8Cmihailn...@gmail.com=E5=86=99=E9=
=81=93=EF=BC=9A
>>>>>
>>>>> Ok,=20
>>>>> I hope we all agree reset(T*) and release() have new meaning in the=
=20
>>>>> context of a observer_ptr. Ok?
>>>>>
>>>>> For you, it is not a problem - the class is free to add whatever=20
>>>>> meaning it wants to.
>>>>>
>>>>> I simply argue, it can well be a problem and potentially adding a=20
>>>>> confusion.
>>>>>
>>>>> auto p =3D foo();
>>>>>
>>>>> if(cond(p))
>>>>>  p.reset(hello.getBar());
>>>>>
>>>>>
>>>>>
>>>>> All I am saying, this code above, for current smart pointers, meant -=
=20
>>>>> p now *has* the bar object.
>>>>>
>>>>> With observer_ptr into the picture, it might also mean - p now *point=
s=20
>>>>> to* a bar.
>>>>>
>>>>> For current smart pointers in the standard, it is also true. The=20
>>>> assumption is just further weaken (correctly).
>>>>  ...
>>>>
>>>
>>> Is it, really? For both (all?) smart pointers today, the meaning is the=
=20
>>> same - p is now master of bar. The only difference is, is this ownershi=
p=20
>>> shared with other p clones or not.
>>> Where in the observer case, it is something quite different.=20
>>>
>>> Again, it might well not be a problem, but I don't believe it is a=20
>>> difference to be taken lightly.=20
>>>
>> No. A smart pointer is not necessarily owning, even if all instances in=
=20
>> the current standard are owning. See also=20
>> https://en.wikipedia.org/wiki/Smart_pointer, esp. external links.
>>
> =20
> Of course, but the case in point is all the code written against the=20
> current notions, from both std and other implementations like Qt, and the=
=20
> effect observer will have.
>
I don't see they have defined or suggested such notions of smart pointers.=
=20

> Mind you, I don't argue, observer does something wrong by itself, if take=
n=20
> in isolation.
> I only argue, in the context of older pointer types, this overload use of=
=20
> the old interface is something rather questionable.=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/71dea059-b425-4b2d-966c-ef2ea90ca968%40isocpp.or=
g.

------=_Part_95_966278194.1476957722193
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B410=E6=9C=8819=E6=97=A5=E6=
=98=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8B=E5=8D=886:42:04=EF=BC=8Cmihailn...@=
gmail.com=E5=86=99=E9=81=93=EF=BC=9A<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"><br><br>On Wednesday, October 19, 2016 at 1:29:04 PM=
 UTC+3, FrankHB1989 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"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B410=E6=9C=8819=E6=97=A5=E6=98=9F=E6=
=9C=9F=E4=B8=89 UTC+8=E4=B8=8B=E5=8D=885:58:55=EF=BC=8C<a>mihailn...@<wbr>g=
mail.com</a>=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><br><br>On Wednesday, October 19, 2016 at 12:38:30 PM =
UTC+3, FrankHB1989 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"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B410=E6=9C=8819=E6=97=A5=E6=98=9F=E6=
=9C=9F=E4=B8=89 UTC+8=E4=B8=8B=E5=8D=884:30:37=EF=BC=8C<a>mihailn...@<wbr>g=
mail.com</a>=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div>Ok, </div><div>I hope we all agree reset(T*) and =
release() have new meaning in the context of a observer_ptr. Ok?</div><div>=
<br></div><div>For you, it is not a problem - the class is free to add what=
ever meaning it wants to.</div><div><br></div><div>I simply argue, it can w=
ell be a problem and potentially adding a confusion.</div><div><br></div><d=
iv style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;backgrou=
nd-color:rgb(250,250,250)"><code><div><span style=3D"color:#008">auto</span=
><span style=3D"color:#000"> p </span><span style=3D"color:#660">=3D</span>=
<span style=3D"color:#000"> foo</span><span style=3D"color:#660">();</span>=
<span style=3D"color:#000"><br><br></span><span style=3D"color:#008">if</sp=
an><span style=3D"color:#660">(</span><span style=3D"color:#000">cond</span=
><span style=3D"color:#660">(</span><span style=3D"color:#000">p</span><spa=
n style=3D"color:#660">))</span><span style=3D"color:#000"><br>=C2=A0p</spa=
n><span style=3D"color:#660">.</span><span style=3D"color:#000">reset</span=
><span style=3D"color:#660">(</span><span style=3D"color:#000">hello</span>=
<span style=3D"color:#660">.</span><span style=3D"color:#000">getBar</span>=
<span style=3D"color:#660">());</span><span style=3D"color:#000"><br><br></=
span></div></code></div><div><br></div><div><br></div><div>All I am saying,=
 this code above, for current smart pointers, meant - p now <i>has</i> the =
bar object.</div><div><br></div><div>With observer_ptr into the picture, it=
 might also mean - p now <i>points to</i> a bar.</div><div><br></div></div>=
</blockquote><div>For current smart pointers in the standard, it is also tr=
ue. The assumption is just further weaken (correctly).<br>=C2=A0...<br></di=
v></div></blockquote><div><br></div><div>Is it, really? For=C2=A0both (all?=
)=C2=A0smart pointers today,=C2=A0the meaning is the same - p is now master=
 of bar. The only difference is, is this ownership shared with other p clon=
es or not.</div><div>Where in the observer case, it is something quite diff=
erent. </div><div><br></div><div>Again, it might well not be a problem, but=
 I don&#39;t believe it is a difference to be taken lightly. </div></div></=
blockquote><div>No. A smart pointer is not necessarily owning, even if all =
instances in the current standard are owning. See also <a href=3D"https://e=
n.wikipedia.org/wiki/Smart_pointer" rel=3D"nofollow" target=3D"_blank" onmo=
usedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fe=
n.wikipedia.org%2Fwiki%2FSmart_pointer\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAF=
QjCNHTmVZBea2puxnrb_pdZDt3R4OhlA&#39;;return true;" onclick=3D"this.href=3D=
&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fen.wikipedia.org%2Fwiki%=
2FSmart_pointer\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHTmVZBea2puxnrb_pdZ=
Dt3R4OhlA&#39;;return true;">https://en.wikipedia.org/wiki/<wbr>Smart_point=
er</a>, esp. external links.<br></div></div></blockquote><div>=C2=A0</div><=
div>Of course, but the case in point is all the code written=C2=A0against t=
he current notions, from both std and other implementations like Qt, and th=
e effect observer will have.</div></div></blockquote><div>I don&#39;t see t=
hey have defined or suggested such notions of smart pointers. <br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Mind you, I=
 don&#39;t argue, observer does something wrong by itself, if taken in isol=
ation.</div><div>I only argue, in the context of older pointer types, this =
overload use of the old interface is something rather questionable. </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/71dea059-b425-4b2d-966c-ef2ea90ca968%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/71dea059-b425-4b2d-966c-ef2ea90ca968=
%40isocpp.org</a>.<br />

------=_Part_95_966278194.1476957722193--

------=_Part_94_1564122504.1476957722193--

.

------=_Part_94_740886428.1476958280156
Content-Type: multipart/alternative;
 boundary="----=_Part_95_1327537731.1476958280157"

------=_Part_95_1327537731.1476958280157
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=E5=9C=A8 2016=E5=B9=B410=E6=9C=8820=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UT=
C+8=E4=B8=8A=E5=8D=881:05:07=EF=BC=8Cjoseph....@gmail.com=E5=86=99=E9=81=93=
=EF=BC=9A
>
> Something like observer_ptr should exist. Use of raw pointers is simply=
=20
> too overloaded. Even if you buy the argument that, in modern C++, raw=20
> pointers have a single accepted use as non-owning references (and I=20
> don't**), something like observer_ptr narrows the range of operations to=
=20
> what is sensible for such a reference type (e.g. no pointer arithmetic).=
=20
> However, I believe the design of observer_ptr is not well tailored to its=
=20
> purported purpose:
>
>    - *It is cumbersome to use*: any pointer can be "observed" safely, so=
=20
>    why do I have to use make_observer or reset to change what I'm=20
>    observing? This seems to be due to observer_ptr being based on=20
>    unique_ptr (hence the inappropriate release function) which=20
>    understandably wants to prevent accidental assignment of arbitrary raw=
=20
>    pointers, since it takes ownership of whatever it holds. The API is=20
>    appropriate for an owning pointer, not an observing pointer (p.s. the=
=20
>    presence of a reset function would be a bike shed issue if direct=20
>    assignment were possible).
>
> This is probably because of code migration.

I guess mixing of observer_ptrs and raw pointers is not intended by the=20
committee.
=20

>
>    - *It has a null state*: this is sometimes desirable, but references=
=20
>    are frequently used instead of pointers to "observe" something while=
=20
>    precluding the possibility of not observing anything. Of course, point=
ers=20
>    can be used, but care must be taken not to dereference a null pointer;=
 it=20
>    is better (IMO) to have compile-time assurance that your reference typ=
e=20
>    cannot be null. Where the the null-less counterpart to observer_ptr?
>
>  It is a pointer, so it is nullable.

Anyway, it may be better to have a nonnullable counterpart, but not just=20
for observer_ptr.

>
>    - *It is not const-correct*: pointers circumvent the "const-correct"=
=20
>    nature of the C++ type system; a const pointer is not implicitly a poi=
nter=20
>    to const. This should be the default behaviour of any "observer" type.=
 In=20
>    fact, this should be the behaviour of any "owner" type as well; I feel=
 as=20
>    though unique_ptr and shared_ptr should have really been called=20
>    unique_owner and shared_owner, and should have exhibited const-correct=
=20
>    behaviour. That said, I can see value in the flexibility of pointer-li=
ke=20
>    owning types, so perhaps we are in need of both sets of types (that is=
, if=20
>    propagate_const cannot solve the issue satisfactorily; I'm not yet=20
>    sure it can).
>
> Const-correctness here is not the problem of any particular pointers.

And there are more serious ones. (So I am reluctant to introduce wrappers=
=20
to solve these problems.)

First of all, the correctness should not only work for particular `const`.=
=20
"Const-correctness", or more "correctly", immutable-correctness, should be=
=20
based on any equivalent relationship in general. Requiring "const" here is=
=20
only due to the limitation of the current type system in C++.

Hard-coded "const" leads to bad problems. For instance, enforcing `const`=
=20
on the key type of associative containers (since C++11) is essentially=20
wrong because the equivalence implied by comparator has nothing to do with=
=20
"const". Even if the users can guarantee the equivalence by themselves,=20
they can only override the `const` by `mutable` within the key type (as a=
=20
class) definition which kills all benefits of the typecheck; otherwise the=
=20
associative containers are almost not usable. For this particular problems,=
=20
UB in C++03 is actually fair enough to ensure the zero cost abstraction (as=
=20
well as to prevent reinventing the poor wheels by yourself).

To overcome this, perhaps some forms of parameterized `const` (e.g.=20
`const<xxx::operator=3D=3D>`) are needed. Then plain old `const` can be=20
considered (relatively) harmful because it enforces less type-correctness,=
=20
as non-`const` APIs are criticized today.

(Also note that the "as-if" based transformation implementations like=20
constant folding can actually work more broadly.)

So always "default to be const" is wrong or at least suspicious, especially=
=20
for a language which has even no sane way to syntheses the trivial=20
equivelence (equality operators which behave similar enough to built-in=20
constant folding conditions checked by a typical optimizing implementation)=
=20
automatically by default.

There is no centralized authority to specify the semantics requirements of=
=20
immutable-correctness (it's all up to the users' need -- whether they have=
=20
to make multiple different equivalent relationships coexisted on the same=
=20
type), so it is risky to assume `const` guarantee the real "correctness"=20
needed by users of the API, merely via a single hard-coded core language=20
feature (which is even not predictable in aspect of binary=20
representations). But there is only one "non-const". It's the compromise=20
when you can't guarantee the propagation of `const` is safely away from=20
those problems in long term.

=20

> I am aware of the existence of not_null in the GSL, as well as the=20
> proposed propagate_const wrapper. However, I'm not sure how I feel about=
=20
> littering my code with these beauties:
>
>
>   propagate_const<not_null<observer_ptr<T*>>> obs =3D make_observer(&obj)=
;
>
>
> Imagine the compiler errors. In addition, there are a number of other=20
> issues:
>
>    - not_null may not support smart pointers=20
>    <https://github.com/isocpp/CppCoreGuidelines/issues/399>.
>    - not_null isn't necessarily guaranteed to not be null, and may have=
=20
>    run-time overhead if it is.
>    - not_null isn't proposed for inclusion in the standard AFAIK.
>    - propagate_const disables all copying, even when it is technically=20
>    possible (e.g. T* to T* or T* const to T const*), which is hugely=20
>    limiting when dealing with "observer" types.
>    - propagate_const is designed with a very limited "pointer-like"=20
>    interface; it is likely to be of limited use for "smart wrappers" whic=
h do=20
>    not adhere to the pointer model (a problem if you want a null-less=20
>    counterpart to observer_ptr).
>
> What's more, you have to ask, why are we starting with a type which is=20
> ill-fitting to model a const-correct, not-null observer type (T*) and=20
> then layering it with various wrappers designed to mould it into somethin=
g=20
> which fits the bill? Wouldn't it be better to design separate wrapper typ=
es=20
> which just do the job?
>
>
>   observer<T> obs =3D obj;
>
>   optional_observer<T> opt_obs =3D obj;
>
>
> This is infinitely more desirable IMO. It's worth noting that, while is=
=20
> dislike the idea of using not_null for anything other than sanitizing=20
> legacy code (and the designers seem to agree, seeing as they want it to=
=20
> support only raw pointers), I am aware (I think) of why propagate_const=
=20
> is designed the way it is. If propagate_const could be redesigned to be=
=20
> more general and flexible (and I believe it may, if the Smart References=
=20
> through Delegation=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0352r0.pdf>=20
> proposal were accepted), then *perhaps* it would make sense to leave it=
=20
> the responsibility of applying const-correctness to a "smart wrapper" API=
..=20
>
>
>   propagate_const<observer<T>> obs =3D obj;
>
>
> Just my two cents.
>
> ** Raw pointers are used in low-level code for all sorts of uses; and=20
> anyway, I assume it is better to be explicit that assume people know what=
=20
> you mean.
>

--=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/8199f37c-7738-4b59-8b01-c258a8165884%40isocpp.or=
g.

------=_Part_95_1327537731.1476958280157
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B410=E6=9C=8820=E6=97=A5=E6=
=98=9F=E6=9C=9F=E5=9B=9B UTC+8=E4=B8=8A=E5=8D=881:05:07=EF=BC=8Cjoseph....@=
gmail.com=E5=86=99=E9=81=93=EF=BC=9A<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">Something like <span style=3D"font-family:courier ne=
w,monospace">observer_ptr</span> should exist. Use of raw pointers is simpl=
y too overloaded. Even if you buy the argument that, in modern C++, raw poi=
nters have a single accepted use as non-owning references (and I don&#39;t*=
*), something like <span style=3D"font-family:courier new,monospace">observ=
er_ptr</span> narrows the range of operations to what is sensible for such =
a reference type (e.g. no pointer arithmetic). However, I believe the desig=
n of <span style=3D"font-family:courier new,monospace">observer_ptr</span> =
is not well tailored to its purported purpose:<br><ul><li><i>It is cumberso=
me to use</i>:<span> any pointer can be &quot;observed&quot; safely, so why=
 do I have to use <span style=3D"font-family:courier new,monospace">make_ob=
server</span> or <span style=3D"font-family:courier new,monospace">reset</s=
pan> to change what I&#39;m observing? This seems to be due to <span style=
=3D"font-family:courier new,monospace">observer_ptr</span> being based on <=
span style=3D"font-family:courier new,monospace">unique_ptr</span> (hence t=
he inappropriate <span style=3D"font-family:courier new,monospace">release<=
/span> function) which understandably wants to prevent accidental assignmen=
t of arbitrary raw pointers, since it takes ownership of whatever it holds.=
 The API is appropriate for an owning pointer, not an observing pointer (p.=
s. the presence of a <span style=3D"font-family:courier new,monospace">rese=
t</span> function would be a bike shed issue if direct assignment were poss=
ible).</span></li></ul></div></blockquote><div>This is probably because of =
code migration.<br><br>I guess mixing of <span><span style=3D"font-family:c=
ourier new,monospace">observer_ptr</span></span>s and raw pointers is not i=
ntended by the committee.<br>=C2=A0</div><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"><ul><li><span><i>It has a null state</i>: this =
is sometimes desirable, but references are frequently used instead of point=
ers to &quot;observe&quot; something while precluding the possibility of no=
t observing anything. Of course, pointers can be used, but care must be tak=
en not to dereference a null pointer; it is better (IMO) to have compile-ti=
me assurance that your reference type cannot be null. Where the the null-le=
ss counterpart to <span style=3D"font-family:courier new,monospace">observe=
r_ptr</span>?</span></li></ul></div></blockquote><div>=C2=A0It is a pointer=
, so it is nullable.<br><br>Anyway, it may be better to have a nonnullable =
counterpart, but not just for <span><span style=3D"font-family:courier new,=
monospace">observer_ptr</span></span>.<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr"><ul><li><span><i>It is not const-correct=
</i>: pointers circumvent the &quot;const-correct&quot; nature of the C++ t=
ype system; a const pointer is not implicitly a pointer to const. This shou=
ld be the default behaviour of any &quot;observer&quot; type. In fact, this=
 should be the behaviour of any &quot;owner&quot; type as well; I feel as t=
hough <span style=3D"font-family:courier new,monospace">unique_ptr</span> a=
nd <span style=3D"font-family:courier new,monospace">shared_ptr</span> shou=
ld have really been called <span style=3D"font-family:courier new,monospace=
">unique_owner</span> and <span style=3D"font-family:courier new,monospace"=
>shared_owner</span>, and should have exhibited const-correct behaviour. Th=
at said, I can see value in the flexibility of pointer-like owning types, s=
o perhaps we are in need of both sets of types (that is, if <span style=3D"=
font-family:courier new,monospace">propagate_const</span> cannot solve the =
issue satisfactorily; I&#39;m not yet sure it can).</span></li></ul></div><=
/blockquote><div>Const-correctness here is not the problem of any particula=
r pointers.<br><br>And there are more serious ones. (So I am reluctant to i=
ntroduce wrappers to solve these problems.)<br><br>First of all, the correc=
tness should not only work for particular `const`. &quot;Const-correctness&=
quot;, or more &quot;correctly&quot;, immutable-correctness, should be base=
d on any equivalent relationship in general. Requiring &quot;const&quot; he=
re is only due to the limitation of the current type system in C++.<br><br>=
Hard-coded &quot;const&quot; leads to bad problems. For instance, enforcing=
 `const` on the key type of associative containers (since C++11) is essenti=
ally wrong because the equivalence implied by comparator has nothing to do =
with &quot;const&quot;. Even if the users can guarantee the equivalence by =
themselves, they can only override the `const` by `mutable` within the key =
type (as a class) definition which kills all benefits of the typecheck; oth=
erwise the associative containers are almost not usable. For this particula=
r problems, UB in C++03 is actually fair enough to ensure the zero cost abs=
traction (as well as to prevent reinventing the poor wheels by yourself).<b=
r><br>To overcome this, perhaps some forms of parameterized `const` (e.g. `=
const&lt;xxx::operator=3D=3D&gt;`) are needed. Then plain old `const` can b=
e considered (relatively) harmful because it enforces less type-correctness=
, as non-`const` APIs are criticized today.<br><br>(Also note that the &quo=
t;as-if&quot; based transformation implementations like constant folding ca=
n actually work more broadly.)<br><br>So always &quot;default to be const&q=
uot; is wrong or at least suspicious, especially for a language which has e=
ven no sane way to syntheses the trivial equivelence (equality operators wh=
ich behave similar enough to built-in constant folding conditions checked b=
y a typical optimizing implementation) automatically by default.<br><br>The=
re is no centralized authority to specify the semantics requirements of imm=
utable-correctness (it&#39;s all up to the users&#39; need -- whether they =
have to make multiple different equivalent relationships coexisted on the s=
ame type), so it is risky to assume `const` guarantee the real &quot;correc=
tness&quot; needed by users of the API, merely via a single hard-coded core=
 language feature (which is even not predictable in aspect of binary repres=
entations). But there is only one &quot;non-const&quot;. It&#39;s the compr=
omise when you can&#39;t guarantee the propagation of `const` is safely awa=
y from those problems in long term.<br><br>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr"><p>I am aware of the existence of=
 <span style=3D"font-family:courier new,monospace">not_null</span> in the G=
SL, as well as the proposed <span style=3D"font-family:courier new,monospac=
e">propagate_const</span> wrapper. However, I&#39;m not sure how I feel abo=
ut littering my code with these beauties:<br></p><p><br></p><p><span style=
=3D"font-family:courier new,monospace">=C2=A0 propagate_const&lt;not_null&l=
t;<wbr>observer_ptr&lt;T*&gt;&gt;&gt; obs =3D make_observer(&amp;obj);</spa=
n><br></p><p><br></p>Imagine the compiler errors. In addition, there are a =
number of other issues:<br><ul><li><span style=3D"font-family:courier new,m=
onospace">not_null</span> may <a href=3D"https://github.com/isocpp/CppCoreG=
uidelines/issues/399" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fis=
ocpp%2FCppCoreGuidelines%2Fissues%2F399\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dA=
FQjCNFWx00UNdIp_EFYn64xTHrO14OnMA&#39;;return true;" onclick=3D"this.href=
=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fisocpp%2=
FCppCoreGuidelines%2Fissues%2F399\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF=
Wx00UNdIp_EFYn64xTHrO14OnMA&#39;;return true;">not support smart pointers</=
a><span style=3D"font-family:courier new,monospace"><span style=3D"font-fam=
ily:arial,sans-serif">.</span></span></li><li><span style=3D"font-family:co=
urier new,monospace">not_null</span> isn&#39;t necessarily guaranteed to no=
t be null, and may have run-time overhead if it is.</li><li><span style=3D"=
font-family:courier new,monospace">not_null</span> isn&#39;t proposed for i=
nclusion in the standard AFAIK.</li><li><span style=3D"font-family:courier =
new,monospace">propagate_const</span> disables all copying, even when it is=
 technically possible (e.g. <span style=3D"font-family:courier new,monospac=
e">T*</span> to <span style=3D"font-family:courier new,monospace">T*</span>=
 or <span style=3D"font-family:courier new,monospace">T* const</span> to <s=
pan style=3D"font-family:courier new,monospace">T const*</span>), which is =
hugely limiting when dealing with &quot;observer&quot; types.</li><li><span=
 style=3D"font-family:courier new,monospace">propagate_const</span> is desi=
gned with a very limited &quot;pointer-like&quot; interface; it is likely t=
o be of limited use for &quot;smart wrappers&quot; which do not adhere to t=
he pointer model (a problem if you want a null-less counterpart to <span st=
yle=3D"font-family:courier new,monospace">observer_ptr</span>).</li></ul><p=
>What&#39;s more, you have to ask, why are we starting with a type which is=
 ill-fitting to model a const-correct, not-null observer type (<span style=
=3D"font-family:courier new,monospace">T*</span>) and then layering it with=
 various wrappers designed to mould it into something which fits the bill? =
Wouldn&#39;t it be better to design separate wrapper types which just do th=
e job?</p><p><br></p><p><span style=3D"font-family:courier new,monospace">=
=C2=A0 observer&lt;T&gt; obs =3D obj;</span><br></p><p><span style=3D"font-=
family:courier new,monospace">=C2=A0 optional_observer&lt;T&gt; opt_obs =3D=
 obj;</span><br></p><p><br></p>This is infinitely more desirable IMO. It&#3=
9;s worth noting that, while is dislike the idea of using <span style=3D"fo=
nt-family:courier new,monospace">not_null</span> for anything other than sa=
nitizing legacy code (and the designers seem to agree, seeing as they want =
it to support only raw pointers), I am aware (I think) of why <span style=
=3D"font-family:courier new,monospace">propagate_const</span> is designed t=
he way it is. If <span style=3D"font-family:courier new,monospace">propagat=
e_const</span> could be redesigned to be more general and flexible (and I b=
elieve it may, if the <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/doc=
s/papers/2016/p0352r0.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-s=
td.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0352r0.pdf\x26sa\x3dD=
\x26sntz\x3d1\x26usg\x3dAFQjCNHYZPJtfbho-i-q7MgRJPt5k81BRw&#39;;return true=
;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2F=
www.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0352r0.pdf\=
x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHYZPJtfbho-i-q7MgRJPt5k81BRw&#39;;r=
eturn true;">Smart References through Delegation</a> proposal were accepted=
), then <i>perhaps</i> it would make sense to leave it the responsibility o=
f applying const-correctness to a &quot;smart wrapper&quot; API. <br><span =
style=3D"font-family:courier new,monospace"></span><p><br></p><p><span styl=
e=3D"font-family:courier new,monospace">=C2=A0 propagate_const&lt;observer&=
lt;T&gt;&gt; obs =3D obj;</span><br></p><p><br></p>Just my two cents.<br><b=
r>** Raw pointers are used in low-level code for all sorts of uses; and=20
anyway, I assume it is better to be explicit that assume people know=20
what you mean.<br></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/8199f37c-7738-4b59-8b01-c258a8165884%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8199f37c-7738-4b59-8b01-c258a8165884=
%40isocpp.org</a>.<br />

------=_Part_95_1327537731.1476958280157--

------=_Part_94_740886428.1476958280156--

.

------=_Part_130_209579376.1476961598228
Content-Type: multipart/alternative;
 boundary="----=_Part_131_49941150.1476961598228"

------=_Part_131_49941150.1476961598228
Content-Type: text/plain; charset=UTF-8



On Thursday, October 20, 2016 at 11:45:10 AM UTC+3, joseph....@gmail.com
wrote:
>
> On Thursday, 20 October 2016 15:09:16 UTC+8, mihailn...@gmail.com wrote:
>>
>> My intentions are not to change your mind - we, as well as everyone else,
>> are perfectly aware of the pros and cons of both approaches - raw vs new
>> ptr.
>>
>
> I think it helps to have these things written down. Even if everyone else
> knows everything already, it helps me get my thoughts in order and realize
> where my reasoning is flawed.
>

Agreed. These pros and cons lists are important, so one can see all sides.
I for one see better now, why people want a view type, most importantly -
what features they want from it!


>
> We also agree, any "operator." (in quotes, not necessarily overloading it)
>> will dramatically change any possible implementation of such a wrapper
>> pointer type.
>>
>
> I don't agree with this. I think "operator dot overloading" will have
> limited to no application in this case. I believe it will have more of an
> application with types that act to modify select parts of an API while
> retaining the overall appearance of the underlying type like, for example,
> propagate_const.
>

Considering all proposals include an impl of a smart reference - it
certainly will have significant impact. We probably don't want to end up
with too much observing wrappers.


And lets be honest, references now are the non-null pointers we are trying
to invent anew. They are invented for this same purpose ages ago.

IF the downsides of these are solved (a.k.a. smart references), maybe they
are the right way to handle the observer case.

May be the future is not a pointer type, but a reference type.
After all, they were the first observers out there!


>
>
>> I also agree with you propagate_const should be integral part of such a
>> wrapper pointer type, not a cumbersome opt-in.
>>
>
> I'm in two minds about this. It may be better to keep const propagation
> separate.
>

But we more often need the pointed-to be const, not the pointer.

We write const auto* many times more often then auto*const.

Yes, propagate, will mean const auto*const, so there should be control.

In any case, propagation is not unreasonable default:

It will enable const auto obj = getObj(); to mean what the user probably
intended to mean!
Vary, very reasonable default.

It is interesting to note, smart references will suffer from the same
problem.


> As a result, I (still) strongly believe observer_ptr should *not* go into
>> the standard in its current form.
>> It will be half-assessed, and will rise as many issues/questions as it
>> solves and will be become the auto_ptr version of a much better view type.
>>
>
> Agreed.
>

--
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/f4cf845d-638b-488b-afad-a6de0ab9addd%40isocpp.org.

------=_Part_131_49941150.1476961598228
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, October 20, 2016 at 11:45:10 AM UTC+3=
, joseph....@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr">On Thursday, 20 October 2016 15:09:16 UTC+8, <a>mihailn...@=
gmail.com</a>  wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div>My intentions are not to change your mind=C2=A0- we, as well as eve=
ryone else, are perfectly aware of the=C2=A0pros and cons of both approache=
s - raw vs new ptr.</div></div></blockquote><div>=C2=A0<br>I think it helps=
 to have these things written down. Even if everyone else knows everything =
already, it helps me get my thoughts in order and realize where my reasonin=
g is flawed.<br></div></div></blockquote><div><br></div><div>Agreed. These =
pros and cons lists are important, so one can see all sides. I for one see =
better now,=C2=A0why people want a view type, most importantly - what featu=
res they want from it!</div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><div><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr"><div></div><div>We also agree, any &quot;opera=
tor.&quot; (in quotes, not necessarily overloading it) will dramatically ch=
ange any possible implementation of=C2=A0such a wrapper pointer type.</div>=
</div></blockquote><div><br>I don&#39;t agree with this. I think &quot;oper=
ator dot overloading&quot; will have limited to no application in this case=
.. I believe it will have more of an application with types that act to modi=
fy select parts of an API while retaining the overall appearance of the und=
erlying type like, for example, <span style=3D"font-family:courier new,mono=
space">propagate_const</span>.<br></div></div></blockquote><div><br></div><=
div>Considering all proposals include an impl of a smart reference - it cer=
tainly will have significant impact. We probably don&#39;t want to end up w=
ith too much observing wrappers. </div><div><br></div><div><br></div><div>A=
nd lets be honest, references now are the non-null pointers we are trying t=
o invent anew. They are invented for this same purpose ages ago.</div><div>=
<br></div><div>IF the downsides of these are solved (a.k.a. smart reference=
s), maybe they are the right way to handle the observer case.</div><div><br=
></div><div>May be the future is not a pointer type, but a reference type.<=
/div><div>After all, they were the first observers out there!</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;"><div dir=3D"ltr"><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"><div dir=3D"ltr"><div>=
I also=C2=A0agree with you=C2=A0propagate_const should be integral part of =
such a wrapper pointer type, not a cumbersome opt-in.=C2=A0</div></div></bl=
ockquote><div><br>I&#39;m in two minds about this. It may be better to keep=
 const propagation separate.<br></div></div></blockquote><div><br></div><di=
v>But we more often need the pointed-to be const, not the pointer.</div><di=
v><br></div><div>We write const auto* many times more often then auto*const=
..</div><div><br></div><div>Yes, propagate, will mean const auto*const, so t=
here should be control.</div><div><br></div><div>In any case, propagation i=
s not unreasonable default:</div><div><br></div><div>It will enable const a=
uto obj =3D getObj();=C2=A0to mean what the user probably intended to mean!=
</div><div>Vary, very reasonable default. </div><div><br></div><div>It is i=
nteresting to note, smart references will suffer from the same problem.</di=
v><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
>As a result, I (still)=C2=A0strongly believe=C2=A0observer_ptr=C2=A0should=
 <b>not</b>=C2=A0go into the standard in its current form.<div>It will be h=
alf-assessed, and will rise as many issues/questions as it solves and will =
be become=C2=A0the=C2=A0auto_ptr version of a much better view type. </div>=
</div></blockquote><div><br>Agreed.<br></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/f4cf845d-638b-488b-afad-a6de0ab9addd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f4cf845d-638b-488b-afad-a6de0ab9addd=
%40isocpp.org</a>.<br />

------=_Part_131_49941150.1476961598228--

------=_Part_130_209579376.1476961598228--

.

------=_Part_282_816813992.1476976047237
Content-Type: multipart/alternative;
 boundary="----=_Part_283_1779350520.1476976047237"

------=_Part_283_1779350520.1476976047237
Content-Type: text/plain; charset=UTF-8

On Thursday, October 20, 2016 at 7:06:38 AM UTC-4, mihailn...@gmail.com
wrote:
>
> On Thursday, October 20, 2016 at 11:45:10 AM UTC+3, joseph....@gmail.com
> wrote:
>>
>> On Thursday, 20 October 2016 15:09:16 UTC+8, mihailn...@gmail.com wrote:
>>
> We also agree, any "operator." (in quotes, not necessarily overloading it)
>>> will dramatically change any possible implementation of such a wrapper
>>> pointer type.
>>>
>>
>> I don't agree with this. I think "operator dot overloading" will have
>> limited to no application in this case. I believe it will have more of an
>> application with types that act to modify select parts of an API while
>> retaining the overall appearance of the underlying type like, for example,
>> propagate_const.
>>
>
> Considering all proposals include an impl of a smart reference - it
> certainly will have significant impact.
>

Point of order: none of the operator-dot proposals come with smart
references. They *talk about* them, but they do not include any actual
standard library addendums to include smart reference types. It's important
to recognize the distinction there.

--
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/095f5a4d-4b5a-407a-98df-74d17458b595%40isocpp.org.

------=_Part_283_1779350520.1476976047237
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, October 20, 2016 at 7:06:38 AM UTC-4, mihailn=
....@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Thursday, October 20, 2016 at 11:45:10 AM UTC+3, <a>joseph....@=
gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
">On Thursday, 20 October 2016 15:09:16 UTC+8, <a>mihailn...@gmail.com</a> =
 wrote:</div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div></div><div>We also agree, any &quot;operator.&quot; (in quotes, not =
necessarily overloading it) will dramatically change any possible implement=
ation of=C2=A0such a wrapper pointer type.</div></div></blockquote><div><br=
>I don&#39;t agree with this. I think &quot;operator dot overloading&quot; =
will have limited to no application in this case. I believe it will have mo=
re of an application with types that act to modify select parts of an API w=
hile retaining the overall appearance of the underlying type like, for exam=
ple, <span style=3D"font-family:courier new,monospace">propagate_const</spa=
n>.<br></div></div></blockquote><div><br></div><div>Considering all proposa=
ls include an impl of a smart reference - it certainly will have significan=
t impact.</div></div></blockquote><div><br>Point of order: none of the oper=
ator-dot proposals come with smart references. They <i>talk about</i> them,=
 but they do not include any actual standard library addendums to include s=
mart reference types. It&#39;s important to recognize the distinction there=
..</div><br></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/095f5a4d-4b5a-407a-98df-74d17458b595%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/095f5a4d-4b5a-407a-98df-74d17458b595=
%40isocpp.org</a>.<br />

------=_Part_283_1779350520.1476976047237--

------=_Part_282_816813992.1476976047237--

.