------=_Part_18_391662637.1534566942436
Content-Type: multipart/alternative;
 boundary="----=_Part_19_1630580917.1534566942436"

------=_Part_19_1630580917.1534566942436
Content-Type: text/plain; charset="UTF-8"

After learning Rust for about a month I came across a typical problem in my
C++ job (and today I wanted to solve it). Basically I thought there should
be a way for the compiler to enforce a maybe null valued pointer is valid
before it is de-referenced (similar to Rust's Option type). Subsequently I
came up with the linked class template but it struck me this this was a
very common problem so I have made an implementation and started to make a
standards proposal.

The proposal is basically a template which wraps a pointer, or smart
pointer. It then has many of the accessors of the pointer but in particular
it doesn't have the unsafe to de-reference ones like (operator*,
operator->, get()). Instead to access the pointee you use a call or call_or
method and provide a function object where the parameter
matches the pointee type (by reference or const reference). The lambda is
then only invoked if the pointer is valid.

For pointers wrapped in this template (while they are wrapped in the
template) you can be sure the program checked the pointer before
de-reference if it compiles.

Anyway, so far its posted here,
https://github.com/niccroad/ptr_guard

Note, I wrote this from scratch its in no way connected to the
implementation of this concept I wrote for my work place.




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

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

<div dir=3D"ltr">After learning Rust for about a month I came across a typi=
cal problem in my C++ job (and today I wanted to solve it). Basically I tho=
ught there should be a way for the compiler to enforce a maybe null valued =
pointer is valid before it is de-referenced (similar to Rust&#39;s Option t=
ype). Subsequently I came up with the linked class template but it struck m=
e this this was a very common problem so I have made an implementation and =
started to make a standards proposal.<div><br></div><div>The proposal is ba=
sically a template which wraps a pointer, or smart pointer. It then has man=
y of the accessors of the pointer but in particular it doesn&#39;t have the=
 unsafe to de-reference ones like (operator*, operator-&gt;, get()). Instea=
d to access the pointee you use a call or call_or method and provide a func=
tion object where the parameter</div><div>matches the pointee type (by refe=
rence or const reference). The lambda is then only invoked if the pointer i=
s valid.</div><div><br></div><div>For pointers wrapped in this template (wh=
ile they are wrapped in the template) you can be sure the program checked t=
he pointer before de-reference if it compiles.</div><div><br></div><div>Any=
way, so far its posted here,</div><div>https://github.com/niccroad/ptr_guar=
d<br></div><div><br></div><div>Note, I wrote this from scratch its in no wa=
y connected to the implementation of this concept I wrote for my work place=
..</div><div><br></div><div><br></div><div><br></div><div><br></div></div>

<p></p>

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

------=_Part_19_1630580917.1534566942436--

------=_Part_18_391662637.1534566942436--

.

------=_Part_1117_281746749.1534587769749
Content-Type: multipart/alternative;
 boundary="----=_Part_1118_1554131442.1534587769749"

------=_Part_1118_1554131442.1534587769749
Content-Type: text/plain; charset="UTF-8"

C++ already has non-nullable pointers, they are called references. In your
programs, wherever you expect non-nullable pointer, you should use a
reference. If you expect a nullable pointer, i.e. null has meaning, then
use pointers and explicitly check for null. You also have this thingy
std::reference_wrapper which acts as a reassignable, but still non nullable
reference.

From what I see, this proposed solution has 2 issues:

   1. You pay the overhead of checking for null on every call to call() or
   call_or(). This may or may not be optimized away.
   2. It is not clear for the reader of the code if the function passed to
   call() will get called.


On Saturday, August 18, 2018 at 6:35:42 AM UTC+2, NicTheNZer wrote:
>
> After learning Rust for about a month I came across a typical problem in
> my C++ job (and today I wanted to solve it). Basically I thought there
> should be a way for the compiler to enforce a maybe null valued pointer is
> valid before it is de-referenced (similar to Rust's Option type).
> Subsequently I came up with the linked class template but it struck me this
> this was a very common problem so I have made an implementation and started
> to make a standards proposal.
>
> The proposal is basically a template which wraps a pointer, or smart
> pointer. It then has many of the accessors of the pointer but in particular
> it doesn't have the unsafe to de-reference ones like (operator*,
> operator->, get()). Instead to access the pointee you use a call or call_or
> method and provide a function object where the parameter
> matches the pointee type (by reference or const reference). The lambda is
> then only invoked if the pointer is valid.
>
> For pointers wrapped in this template (while they are wrapped in the
> template) you can be sure the program checked the pointer before
> de-reference if it compiles.
>
> Anyway, so far its posted here,
> https://github.com/niccroad/ptr_guard
>
> Note, I wrote this from scratch its in no way connected to the
> implementation of this concept I wrote for my work place.
>
>
>
>
>

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

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

<div dir=3D"ltr"><div>C++ already has non-nullable pointers, they are calle=
d references. In your programs, wherever you expect non-nullable pointer, y=
ou should use a reference. If you expect a nullable pointer, i.e. null has =
meaning, then use pointers and explicitly check for null. You also have thi=
s thingy <span style=3D"font-family: courier new, monospace;">std::referenc=
e_wrapper<font face=3D"arial,sans-serif"> which acts as a reassignable, but=
 still non nullable reference.</font></span><br></div><div><br></div><div>F=
