------=_Part_4519_1173486906.1432144166869
Content-Type: multipart/alternative;
 boundary="----=_Part_4520_304615094.1432144166869"

------=_Part_4520_304615094.1432144166869
Content-Type: text/plain; charset=UTF-8

A long time ago, there was a suggestion to prevent accidentally implicitly
constructing basic_string with
null: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466

The issue was opened before nullptr_t existed, but ultimately the proposed
resolution was to add a "basic_string(nullptr_t) = delete;" constructor.

To give an example of what this aims to prevent: suppose we have void
do_stuff(blah, std::string const&, blah);. Elsewhere, one might attempt to
call do_stuff(blah, nullptr, blah), and this will compile just fine even
though it always invokes UB. (It's easy to get in this situation during
refactoring of old code that uses `const char *`.) The goal isn't a general
static null checker, just to prevent cases like this that are very easy to
detect at compile time without language changes.

LWG 466 was ultimately closed as not-a-defect, but my understanding is that
this was because the LWG defect process was the wrong venue, not because
adding the overload was considered a bad idea. So I'd like to re-surface it
as a library proposal.

Before writing up a formal paper I'll go through and look for other
examples of classes with an implicit constructor from a pointer that must
not be null (e.g., basic_string_view, probably others) and include those
too. It may also be useful to add a deleted overload for explicit /
multi-arg constructors (e.g. basic_regex::basic_regex) and free functions
(std::strlen and many more), but I think that's out of the scope of what
I'd like to propose for now.

Any other thoughts or suggestions? Thanks!

- Jacob

--

---
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_4520_304615094.1432144166869
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">A long time ago, there was a suggestion to prevent acciden=
tally implicitly constructing basic_string with null:&nbsp;http://www.open-=
std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466<div><br></div><div>The issu=
e was opened before nullptr_t existed, but ultimately the proposed resoluti=
on was to add a "basic_string(nullptr_t) =3D delete;" constructor.</div><di=
v><br><div><div>To give an example of what this aims to prevent: suppose we=
 have void do_stuff(blah, std::string const&amp;, blah);. Elsewhere, one mi=
ght attempt to call do_stuff(blah, nullptr, blah), and this will compile ju=
st fine even though it always invokes UB. (It's easy to get in this situati=
on during refactoring of old code that uses `const char *`.) The goal isn't=
 a general static null checker, just to prevent cases like this that are ve=
ry easy to detect at compile time without language changes.</div></div></di=
v><div><br></div><div>LWG 466 was ultimately closed as not-a-defect, but my=
 understanding is that this was because the LWG defect process was the wron=
g venue, not because adding the overload was considered a bad idea. So I'd =
like to re-surface it as a library proposal.</div><div><br></div><div>Befor=
e writing up a formal paper I'll go through and look for other examples of =
classes with an implicit constructor from a pointer that must not be null (=
e.g., basic_string_view, probably others) and include those too. It may als=
o be useful to add a deleted overload for explicit / multi-arg constructors=
 (e.g. basic_regex::basic_regex) and free functions (std::strlen and many m=
ore), but I think that's out of the scope of what I'd like to propose for n=
ow.</div><div><br></div><div>Any other thoughts or suggestions? Thanks!</di=
v><div><br></div><div>- Jacob</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 />

------=_Part_4520_304615094.1432144166869--
------=_Part_4519_1173486906.1432144166869--

.

--Apple-Mail=_C1BEAC5C-FB04-4ACD-A2C0-8BEA62DF2787
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9305=E2=80=9321, at 1:49 AM, j4cbo@dropbox.com wrote:
>=20
> LWG 466 was ultimately closed as not-a-defect, but my understanding is th=
at this was because the LWG defect process was the wrong venue, not because=
 adding the overload was considered a bad idea. So I'd like to re-surface i=
t as a library proposal.

It=E2=80=99s resurfaced on this list before, with a fair bit of controversy=
.. Try looking for the previous discussion. I would, but it=E2=80=99s gettin=
g late in my timezone.

It would be nice to somehow allow compile-time diagnosis of certain runtime=
 UB, but it=E2=80=99s really impossible for now. Meaning this isn=E2=80=99t=
 a QOI issue as suggested by the DR. My rough recollection of the debate is=
 that it=E2=80=99s stuck between folks who want the tools to provide a comp=
ile-time diagnosis without normatively adding the overload, and folks who a=
re afraid that adding the overload will =E2=80=9Cbreak=E2=80=9D too much co=
de which is UB that never actually runs.

If that=E2=80=99s right, the proposal will need to maneuver and convince bo=
th those who think diagnoses come for free, and those who see diagnosis as =
having a cost in itself. Also I recall an example like this, used to questi=
on the value of fallible static analysis:

std::string makestr( char const *in )
    { return std::string( in ); }

