Hello all,

I would like to have an explicit non-owning smart pointer, like "T*",
but that is required to check in "->" and "*" that the pointer is
non-null (alternative implementations like checking on construction
and assignments are welcome!)

This would stop people that want to programm defensively from having
to check their argument pointers from being null or from transforming
their parameters to references (just because they don't expect null
pointers? Um, we should have a more direct way to do this and still be
able to operate on pointers!).

template<typename T>
struct raw_ptr {
   T *operator->() const {
      .... throw if ptr== 0
   }

   T &operator*() {
      ... throw if ptr == 0
   }
};

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 22.08.2015 17:49, 'Johannes Schaub' via ISO C++ Standard - Future
Proposals wrote:
> Hello all,
>
> I would like to have an explicit non-owning smart pointer, like "T*",
> but that is required to check in "->" and "*" that the pointer is
> non-null (alternative implementations like checking on construction
> and assignments are welcome!)
>
> This would stop people that want to programm defensively from having
> to check their argument pointers from being null or from transforming
> their parameters to references (just because they don't expect null
> pointers? Um, we should have a more direct way to do this and still be
> able to operate on pointers!).
>
> template<typename T>
> struct raw_ptr {
>     T *operator->() const {
>        .... throw if ptr== 0
>     }
>
>     T &operator*() {
>        ... throw if ptr == 0
>     }
> };

This pointer IS the defensive programming, you're simply moving the
checks around. What's worse, you perform the check every time you
dereference the pointer instead of just once, on a function entry, for
instance.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

2015-08-22 17:03 GMT+02:00 Andrey Semashev <andrey.semashev@gmail.com>:
> On 22.08.2015 17:49, 'Johannes Schaub' via ISO C++ Standard - Future
> Proposals wrote:
>>
>> Hello all,
>>
>> I would like to have an explicit non-owning smart pointer, like "T*",
>> but that is required to check in "->" and "*" that the pointer is
>> non-null (alternative implementations like checking on construction
>> and assignments are welcome!)
>>
>> This would stop people that want to programm defensively from having
>> to check their argument pointers from being null or from transforming
>> their parameters to references (just because they don't expect null
>> pointers? Um, we should have a more direct way to do this and still be
>> able to operate on pointers!).
>>
>> template<typename T>
>> struct raw_ptr {
>>     T *operator->() const {
>>        .... throw if ptr== 0
>>     }
>>
>>     T &operator*() {
>>        ... throw if ptr == 0
>>     }
>> };
>
>
> This pointer IS the defensive programming, you're simply moving the checks
> around. What's worse, you perform the check every time you dereference the
> pointer instead of just once, on a function entry, for instance.
>

I have not understood, what do you mean by "This pointer"? Do you mean
an object'S "this" pointer? How does it support defensive programming
exactly? Or do you mean that my raw_ptr pointer is THE definition of
defensive programming? I would be surprised :)

I agree about "you perform the cehck everytime when you dereference",
therefore I am open for other implementations. Perhaps checking only
on construction and assignments would be best.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 22.08.2015 18:31, 'Johannes Schaub' via ISO C++ Standard - Future
Proposals wrote:
> 2015-08-22 17:03 GMT+02:00 Andrey Semashev <andrey.semashev@gmail.com>:
>> On 22.08.2015 17:49, 'Johannes Schaub' via ISO C++ Standard - Future
>> Proposals wrote:
>>>
>>> Hello all,
>>>
>>> I would like to have an explicit non-owning smart pointer, like "T*",
>>> but that is required to check in "->" and "*" that the pointer is
>>> non-null (alternative implementations like checking on construction
>>> and assignments are welcome!)
>>>
>>> This would stop people that want to programm defensively from having
>>> to check their argument pointers from being null or from transforming
>>> their parameters to references (just because they don't expect null
>>> pointers? Um, we should have a more direct way to do this and still be
>>> able to operate on pointers!).
>>>
>>> template<typename T>
>>> struct raw_ptr {
>>>      T *operator->() const {
>>>         .... throw if ptr== 0
>>>      }
>>>
>>>      T &operator*() {
>>>         ... throw if ptr == 0
>>>      }
>>> };
>>
>>
>> This pointer IS the defensive programming, you're simply moving the checks
>> around. What's worse, you perform the check every time you dereference the
>> pointer instead of just once, on a function entry, for instance.
>>
>
> I have not understood, what do you mean by "This pointer"? Do you mean
> an object'S "this" pointer? How does it support defensive programming
> exactly? Or do you mean that my raw_ptr pointer is THE definition of
> defensive programming? I would be surprised :)

By 'this pointer' I meant your proposed raw_ptr. You don't remove the
defensive code, you simply hide it and multiply for each dereference
operator. This I consider a bad code practice and I'm opposed to the
proposal.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

2015-08-22 17:45 GMT+02:00 Andrey Semashev <andrey.semashev@gmail.com>:
> On 22.08.2015 18:31, 'Johannes Schaub' via ISO C++ Standard - Future
> Proposals wrote:
>>
>> 2015-08-22 17:03 GMT+02:00 Andrey Semashev <andrey.semashev@gmail.com>:
>>>
>>> On 22.08.2015 17:49, 'Johannes Schaub' via ISO C++ Standard - Future
>>> Proposals wrote:
>>>>
>>>>
>>>> Hello all,
>>>>
>>>> I would like to have an explicit non-owning smart pointer, like "T*",
>>>> but that is required to check in "->" and "*" that the pointer is
>>>> non-null (alternative implementations like checking on construction
>>>> and assignments are welcome!)
>>>>
>>>> This would stop people that want to programm defensively from having
>>>> to check their argument pointers from being null or from transforming
>>>> their parameters to references (just because they don't expect null
>>>> pointers? Um, we should have a more direct way to do this and still be
>>>> able to operate on pointers!).
>>>>
>>>> template<typename T>
>>>> struct raw_ptr {
>>>>      T *operator->() const {
>>>>         .... throw if ptr== 0
>>>>      }
>>>>
>>>>      T &operator*() {
>>>>         ... throw if ptr == 0
>>>>      }
>>>> };
>>>
>>>
>>>
>>> This pointer IS the defensive programming, you're simply moving the
>>> checks
>>> around. What's worse, you perform the check every time you dereference
>>> the
>>> pointer instead of just once, on a function entry, for instance.
>>>
>>
>> I have not understood, what do you mean by "This pointer"? Do you mean
>> an object'S "this" pointer? How does it support defensive programming
>> exactly? Or do you mean that my raw_ptr pointer is THE definition of
>> defensive programming? I would be surprised :)
>
>
> By 'this pointer' I meant your proposed raw_ptr. You don't remove the
> defensive code, you simply hide it and multiply for each dereference
> operator. This I consider a bad code practice and I'm opposed to the
> proposal.
>

Thanks for the clarification. My intent wasn't to remove defensive
programming code completely, but to remove defensive programming code
from the user's code. Of course, that is the essence of library tools.
They do the work for their users.

Note that the code is only there once. Code and development time cost
is not dynamically increased when the code is executed by processors.
That not only holds for library tools, but for all code in general.
C++ is an ahead-of-time compiled language almost of the time, not a
just-and-always-in-time compiled.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Sat, Aug 22, 2015 at 10:50 AM, 'Johannes Schaub' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> 2015-08-22 17:45 GMT+02:00 Andrey Semashev <andrey.semashev@gmail.com>:
> > On 22.08.2015 18:31, 'Johannes Schaub' via ISO C++ Standard - Future
> > Proposals wrote:
> >>
> >> 2015-08-22 17:03 GMT+02:00 Andrey Semashev <andrey.semashev@gmail.com>:
> >>>
> >>> On 22.08.2015 17:49, 'Johannes Schaub' via ISO C++ Standard - Future
> >>> Proposals wrote:
> >>>>
> >>>>
> >>>> Hello all,
> >>>>
> >>>> I would like to have an explicit non-owning smart pointer, like "T*",
> >>>> but that is required to check in "->" and "*" that the pointer is
> >>>> non-null (alternative implementations like checking on construction
> >>>> and assignments are welcome!)
> >>>>
> >>>> This would stop people that want to programm defensively from having
> >>>> to check their argument pointers from being null or from transforming
> >>>> their parameters to references (just because they don't expect null
> >>>> pointers? Um, we should have a more direct way to do this and still be
> >>>> able to operate on pointers!).
> >>>>
> >>>> template<typename T>
> >>>> struct raw_ptr {
> >>>>      T *operator->() const {
> >>>>         .... throw if ptr== 0
> >>>>      }
> >>>>
> >>>>      T &operator*() {
> >>>>         ... throw if ptr == 0
> >>>>      }
> >>>> };
> >>>
> >>>
> >>>
> >>> This pointer IS the defensive programming, you're simply moving the
> >>> checks
> >>> around. What's worse, you perform the check every time you dereference
> >>> the
> >>> pointer instead of just once, on a function entry, for instance.
> >>>
> >>
> >> I have not understood, what do you mean by "This pointer"? Do you mean
> >> an object'S "this" pointer? How does it support defensive programming
> >> exactly? Or do you mean that my raw_ptr pointer is THE definition of
> >> defensive programming? I would be surprised :)
> >
> >
> > By 'this pointer' I meant your proposed raw_ptr. You don't remove the
> > defensive code, you simply hide it and multiply for each dereference
> > operator. This I consider a bad code practice and I'm opposed to the
> > proposal.
> >
>
> Thanks for the clarification. My intent wasn't to remove defensive
> programming code completely, but to remove defensive programming code
> from the user's code. Of course, that is the essence of library tools.
> They do the work for their users.
>
> Note that the code is only there once. Code and development time cost
> is not dynamically increased when the code is executed by processors.
> That not only holds for library tools, but for all code in general.
> C++ is an ahead-of-time compiled language almost of the time, not a
> just-and-always-in-time compiled.
>
>
> Your solution puts more burden on the developer in terms of exception
handling, and does not provide for assertions -- and IMO is detrimental to
the type of thinking the programmer should experience when dealing with
pointers.  If I understand correctly your raw_ptr could not be used within
any method marked noexcept.