rom what I see, this proposed solution has 2 issues:</div><div><ol><li>You =
pay the overhead of checking for null on every call to <span style=3D"font-=
family: courier new, monospace;">call() <span style=3D"font-family: arial, =
sans-serif;">or</span> call_or(). <font face=3D"arial,sans-serif">This may =
or may not be optimized away.</font><br></span></li><li><span style=3D"font=
-family: courier new, monospace;"><font face=3D"arial,sans-serif">It is not=
 clear for the reader of the code if the function </font>passed to </span><=
span style=3D"font-family: courier new, monospace;"><span style=3D"font-fam=
ily: courier new, monospace;">call()<font face=3D"arial,sans-serif"> will g=
et called.</font><br></span></span></li></ol></div><br>On Saturday, August =
18, 2018 at 6:35:42 AM UTC+2, NicTheNZer wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr">After learning Rust for about a month I c=
ame across a typical problem in my C++ job (and today I wanted to solve it)=
.. Basically I thought there should be a way for the compiler to enforce a m=
aybe null valued pointer is valid before it is de-referenced (similar to Ru=
st&#39;s Option type). Subsequently I came up with the linked class templat=
e but it struck me this this was a very common problem so I have made an im=
plementation and started to make a standards proposal.<div><br></div><div>T=
he proposal is basically a template which wraps a pointer, or smart pointer=
.. It then has many of the accessors of the pointer but in particular it doe=
sn&#39;t have the unsafe to de-reference ones like (operator*, operator-&gt=
;, get()). Instead to access the pointee you use a call or call_or method a=
nd provide a function object where the parameter</div><div>matches the poin=
tee type (by reference or const reference). The lambda is then only invoked=
 if the pointer is valid.</div><div><br></div><div>For pointers wrapped in =
this template (while they are wrapped in the template) you can be sure the =
program checked the pointer before de-reference if it compiles.</div><div><=
br></div><div>Anyway, so far its posted here,</div><div><a href=3D"https://=
github.com/niccroad/ptr_guard" target=3D"_blank" rel=3D"nofollow" onmousedo=
wn=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub=
..com%2Fniccroad%2Fptr_guard\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFSLtUdF=
vRwA6t3q-US5_JQSho4MA&#39;;return true;" onclick=3D"this.href=3D&#39;https:=
//www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fniccroad%2Fptr_guard\x=
26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFSLtUdFvRwA6t3q-US5_JQSho4MA&#39;;re=
turn true;">https://github.com/niccroad/<wbr>ptr_guard</a><br></div><div><b=
r></div><div>Note, I wrote this from scratch its in no way connected to the=
 implementation of this concept I wrote for my work place.</div><div><br></=
div><div><br></div><div><br></div><div><br></div></div></blockquote></div>

<p></p>

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

------=_Part_1118_1554131442.1534587769749--

------=_Part_1117_281746749.1534587769749--

.

------=_Part_1042_1845664828.1534589463430
Content-Type: multipart/alternative;
 boundary="----=_Part_1043_1022203970.1534589463430"

------=_Part_1043_1022203970.1534589463430
Content-Type: text/plain; charset="UTF-8"

I absolutely agree, for something which can not be null in C++ its usually
best to use a reference or value. There are however situations for which I
want to use a pointer and for that to be able to be null in some run-time
states.

What this template tries to enforce is that that pointer has been checked
prior to de-reference. If that can be demonstrated (e.g missing conditions)
can be found or mostly found then you can demonstrate the absence of a
whole class of bugs just by compiling. The points you raised are both
integral to the idea, but its fundamentally a pointer concept not a
reference concept.

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

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

<div dir=3D"ltr"><div>I absolutely agree, for something which can not be nu=
ll in C++ its usually best to use a reference or value. There are however s=
ituations for which I want to use a pointer and for that to be able to be n=
ull in some run-time states.</div><div><br></div><div>What this template tr=
ies to enforce is that that pointer has been checked prior to de-reference.=
 If that can be demonstrated (e.g missing conditions) can be found or mostl=
y found then you can demonstrate the absence of a whole class of bugs just =
by compiling. The points you raised are both integral to the idea, but its =
fundamentally a pointer concept not a reference concept.</div></div>

<p></p>

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

------=_Part_1043_1022203970.1534589463430--

------=_Part_1042_1845664828.1534589463430--

.

--00000000000033189b0573b37d83
Content-Type: text/plain; charset="UTF-8"

I don't see why this is handled in a variant-like manner, with a function
call. That approach makes sense when there are many possible states, not
just two.

It would make more sense to me to dereference to a std::optional.

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

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

<div dir=3D"auto">I don&#39;t see why this is handled in a variant-like man=
ner, with a function call. That approach makes sense when there are many po=
ssible states, not just two.<div dir=3D"auto"><br></div><div dir=3D"auto">I=
t would make more sense to me to dereference to a std::optional.</div></div=
>

<p></p>

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

--00000000000033189b0573b37d83--