void foo()
    { std::string s =3D makestr( nullptr ); }

Good luck!

--=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/.

--Apple-Mail=_C1BEAC5C-FB04-4ACD-A2C0-8BEA62DF2787
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9305=
=E2=80=9321, at 1:49 AM, <a href=3D"mailto:j4cbo@dropbox.com" class=3D"">j4=
cbo@dropbox.com</a> wrote:</div><br class=3D"Apple-interchange-newline"><di=
v class=3D""><div style=3D"font-family: Helvetica; font-size: 12px; font-st=
yle: normal; font-variant: normal; font-weight: normal; letter-spacing: nor=
mal; line-height: normal; orphans: auto; text-align: start; text-indent: 0p=
x; text-transform: none; white-space: normal; widows: auto; word-spacing: 0=
px; -webkit-text-stroke-width: 0px;" class=3D"">LWG 466 was ultimately clos=
ed as not-a-defect, but my understanding is that this was because the LWG d=
efect process was the wrong venue, not because adding the overload was cons=
idered a bad idea. So I'd like to re-surface it as a library proposal.</div=
></div></blockquote></div><br class=3D""><div class=3D"">It=E2=80=99s resur=
faced on this list before, with a fair bit of controversy. Try looking for =
the previous discussion. I would, but it=E2=80=99s getting late in my timez=
one.</div><div class=3D""><br class=3D""></div><div class=3D"">It would be =
nice to somehow allow compile-time diagnosis of certain runtime UB, but it=
=E2=80=99s really impossible for now. Meaning this isn=E2=80=99t a QOI issu=
e as suggested by the DR. My rough recollection of the debate is that it=E2=
=80=99s stuck between folks who want the tools to provide a compile-time di=
agnosis without normatively adding the overload, and folks who are afraid t=
hat adding the overload will =E2=80=9Cbreak=E2=80=9D too much code which is=
 UB that never actually runs.</div><div class=3D""><br class=3D""></div><di=
v class=3D"">If that=E2=80=99s right, the proposal will need to maneuver an=
d convince both those who think diagnoses come for free, and those who see =
diagnosis as having a cost in itself. Also I recall an example like this, u=
sed to question the value of fallible static analysis:</div><div class=3D""=
><br class=3D""></div><div class=3D""><font face=3D"Courier" class=3D"">std=
::string makestr( char const *in )</font></div><div class=3D""><font face=
=3D"Courier" class=3D"">&nbsp; &nbsp; { return std::string( in ); }</font><=
/div><div class=3D""><font face=3D"Courier" class=3D""><br class=3D""></fon=
t></div><div class=3D""><font face=3D"Courier" class=3D"">void foo()</font>=
</div><div class=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp; { std=
::string s =3D makestr( nullptr ); }</font></div><div class=3D""><br class=
=3D""></div><div class=3D"">Good luck!</div></body></html>

<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 />

--Apple-Mail=_C1BEAC5C-FB04-4ACD-A2C0-8BEA62DF2787--

.

------=_Part_1477_2057533459.1432337617096
Content-Type: multipart/alternative;
 boundary="----=_Part_1478_35677772.1432337617096"

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

On Wednesday, May 20, 2015 at 11:09:00 AM UTC-7, David Krauss wrote:
>
>
> On 2015=E2=80=9305=E2=80=9321, at 1:49 AM, j4...@dropbox.com <javascript:=
> wrote:
>
> LWG 466 was ultimately closed as not-a-defect, but my understanding is=20
> that this was because the LWG defect process was the wrong venue, not=20
> because adding the overload was considered a bad idea. So I'd like to=20
> re-surface it as a library proposal.
>
>
> It=E2=80=99s resurfaced on this list before, with a fair bit of controver=
sy. Try=20
> looking for the previous discussion. I would, but it=E2=80=99s getting la=
te in my=20
> timezone.
>
> It would be nice to somehow allow compile-time diagnosis of certain=20
> runtime UB, but it=E2=80=99s really impossible for now. Meaning this isn=
=E2=80=99t a QOI=20
> issue as suggested by the DR. My rough recollection of the debate is that=
=20
> it=E2=80=99s stuck between folks who want the tools to provide a compile-=
time=20
> diagnosis without normatively adding the overload, and folks who are afra=
id=20
> that adding the overload will =E2=80=9Cbreak=E2=80=9D too much code which=
 is UB that never=20
> actually runs.
>
> If that=E2=80=99s right, the proposal will need to maneuver and convince =
both=20
> those who think diagnoses come for free, and those who see diagnosis as=
=20
> having a cost in itself. Also I recall an example like this, used to=20
> question the value of fallible static analysis:
>
> std::string makestr( char const *in )
>     { return std::string( in ); }
>
> void foo()
>     { std::string s =3D makestr( nullptr ); }
>
>
Some objections like the above might be going the way of the dinosaur, as=
=20
perfectly generic programming becomes more common. (Yes, yes, it's still in=
=20
the position of a very small mammal underfoot at the moment, but...)=20
Consider this generic version:

template<typename Ptr> std::string makestr(Ptr&& in) { return std::string(=
=20
std::forward<Ptr>(in); }
void foo() { std::string s =3D makestr(nullptr); }

This version *will* trigger the compile-time error the user wants.

On the other other hand, might anyone care that T(nullptr) [for=20
T=3Dstd::string] would have different SFINAE behavior (even though it's in =
a=20
non-evaluated context)?
Obviously *any* change can affect SFINAE and people generally don't care...=
=20
but is this case sufficiently visible for people to care about it?

I'm favorably disposed toward this proposal but at the same time I don't=20
think it will really provide any benefit in practice.

=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_1478_35677772.1432337617096
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, May 20, 2015 at 11:09:00 AM UTC-7, David Kra=
uss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-w=
rap:break-word"><br><div><blockquote type=3D"cite"><div>On 2015=E2=80=9305=
=E2=80=9321, at 1:49 AM, <a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"LPPC1YblVKwJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return tru=
e;">j4...@dropbox.com</a> wrote:</div><br><div><div style=3D"font-family:He=
lvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:no=
rmal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:=
0px;text-transform:none;white-space:normal;word-spacing:0px">LWG 466 was ul=
timately closed as not-a-defect, but my understanding is that this was beca=
use the LWG defect process was the wrong venue, not because adding the over=
load was considered a bad idea. So I'd like to re-surface it as a library p=
roposal.</div></div></blockquote></div><br><div>It=E2=80=99s resurfaced on =
this list before, with a fair bit of controversy. Try looking for the previ=
ous discussion. I would, but it=E2=80=99s getting late in my timezone.</div=
><div><br></div><div>It would be nice to somehow allow compile-time diagnos=
is of certain runtime UB, but it=E2=80=99s really impossible for now. Meani=
ng this isn=E2=80=99t a QOI issue as suggested by the DR. My rough recollec=
tion of the debate is that it=E2=80=99s stuck between folks who want the to=
ols to provide a compile-time diagnosis without normatively adding the over=
load, and folks who are afraid that adding the overload will =E2=80=9Cbreak=
=E2=80=9D too much code which is UB that never actually runs.</div><div><br=
></div><div>If that=E2=80=99s right, the proposal will need to maneuver and=
 convince both those who think diagnoses come for free, and those who see d=
iagnosis as having a cost in itself. Also I recall an example like this, us=
ed to question the value of fallible static analysis:</div><div><br></div><=
div><font face=3D"Courier">std::string makestr( char const *in )</font></di=
v><div><font face=3D"Courier">&nbsp; &nbsp; { return std::string( in ); }</=
font></div><div><font face=3D"Courier"><br></font></div><div><font face=3D"=
Courier">void foo()</font></div><div><font face=3D"Courier">&nbsp; &nbsp; {=
 std::string s =3D makestr( nullptr ); }</font></div><div><br></div></div><=
/blockquote><div><br></div><div>Some objections like the above might be goi=
ng the way of the dinosaur, as perfectly generic programming becomes more c=
ommon. (Yes, yes, it's still in the position of a very small mammal underfo=
ot at the moment, but...) Consider this generic version:</div><div><br></di=
v><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250);=
 border: 1px solid rgb(187, 187, 187); word-wrap: break-word;"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">template</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">typename</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">Ptr</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">string</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> makestr</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span styl=
e=3D"color: #606;" class=3D"styled-by-prettify">Ptr</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&amp;&amp;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">in</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">return</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">string</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">forward</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&lt;</span><span style=3D"color: #606;" class=3D"styled-by=
-prettify">Ptr</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&gt;(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">i=
n</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> s=
td</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">string</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> s </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> makestr</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">nullptr</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span></div></code></div><div><br>This version <i>will</i> trigger th=
e compile-time error the user wants.</div><div><br></div><div>On the other =
other hand, might anyone care that <font face=3D"courier new, monospace">T(=
nullptr) [for T=3Dstd::string]</font> would have different SFINAE behavior =
(even though it's in a non-evaluated context)?</div><div>Obviously <i>any</=
i> change can affect SFINAE and people generally don't care... but is this =
case sufficiently visible for people to care about it?</div><div><br></div>=
<div>I'm favorably disposed toward this proposal but at the same time I don=
't think it will really provide any benefit in practice.</div><div><br></di=
v><div>=E2=80=93Arthur<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 />

------=_Part_1478_35677772.1432337617096--
------=_Part_1477_2057533459.1432337617096--

.