I hope that reasoning is helpful.
-Andrew Sandoval

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Aug 22, 2015 at 10:50 AM, &#39;Johannes Schaub&#39; via ISO C++ Standar=
d - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@=
isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">2015-08-22 17:45 GMT+02:00 Andrey Semas=
hev &lt;<a href=3D"mailto:andrey.semashev@gmail.com">andrey.semashev@gmail.=
com</a>&gt;:<br>
&gt; On <a href=3D"tel:22.08.2015%2018" value=3D"+12208201518">22.08.2015 1=
8</a>:31, &#39;Johannes Schaub&#39; via ISO C++ Standard - Future<br>
&gt; Proposals wrote:<br>
&gt;&gt;<br>
&gt;&gt; 2015-08-22 17:03 GMT+02:00 Andrey Semashev &lt;<a href=3D"mailto:a=
ndrey.semashev@gmail.com">andrey.semashev@gmail.com</a>&gt;:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On <a href=3D"tel:22.08.2015%2017" value=3D"+12208201517">22.0=
8.2015 17</a>:49, &#39;Johannes Schaub&#39; via ISO C++ Standard - Future<b=
r>
&gt;&gt;&gt; Proposals wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Hello all,<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I would like to have an explicit non-owning smart pointer,=
 like &quot;T*&quot;,<br>
&gt;&gt;&gt;&gt; but that is required to check in &quot;-&gt;&quot; and &qu=
ot;*&quot; that the pointer is<br>
&gt;&gt;&gt;&gt; non-null (alternative implementations like checking on con=
struction<br>
&gt;&gt;&gt;&gt; and assignments are welcome!)<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; This would stop people that want to programm defensively f=
rom having<br>
&gt;&gt;&gt;&gt; to check their argument pointers from being null or from t=
ransforming<br>
&gt;&gt;&gt;&gt; their parameters to references (just because they don&#39;=
t expect null<br>
&gt;&gt;&gt;&gt; pointers? Um, we should have a more direct way to do this =
and still be<br>
&gt;&gt;&gt;&gt; able to operate on pointers!).<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; template&lt;typename T&gt;<br>
&gt;&gt;&gt;&gt; struct raw_ptr {<br>
&gt;&gt;&gt;&gt;=C2=A0 =C2=A0 =C2=A0 T *operator-&gt;() const {<br>
&gt;&gt;&gt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.... throw if ptr=3D=3D 0=
<br>
&gt;&gt;&gt;&gt;=C2=A0 =C2=A0 =C2=A0 }<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;=C2=A0 =C2=A0 =C2=A0 T &amp;operator*() {<br>
&gt;&gt;&gt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0... throw if ptr =3D=3D 0=
<br>
&gt;&gt;&gt;&gt;=C2=A0 =C2=A0 =C2=A0 }<br>
&gt;&gt;&gt;&gt; };<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; This pointer IS the defensive programming, you&#39;re simply m=
oving the<br>
&gt;&gt;&gt; checks<br>
&gt;&gt;&gt; around. What&#39;s worse, you perform the check every time you=
 dereference<br>
&gt;&gt;&gt; the<br>
&gt;&gt;&gt; pointer instead of just once, on a function entry, for instanc=
e.<br>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; I have not understood, what do you mean by &quot;This pointer&quot=
;? Do you mean<br>
&gt;&gt; an object&#39;S &quot;this&quot; pointer? How does it support defe=
nsive programming<br>
&gt;&gt; exactly? Or do you mean that my raw_ptr pointer is THE definition =
of<br>
&gt;&gt; defensive programming? I would be surprised :)<br>
&gt;<br>
&gt;<br>
&gt; By &#39;this pointer&#39; I meant your proposed raw_ptr. You don&#39;t=
 remove the<br>
&gt; defensive code, you simply hide it and multiply for each dereference<b=
r>
&gt; operator. This I consider a bad code practice and I&#39;m opposed to t=
he<br>
&gt; proposal.<br>
&gt;<br>
<br>
Thanks for the clarification. My intent wasn&#39;t to remove defensive<br>
programming code completely, but to remove defensive programming code<br>
from the user&#39;s code. Of course, that is the essence of library tools.<=
br>
They do the work for their users.<br>
<br>
Note that the code is only there once. Code and development time cost<br>
is not dynamically increased when the code is executed by processors.<br>
That not only holds for library tools, but for all code in general.<br>
C++ is an ahead-of-time compiled language almost of the time, not a<br>
just-and-always-in-time compiled.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
</font></span></blockquote></div>Your solution puts more burden on the deve=
loper in terms of exception handling, and does not provide for assertions -=
- and IMO is detrimental to the type of thinking the programmer should expe=
rience when dealing with pointers.=C2=A0 If I understand correctly your raw=
_ptr could not be used within any method marked noexcept.<br><br></div><div=
 class=3D"gmail_extra">I hope that reasoning is helpful.<br></div><div clas=
s=3D"gmail_extra">-Andrew Sandoval</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11376382bc34ef051de9f785--

.

--047d7ba9782431096b051deb87a0
Content-Type: text/plain; charset=UTF-8

How does the proposed non-owning non-null smart pointer differ from
references?  That is, why not just use references instead of pointers?

Also see related N3840.

On Sat, Aug 22, 2015 at 4:49 PM, 'Johannes Schaub' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> Hello all,
>
> I would like to have an explicit non-owning smart pointer, like "T*",
> but that is required to check in "->" and "*" that the pointer is
> non-null (alternative implementations like checking on construction
> and assignments are welcome!)
>
> This would stop people that want to programm defensively from having
> to check their argument pointers from being null or from transforming
> their parameters to references (just because they don't expect null
> pointers? Um, we should have a more direct way to do this and still be
> able to operate on pointers!).
>
> template<typename T>
> struct raw_ptr {
>    T *operator->() const {
>       .... throw if ptr== 0
>    }
>
>    T &operator*() {
>       ... throw if ptr == 0
>    }
> };
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">How does the proposed non-owning non-null smart pointer di=
ffer from references?=C2=A0 That is, why not just use references instead of=
 pointers?<div><br></div><div>Also see related N3840.</div><div><br></div><=
div><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Sat, Aug 22, 2=
015 at 4:49 PM, &#39;Johannes Schaub&#39; via ISO C++ Standard - Future Pro=
posals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocpp.org" ta=
rget=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex">Hello all,<br>
<br>
I would like to have an explicit non-owning smart pointer, like &quot;T*&qu=
ot;,<br>
but that is required to check in &quot;-&gt;&quot; and &quot;*&quot; that t=
he pointer is<br>
non-null (alternative implementations like checking on construction<br>
and assignments are welcome!)<br>
<br>
This would stop people that want to programm defensively from having<br>
to check their argument pointers from being null or from transforming<br>
their parameters to references (just because they don&#39;t expect null<br>
pointers? Um, we should have a more direct way to do this and still be<br>
able to operate on pointers!).<br>
<br>
template&lt;typename T&gt;<br>
struct raw_ptr {<br>
=C2=A0 =C2=A0T *operator-&gt;() const {<br>
=C2=A0 =C2=A0 =C2=A0 .... throw if ptr=3D=3D 0<br>
=C2=A0 =C2=A0}<br>
<br>
=C2=A0 =C2=A0T &amp;operator*() {<br>
=C2=A0 =C2=A0 =C2=A0 ... throw if ptr =3D=3D 0<br>
=C2=A0 =C2=A0}<br>
};<br>
<span class=3D""><font color=3D"#888888"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7ba9782431096b051deb87a0--

.

------=_Part_885_1650597721.1440278329706
Content-Type: multipart/alternative;
 boundary="----=_Part_886_416342007.1440278329706"

------=_Part_886_416342007.1440278329706
Content-Type: text/plain; charset=UTF-8

On Saturday, August 22, 2015 at 3:38:30 PM UTC-4, Andrew Tomazos wrote:
>
> How does the proposed non-owning non-null smart pointer differ from
> references?  That is, why not just use references instead of pointers?
>

Presumably because they can be reseated. Granted, I don't think that use
case is worth bothering with, but that's probably the general idea.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Saturday, August 22, 2015 at 3:38:30 PM UTC-4, Andrew T=
omazos wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
How does the proposed non-owning non-null smart pointer differ from referen=
ces?=C2=A0 That is, why not just use references instead of pointers?</div><=
/blockquote><div><br>Presumably because they can be reseated. Granted, I do=
n&#39;t think that use case is worth bothering with, but that&#39;s probabl=
y the general idea.</div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_886_416342007.1440278329706--
------=_Part_885_1650597721.1440278329706--

.

------=_Part_420_938684395.1440282926901
Content-Type: text/plain; charset=UTF-8

Checked get doesn't need to be part of the type; it can be a free function:

auto* checked_get(auto&& ptr) {
  return ptr ? ptr.get() : throw "empty"; }

Note this works with other types of smart pointer as well.

A true non-empty pointer would be a different kettle of fish, but it's hard to see how such a type could be regular, which might be something of an impediment.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_420_938684395.1440282926901--

.

------=_Part_448_1041596323.1440282984008
Content-Type: text/plain; charset=UTF-8