.

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

On Sat, 18 Aug 2018, 11:51 NicTheNZer, <nicolas.croad@gmail.com> wrote:

> I absolutely agree, for something which can not be null in C++ its usually
> best to use a reference or value. There are however situations for which I
> want to use a pointer and for that to be able to be null in some run-time
> states.
>

But I dont think that approach should be promoted by the standard. It's a
fairly archaic way of doing things now we have std::variant, std::optional,
and the like. That being said, we still have to interface with older code
and C, and wrapping their return values in something safe does make some
sense.

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

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

<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, =
18 Aug 2018, 11:51 NicTheNZer, &lt;<a href=3D"mailto:nicolas.croad@gmail.co=
m">nicolas.croad@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div>I absolutely agree, for something which can no=
t be null in C++ its usually best to use a reference or value. There are ho=
wever situations for which I want to use a pointer and for that to be able =
to be null in some run-time states.</div></div></blockquote></div></div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">But I dont think that approach s=
hould be promoted by the standard. It&#39;s a fairly archaic way of doing t=
hings now we have std::variant, std::optional, and the like. That being sai=
d, we still have to interface with older code and C, and wrapping their ret=
urn values in something safe does make some sense.</div><div dir=3D"auto"><=
/div></div>

<p></p>

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

--000000000000ff9d2c0573b38fcc--

.

------=_Part_471_447095750.1534590582431
Content-Type: multipart/alternative;
 boundary="----=_Part_472_1422483831.1534590582431"

------=_Part_472_1422483831.1534590582431
Content-Type: text/plain; charset="UTF-8"

One of the alternative implementations seemed to be just use std::optional.
Except that if you de-reference it this applies

https://en.cppreference.com/w/cpp/utility/optional/operator*
The behavior is undefined if *this does not contain a value.

In fact I was thinking this should be extended to be able to wrap
std::optional due to this. I don't understand any way std::optional is
safer than a raw pointer semantically. I originally tried to figure a way
to make this work with operator-> on the ptr_guard but I don't think there
is one.

On Saturday, 18 August 2018 22:58:57 UTC+12, Jake Arkinstall wrote:
>
> On Sat, 18 Aug 2018, 11:51 NicTheNZer, <nicola...@gmail.com <javascript:>>
> wrote:
>
>> I absolutely agree, for something which can not be null in C++ its
>> usually best to use a reference or value. There are however situations for
>> which I want to use a pointer and for that to be able to be null in some
>> run-time states.
>>
>
> But I dont think that approach should be promoted by the standard. It's a
> fairly archaic way of doing things now we have std::variant, std::optional,
> and the like. That being said, we still have to interface with older code
> and C, and wrapping their return values in something safe does make some
> sense.
>

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

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

<div dir=3D"ltr">One of the alternative implementations seemed to be just u=
se std::optional. Except that if you de-reference it this applies=C2=A0<div=
><span style=3D"color: rgb(0, 0, 0); font-family: DejaVuSans, &quot;DejaVu =
Sans&quot;, arial, sans-serif; font-size: 12.8px;"><br></span></div><div><f=
ont color=3D"#000000" face=3D"DejaVuSans, DejaVu Sans, arial, sans-serif"><=
span style=3D"font-size: 12.8px;">https://en.cppreference.com/w/cpp/utility=
/optional/operator*</span></font><br></div><div><span style=3D"color: rgb(0=
, 0, 0); font-family: DejaVuSans, &quot;DejaVu Sans&quot;, arial, sans-seri=
f; font-size: 12.8px;">The behavior is undefined if=C2=A0</span><span class=
=3D"t-c" style=3D"background-color: rgba(0, 0, 0, 0.03); border-width: 1px;=
 border-style: solid; border-color: rgb(214, 214, 214); border-radius: 3px;=
 margin-right: 2px; margin-left: 2px; padding-right: 2px; padding-left: 2px=
; display: inline-block; color: rgb(0, 0, 0); font-family: DejaVuSans, &quo=
t;DejaVu Sans&quot;, arial, sans-serif; font-size: 12.8px;"><span class=3D"=
mw-geshi cpp source-cpp" style=3D"font-family: monospace; line-height: norm=
al; white-space: nowrap;"><span class=3D"sy2" style=3D"color: rgb(0, 0, 64)=
;">*</span>this</span></span><span style=3D"color: rgb(0, 0, 0); font-famil=
y: DejaVuSans, &quot;DejaVu Sans&quot;, arial, sans-serif; font-size: 12.8p=
x;">=C2=A0does not contain a value.</span></div><div><font color=3D"#000000=
" face=3D"DejaVuSans, DejaVu Sans, arial, sans-serif"><span style=3D"font-s=
ize: 12.8px;"><br></span></font></div><div><font color=3D"#000000" face=3D"=
DejaVuSans, DejaVu Sans, arial, sans-serif"><span style=3D"font-size: 12.8p=
x;">In fact I was thinking this should be extended to be able to wrap std::=
optional due to this. I don&#39;t understand any way std::optional is safer=
 than a raw pointer semantically.=C2=A0</span></font><span style=3D"color: =
rgb(0, 0, 0); font-family: DejaVuSans, &quot;DejaVu Sans&quot;, arial, sans=
-serif; font-size: 12.8px;">I originally tried to figure a way to make this=
 work with operator-&gt; on the ptr_guard but I don&#39;t think there is on=
e.</span></div><div><br>On Saturday, 18 August 2018 22:58:57 UTC+12, Jake A=
rkinstall  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"a=
uto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, 18 Aug 2018, =
11:51 NicTheNZer, &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"ZIRbkO7eDgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#3=
9;;return true;">nicola...@gmail.com</a>&gt; wrote:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div>I absolutely agree, for something wh=
ich can not be null in C++ its usually best to use a reference or value. Th=
ere are however situations for which I want to use a pointer and for that t=
o be able to be null in some run-time states.</div></div></blockquote></div=
></div><div dir=3D"auto"><br></div><div dir=3D"auto">But I dont think that =
approach should be promoted by the standard. It&#39;s a fairly archaic way =
of doing things now we have std::variant, std::optional, and the like. That=
 being said, we still have to interface with older code and C, and wrapping=
 their return values in something safe does make some sense.</div><div dir=
=3D"auto"></div></div>
</blockquote></div></div>

<p></p>

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

------=_Part_472_1422483831.1534590582431--

------=_Part_471_447095750.1534590582431--

.

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

On Sat, 18 Aug 2018, 12:09 NicTheNZer, <nicolas.croad@gmail.com> wrote:

> One of the alternative implementations seemed to be just use
> std::optional. Except that if you de-reference it this applies
>
> https://en.cppreference.com/w/cpp/utility/optional/operator*
> The behavior is undefined if *this does not contain a value.
>
> In fact I was thinking this should be extended to be able to wrap
> std::optional due to this. I don't understand any way std::optional is
> safer than a raw pointer semantically.
>

I think we have different definitions of safe. For me, safe means you can
do what you want, but its harder to do something wrong by accident or
ignorance. Raw pointers, for example, are unsafe because it's far easier to
do something wrong (as a beginner) than it is to do something right.

If you allow a dereference to a std::optional, but return the null if the
pointer isn't valid, you avoid that UB in the first place.

std::optional<T> operator*(){
    if(!ptr) return {};
    return *ptr;
}

>

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

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

<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, =
18 Aug 2018, 12:09 NicTheNZer, &lt;<a href=3D"mailto:nicolas.croad@gmail.co=
m">nicolas.croad@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr">One of the alternative implementations seemed to be=
 just use std::optional. Except that if you de-reference it this applies=C2=
=A0<div><span style=3D"color:rgb(0,0,0);font-family:DejaVuSans,&quot;DejaVu=
 Sans&quot;,arial,sans-serif;font-size:12.8px"><br></span></div><div><font =
color=3D"#000000" face=3D"DejaVuSans, DejaVu Sans, arial, sans-serif"><span=
 style=3D"font-size:12.8px"><a href=3D"https://en.cppreference.com/w/cpp/ut=
ility/optional/operator*" target=3D"_blank" rel=3D"noreferrer">https://en.c=
ppreference.com/w/cpp/utility/optional/operator*</a></span></font><br></div=
><div><span style=3D"color:rgb(0,0,0);font-family:DejaVuSans,&quot;DejaVu S=
ans&quot;,arial,sans-serif;font-size:12.8px">The behavior is undefined if=
=C2=A0</span><span class=3D"m_2874042238096725265t-c" style=3D"background-c=
olor:rgba(0,0,0,0.03);border-width:1px;border-style:solid;border-color:rgb(=
214,214,214);border-radius:3px;margin-right:2px;margin-left:2px;padding-rig=
ht:2px;padding-left:2px;display:inline-block;color:rgb(0,0,0);font-family:D=
ejaVuSans,&quot;DejaVu Sans&quot;,arial,sans-serif;font-size:12.8px"><span =
class=3D"m_2874042238096725265mw-geshi m_2874042238096725265cpp m_287404223=
8096725265source-cpp" style=3D"font-family:monospace;line-height:normal;whi=
te-space:nowrap"><span class=3D"m_2874042238096725265sy2" style=3D"color:rg=
b(0,0,64)">*</span>this</span></span><span style=3D"color:rgb(0,0,0);font-f=
amily:DejaVuSans,&quot;DejaVu Sans&quot;,arial,sans-serif;font-size:12.8px"=
>=C2=A0does not contain a value.</span></div><div><font color=3D"#000000" f=
ace=3D"DejaVuSans, DejaVu Sans, arial, sans-serif"><span style=3D"font-size=
:12.8px"><br></span></font></div><div><font color=3D"#000000" face=3D"DejaV=
uSans, DejaVu Sans, arial, sans-serif"><span style=3D"font-size:12.8px">In =
fact I was thinking this should be extended to be able to wrap std::optiona=
l due to this. I don&#39;t understand any way std::optional is safer than a=
 raw pointer semantically.</span></font></div></div></blockquote></div></di=