Checked get doesn't need to be part of the type; it can be a free function:

auto* checked_get(auto&& ptr) {
  return ptr ? ptr.get() : throw "empty"; }

Note this works with other types of smart pointer as well.

A true non-empty pointer would be a different kettle of fish, but it's hard to see how such a type could be regular, which might be something of an impediment.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_448_1041596323.1440282984008--

.

------=_Part_392_2034808554.1440283001084
Content-Type: text/plain; charset=UTF-8

Checked get doesn't need to be part of the type; it can be a free function:

auto* checked_get(auto&& ptr) {
  return ptr ? ptr.get() : throw "empty"; }

Note this works with other types of smart pointer as well.

A true non-empty pointer would be a different kettle of fish, but it's hard to see how such a type could be regular, which might be something of an impediment.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_392_2034808554.1440283001084--

.

Dropbox have such a project and I think they are going to present it at
CppCon
https://github.com/dropbox/nn

The gist of it is you take a nn_unique_ptr<T> (nn = non-null) as
argument and whoever constructs the nn_unique_ptr<T> makes the promise
it is not initialized with null, so you're exposing this contract in a
function's signature. It also works with raw pointers.

Am 22.08.2015 um 16:49 schrieb 'Johannes Schaub' via ISO C++ Standard -
Future Proposals:
> Hello all,
>
> I would like to have an explicit non-owning smart pointer, like "T*",
> but that is required to check in "->" and "*" that the pointer is
> non-null (alternative implementations like checking on construction
> and assignments are welcome!)
>
> This would stop people that want to programm defensively from having
> to check their argument pointers from being null or from transforming
> their parameters to references (just because they don't expect null
> pointers? Um, we should have a more direct way to do this and still be
> able to operate on pointers!).
>
> template<typename T>
> struct raw_ptr {
>     T *operator->() const {
>        .... throw if ptr== 0
>     }
>
>     T &operator*() {
>        ... throw if ptr == 0
>     }
> };
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Sat, Aug 22, 2015 at 11:18 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Saturday, August 22, 2015 at 3:38:30 PM UTC-4, Andrew Tomazos wrote:
>>
>> How does the proposed non-owning non-null smart pointer differ from
>> references?  That is, why not just use references instead of pointers?
>>
>
> Presumably because they can be reseated. Granted, I don't think that use
> case is worth bothering with, but that's probably the general idea.
>

std::ref and std::reference_wrapper allow references to be used as value
types and rebound through assignment.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Aug 22, 2015 at 11:18 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=
=3D"">On Saturday, August 22, 2015 at 3:38:30 PM UTC-4, Andrew Tomazos wrot=
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">How does the pro=
posed non-owning non-null smart pointer differ from references?=C2=A0 That =
is, why not just use references instead of pointers?</div></blockquote></sp=
an><div><br>Presumably because they can be reseated. Granted, I don&#39;t t=
hink that use case is worth bothering with, but that&#39;s probably the gen=
eral idea.</div></div></blockquote><div><br></div><div>std::ref and std::re=
ference_wrapper allow references to be used as value types and rebound thro=
ugh assignment.</div><div><br></div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--f46d0444033263ec54051df03713--

.

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

After seeing a couple of references to the nn library in dropbox I finally
took a look at the implementation. The first thing to note is that the
library does not make any promises as of the pointer not being null at any
time, it only provides protection against mistakenly setting it to a null
value initially. Borrowing from their example of use:

class Widget {
    Widget(nn_shared_ptr<Gadget>& gadget) : m_gadget(move(gadget)) {}
      // Argument type changed from value to reference!
....

A client holding a 'nn_shared_ptr<Gadget>' and passing that to the
constructor of 'Widget' ends up with a null nn_shared_ptr. Even without the
modification, that is taking the argument by value, inside the body of the
constructor the argument 'gadget' is null.

Similarly, a couple of lines below, outside of the constructor:

nn_shared_ptr<Widget> shared_widget = move(my_widget);

The promises that the component offer are quite limited, and I find the nn_
beyond what the component is able to offer. It looks like a nice utility to
avoid simple mistakes, but I am not sure that I'd like it adopted into the
standard.

I am with Andrew Tomazos here, references better reflect non-empty
pointers. I have not had the need to reseat a type with reference semantics
in a context where reference_wrapper was not the better alternative, so I
might be biased here.

Also, I work in a code base where raw pointers are pervasive (output
arguments to functions are pointers, never references), we use defensive
programming in a similar way to n4075 and I never found it a burden to add
a test on function entry for non-null-ness of the arguments. Yes, having
this enforced by the type system would be great, but the solution needs to
be *safe*, a nn_ptr that can still become empty and for which the same
defensive checks need to be in place is not that much better than the
equivalent ptr.