v><div dir=3D"auto"><br></div><div dir=3D"auto">I think we have different d=
efinitions of safe. For me, safe means you can do what you want, but its ha=
rder to do something wrong by accident or ignorance. Raw pointers, for exam=
ple, are unsafe because it&#39;s far easier to do something wrong (as a beg=
inner) than it is to do something right.</div><div dir=3D"auto"><br></div><=
div dir=3D"auto">If you allow a dereference to a std::optional, but return =
the null if the pointer isn&#39;t valid, you avoid that UB in the first pla=
ce.</div><div dir=3D"auto"><br></div><div dir=3D"auto">std::optional&lt;T&g=
t; operator*(){</div><div dir=3D"auto">=C2=A0 =C2=A0 if(!ptr) return {};</d=
iv><div dir=3D"auto">=C2=A0 =C2=A0 return *ptr;</div><div dir=3D"auto">}</d=
iv><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">
</blockquote></div></div></div>

<p></p>

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

--000000000000f0d11e0573b3e512--

.

------=_Part_1179_1956038185.1534626150882
Content-Type: multipart/alternative;
 boundary="----=_Part_1180_1239767823.1534626150882"

------=_Part_1180_1239767823.1534626150882
Content-Type: text/plain; charset="UTF-8"


On Saturday, 18 August 2018 23:22:59 UTC+12, Jake Arkinstall wrote:
>
> On Sat, 18 Aug 2018, 12:09 NicTheNZer, <nicola...@gmail.com <javascript:>>
> wrote:
>
>> One of the alternative implementations seemed to be just use
>> std::optional. Except that if you de-reference it this applies
>>
>> https://en.cppreference.com/w/cpp/utility/optional/operator*
>> The behavior is undefined if *this does not contain a value.
>>
>> In fact I was thinking this should be extended to be able to wrap
>> std::optional due to this. I don't understand any way std::optional is
>> safer than a raw pointer semantically.
>>
>
> I think we have different definitions of safe. For me, safe means you can
> do what you want, but its harder to do something wrong by accident or
> ignorance. Raw pointers, for example, are unsafe because it's far easier to
> do something wrong (as a beginner) than it is to do something right.
>

I think my definition is similar enough, but I don't really understand why
you categorized std::optional as safe relative to raw pointers.
Dereferencing an empty optional and a null pointer are both UB. The point
of the ptr_guard is to make sure you have a validity test around doing that.

If you allow a dereference to a std::optional, but return the null if the
> pointer isn't valid, you avoid that UB in the first place.
>

But its UB if the program goes on to de-reference the std::optional anyway.


> std::optional<T> operator*(){
>     if(!ptr) return {};
>     return *ptr;
> }
>

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

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