    David


On Sun, Aug 23, 2015 at 12:14 AM, Miro Knejp <miro.knejp@gmail.com> wrote:

> Dropbox have such a project and I think they are going to present it at
> CppCon
> https://github.com/dropbox/nn
>
> The gist of it is you take a nn_unique_ptr<T> (nn = non-null) as argument
> and whoever constructs the nn_unique_ptr<T> makes the promise it is not
> initialized with null, so you're exposing this contract in a function's
> signature. It also works with raw pointers.
>
>
> Am 22.08.2015 um 16:49 schrieb 'Johannes Schaub' via ISO C++ Standard -
> Future Proposals:
>
>> Hello all,
>>
>> I would like to have an explicit non-owning smart pointer, like "T*",
>> but that is required to check in "->" and "*" that the pointer is
>> non-null (alternative implementations like checking on construction
>> and assignments are welcome!)
>>
>> This would stop people that want to programm defensively from having
>> to check their argument pointers from being null or from transforming
>> their parameters to references (just because they don't expect null
>> pointers? Um, we should have a more direct way to do this and still be
>> able to operate on pointers!).
>>
>> template<typename T>
>> struct raw_ptr {
>>     T *operator->() const {
>>        .... throw if ptr== 0
>>     }
>>
>>     T &operator*() {
>>        ... throw if ptr == 0
>>     }
>> };
>>
>>
> --
>
> --- You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">After seeing a couple of references to the nn library in d=
ropbox I finally took a look at the implementation. The first thing to note=
 is that the library does not make any promises as of the pointer not being=
 null at any time, it only provides protection against mistakenly setting i=
t to a null value initially. Borrowing from their example of use:<br><br>cl=
ass Widget {<br>=C2=A0 =C2=A0 Widget(nn_shared_ptr&lt;Gadget&gt;&amp; gadge=
t) : m_gadget(move(gadget)) {}<div>=C2=A0 =C2=A0 =C2=A0 // Argument type ch=
anged from value to reference!<br>...<br><br>A client holding a &#39;nn_sha=
red_ptr&lt;Gadget&gt;&#39; and passing that to the constructor of &#39;Widg=
et&#39; ends up with a null nn_shared_ptr. Even without the modification, t=
hat is taking the argument by value, inside the body of the constructor the=
 argument &#39;gadget&#39; is null.<br><br>Similarly, a couple of lines bel=
ow, outside of the constructor:<br><br>nn_shared_ptr&lt;Widget&gt; shared_w=
idget =3D move(my_widget);<br><br>The promises that the component offer are=
 quite limited, and I find the nn_ beyond what the component is able to off=
er. It looks like a nice utility to avoid simple mistakes, but I am not sur=
e that I&#39;d like it adopted into the standard.<br><br>I am with Andrew T=
omazos here, references better reflect non-empty pointers. I have not had t=
he need to reseat a type with reference semantics in a context where refere=
nce_wrapper was not the better alternative, so I might be biased here.<br><=
br>Also, I work in a code base where raw pointers are pervasive (output arg=
uments to functions are pointers, never references), we use defensive progr=
amming in a similar way to n4075 and I never found it a burden to add a tes=
t on function entry for non-null-ness of the arguments. Yes, having this en=
forced by the type system would be great, but the solution needs to be *saf=
e*, a nn_ptr that can still become empty and for which the same defensive c=
hecks need to be in place is not that much better than the equivalent ptr.<=
br><br>=C2=A0 =C2=A0 David<br><br></div></div><div class=3D"gmail_extra"><b=
r><div class=3D"gmail_quote">On Sun, Aug 23, 2015 at 12:14 AM, Miro Knejp <=
span dir=3D"ltr">&lt;<a href=3D"mailto:miro.knejp@gmail.com" target=3D"_bla=
nk">miro.knejp@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">Dropbox have such a project and I think they are going to present it =
at CppCon<br>
<a href=3D"https://github.com/dropbox/nn" rel=3D"noreferrer" target=3D"_bla=
nk">https://github.com/dropbox/nn</a><br>
<br>
The gist of it is you take a nn_unique_ptr&lt;T&gt; (nn =3D non-null) as ar=
gument and whoever constructs the nn_unique_ptr&lt;T&gt; makes the promise =
it is not initialized with null, so you&#39;re exposing this contract in a =
function&#39;s signature. It also works with raw pointers.<div class=3D"HOE=
nZb"><div class=3D"h5"><br>
<br>
Am 22.08.2015 um 16:49 schrieb &#39;Johannes Schaub&#39; via ISO C++ Standa=
rd - Future Proposals:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Hello all,<br>
<br>
I would like to have an explicit non-owning smart pointer, like &quot;T*&qu=
ot;,<br>
but that is required to check in &quot;-&gt;&quot; and &quot;*&quot; that t=
he pointer is<br>
non-null (alternative implementations like checking on construction<br>
and assignments are welcome!)<br>
<br>
This would stop people that want to programm defensively from having<br>
to check their argument pointers from being null or from transforming<br>
their parameters to references (just because they don&#39;t expect null<br>
pointers? Um, we should have a more direct way to do this and still be<br>
able to operate on pointers!).<br>
<br>
template&lt;typename T&gt;<br>
struct raw_ptr {<br>
=C2=A0 =C2=A0 T *operator-&gt;() const {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0.... throw if ptr=3D=3D 0<br>
=C2=A0 =C2=A0 }<br>
<br>
=C2=A0 =C2=A0 T &amp;operator*() {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0... throw if ptr =3D=3D 0<br>
=C2=A0 =C2=A0 }<br>
};<br>
<br>
</blockquote>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c3bb3282af4c051e0a7c8f--

.

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

Am 22.08.2015 21:38 schrieb "Andrew Tomazos" <andrewtomazos@gmail.com>:
>
> How does the proposed non-owning non-null smart pointer differ from
references?  That is, why not just use references instead of pointers?
>
> Also see related N3840.
>

The reason for me to use pointers is for their added indirection to get to
their guts. I am passing these objects around for their identity. The
objects don't represent a value.

References will provide me with a way to refer to objects without
indirection yet with their identity encapsulated and hidden from me. I am
used to see string&, vector& and whatnot, all of them represent a value and
their identity is of no use. I am not used to QWidget&, as its identity is
primary and it is too easy to operate on it on the value level thatvway and
accidentally copy it and cause a compile error.

Applying address-of to a reference always rises the alarm bells. Using a
reference just because one of its properties satisfies a desired
requirement while other properties are dissatisfying is not the right way
for me.

> On Sat, Aug 22, 2015 at 4:49 PM, 'Johannes Schaub' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
>>
>> Hello all,
>>
>> I would like to have an explicit non-owning smart pointer, like "T*",
>> but that is required to check in "->" and "*" that the pointer is
>> non-null (alternative implementations like checking on construction
>> and assignments are welcome!)
>>
>> This would stop people that want to programm defensively from having
>> to check their argument pointers from being null or from transforming
>> their parameters to references (just because they don't expect null
>> pointers? Um, we should have a more direct way to do this and still be
>> able to operate on pointers!).
>>
>> template<typename T>
>> struct raw_ptr {
>>    T *operator->() const {
>>       .... throw if ptr== 0
>>    }
>>
>>    T &operator*() {
>>       ... throw if ptr == 0
>>    }
>> };
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send
an email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<p dir=3D"ltr"><br>
Am 22.08.2015 21:38 schrieb &quot;Andrew Tomazos&quot; &lt;<a href=3D"mailt=
o:andrewtomazos@gmail.com">andrewtomazos@gmail.com</a>&gt;:<br>
&gt;<br>
&gt; How does the proposed non-owning non-null smart pointer differ from re=
ferences?=C2=A0 That is, why not just use references instead of pointers?<b=
r>
&gt;<br>
&gt; Also see related N3840.<br>
&gt;</p>
<p dir=3D"ltr">The reason for me to use pointers is for their added indirec=
tion to get to their guts. I am passing these objects around for their iden=
tity. The objects don&#39;t represent a value.</p>
<p dir=3D"ltr">References will provide me with a way to refer to objects wi=
thout indirection yet with their identity encapsulated and hidden from me. =
I am used to see string&amp;, vector&amp; and whatnot, all of them represen=
t a value and their identity is of no use. I am not used to QWidget&amp;, a=
s its identity is primary and it is too easy to operate on it on the value =
level thatvway and accidentally copy it and cause a compile error. </p>
<p dir=3D"ltr">Applying address-of to a reference always rises the alarm be=
lls. Using a reference just because one of its properties satisfies a desir=
ed requirement while other properties are dissatisfying is not the right wa=
y for me.<br><br></p>
<p dir=3D"ltr">&gt; On Sat, Aug 22, 2015 at 4:49 PM, &#39;Johannes Schaub&#=
39; via ISO C++ Standard - Future Proposals &lt;<a href=3D"mailto:std-propo=
sals@isocpp.org">std-proposals@isocpp.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Hello all,<br>
&gt;&gt;<br>
&gt;&gt; I would like to have an explicit non-owning smart pointer, like &q=
uot;T*&quot;,<br>
&gt;&gt; but that is required to check in &quot;-&gt;&quot; and &quot;*&quo=
t; that the pointer is<br>
&gt;&gt; non-null (alternative implementations like checking on constructio=
n<br>
&gt;&gt; and assignments are welcome!)<br>
&gt;&gt;<br>
&gt;&gt; This would stop people that want to programm defensively from havi=
ng<br>
&gt;&gt; to check their argument pointers from being null or from transform=
ing<br>
&gt;&gt; their parameters to references (just because they don&#39;t expect=
 null<br>
&gt;&gt; pointers? Um, we should have a more direct way to do this and stil=
l be<br>
&gt;&gt; able to operate on pointers!).<br>
&gt;&gt;<br>
&gt;&gt; template&lt;typename T&gt;<br>
&gt;&gt; struct raw_ptr {<br>
&gt;&gt; =C2=A0 =C2=A0T *operator-&gt;() const {<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0 .... throw if ptr=3D=3D 0<br>
&gt;&gt; =C2=A0 =C2=A0}<br>
&gt;&gt;<br>
&gt;&gt; =C2=A0 =C2=A0T &amp;operator*() {<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0 ... throw if ptr =3D=3D 0<br>
&gt;&gt; =C2=A0 =C2=A0}<br>
&gt;&gt; };<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt;<br>
&gt;&gt; ---<br>
&gt;&gt; You received this message because you are subscribed to the Google=
 Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt;&gt; To unsubscribe from this group and stop receiving emails from it, =
send an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">=
std-proposals+unsubscribe@isocpp.org</a>.<br>
&gt;&gt; To post to this group, send email to <a href=3D"mailto:std-proposa=
ls@isocpp.org">std-proposals@isocpp.org</a>.<br>
&gt;&gt; Visit this group at <a href=3D"http://groups.google.com/a/isocpp.o=
rg/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-pr=
oposals/</a>.<br>
&gt;<br>
&gt;<br>
&gt; -- <br>
&gt;<br>
&gt; --- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-propos=
als/</a>.<br>
</p>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113f92c02d8c2a051e0b4151--

.

Am 24.08.2015 um 10:34 schrieb David Rodr=C3=ADguez Ibeas:
> After seeing a couple of references to the nn library in dropbox I=20
> finally took a look at the implementation. The first thing to note is=20
> that the library does not make any promises as of the pointer not=20
> being null at any time, it only provides protection against mistakenly=20
> setting it to a null value initially. Borrowing from their example of use=
:
>
> class Widget {
>     Widget(nn_shared_ptr<Gadget>& gadget) : m_gadget(move(gadget)) {}
>       // Argument type changed from value to reference!
> ...
>
> A client holding a 'nn_shared_ptr<Gadget>' and passing that to the=20
> constructor of 'Widget' ends up with a null nn_shared_ptr. Even=20
> without the modification, that is taking the argument by value, inside=20
> the body of the constructor the argument 'gadget' is null.
Your example is just asking for UB. If the referenced value is used=20
after the move for anything other than destruction or assignment to then=20
you have UB for any operations on that type with any kind of=20
precondition. Accidentally modifying a reference instead of a copy can=20
cause problems in a whole lot of cases, I don't see a point in special=20
casing nn_shared_ptr.
>
> Similarly, a couple of lines below, outside of the constructor:
>
> nn_shared_ptr<Widget> shared_widget =3D move(my_widget);
Same as above, if you use my_widget after the line you're just asking=20
for UB to happen at some point. There is nothing special about=20
nn_unique_ptr there. At least one compiler sets raw pointers to NULL=20
when being moved-from in a debug build to catch these cases (don't=20
remember which compiler it was unfortunately).
>
> The promises that the component offer are quite limited, and I find=20
> the nn_ beyond what the component is able to offer. It looks like a=20
> nice utility to avoid simple mistakes, but I am not sure that I'd like=20
> it adopted into the standard.
Sometimes all you need is a vocabulary type to remind people of some=20
contract. I wouldn't even mind there not being any checks involved in=20
the cosntruction of nn_something at all. If merely the presence of a=20
nn_something in a function's signature reminds the programmer of=20
checking the pointer for null before passing it to the function it has=20
served a very important purpose. And if that type has no implicit=20
constructor from nullable pointer types it breaks in code refactorings=20
that might change invariants somewhere, which is a good thing. Plus, if=20
these types were part of the standard library they might be taught to=20
static analysis tools.
>
> I am with Andrew Tomazos here, references better reflect non-empty=20
> pointers. I have not had the need to reseat a type with reference=20
> semantics in a context where reference_wrapper was not the better=20
> alternative, so I might be biased here.
True for raw pointers, but the standard does currently not offer a way=20
of saying "I want a non-null shared_ptr". A shared_ptr reference doesn't=20
say anything about non-emptiness. That is a service the nn library is=20
providing.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_2759_60662346.1440453305194
Content-Type: multipart/alternative;
 boundary="----=_Part_2760_448921298.1440453305194"

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



On Monday, August 24, 2015 at 5:48:32 PM UTC-4, Miro Knejp wrote:
>
> Am 24.08.2015 um 10:34 schrieb David Rodr=C3=ADguez Ibeas:=20
> > After seeing a couple of references to the nn library in dropbox I=20
> > finally took a look at the implementation. The first thing to note is=
=20
> > that the library does not make any promises as of the pointer not=20
> > being null at any time, it only provides protection against mistakenly=
=20
> > setting it to a null value initially. Borrowing from their example of=
=20
> use:=20
> >=20
> > class Widget {=20
> >     Widget(nn_shared_ptr<Gadget>& gadget) : m_gadget(move(gadget)) {}=
=20
> >       // Argument type changed from value to reference!=20
> > ...=20
> >=20
> > A client holding a 'nn_shared_ptr<Gadget>' and passing that to the=20
> > constructor of 'Widget' ends up with a null nn_shared_ptr. Even=20
> > without the modification, that is taking the argument by value, inside=
=20
> > the body of the constructor the argument 'gadget' is null.=20
> Your example is just asking for UB. If the referenced value is used=20
> after the move for anything other than destruction or assignment to then=
=20
> you have UB for any operations on that type with any kind of=20
> precondition. Accidentally modifying a reference instead of a copy can=20
> cause problems in a whole lot of cases, I don't see a point in special=20
> casing nn_shared_ptr.=20
>

I would also like to add that it is *exceedingly rude* to take a non-const=
=20
lvalue reference as a parameter and move from it. That's what rvalue=20
references are for.=20

>=20
> > I am with Andrew Tomazos here, references better reflect non-empty=20
> > pointers. I have not had the need to reseat a type with reference=20
> > semantics in a context where reference_wrapper was not the better=20
> > alternative, so I might be biased here.=20
> True for raw pointers, but the standard does currently not offer a way=20
> of saying "I want a non-null shared_ptr". A shared_ptr reference doesn't=
=20
> say anything about non-emptiness. That is a service the nn library is=20
> providing.
>

Yes, it's a service. But why is that a useful service? People want=20
intrusive pointers, so let's say we provide them. Then, people will want=20
"non-null" intrusive pointers. When does it end?

I'd much rather have actual language syntax for specifying a contract like=
=20
"non-null" than to have to double every pointer type with a "non-null"=20
equivalent.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<br><br>On Monday, August 24, 2015 at 5:48:32 PM UTC-4, Miro Knejp wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">Am 24.08.2015 um 10:34 schrieb D=
avid Rodr=C3=ADguez Ibeas:
<br>&gt; After seeing a couple of references to the nn library in dropbox I=
=20
<br>&gt; finally took a look at the implementation. The first thing to note=
 is=20
<br>&gt; that the library does not make any promises as of the pointer not=
=20
<br>&gt; being null at any time, it only provides protection against mistak=
enly=20
<br>&gt; setting it to a null value initially. Borrowing from their example=
 of use:
<br>&gt;
<br>&gt; class Widget {
<br>&gt; =C2=A0 =C2=A0 Widget(nn_shared_ptr&lt;Gadget&gt;&amp; gadget) : m_=
gadget(move(gadget)) {}
<br>&gt; =C2=A0 =C2=A0 =C2=A0 // Argument type changed from value to refere=
nce!
<br>&gt; ...
<br>&gt;
<br>&gt; A client holding a &#39;nn_shared_ptr&lt;Gadget&gt;&#39; and passi=
ng that to the=20
<br>&gt; constructor of &#39;Widget&#39; ends up with a null nn_shared_ptr.=
 Even=20
<br>&gt; without the modification, that is taking the argument by value, in=
side=20
<br>&gt; the body of the constructor the argument &#39;gadget&#39; is null.
<br>Your example is just asking for UB. If the referenced value is used=20
<br>after the move for anything other than destruction or assignment to the=
n=20
<br>you have UB for any operations on that type with any kind of=20
<br>precondition. Accidentally modifying a reference instead of a copy can=
=20
<br>cause problems in a whole lot of cases, I don&#39;t see a point in spec=
ial=20
<br>casing nn_shared_ptr.
<br></blockquote><div><br>I would also like to add that it is <i>exceedingl=
y rude</i> to take a non-const lvalue reference as a parameter and move fro=
m it. That&#39;s what rvalue references are for. <br><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;">&gt;
<br>&gt; I am with Andrew Tomazos here, references better reflect non-empty=
=20
<br>&gt; pointers. I have not had the need to reseat a type with reference=
=20
<br>&gt; semantics in a context where reference_wrapper was not the better=
=20
<br>&gt; alternative, so I might be biased here.
<br>True for raw pointers, but the standard does currently not offer a way=
=20
<br>of saying &quot;I want a non-null shared_ptr&quot;. A shared_ptr refere=
nce doesn&#39;t=20
<br>say anything about non-emptiness. That is a service the nn library is=
=20
<br>providing.<br></blockquote><div><br>Yes, it&#39;s a service. But why is=
 that a useful service? People want intrusive pointers, so let&#39;s say we=
 provide them. Then, people will want &quot;non-null&quot; intrusive pointe=
rs. When does it end?<br><br>I&#39;d much rather have actual language synta=
x for specifying a contract like &quot;non-null&quot; than to have to doubl=
e every pointer type with a &quot;non-null&quot; equivalent.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2760_448921298.1440453305194--
------=_Part_2759_60662346.1440453305194--

.

------=_Part_2193_1442925909.1440458355278
Content-Type: multipart/alternative;
 boundary="----=_Part_2194_578078004.1440458355278"

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

On Monday, August 24, 2015 at 2:55:05 PM UTC-7, Nicol Bolas wrote:
>
> On Monday, August 24, 2015 at 5:48:32 PM UTC-4, Miro Knejp wrote:
>>
>> Am 24.08.2015 um 10:34 schrieb David Rodr=C3=ADguez Ibeas:=20
>> > After seeing a couple of references to the nn library in dropbox I=20
>> > finally took a look at the implementation. The first thing to note is=
=20
>> > that the library does not make any promises as of the pointer not=20
>> > being null at any time, it only provides protection against mistakenly=
=20
>> > setting it to a null value initially. Borrowing from their example of=
=20
>> use:=20
>> >=20
>> > class Widget {=20
>> >     Widget(nn_shared_ptr<Gadget>& gadget) : m_gadget(move(gadget)) {}=
=20
>> >       // Argument type changed from value to reference!=20
>> > ...=20
>> >=20
>> > A client holding a 'nn_shared_ptr<Gadget>' and passing that to the=20
>> > constructor of 'Widget' ends up with a null nn_shared_ptr. Even=20
>> > without the modification, that is taking the argument by value, inside=
=20
>> > the body of the constructor the argument 'gadget' is null.=20
>> Your example is just asking for UB. If the referenced value is used=20
>> after the move for anything other than destruction or assignment to then=
=20
>> you have UB for any operations on that type with any kind of=20
>> precondition. Accidentally modifying a reference instead of a copy can=
=20
>> cause problems in a whole lot of cases, I don't see a point in special=
=20
>> casing nn_shared_ptr.=20
>>
>
> I would also like to add that it is *exceedingly rude* to take a=20
> non-const lvalue reference as a parameter and move from it. That's what=
=20
> rvalue references are for.=20
>

Hear hear! :)
=20

> Yes, it's a service. But why is that a useful service? People want=20
> intrusive pointers, so let's say we provide them. Then, people will want=
=20
> "non-null" intrusive pointers. When does it end?
>
> I'd much rather have actual language syntax for specifying a contract lik=
e=20
> "non-null" than to have to double every pointer type with a "non-null"=20
> equivalent.
>

Isn't it roughly analogous to "atomic-ness" in that respect? Someone wants=
=20
an "atomic" int, so we add std::atomic_int; then someone wants an "atomic"=
=20
bool, so we add std::atomic_bool; then...
But eventually we solve the general problem by providing std::atomic<T> as=
=20
a template, and then all the "doubled" types can go away and we have what=
=20
we wanted at the beginning: a simple way of specifying the atomic variety=
=20
of any type T.
So I would expect the same progression here: all you need is a template=20
nn<T>, and then you can have a non-null raw pointer nn<int*>, or a non-null=
=20
smart pointer nn<std::shared_ptr<int>>, or a non-null intrusive pointer=20
nn<IntrusivePtr<T>>, or whatever. You have a simple way of specifying the=
=20
non-null variety of any type T.
I haven't looked at the nn docs myself, but I'm going to a lightning talk=
=20
on nn tonight, so I'll know more in a couple of hours. :)
http://www.meetup.com/SF-Bay-Area-Cpp/events/224548018/

=E2=80=93Arthur

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

On Monday, August 24, 2015 at 2:55:05 PM UTC-7, Nicol Bolas wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;">On Monday, August 24, 2015 at 5:48:32 P=
M UTC-4, Miro Knejp wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Am 24.08.=
2015 um 10:34 schrieb David Rodr=C3=ADguez Ibeas:
<br>&gt; After seeing a couple of references to the nn library in dropbox I=
=20
<br>&gt; finally took a look at the implementation. The first thing to note=
 is=20
<br>&gt; that the library does not make any promises as of the pointer not=
=20
<br>&gt; being null at any time, it only provides protection against mistak=
enly=20
<br>&gt; setting it to a null value initially. Borrowing from their example=
 of use:
<br>&gt;
<br>&gt; class Widget {
<br>&gt; =C2=A0 =C2=A0 Widget(nn_shared_ptr&lt;Gadget&gt;&amp; gadget) : m_=
gadget(move(gadget)) {}
<br>&gt; =C2=A0 =C2=A0 =C2=A0 // Argument type changed from value to refere=
nce!
<br>&gt; ...
<br>&gt;
<br>&gt; A client holding a &#39;nn_shared_ptr&lt;Gadget&gt;&#39; and passi=
ng that to the=20
<br>&gt; constructor of &#39;Widget&#39; ends up with a null nn_shared_ptr.=
 Even=20
<br>&gt; without the modification, that is taking the argument by value, in=
side=20
<br>&gt; the body of the constructor the argument &#39;gadget&#39; is null.
<br>Your example is just asking for UB. If the referenced value is used=20
<br>after the move for anything other than destruction or assignment to the=
n=20
<br>you have UB for any operations on that type with any kind of=20
<br>precondition. Accidentally modifying a reference instead of a copy can=
=20
<br>cause problems in a whole lot of cases, I don&#39;t see a point in spec=
ial=20
<br>casing nn_shared_ptr.
<br></blockquote><div><br>I would also like to add that it is <i>exceedingl=
y rude</i> to take a non-const lvalue reference as a parameter and move fro=
m it. That&#39;s what rvalue references are for. <br></div></blockquote><di=
v><br></div><div>Hear hear! :)</div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div>Yes, it&#39;s a service. But why is that a usef=
ul service? People want intrusive pointers, so let&#39;s say we provide the=
m. Then, people will want &quot;non-null&quot; intrusive pointers. When doe=
s it end?<br></div><div><br>I&#39;d much rather have actual language syntax=
 for specifying a contract like &quot;non-null&quot; than to have to double=
 every pointer type with a &quot;non-null&quot; equivalent.<br></div></bloc=
kquote><div><br></div><div>Isn&#39;t it roughly analogous to &quot;atomic-n=
ess&quot; in that respect? Someone wants an &quot;atomic&quot; int, so we a=
dd std::atomic_int; then someone wants an &quot;atomic&quot; bool, so we ad=
d std::atomic_bool; then...</div><div>But eventually we solve the general p=
roblem by providing std::atomic&lt;T&gt; as a template, and then all the &q=
uot;doubled&quot; types can go away and we have what we wanted at the begin=
ning: a simple way of specifying the atomic variety of any type T.</div><di=
v>So I would expect the same progression here: all you need is a template n=
n&lt;T&gt;, and then you can have a non-null raw pointer <font face=3D"cour=
ier new, monospace">nn&lt;int*&gt;</font>, or a non-null smart pointer <fon=
t face=3D"courier new, monospace">nn&lt;std::shared_ptr&lt;int&gt;&gt;</fon=
t>, or a non-null intrusive pointer <font face=3D"courier new, monospace">n=
n&lt;IntrusivePtr&lt;T&gt;&gt;</font>, or whatever. You have a simple way o=
f specifying the non-null variety of any type T.</div><div>I haven&#39;t lo=
oked at the nn docs myself, but I&#39;m going to a lightning talk on nn ton=
ight, so I&#39;ll know more in a couple of hours. :)</div><div><a href=3D"h=
ttp://www.meetup.com/SF-Bay-Area-Cpp/events/224548018/">http://www.meetup.c=
om/SF-Bay-Area-Cpp/events/224548018/<br></a></div><div><br></div><div>=E2=
=80=93Arthur</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2194_578078004.1440458355278--
------=_Part_2193_1442925909.1440458355278--

.

------=_Part_1122_1814361645.1440459762939
Content-Type: multipart/alternative;
 boundary="----=_Part_1123_474277865.1440459762939"

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



On Monday, August 24, 2015 at 7:19:15 PM UTC-4, Arthur O'Dwyer wrote:
>
> On Monday, August 24, 2015 at 2:55:05 PM UTC-7, Nicol Bolas wrote:
>>
>> On Monday, August 24, 2015 at 5:48:32 PM UTC-4, Miro Knejp wrote:
>>>
>>> Am 24.08.2015 um 10:34 schrieb David Rodr=C3=ADguez Ibeas:=20
>>> > After seeing a couple of references to the nn library in dropbox I=20
>>> > finally took a look at the implementation. The first thing to note is=
=20
>>> > that the library does not make any promises as of the pointer not=20
>>> > being null at any time, it only provides protection against mistakenl=
y=20
>>> > setting it to a null value initially. Borrowing from their example of=
=20
>>> use:=20
>>> >=20
>>> > class Widget {=20
>>> >     Widget(nn_shared_ptr<Gadget>& gadget) : m_gadget(move(gadget)) {}=
=20
>>> >       // Argument type changed from value to reference!=20
>>> > ...=20
>>> >=20
>>> > A client holding a 'nn_shared_ptr<Gadget>' and passing that to the=20
>>> > constructor of 'Widget' ends up with a null nn_shared_ptr. Even=20
>>> > without the modification, that is taking the argument by value, insid=
e=20
>>> > the body of the constructor the argument 'gadget' is null.=20
>>> Your example is just asking for UB. If the referenced value is used=20
>>> after the move for anything other than destruction or assignment to the=
n=20
>>> you have UB for any operations on that type with any kind of=20
>>> precondition. Accidentally modifying a reference instead of a copy can=
=20
>>> cause problems in a whole lot of cases, I don't see a point in special=
=20
>>> casing nn_shared_ptr.=20
>>>
>>
>> I would also like to add that it is *exceedingly rude* to take a=20
>> non-const lvalue reference as a parameter and move from it. That's what=
=20
>> rvalue references are for.=20
>>
>
> Hear hear! :)
> =20
>
>> Yes, it's a service. But why is that a useful service? People want=20
>> intrusive pointers, so let's say we provide them. Then, people will want=
=20
>> "non-null" intrusive pointers. When does it end?
>>
>> I'd much rather have actual language syntax for specifying a contract=20
>> like "non-null" than to have to double every pointer type with a "non-nu=
ll"=20
>> equivalent.
>>
>
> Isn't it roughly analogous to "atomic-ness" in that respect? Someone want=
s=20
> an "atomic" int, so we add std::atomic_int; then someone wants an "atomic=
"=20
> bool, so we add std::atomic_bool; then...
> But eventually we solve the general problem by providing std::atomic<T> a=
s=20
> a template, and then all the "doubled" types can go away and we have what=
=20
> we wanted at the beginning: a simple way of specifying the atomic variety=
=20
> of any type T.
> So I would expect the same progression here: all you need is a template=
=20
> nn<T>, and then you can have a non-null raw pointer nn<int*>, or a=20
> non-null smart pointer nn<std::shared_ptr<int>>, or a non-null intrusive=
=20
> pointer nn<IntrusivePtr<T>>, or whatever. You have a simple way of=20
> specifying the non-null variety of any type T.
> I haven't looked at the nn docs myself, but I'm going to a lightning talk=
=20
> on nn tonight, so I'll know more in a couple of hours. :)
> http://www.meetup.com/SF-Bay-Area-Cpp/events/224548018/
>

The difference is that you generally do not inflict atomics on other=20
people. You use atomic types internally; you don't generally take them as=
=20
parameters, and therefore do not require others to directly use them.=20
Atomic types, however useful, are also exceedingly rare.

Whereas pointers are quite common. So if my interface takes a=20
nn<shared_ptr<T>>, then that means you have to create one. So either you're=
=20
using one yourself, or you have to do a conversion, which may potentially=
=20
throw.

The other thing is that nn<T> doesn't really work very well. It would have=
=20
to assume a very great deal about the type. You have to define some kind of=
=20
"pointer-like" concept for it, which all pointers would have to satisfy.

Whereas std::atomic has far fewer requirements on T.

And again, I would point out that contracts basically eliminates the need=
=20
for this. So I'd rather we get a feature that does the full job than a=20
bunch of half-measures that will become obsolete once the real thing is=20
done.

Remember std::bind.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<br><br>On Monday, August 24, 2015 at 7:19:15 PM UTC-4, Arthur O&#39;Dwyer =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Monday, August 24, 20=
15 at 2:55:05 PM UTC-7, Nicol Bolas wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">On Monday, August 24, 2015 at 5:48:32 PM UTC-4, Miro Knejp wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">Am 24.08.2015 um 10:34 schrieb David R=
odr=C3=ADguez Ibeas:
<br>&gt; After seeing a couple of references to the nn library in dropbox I=
=20
<br>&gt; finally took a look at the implementation. The first thing to note=
 is=20
<br>&gt; that the library does not make any promises as of the pointer not=
=20
<br>&gt; being null at any time, it only provides protection against mistak=
enly=20
<br>&gt; setting it to a null value initially. Borrowing from their example=
 of use:
<br>&gt;
<br>&gt; class Widget {
<br>&gt; =C2=A0 =C2=A0 Widget(nn_shared_ptr&lt;Gadget&gt;&amp; gadget) : m_=
gadget(move(gadget)) {}
<br>&gt; =C2=A0 =C2=A0 =C2=A0 // Argument type changed from value to refere=
nce!
<br>&gt; ...
<br>&gt;
<br>&gt; A client holding a &#39;nn_shared_ptr&lt;Gadget&gt;&#39; and passi=
ng that to the=20
<br>&gt; constructor of &#39;Widget&#39; ends up with a null nn_shared_ptr.=
 Even=20
<br>&gt; without the modification, that is taking the argument by value, in=
side=20
<br>&gt; the body of the constructor the argument &#39;gadget&#39; is null.
<br>Your example is just asking for UB. If the referenced value is used=20
<br>after the move for anything other than destruction or assignment to the=
n=20
<br>you have UB for any operations on that type with any kind of=20
<br>precondition. Accidentally modifying a reference instead of a copy can=
=20
<br>cause problems in a whole lot of cases, I don&#39;t see a point in spec=
ial=20
<br>casing nn_shared_ptr.
<br></blockquote><div><br>I would also like to add that it is <i>exceedingl=
y rude</i> to take a non-const lvalue reference as a parameter and move fro=
m it. That&#39;s what rvalue references are for. <br></div></blockquote><di=
v><br></div><div>Hear hear! :)</div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div>Yes, it&#39;s a service. But why is that a useful se=
rvice? People want intrusive pointers, so let&#39;s say we provide them. Th=
en, people will want &quot;non-null&quot; intrusive pointers. When does it =
end?<br></div><div><br>I&#39;d much rather have actual language syntax for =
specifying a contract like &quot;non-null&quot; than to have to double ever=
y pointer type with a &quot;non-null&quot; equivalent.<br></div></blockquot=
e><div><br></div><div>Isn&#39;t it roughly analogous to &quot;atomic-ness&q=
uot; in that respect? Someone wants an &quot;atomic&quot; int, so we add st=
d::atomic_int; then someone wants an &quot;atomic&quot; bool, so we add std=
::atomic_bool; then...</div><div>But eventually we solve the general proble=
m by providing std::atomic&lt;T&gt; as a template, and then all the &quot;d=
oubled&quot; types can go away and we have what we wanted at the beginning:=
 a simple way of specifying the atomic variety of any type T.</div><div>So =
I would expect the same progression here: all you need is a template nn&lt;=
T&gt;, and then you can have a non-null raw pointer <font face=3D"courier n=
ew, monospace">nn&lt;int*&gt;</font>, or a non-null smart pointer <font fac=
e=3D"courier new, monospace">nn&lt;std::shared_ptr&lt;int&gt;&gt;</font>, o=
r a non-null intrusive pointer <font face=3D"courier new, monospace">nn&lt;=
IntrusivePtr&lt;T&gt;&gt;</font>, or whatever. You have a simple way of spe=
cifying the non-null variety of any type T.</div><div>I haven&#39;t looked =
at the nn docs myself, but I&#39;m going to a lightning talk on nn tonight,=
 so I&#39;ll know more in a couple of hours. :)</div><div><a href=3D"http:/=
/www.meetup.com/SF-Bay-Area-Cpp/events/224548018/" target=3D"_blank" rel=3D=
"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\75ht=
tp%3A%2F%2Fwww.meetup.com%2FSF-Bay-Area-Cpp%2Fevents%2F224548018%2F\46sa\75=
D\46sntz\0751\46usg\75AFQjCNGOK813Kl9R6Ktlg2FbKCPIL52MsA&#39;;return true;"=
 onclick=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww=
..meetup.com%2FSF-Bay-Area-Cpp%2Fevents%2F224548018%2F\46sa\75D\46sntz\0751\=
46usg\75AFQjCNGOK813Kl9R6Ktlg2FbKCPIL52MsA&#39;;return true;">http://www.me=
etup.com/SF-Bay-<wbr>Area-Cpp/events/224548018/<br></a></div></blockquote><=
div><br>The difference is that you generally do not inflict atomics on othe=
r people. You use atomic types internally; you don&#39;t generally take the=
m as parameters, and therefore do not require others to directly use them. =
Atomic types, however useful, are also exceedingly rare.<br><br>Whereas poi=
nters are quite common. So if my interface takes a nn&lt;shared_ptr&lt;T&gt=
;&gt;, then that means you have to create one. So either you&#39;re using o=
ne yourself, or you have to do a conversion, which may potentially throw.<b=
r><br>The other thing is that nn&lt;T&gt; doesn&#39;t really work very well=
.. It would have to assume a very great deal about the type. You have to def=
ine some kind of &quot;pointer-like&quot; concept for it, which all pointer=
s would have to satisfy.<br><br>Whereas std::atomic has far fewer requireme=
nts on T.<br><br>And again, I would point out that contracts basically elim=
inates the need for this. So I&#39;d rather we get a feature that does the =
full job than a bunch of half-measures that will become obsolete once the r=
eal thing is done.<br><br>Remember std::bind.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1123_474277865.1440459762939--
------=_Part_1122_1814361645.1440459762939--

.

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

On Mon, Aug 24, 2015 at 4:19 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:
>
> So I would expect the same progression here: all you need is a template
> nn<T>, and then you can have a non-null raw pointer nn<int*>, or a
> non-null smart pointer nn<std::shared_ptr<int>>, or a non-null intrusive
> pointer nn<IntrusivePtr<T>>, or whatever. You have a simple way of
> specifying the non-null variety of any type T.
> I haven't looked at the nn docs myself, but I'm going to a lightning talk
> on nn tonight, so I'll know more in a couple of hours. :)
>

Just a thought, as this ship has in some ways already sailed for the
language/libraries, but I'd like to raise the notion that instead of having
a non-null template, it probably would have been better if we could have
taken the opposite approach (maybe there is still some way that we can move
toward this in the long term, but I don't have high hopes for that). By
this I mean it would have been nice to have started with never-null
pointers, and then we would have gotten the "nullable" version simply by
way of the proposed std::optional<>. With proper specification and hooks,
an optional<non_null_pointer> can directly hold our current pointer type
and no separate discriminator, using the current null value to represent
the empty state of the optional. Even without hooks, the optional<> version
would still work, just like it does for other types, it would just be less
efficient than if the hooks were present. Similar kinds of customizations
could be used with user-defined types that can be made efficiently
nullable, such as the smart pointer types.

I find this a better alternative than making a "nonnull" template since all
instantiable types in C++ have "non-null" state by the very nature of them
being constructed (even types with no members). On the other hand, not all
types have the notion of a "null" state, where for the sake of discussion a
"null" state is some state or set of states that may be able to be
represented in the object's storage but that isn't a valid value for that
type. optional<T> makes sense for all instantiable T types and can come up
in generic code when you wish to possibly contain an instance of T. On the
other hand, nonnull is a little more unique to types that have such a
"null" state, and more commonly comes up in non-generic code where the user
wishes to enforce strict invariants. It would be nice if all of our types
had very strict invariants (never null) by their nature and we only ever
*extend* the set of possible states via a template, as opposed to using a
template to reduce those states.

Starting with non-nullable types has other tangible advantages. For one,
it's generally easier to implement most functions that operate on a
non-nullable type, since the invariants are more strict. An example of this
is a reference-counted smart pointer -- if you know for a fact that you are
always pointing to something while you hold an instance of the smart
pointer type, the implementation doesn't even have to do any branching
before incrementing or decrementing the reference count. That added
complexity in implementation only comes about when implementing a
"nullable" smart pointer. An optional<ref_counted_ptr> would be sufficient
to represent a nullable smart pointer without complicating the
ref_counted_ptr implementation itself at all, and if the optional<> version
needed to be optimal, it could always be hooked into in some manner. Even
if hooked into, implementing those hooks for null could conceivably be
simpler than implementing a nullable type from scratch, since the branching
required for things like copy/assign/destruction (again, think of reference
counting as an example) remains completely isolated in the optional<>
implementation itself. The hooks would conceivably only need to be able to
identify and place the object into the null state. On the other hand, with
a non_null template and types that are initially "nullable", the developer
of the nullable type would start by implementing a more-complicated
"nullable" version of a type, and then use a wrapper to prevent the null
state. This has two unfortunate implications. For one, it means that the
initial implementation of the type is more complicated since it generally
needs to be explicitly aware of the null state, and secondly, any branching
around the null state would also be present in the "non-null" version,
since the non-null version would just wrap the nullable version. In short,
IMO, we designed things backwards and are now paying for it.

Anyway, those are just my thoughts on the current state of things. I
strongly believe that the supposed need for a non-null template is just an
artifact of a less-than-desirable design decision early on. That said, it's
likely too late to change things.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Aug 24, 2015 at 4:19 PM, Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@g=
mail.com</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>So I woul=
d expect the same progression here: all you need is a template nn&lt;T&gt;,=
 and then you can have a non-null raw pointer <font face=3D"courier new, mo=
nospace">nn&lt;int*&gt;</font>, or a non-null smart pointer <font face=3D"c=
ourier new, monospace">nn&lt;std::shared_ptr&lt;int&gt;&gt;</font>, or a no=
n-null intrusive pointer <font face=3D"courier new, monospace">nn&lt;Intrus=
ivePtr&lt;T&gt;&gt;</font>, or whatever. You have a simple way of specifyin=
g the non-null variety of any type T.</div><div>I haven&#39;t looked at the=
 nn docs myself, but I&#39;m going to a lightning talk on nn tonight, so I&=
#39;ll know more in a couple of hours. :)</div></blockquote><div><br></div>=
<div>Just a thought, as this ship has in some ways already sailed for the l=
anguage/libraries, but I&#39;d like to raise the notion that instead of hav=
ing a non-null template, it probably would have been better if we could hav=
e taken the opposite approach (maybe there is still some way that we can mo=
ve toward this in the long term, but I don&#39;t have high hopes for that).=
 By this I mean it would have been nice to have started with never-null poi=
nters, and then we would have gotten the &quot;nullable&quot; version simpl=
y by way of the proposed std::optional&lt;&gt;. With proper specification a=
nd hooks, an optional&lt;non_null_pointer&gt; can directly hold our current=
 pointer type and no separate discriminator, using the current null value t=
o represent the empty state of the optional. Even without hooks, the option=
al&lt;&gt; version would still work, just like it does for other types, it =
would just be less efficient than if the hooks were present. Similar kinds =
of customizations could be used with user-defined types that can be made ef=
ficiently nullable, such as the smart pointer types.</div><div><br></div><d=
iv>I find this a better alternative than making a &quot;nonnull&quot; templ=
ate since all instantiable types in C++ have &quot;non-null&quot; state by =
the very nature of them being constructed (even types with no members). On =
the other hand, not all types have the notion of a &quot;null&quot; state, =
where for the sake of discussion a &quot;null&quot; state is some state or =
set of states that may be able to be represented in the object&#39;s storag=
e but that isn&#39;t a valid value for that type. optional&lt;T&gt; makes s=
ense for all instantiable T types and can come up in generic code when you =
wish to possibly contain an instance of T. On the other hand, nonnull is a =
little more unique to types that have such a &quot;null&quot; state, and mo=
re commonly comes up in non-generic code where the user wishes to enforce s=
trict invariants. It would be nice if all of our types had very strict inva=
riants (never null) by their nature and we only ever *extend* the set of po=
ssible states via a template, as opposed to using a template to reduce thos=
e states.</div><div><br></div><div>Starting with non-nullable types has oth=
er tangible advantages. For one, it&#39;s generally easier to implement mos=
t functions that operate on a non-nullable type, since the invariants are m=
ore strict. An example of this is a reference-counted smart pointer -- if y=
ou know for a fact that you are always pointing to something while you hold=
 an instance of the smart pointer type, the implementation doesn&#39;t even=
 have to do any branching before incrementing or decrementing the reference=
 count. That added complexity in implementation only comes about when imple=
menting a &quot;nullable&quot; smart pointer. An optional&lt;ref_counted_pt=
r&gt; would be sufficient to represent a nullable smart pointer without com=
plicating the ref_counted_ptr implementation itself at all, and if the opti=
onal&lt;&gt; version needed to be optimal, it could always be hooked into i=
n some manner. Even if hooked into, implementing those hooks for null could=
 conceivably be simpler than implementing a nullable type from scratch, sin=
ce the branching required for things like copy/assign/destruction (again, t=
hink of reference counting as an example) remains completely isolated in th=
e optional&lt;&gt; implementation itself. The hooks would conceivably only =
need to be able to identify and place the object into the null state. On th=
e other hand, with a non_null template and types that are initially &quot;n=
ullable&quot;, the developer of the nullable type would start by implementi=
ng a more-complicated &quot;nullable&quot; version of a type, and then use =
a wrapper to prevent the null state. This has two unfortunate implications.=
 For one, it means that the initial implementation of the type is more comp=
licated since it generally needs to be explicitly aware of the null state, =
and secondly, any branching around the null state would also be present in =
the &quot;non-null&quot; version, since the non-null version would just wra=
p the nullable version. In short, IMO, we designed things backwards and are=
 now paying for it.</div><div><br></div><div>Anyway, those are just my thou=
ghts on the current state of things. I strongly believe that the supposed n=
eed for a non-null template is just an artifact of a less-than-desirable de=
sign decision early on. That said, it&#39;s likely too late to change thing=
s.</div><div><br></div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113cd41acef5ff051e17cbd1--

.

--089e013a2afa450ef3051e17d002
Content-Type: text/plain; charset=UTF-8

On Mon, Aug 24, 2015 at 5:27 PM, Matt Calabrese <calabrese@google.com>
wrote:
>
> Anyway, those are just my thoughts on the current state of things. I
> strongly believe that the supposed need for a non-null template is just an
> artifact of a less-than-desirable design decision early on. That said, it's
> likely too late to change things.
>

Also note that without destructive move, starting with non-null isn't quite
feasible in practice.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Aug 24, 2015 at 5:27 PM, Matt Calabrese <span dir=3D"ltr">&lt;<a href=
=3D"mailto:calabrese@google.com" target=3D"_blank">calabrese@google.com</a>=
&gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><div>Anyway, those are just my=
 thoughts on the current state of things. I strongly believe that the suppo=
sed need for a non-null template is just an artifact of a less-than-desirab=
le design decision early on. That said, it&#39;s likely too late to change =
things.</div></div></div></div></blockquote><div><br></div><div>Also note t=
hat without destructive move, starting with non-null isn&#39;t quite feasib=
le in practice.=C2=A0</div></div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e013a2afa450ef3051e17d002--

.

Am 25.08.2015 um 01:42 schrieb Nicol Bolas:
> Whereas pointers are quite common. So if my interface takes a
> nn<shared_ptr<T>>, then that means you have to create one. So either
> you're using one yourself, or you have to do a conversion, which may
> potentially throw.
It doesn't necessarily have to throw. A precondition doesn't have to be
checked if it is already met before constructing nn<shared_ptr<T>>. I am
against checking preconditions in constructors of these utlity types
because that usually leads to gratuitous checking in places where it
isn't necessary. The nn<T> type has a constructor nn(T,
i_promise_i_checked_for_null_t) which is verbose and self-documenting
enough that it's mere presence in code should serve its purpose.

The point of contracts is not always to be checked and enforced at
runtime but rather by the type system or static analysis where possible,
or simply to remind people of their existence.

The important point here is that there is something encoded in the
signature of a function that reminds one of a contract and cannot be
easily ignored. The time it takes one to type out "nn<shared_ptr<T>>"
might be enough to make one re-think of why it is necessary to do that.
As David said, it may eliminate accidental misuses, which is a big plus
in my world.
>
> The other thing is that nn<T> doesn't really work very well. It would
> have to assume a very great deal about the type. You have to define
> some kind of "pointer-like" concept for it, which all pointers would
> have to satisfy.
It actually does work very well, that's why people use it. Every
template type has to assume *something* about its template parameters.
That is part of its interface. Is "a very great deal" the result of your
professional analysis or just a guess? We have
http://en.cppreference.com/w/cpp/concept/NullablePointer as a solid
starting point.
>
> Whereas std::atomic has far fewer requirements on T.
How can you know it has "far fewer" requirements when you haven't yet
specified the requirements nn has on T? std::atomic requires a
TriviallyCopyable type, which has a whole laundry list of requirements
attached to it.
>
> And again, I would point out that contracts basically eliminates the
> need for this. So I'd rather we get a feature that does the full job
> than a bunch of half-measures that will become obsolete once the real
> thing is done.
>
> Remember std::bind.
If contracts make it into C++17 I totally agree, but if not then
something like the nn library has a much lower barrier of entry in my
oppinion and could make it into the next revision so there is at least
*something* to bridge the gap until C++2x. As far as I know std::bind
exists because it took over a decade to get C++11 done and too many
features/people came and went.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Mon, Aug 24, 2015 at 10:55 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> I would also like to add that it is *exceedingly rude* to take a
> non-const lvalue reference as a parameter and move from it. That's what
> rvalue references are for.
>
>
Completely agree, the only point I was trying to raise is that the nn type
(and possibly Johannes suggestion, depending on how that would be rendered)
does *not* provide the guarantee at the type-system level. Compare this
with the use of a reference, which is guaranteed by the language.

    David

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Aug 24, 2015 at 10:55 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div>I would also like to ad=
d that it is <i>exceedingly rude</i> to take a non-const lvalue reference a=
s a parameter and move from it. That&#39;s what rvalue references are for. =
<br><br></div></blockquote><div><br>Completely agree, the only point I was =
trying to raise is that the nn type (and possibly Johannes suggestion, depe=
nding on how that would be rendered) does *not* provide the guarantee at th=
e type-system level. Compare this with the use of a reference, which is gua=
ranteed by the language.<br><br>=C2=A0 =C2=A0 David</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11340d7a938875051e1f744a--

.

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

On Mon, Aug 24, 2015 at 10:49 PM, Miro Knejp <miro.knejp@gmail.com> wrote:

> Your example is just asking for UB. If the referenced value is used after
> the move for anything other than destruction or assignment to then you have
> UB for any operations on that type with any kind of precondition.


This is exactly the point, there is a precondition on the use of nn<>
pointers that they are not null, but because the type name seems to promise
that it won't ever be null chances are that anyone dealing with an nn<>
would not test for null-ness.

My point is that the type-system (with that definition of nn<>) cannot
promise that the pointer won't be null, but users may be caught off-guard
thinking "how could a non-null pointer ever be null?"

Whenever an owning non-null pointer is used, either ownership is shared
(nn<shared_ptr>) or you cannot at the same time use the type on an
interface and guarantee that it won't be null ever. There will be cases
where you end up with an empty moved-from non-null pointer.

I do understand the value of something like this in a library to reduce
errors, in the same way that some coding standards place additional
constrains on programs (naming conventions, function signatures...) but I
just don't see them belonging in the standard.

    David

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11340d7a4eb394051e1f8e59
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 Mon, Aug 24, 2015 at 10:49 PM, Miro Knejp <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:miro.knejp@gmail.com" target=3D"_blank">miro.knejp@gmail.com<=
/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Your example is jus=
t asking for UB. If the referenced value is used after the move for anythin=
g other than destruction or assignment to then you have UB for any operatio=
ns on that type with any kind of precondition. </blockquote><div><br></div>=
<div>This is exactly the point, there is a precondition on the use of nn&lt=
;&gt; pointers that they are not null, but because the type name seems to p=
romise that it won&#39;t ever be null chances are that anyone dealing with =
an nn&lt;&gt; would not test for null-ness.<br><br>My point is that the typ=
e-system (with that definition of nn&lt;&gt;) cannot promise that the point=
er won&#39;t be null, but users may be caught off-guard thinking &quot;how =
could a non-null pointer ever be null?&quot;<br></div><div><br>Whenever an =
owning non-null pointer is used, either ownership is shared (nn&lt;shared_p=
tr&gt;) or you cannot at the same time use the type on an interface and gua=
rantee that it won&#39;t be null ever. There will be cases where you end up=
 with an empty moved-from non-null pointer.<br><br>I do understand the valu=
e of something like this in a library to reduce errors, in the same way tha=
t some coding standards place additional constrains on programs (naming con=
ventions, function signatures...) but I just don&#39;t see them belonging i=
n the standard.<br><br>=C2=A0 =C2=A0 David</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11340d7a4eb394051e1f8e59--

.