<div dir=3D"ltr"><br>On Saturday, 18 August 2018 23:22:59 UTC+12, Jake Arki=
nstall  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"auto=
"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, 18 Aug 2018, 12:=
09 NicTheNZer, &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated=
-mailto=3D"otkSXT7gDgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;j=
avascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;=
return true;">nicola...@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">One of the alternative implementations seeme=
d to be just use std::optional. Except that if you de-reference it this app=
lies=C2=A0<div><span style=3D"color:rgb(0,0,0);font-family:DejaVuSans,&quot=
;DejaVu Sans&quot;,arial,sans-serif;font-size:12.8px"><br></span></div><div=
><font color=3D"#000000" face=3D"DejaVuSans, DejaVu Sans, arial, sans-serif=
"><span style=3D"font-size:12.8px"><a href=3D"https://en.cppreference.com/w=
/cpp/utility/optional/operator*" rel=3D"nofollow" target=3D"_blank" onmouse=
down=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fen.c=
ppreference.com%2Fw%2Fcpp%2Futility%2Foptional%2Foperator*\x26sa\x3dD\x26sn=
tz\x3d1\x26usg\x3dAFQjCNEGct0TokhLr-uZVsziQCdtV7PXKQ&#39;;return true;" onc=
lick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fen.c=
ppreference.com%2Fw%2Fcpp%2Futility%2Foptional%2Foperator*\x26sa\x3dD\x26sn=
tz\x3d1\x26usg\x3dAFQjCNEGct0TokhLr-uZVsziQCdtV7PXKQ&#39;;return true;">htt=
ps://en.cppreference.com/w/<wbr>cpp/utility/optional/operator*</a></span></=
font><br></div><div><span style=3D"color:rgb(0,0,0);font-family:DejaVuSans,=
&quot;DejaVu Sans&quot;,arial,sans-serif;font-size:12.8px">The behavior is =
undefined if=C2=A0</span><span style=3D"background-color:rgba(0,0,0,0.03);b=
order-width:1px;border-style:solid;border-color:rgb(214,214,214);border-rad=
ius:3px;margin-right:2px;margin-left:2px;padding-right:2px;padding-left:2px=
;display:inline-block;color:rgb(0,0,0);font-family:DejaVuSans,&quot;DejaVu =
Sans&quot;,arial,sans-serif;font-size:12.8px"><span style=3D"font-family:mo=
nospace;line-height:normal;white-space:nowrap"><span style=3D"color:rgb(0,0=
,64)">*</span>this</span></span><span style=3D"color:rgb(0,0,0);font-family=
:DejaVuSans,&quot;DejaVu Sans&quot;,arial,sans-serif;font-size:12.8px">=C2=
=A0does not contain a value.</span></div><div><font color=3D"#000000" face=
=3D"DejaVuSans, DejaVu Sans, arial, sans-serif"><span style=3D"font-size:12=
..8px"><br></span></font></div><div><font color=3D"#000000" face=3D"DejaVuSa=
ns, DejaVu Sans, arial, sans-serif"><span style=3D"font-size:12.8px">In fac=
t I was thinking this should be extended to be able to wrap std::optional d=
ue to this. I don&#39;t understand any way std::optional is safer than a ra=
w pointer semantically.</span></font></div></div></blockquote></div></div><=
div dir=3D"auto"><br></div><div dir=3D"auto">I think we have different defi=
nitions of safe. For me, safe means you can do what you want, but its harde=
r to do something wrong by accident or ignorance. Raw pointers, for example=
, are unsafe because it&#39;s far easier to do something wrong (as a beginn=
er) than it is to do something right.</div></div></blockquote><div><br></di=
v><div>I think my definition is similar enough, but I don&#39;t really unde=
rstand why you categorized std::optional as safe relative to raw pointers. =
Dereferencing an empty optional and a null pointer are both UB. The point o=
f the ptr_guard is to make sure you have a validity test around doing that.=
</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"auto"><div dir=3D"auto">If you allow a dereference to a std::optional, =
but return the null if the pointer isn&#39;t valid, you avoid that UB in th=
e first place.</div></div></blockquote><div><br></div><div>But its UB if th=
e program goes on to de-reference the std::optional anyway.</div><div><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"auto"><div di=
r=3D"auto"><br></div><div dir=3D"auto">std::optional&lt;T&gt; operator*(){<=
/div><div dir=3D"auto">=C2=A0 =C2=A0 if(!ptr) return {};</div><div dir=3D"a=
uto">=C2=A0 =C2=A0 return *ptr;</div><div dir=3D"auto">}=C2=A0</div></div><=
/blockquote></div>

<p></p>

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

------=_Part_1180_1239767823.1534626150882--

------=_Part_1179_1956038185.1534626150882--

.

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

The de-facto way to access a value in an optional is through the value() or
the value_or() methods. The only time a user should ever, ever dereference
an optional is when they know damn well that the optional has a value and
when they don't want to introduce exception overhead.

Though I do admit, it's things like this that I believe we should have a
colour scheme in the reference. Green means it's safe for beginners to use,
red means use at your own risk. In this case, optional<T>::value() would be
green and optional<T>::operator*() would be red. This way a library can
offer a more efficient route to accessing data whilst knowing that they're
doing everything they can reasonably do to detract novices from using it.

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

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

<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">The de-f=
acto way to access a value in an optional is through the value() or the val=
ue_or() methods. The only time a user should ever, ever dereference an opti=
onal is when they know damn well that the optional has a value and when the=
y don&#39;t want to introduce exception overhead.</div><div dir=3D"ltr"><br=
></div><div dir=3D"ltr">Though I do admit, it&#39;s things like this that I=
 believe we should have a colour scheme in the reference. Green means it&#3=
9;s safe for beginners to use, red means use at your own risk. In this case=
, optional&lt;T&gt;::value() would be green and optional&lt;T&gt;::operator=
*() would be red. This way a library can offer a more efficient route to ac=
cessing data whilst knowing that they&#39;re doing everything they can reas=
onably do to detract novices from using it.</div></div></div></div>

<p></p>

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

--000000000000fda8d10573bc4f12--

.

------=_Part_1187_1688547546.1534628341054
Content-Type: multipart/alternative;
 boundary="----=_Part_1188_1555386907.1534628341054"

------=_Part_1188_1555386907.1534628341054
Content-Type: text/plain; charset="UTF-8"



On Sunday, 19 August 2018 09:25:18 UTC+12, Jake Arkinstall wrote:
>
> The de-facto way to access a value in an optional is through the value()
> or the value_or() methods. The only time a user should ever, ever
> dereference an optional is when they know damn well that the optional has a
> value and when they don't want to introduce exception overhead.
>

Even value() is unsafe if an exception is unexpected or exceptions are
turned off (as your program terminates or probably doesn't handle the
exception). If I was wrapping ptr_guard around std::optional that is one of
the methods I would make inaccessible probably.

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

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

<div dir=3D"ltr"><br><br>On Sunday, 19 August 2018 09:25:18 UTC+12, Jake Ar=
kinstall  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"au=
to"><div><div class=3D"gmail_quote"><div dir=3D"ltr">The de-facto way to ac=
cess a value in an optional is through the value() or the value_or() method=
s. The only time a user should ever, ever dereference an optional is when t=
hey know damn well that the optional has a value and when they don&#39;t wa=
nt to introduce exception overhead.</div></div></div></div></blockquote><di=
v><br></div><div>Even value() is unsafe if an exception is unexpected or ex=
ceptions are turned off (as your program terminates or probably doesn&#39;t=
 handle the exception). If I was wrapping ptr_guard around std::optional th=
at is one of the methods I would make inaccessible probably.</div><div><br>=
</div></div>

<p></p>

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

------=_Part_1188_1555386907.1534628341054--

------=_Part_1187_1688547546.1534628341054--

.

------=_Part_1184_304189469.1534633265924
Content-Type: multipart/alternative;
 boundary="----=_Part_1185_1427553042.1534633265924"

------=_Part_1185_1427553042.1534633265924
Content-Type: text/plain; charset="UTF-8"

On Saturday, August 18, 2018 at 5:25:18 PM UTC-4, Jake Arkinstall wrote:
>
> The de-facto way to access a value in an optional is through the value()
> or the value_or() methods. The only time a user should ever, ever
> dereference an optional is when they know damn well that the optional has a
> value and when they don't want to introduce exception overhead.
>

But that is what this whole "safety" thing is all about. `*ptr` is
perfectly safe when you "know damn well" that the pointer points to a real
object. The problem is when you *think* you "know damn well" and are *wrong*
about that.

To me, the safety advantage of `optional` over a pointer is that `optional`
has only two states: engaged, and unengaged. Pointers have 3: `nullptr`,
valid pointer to an object, or *invalid* pointer. You can't tell when the
latter happens (yes, technically, you can destroy the object stored in an
`optional`, but its rather hard and you really shouldn't).

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

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

<div dir=3D"ltr">On Saturday, August 18, 2018 at 5:25:18 PM UTC-4, Jake Ark=
install wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"auto=
"><div><div class=3D"gmail_quote"><div dir=3D"ltr">The de-facto way to acce=
ss a value in an optional is through the value() or the value_or() methods.=
 The only time a user should ever, ever dereference an optional is when the=
y know damn well that the optional has a value and when they don&#39;t want=
 to introduce exception overhead.</div></div></div></div></blockquote><div>=
<br></div><div>But that is what this whole &quot;safety&quot; thing is all =
about. `*ptr` is perfectly safe when you &quot;know damn well&quot; that th=
e pointer points to a real object. The problem is when you <i>think</i> you=
 &quot;know damn well&quot; and are <i>wrong</i> about that.</div><div><br>=
</div><div>To me, the safety advantage of `optional` over a pointer is that=
 `optional` has only two states: engaged, and unengaged. Pointers have 3: `=
nullptr`, valid pointer to an object, or <i>invalid</i> pointer. You can&#3=
9;t tell when the latter happens (yes, technically, you can destroy the obj=
ect stored in an `optional`, but its rather hard and you really shouldn&#39=
;t).<br></div><br></div>

<p></p>

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

------=_Part_1185_1427553042.1534633265924--

------=_Part_1184_304189469.1534633265924--

.

--00000000000025806a0573c0a297
Content-Type: text/plain; charset="UTF-8"

On Sun, 19 Aug 2018, 00:01 Nicol Bolas, <jmckesson@gmail.com> wrote:

> On Saturday, August 18, 2018 at 5:25:18 PM UTC-4, Jake Arkinstall wrote:
>>
>> The de-facto way to access a value in an optional is through the value()
>> or the value_or() methods. The only time a user should ever, ever
>> dereference an optional is when they know damn well that the optional has a
>> value and when they don't want to introduce exception overhead.
>>
>
> But that is what this whole "safety" thing is all about. `*ptr` is
> perfectly safe when you "know damn well" that the pointer points to a real
> object. The problem is when you *think* you "know damn well" and are
> *wrong* about that.
>
> To me, the safety advantage of `optional` over a pointer is that
> `optional` has only two states: engaged, and unengaged. Pointers have 3:
> `nullptr`, valid pointer to an object, or *invalid* pointer. You can't
> tell when the latter happens (yes, technically, you can destroy the object
> stored in an `optional`, but its rather hard and you really shouldn't).
>

That's what I'm trying to get at. With an optional, you can do one check
and then dereference to your heart's content. You know from that single
check that it is valid (unlike, as you point out, a pointer, which can have
a non-null address but be invalid), so you can then put the direct value
access in a loop without killing performance (particularly if it's a fast
operation performed many times).

With regards to this proposal, I'd maybe want something that used a
debug-level *contract* to ensure that the value is valid. But when it comes
to a release build, I don't want pedantic checking every time I want to use
something. It does mean UB if someone does something dumb with a release
build, but that UB is a worthwhile tradeoff for speed.

That's why unique_ptr is so useful, after all. It's a thin wrapper. This
wrapper in its current form is far from thin, unless you provide a
dereference function combined with a contract (though I do expect that we
will see a lot of the current library using contracts to detect UB soon
enough, optional included).

>

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

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

<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Sun, =
19 Aug 2018, 00:01 Nicol Bolas, &lt;<a href=3D"mailto:jmckesson@gmail.com" =
target=3D"_blank" rel=3D"noreferrer">jmckesson@gmail.com</a>&gt; wrote:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Saturday, August 1=
8, 2018 at 5:25:18 PM UTC-4, Jake Arkinstall wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=
=3D"ltr">The de-facto way to access a value in an optional is through the v=
alue() or the value_or() methods. The only time a user should ever, ever de=
reference an optional is when they know damn well that the optional has a v=
alue and when they don&#39;t want to introduce exception overhead.</div></d=
iv></div></div></blockquote><div><br></div><div>But that is what this whole=
 &quot;safety&quot; thing is all about. `*ptr` is perfectly safe when you &=
quot;know damn well&quot; that the pointer points to a real object. The pro=
blem is when you <i>think</i> you &quot;know damn well&quot; and are <i>wro=
ng</i> about that.</div><div><br></div><div>To me, the safety advantage of =
`optional` over a pointer is that `optional` has only two states: engaged, =
and unengaged. Pointers have 3: `nullptr`, valid pointer to an object, or <=
i>invalid</i> pointer. You can&#39;t tell when the latter happens (yes, tec=
hnically, you can destroy the object stored in an `optional`, but its rathe=
r hard and you really shouldn&#39;t).</div></div></blockquote></div></div><=
div dir=3D"auto"><br></div><div dir=3D"auto">That&#39;s what I&#39;m trying=
 to get at. With an optional, you can do one check and then dereference to =
your heart&#39;s content. You know from that single check that it is valid =
(unlike, as you point out, a pointer, which can have a non-null address but=
 be invalid), so you can then put the direct value access in a loop without=
 killing performance (particularly if it&#39;s a fast operation performed m=
any times).</div><div dir=3D"auto"><br></div><div dir=3D"auto">With regards=
 to this proposal, I&#39;d maybe want something that used a debug-level <i>=
contract</i>=C2=A0to ensure that the value is valid. But when it comes to a=
 release build, I don&#39;t want pedantic checking every time I want to use=
 something. It does mean UB if someone does something dumb with a release b=
uild, but that UB is a worthwhile tradeoff for speed.</div><div dir=3D"auto=
"><br></div><div dir=3D"auto">That&#39;s why unique_ptr is so useful, after=
 all. It&#39;s a thin wrapper. This wrapper in its current form is far from=
 thin, unless you provide a dereference function combined with a contract (=
though I do expect that we will see a lot of the current library using cont=
racts to detect UB soon enough, optional included).</div><div dir=3D"auto">=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>

<p></p>

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

--00000000000025806a0573c0a297--

.

------=_Part_163_1095048345.1534647895359
Content-Type: multipart/alternative;
 boundary="----=_Part_164_1625070074.1534647895359"

------=_Part_164_1625070074.1534647895359
Content-Type: text/plain; charset="UTF-8"



> With regards to this proposal, I'd maybe want something that used a
> debug-level *contract* to ensure that the value is valid. But when it
> comes to a release build, I don't want pedantic checking every time I want
> to use something. It does mean UB if someone does something dumb with a
> release build, but that UB is a worthwhile tradeoff for speed.
>

The contents of ptr_guard can be a nullptr in a correct program. ptr_guard
is not in any way a template for a non null ptr. You can't put a contract
on the ptr to be non-null because that contract would be invalidated when
the pointer is null.

That's why unique_ptr is so useful, after all. It's a thin wrapper. This
> wrapper in its current form is far from thin, unless you provide a
> dereference function combined with a contract (though I do expect that we
> will see a lot of the current library using contracts to detect UB soon
> enough, optional included).
>

While the implementation is somewhat complex, in practice call should
compile down to
    if (ptr) { ptr->member(); }
for a call like
    guard.call([](Pointee& pointee) { pointee.member(); });

If its a contract it doesn't detect the problem at compile time. Failing
due to contract failure is not much better than seg-faulting due to UB.

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

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

<div dir=3D"ltr"><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div dir=3D"auto"><div dir=3D"auto">With regards to this proposal, I&#39;=
d maybe want something that used a debug-level <i>contract</i>=C2=A0to ensu=
re that the value is valid. But when it comes to a release build, I don&#39=
;t want pedantic checking every time I want to use something. It does mean =
UB if someone does something dumb with a release build, but that UB is a wo=
rthwhile tradeoff for speed.</div></div></blockquote><div><br></div><div>Th=
e contents of ptr_guard can be a nullptr in a correct program. ptr_guard is=
 not in any way a template for a non null ptr. You can&#39;t put a contract=
 on the ptr to be non-null because that contract would be invalidated when =
the pointer is null.</div><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"auto"><div dir=3D"auto">That&#39;s why unique_ptr is=
 so useful, after all. It&#39;s a thin wrapper. This wrapper in its current=
 form is far from thin, unless you provide a dereference function combined =
with a contract (though I do expect that we will see a lot of the current l=
ibrary using contracts to detect UB soon enough, optional included).</div><=
/div></blockquote><div><br></div><div>While the implementation is somewhat =
complex, in practice call should compile down to</div><div>=C2=A0 =C2=A0 if=
 (ptr) { ptr-&gt;member(); }</div><div>for a call like</div><div>=C2=A0 =C2=
=A0 guard.call([](Pointee&amp; pointee) { pointee.member(); });<br></div><d=
iv><br></div><div>If its a contract it doesn&#39;t detect the problem at co=
mpile time. Failing due to contract failure is not much better than seg-fau=
lting due to UB.</div><div><br></div></div>

<p></p>

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

------=_Part_164_1625070074.1534647895359--

------=_Part_163_1095048345.1534647895359--

.