Topic: Remove implicit bool conversions
Author: m.cencora@gmail.com
Date: Tue, 27 Feb 2018 03:28:55 -0800 (PST)
Raw View
------=_Part_1144_1725369457.1519730935597
Content-Type: multipart/alternative;
boundary="----=_Part_1145_1739059198.1519730935598"
------=_Part_1145_1739059198.1519730935598
Content-Type: text/plain; charset="UTF-8"
Hi,
I propose to remove implicit conversion to and from bool type, and leave it
only in as part of contextual conversion (if, while, ?:, etc).
Reason: why would you ever want following code to compile?
#include <string>
int bar(int) { return 1; }
void bar(int *) { }
void foo(std::string) {}
int foo(bool) { return 1; }
int main()
{
auto t1 = bar(false);
auto t2 = foo("");
auto t3 = false + true + true;
}
For bar(), we don't know what was users intent, so it is in his best
interest to cast the bool value to int or int *.
For foo() the user most likely wanted the foo(std::string) overload to be
called.
For bool arithmetic operations, I think the user intent would be much
better stated if he used any_of(begin(range), end(range), identity) (or its
hand written equivalent), or fold expression when possible.
This will fix some problems with variant construction that P0608R1 wants to
fix.
Regards,
Maciej
--
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/7afbe2f6-15b2-42b0-a2f1-5ff042b59042%40isocpp.org.
------=_Part_1145_1739059198.1519730935598
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<div><br></div><div>I propose to remove implicit conver=
sion to and from bool type, and leave it only in as part of contextual conv=
ersion (if, while, ?:, etc).<div><br></div><div><div>Reason: why would you =
ever want following code to compile?</div><div><br></div><div class=3D"pret=
typrint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(1=
87, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-wor=
d;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #800;" class=3D"styled-by-prettify">#include</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #080;" class=3D"styled-by-prettify"><string></span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br><br><br></span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> bar</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">return</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #066;" class=3D"styled-by-prettify">1</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> bar<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">*)</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </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"><br=
><br><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">v=
oid</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</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"colo=
r: #008;" class=3D"styled-by-prettify">string</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">{}</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">bool</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify=
">1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br><br><br></span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> main</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>=C2=A0 =C2=A0</span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> t1 </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> ba=
r</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">false</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0</span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> t2 </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">(</span><span style=3D"color: #080;" 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>=C2=A0 =C2=A0</span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> t3 </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">false</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">+</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">true</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">+</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">true</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></cod=
e></div><div><div><br></div></div><div><br></div><div>For bar(), we don'=
;t know what was users intent, so it is in his best interest to cast the bo=
ol value to int or int *.</div><div>For foo() the user most likely wanted t=
he foo(std::string) overload to be called.</div><div>For bool arithmetic op=
erations, I think the user intent would be much better stated if he used an=
y_of(begin(range), end(range), identity) (or its hand written equivalent), =
or fold expression when possible.</div><div><br></div><div>This will fix so=
me problems with variant construction that P0608R1 wants to fix.<br></div><=
div><br></div><div>Regards,</div><div>Maciej</div><div><br></div><div><br><=
/div><div><br></div><div><br></div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/7afbe2f6-15b2-42b0-a2f1-5ff042b59042%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7afbe2f6-15b2-42b0-a2f1-5ff042b59042=
%40isocpp.org</a>.<br />
------=_Part_1145_1739059198.1519730935598--
------=_Part_1144_1725369457.1519730935597--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Tue, 27 Feb 2018 12:03:25 +0000
Raw View
--=-efZiHWHdueH2WVA7QlDx
Content-Type: text/plain; charset="UTF-8"
On Tue, 2018-02-27 at 03:28 -0800, m.cencora@gmail.com wrote:
> Hi,
>
> I propose to remove implicit conversion to and from bool type, and
> leave it only in as part of contextual conversion (if, while, ?:,
> etc).
>
> Reason: why would you ever want following code to compile?
>
> #include <string>
>
>
> int bar(int) { return 1; }
> void bar(int *) { }
>
>
> void foo(std::string) {}
> int foo(bool) { return 1; }
>
>
> int main()
> {
> auto t1 = bar(false);
> auto t2 = foo("");
> auto t3 = false + true + true;
> }
>
>
> For bar(), we don't know what was users intent, so it is in his best
> interest to cast the bool value to int or int *.
> For foo() the user most likely wanted the foo(std::string) overload
> to be called.
> For bool arithmetic operations, I think the user intent would be much
> better stated if he used any_of(begin(range), end(range), identity)
> (or its hand written equivalent), or fold expression when possible.
>
> This will fix some problems with variant construction that P0608R1
> wants to fix.
>
Are you also proposing that the implicit conversion to bool in bool
context be disallowed? If so, this may result in quite a bit of
pushback:
There are some useful constructs that rely in it, e.g.:
assert(!"you made an error"); // implicit conversion of const char*
// to bool
if (auto p = get_thing()) { // implicit conversion to bool in
// bool context
p->fiddle();
}
It seems to me that another way to see the problem is that free
function overloads can't be marked explicit?
R
> Regards,
> Maciej
>
>
>
>
> --
> 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/7afbe2f6-15b2-42b0-a2f1-
> 5ff042b59042%40isocpp.org.
--
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/1519733005.15693.6.camel%40gmail.com.
--=-efZiHWHdueH2WVA7QlDx
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE3RJb20ryY2ALx0Tw6HZ1IvK3CgsFAlqVSQ0ACgkQ6HZ1IvK3
CgsZcw//WdVvQzynupYLtQcYNVrbi5pmR2M1nz190/96b0N3Ceip2iA0BCYPHZpQ
Ojl4l9XkCKnxwyLoez2mQ8LTupdC8Lw3mC9OyK1b9gO+e0XbWF8DH41FSsQDXV6n
Hw4PCXlzZqUTDMrIMoUh/iI+J2auHuQ5vdBwtRUcec9eOxmJT6s1CMzwrM2UQgHK
BVrsWBDqq7UGm2R7A+zXBE9hMxCMCU+S64SW8OrTQiSTdWTPrH/3EavdrEzs/v4/
OvPPaID0y8tiMDht9p36PV3WoEgk+g0VWWcFPnkuAFEgLPAmVSdptJXgXIPcPX+7
wbwWuU3VObHSw0K64k/yhfuvOA9vbIkUv7Wb0Bi9gxqwEXuEb2FPIqC8vh3MXN4B
oQlcgxUAgerloRGQEfw1TC3rV9kfKzq++kTlhbg1uCgeVKUW9QGbSs4JntPbXB2F
/esrUrvEjUkNAFMOSTF2GgEoKQbYBMh5ekQkQzjSlXG4fIDPIv2IC7t9LtjVMsjK
g89g7Z/V8m8vq5ejtxpEgayW0qRZCKEbFYbrDtwlJ7O/38FTtVAwONCkAY6PTeZq
EwgnXkn9QRkyJ/II9L2q3Hvg/FePEefIznJP8aO2QUF/DE94pz0RzRxblPNe6MUO
nVBWzDNHT4NoGb/JQ1FQkF52xEYLQHZv/1uKkvo6lHuaLMeKzFw=
=Ae8J
-----END PGP SIGNATURE-----
--=-efZiHWHdueH2WVA7QlDx--
.
Author: m.cencora@gmail.com
Date: Tue, 27 Feb 2018 04:24:42 -0800 (PST)
Raw View
------=_Part_1292_750284034.1519734282163
Content-Type: multipart/alternative;
boundary="----=_Part_1293_1663669208.1519734282163"
------=_Part_1293_1663669208.1519734282163
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
No, I explicitly excluded contextual conversions from this behavior change.
http://en.cppreference.com/w/cpp/language/implicit_conversion#Contextual_co=
nversions
Regards,
Maciej
W dniu wtorek, 27 lutego 2018 13:03:32 UTC+1 u=C5=BCytkownik Richard Hodges=
=20
napisa=C5=82:
>
> On Tue, 2018-02-27 at 03:28 -0800, m.ce...@gmail.com <javascript:> wrote:=
=20
> > Hi,=20
> >=20
> > I propose to remove implicit conversion to and from bool type, and=20
> > leave it only in as part of contextual conversion (if, while, ?:,=20
> > etc).=20
> >=20
> > Reason: why would you ever want following code to compile?=20
> >=20
> > #include <string>=20
> >=20
> >=20
> > int bar(int) { return 1; }=20
> > void bar(int *) { }=20
> >=20
> >=20
> > void foo(std::string) {}=20
> > int foo(bool) { return 1; }=20
> >=20
> >=20
> > int main()=20
> > {=20
> > auto t1 =3D bar(false);=20
> > auto t2 =3D foo("");=20
> > auto t3 =3D false + true + true;=20
> > }=20
> >=20
> >=20
> > For bar(), we don't know what was users intent, so it is in his best=20
> > interest to cast the bool value to int or int *.=20
> > For foo() the user most likely wanted the foo(std::string) overload=20
> > to be called.=20
> > For bool arithmetic operations, I think the user intent would be much=
=20
> > better stated if he used any_of(begin(range), end(range), identity)=20
> > (or its hand written equivalent), or fold expression when possible.=20
> >=20
> > This will fix some problems with variant construction that P0608R1=20
> > wants to fix.=20
> >=20
>
> Are you also proposing that the implicit conversion to bool in bool=20
> context be disallowed? If so, this may result in quite a bit of=20
> pushback:=20
>
> There are some useful constructs that rely in it, e.g.:=20
>
> assert(!"you made an error"); // implicit conversion of const char*=20
> // to bool=20
>
> if (auto p =3D get_thing()) { // implicit conversion to bool in=20
> // bool context=20
> p->fiddle();=20
> }=20
>
> It seems to me that another way to see the problem is that free=20
> function overloads can't be marked explicit?=20
>
> R=20
>
> > Regards,=20
> > Maciej=20
> >=20
> >=20
> >=20
> >=20
> > --=20
> > You received this message because you are subscribed to the Google=20
> > Groups "ISO C++ Standard - Future Proposals" group.=20
> > To unsubscribe from this group and stop receiving emails from it,=20
> > send an email to std-proposal...@isocpp.org <javascript:>.=20
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..=20
>
> > To view this discussion on the web visit https://groups.google.com/a/=
=20
> > isocpp.org/d/msgid/std-proposals/7afbe2f6-15b2-42b0-a2f1-=20
> > 5ff042b59042%40isocpp.org.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/dc784fc9-ba4e-4e76-b72c-203e9af4cb53%40isocpp.or=
g.
------=_Part_1293_1663669208.1519734282163
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">No, I explicitly excluded contextual conversions from this=
behavior change.<div>http://en.cppreference.com/w/cpp/language/implicit_co=
nversion#Contextual_conversions</div><div><br></div><div>Regards,</div><div=
>Maciej<br><br>W dniu wtorek, 27 lutego 2018 13:03:32 UTC+1 u=C5=BCytkownik=
Richard Hodges napisa=C5=82:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">O=
n Tue, 2018-02-27 at 03:28 -0800, <a href=3D"javascript:" target=3D"_blank"=
gdf-obfuscated-mailto=3D"Ql4cfmdtAwAJ" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D'javascript:';return true;" onclick=3D"this.href=3D'ja=
vascript:';return true;">m.ce...@gmail.com</a> wrote:
<br>> Hi,
<br>>=20
<br>> I propose to remove implicit conversion to and from bool type, and
<br>> leave it only in as part of contextual conversion (if, while, ?:,
<br>> etc).
<br>>=20
<br>> Reason: why would you ever want following code to compile?
<br>>=20
<br>> #include <string>
<br>>=20
<br>>=20
<br>> int bar(int) { return 1; }
<br>> void bar(int *) { }
<br>>=20
<br>>=20
<br>> void foo(std::string) {}
<br>> int foo(bool) { return 1; }
<br>>=20
<br>>=20
<br>> int main()
<br>> {
<br>> =C2=A0 =C2=A0auto t1 =3D bar(false);
<br>> =C2=A0 =C2=A0auto t2 =3D foo("");
<br>> =C2=A0 =C2=A0auto t3 =3D false + true + true;
<br>> }
<br>>=20
<br>>=20
<br>> For bar(), we don't know what was users intent, so it is in hi=
s best
<br>> interest to cast the bool value to int or int *.
<br>> For foo() the user most likely wanted the foo(std::string) overloa=
d
<br>> to be called.
<br>> For bool arithmetic operations, I think the user intent would be m=
uch
<br>> better stated if he used any_of(begin(range), end(range), identity=
)
<br>> (or its hand written equivalent), or fold expression when possible=
..
<br>>=20
<br>> This will fix some problems with variant construction that P0608R1
<br>> wants to fix.
<br>>=20
<br>
<br>Are you also proposing that the implicit conversion to bool in bool
<br>context be disallowed? If so, this may result in quite a bit of
<br>pushback:
<br>
<br>There are some useful constructs that rely in it, e.g.:
<br>
<br>assert(!"you made an error"); =C2=A0 // implicit conversion o=
f const char*
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // to bool=20
<br>
<br>if (auto p =3D get_thing()) { =C2=A0 =C2=A0 // implicit conversion to b=
ool in=20
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // bool context
<br>=C2=A0 =C2=A0p->fiddle();
<br>}
<br>
<br>It seems to me that another way to see the problem is that free
<br>function overloads can't be marked explicit?
<br>
<br>R
<br>
<br>> Regards,
<br>> Maciej
<br>>=20
<br>>=20
<br>>=20
<br>>=20
<br>> --=20
<br>> You received this message because you are subscribed to the Google
<br>> Groups "ISO C++ Standard - Future Proposals" group.
<br>> To unsubscribe from this group and stop receiving emails from it,
<br>> send an email to <a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"Ql4cfmdtAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascri=
pt:';return true;">std-proposal...@<wbr>isocpp.org</a>.
<br>> To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"Ql4cfmdtAwAJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hr=
ef=3D'javascript:';return true;">std-pr...@isocpp.org</a>.
<br>> To view this discussion on the web visit <a href=3D"https://groups=
..google.com/a/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'https://groups.google.com/a/';return true;" onclick=3D"this.hre=
f=3D'https://groups.google.com/a/';return true;">https://groups.goo=
gle.com/a/</a>
<br>> <a href=3D"http://isocpp.org/d/msgid/std-proposals/7afbe2f6-15b2-4=
2b0-a2f1-" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fisocpp.org%2Fd%2Fmsgid%2Fstd=
-proposals%2F7afbe2f6-15b2-42b0-a2f1-\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQ=
jCNGwmCgZPQXGAd7077oAlCRI7f_5xg';return true;" onclick=3D"this.href=3D&=
#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fisocpp.org%2Fd%2Fmsgid%2Fst=
d-proposals%2F7afbe2f6-15b2-42b0-a2f1-\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAF=
QjCNGwmCgZPQXGAd7077oAlCRI7f_5xg';return true;">isocpp.org/d/msgid/std-=
<wbr>proposals/7afbe2f6-15b2-42b0-<wbr>a2f1-</a>
<br>> 5ff042b59042%<a href=3D"http://40isocpp.org" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x=
3dhttp%3A%2F%2F40isocpp.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFDkh6mT=
A1MEK0W2avbBV54e4-UgA';return true;" onclick=3D"this.href=3D'http:/=
/www.google.com/url?q\x3dhttp%3A%2F%2F40isocpp.org\x26sa\x3dD\x26sntz\x3d1\=
x26usg\x3dAFQjCNFDkh6mTA1MEK0W2avbBV54e4-UgA';return true;">40isocpp.or=
g</a>.</blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/dc784fc9-ba4e-4e76-b72c-203e9af4cb53%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dc784fc9-ba4e-4e76-b72c-203e9af4cb53=
%40isocpp.org</a>.<br />
------=_Part_1293_1663669208.1519734282163--
------=_Part_1292_750284034.1519734282163--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Tue, 27 Feb 2018 17:02:43 -0800 (PST)
Raw View
------=_Part_3476_1833054061.1519779763586
Content-Type: multipart/alternative;
boundary="----=_Part_3477_1766466262.1519779763586"
------=_Part_3477_1766466262.1519779763586
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tuesday, February 27, 2018 at 3:28:55 AM UTC-8, m.ce...@gmail.com wrote:
>
> Hi,
>
> I propose to remove implicit conversion to and from bool type, and leave=
=20
> it only in as part of contextual conversion (if, while, ?:, etc).
>
> Reason: why would you ever want following code to compile?
>
> #include <string>
>
>
> int bar(int) { return 1; }
> void bar(int *) { }
>
>
> void foo(std::string) {}
> int foo(bool) { return 1; }
>
>
> int main()
> {
> auto t1 =3D bar(false);
> auto t2 =3D foo("");
> auto t3 =3D false + true + true;
> }
>
>
> For bar(), we don't know what was users intent, so it is in his best=20
> interest to cast the bool value to int or int *.
> For foo() the user most likely wanted the foo(std::string) overload to be=
=20
> called.
> For bool arithmetic operations, I think the user intent would be much=20
> better stated if he used any_of(begin(range), end(range), identity) (or i=
ts=20
> hand written equivalent), or fold expression when possible.
>
Your "t3" is uncomfortably close to the existing idiom
printf("Your cart has %d item%s\n", count, &"s"[count =3D=3D 1]);
This relies on the implicit integral promotion of bool to int.
Your "t2" looks highly motivating, but it is uncomfortably close to the=20
extremely widespread idiom
void assert_with_loc(bool Assertion, const std::string &Str);
DagInit *DI =3D ...;
assert_with_loc(DI, "Arguments must be...");
LLVM also (accidentally?) relies on the implicit promotion of bool to int=
=20
here:
llvm::raw_ostream::operator<<(int N) // many places try to stream out=
=20
bools, which quietly selects this overload in present-day C++
So your suggestion seems very likely to break a very large amount of=20
real-world code.
=E2=80=93Arthur
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/8169e6a2-348e-488f-bd5d-7ad9e6aade6a%40isocpp.or=
g.
------=_Part_3477_1766466262.1519779763586
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, February 27, 2018 at 3:28:55 AM UTC-8, m.ce...=
@gmail.com 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"l=
tr">Hi,<div><br></div><div>I propose to remove implicit conversion to and f=
rom bool type, and leave it only in as part of contextual conversion (if, w=
hile, ?:, etc).<div><br></div><div><div>Reason: why would you ever want fol=
lowing code to compile?</div><div><br></div><div style=3D"background-color:=
rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-wi=
dth:1px;word-wrap:break-word"><code><div><span style=3D"color:#800">#includ=
e</span><span style=3D"color:#000"> </span><span style=3D"color:#080"><s=
tring></span><span style=3D"color:#000"><br><br><br></span><span style=
=3D"color:#008">int</span><span style=3D"color:#000"> bar</span><span style=
=3D"color:#660">(</span><span style=3D"color:#008">int</span><span style=3D=
"color:#660">)</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#660">{</span><span style=3D"color:#000"> </span><span style=3D"color:#00=
8">return</span><span style=3D"color:#000"> </span><span style=3D"color:#06=
6">1</span><span style=3D"color:#660">;</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#660">}</span><span style=3D"color:#000"><br></s=
pan><span style=3D"color:#008">void</span><span style=3D"color:#000"> bar</=
span><span style=3D"color:#660">(</span><span style=3D"color:#008">int</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#660">*)</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#660">{</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#660">}</span><span style=
=3D"color:#000"><br><br><br></span><span style=3D"color:#008">void</span><s=
pan style=3D"color:#000"> foo</span><span style=3D"color:#660">(</span><spa=
n style=3D"color:#000">std</span><span style=3D"color:#660">::</span><span =
style=3D"color:#008">string</span><span style=3D"color:#660">)</span><span =
style=3D"color:#000"> </span><span style=3D"color:#660">{}</span><span styl=
e=3D"color:#000"><br></span><span style=3D"color:#008">int</span><span styl=
e=3D"color:#000"> foo</span><span style=3D"color:#660">(</span><span style=
=3D"color:#008">bool</span><span style=3D"color:#660">)</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">{</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#008">return</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#066">1</span><span style=3D"color:=
#660">;</span><span style=3D"color:#000"> </span><span style=3D"color:#660"=
>}</span><span style=3D"color:#000"><br><br><br></span><span style=3D"color=
:#008">int</span><span style=3D"color:#000"> main</span><span style=3D"colo=
r:#660">()</span><span style=3D"color:#000"><br></span><span style=3D"color=
:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0</span><span sty=
le=3D"color:#008">auto</span><span style=3D"color:#000"> t1 </span><span st=
yle=3D"color:#660">=3D</span><span style=3D"color:#000"> bar</span><span st=
yle=3D"color:#660">(</span><span style=3D"color:#008">false</span><span sty=
le=3D"color:#660">);</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0</sp=
an><span style=3D"color:#008">auto</span><span style=3D"color:#000"> t2 </s=
pan><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> foo</s=
pan><span style=3D"color:#660">(</span><span style=3D"color:#080">"&qu=
ot;</span><span style=3D"color:#660">);</span><span style=3D"color:#000"><b=
r>=C2=A0 =C2=A0</span><span style=3D"color:#008">auto</span><span style=3D"=
color:#000"> t3 </span><span style=3D"color:#660">=3D</span><span style=3D"=
color:#000"> </span><span style=3D"color:#008">false</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#660">+</span><span style=3D"color:=
#000"> </span><span style=3D"color:#008">true</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#660">+</span><span style=3D"color:#000"> =
</span><span style=3D"color:#008">true</span><span style=3D"color:#660">;</=
span><span style=3D"color:#000"><br></span><span style=3D"color:#660">}</sp=
an></div></code></div><div><div><br></div></div><div><br></div><div>For bar=
(), we don't know what was users intent, so it is in his best interest =
to cast the bool value to int or int *.</div><div>For foo() the user most l=
ikely wanted the foo(std::string) overload to be called.</div><div>For bool=
arithmetic operations, I think the user intent would be much better stated=
if he used any_of(begin(range), end(range), identity) (or its hand written=
equivalent), or fold expression when possible.</div></div></div></div></bl=
ockquote><div><br></div><div>Your "t3" is uncomfortably close to =
the existing idiom</div><div><br></div><div>=C2=A0 =C2=A0 printf("Your=
cart has %d item%s\n", count, &"s"[count =3D=3D 1]);</d=
iv><div><br></div><div>This relies on the implicit integral promotion of bo=
ol to int.</div><div><br></div><div>Your "t2" looks highly motiva=
ting, but it is uncomfortably close to the extremely widespread idiom</div>=
<div><br></div><div>=C2=A0 =C2=A0 void assert_with_loc(bool Assertion, cons=
t std::string &Str);</div><div>=C2=A0 =C2=A0 DagInit *DI =3D ...;</div>=
<div>=C2=A0 =C2=A0 assert_with_loc(DI, "Arguments must be...");</=
div><div><br></div><div>LLVM also (accidentally?) relies on the implicit pr=
omotion of bool to int here:<br></div><div><br></div><div>=C2=A0 =C2=A0 llv=
m::raw_ostream::operator<<(int N) =C2=A0 // many places try to stream=
out bools, which quietly selects this overload in present-day C++</div><di=
v><br></div><div>So your suggestion seems very likely to break a very large=
amount of real-world code.</div><div><br></div><div>=E2=80=93Arthur</div><=
/div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8169e6a2-348e-488f-bd5d-7ad9e6aade6a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8169e6a2-348e-488f-bd5d-7ad9e6aade6a=
%40isocpp.org</a>.<br />
------=_Part_3477_1766466262.1519779763586--
------=_Part_3476_1833054061.1519779763586--
.
Author: m.cencora@gmail.com
Date: Wed, 28 Feb 2018 01:16:56 -0800 (PST)
Raw View
------=_Part_4515_1605574133.1519809416550
Content-Type: multipart/alternative;
boundary="----=_Part_4516_490967339.1519809416551"
------=_Part_4516_490967339.1519809416551
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I am aware that this is a breaking change, but IMO cost of possible bugs=20
caused by existing from/to bool conversions outweighs the cost of=20
adaptation (which can be done in automatic way with tools like clang-tidy,=
=20
and still remains backward compatible after adaptation).
Question to all: do we want the language to follow developers intent as=20
much as possible (possibly with minor style inconvenience - e.g. explicit=
=20
casting to bool), or we say we can live with monsters hidden around the=20
corner. I vote for the former.
I have never encountered this printf idiom, and I find it rather strange=20
that you would use such a contrived expression, instead of ternary operator
printf("Your cart has %d item%s\n", count, count ? "s" : "");
Your another extremely widespread idiom assert_with_loc, I haven't=20
encountered either.
However it can be easily fixable with explicit bool casts, or turning this=
=20
assert_with_loc into macro, or converting it to a template that accepts=20
convertible to bool types as first param, or by introducing a implicit_bool=
=20
helper:
struct implicit_bool
{
template <typename T, typename =3D std::void_t<decltype(bool(std::declv=
al<
const T&>()))>>
implicit_bool(const T& v)
: value(bool(v))
{}
=20
explicit operator bool() const
{
return value;
}
private:
bool value;
};
Basically, I am yet to see a good implicit bool conversion usage example,=
=20
that wouldn't be easily fixable if we got rid of the implicit bool=20
conversions.
Regards,
Maciej
W dniu =C5=9Broda, 28 lutego 2018 02:02:43 UTC+1 u=C5=BCytkownik Arthur O'D=
wyer=20
napisa=C5=82:
>
> On Tuesday, February 27, 2018 at 3:28:55 AM UTC-8, m.ce...@gmail.com=20
> wrote:
>>
>> Hi,
>>
>> I propose to remove implicit conversion to and from bool type, and leave=
=20
>> it only in as part of contextual conversion (if, while, ?:, etc).
>>
>> Reason: why would you ever want following code to compile?
>>
>> #include <string>
>>
>>
>> int bar(int) { return 1; }
>> void bar(int *) { }
>>
>>
>> void foo(std::string) {}
>> int foo(bool) { return 1; }
>>
>>
>> int main()
>> {
>> auto t1 =3D bar(false);
>> auto t2 =3D foo("");
>> auto t3 =3D false + true + true;
>> }
>>
>>
>> For bar(), we don't know what was users intent, so it is in his best=20
>> interest to cast the bool value to int or int *.
>> For foo() the user most likely wanted the foo(std::string) overload to b=
e=20
>> called.
>> For bool arithmetic operations, I think the user intent would be much=20
>> better stated if he used any_of(begin(range), end(range), identity) (or =
its=20
>> hand written equivalent), or fold expression when possible.
>>
>
> Your "t3" is uncomfortably close to the existing idiom
>
> printf("Your cart has %d item%s\n", count, &"s"[count =3D=3D 1]);
>
> This relies on the implicit integral promotion of bool to int.
>
> Your "t2" looks highly motivating, but it is uncomfortably close to the=
=20
> extremely widespread idiom
>
> void assert_with_loc(bool Assertion, const std::string &Str);
> DagInit *DI =3D ...;
> assert_with_loc(DI, "Arguments must be...");
>
> LLVM also (accidentally?) relies on the implicit promotion of bool to int=
=20
> here:
>
> llvm::raw_ostream::operator<<(int N) // many places try to stream=
=20
> out bools, which quietly selects this overload in present-day C++
>
> So your suggestion seems very likely to break a very large amount of=20
> real-world code.
>
> =E2=80=93Arthur
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/4db2a89f-2f1e-4a08-95fc-b529674499d9%40isocpp.or=
g.
------=_Part_4516_490967339.1519809416551
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I am aware that this is a breaking change, but IMO cost of=
possible bugs caused by existing from/to bool conversions outweighs the co=
st of adaptation (which can be done in automatic way with tools like clang-=
tidy, and still remains backward compatible after adaptation).<div>Question=
to all: do we want the language to follow developers intent as much as pos=
sible (possibly with minor style inconvenience - e.g. explicit casting to b=
ool), or we say we can live with monsters hidden around the corner. I vote =
for the former.<br><div><div><br></div><div>I have never encountered this p=
rintf idiom, and I find it rather strange that you would use such a contriv=
ed expression, instead of ternary operator</div><div><div class=3D"prettypr=
int" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, =
187, 187); border-style: solid; border-width: 1px; word-wrap: break-word;">=
<code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">printf</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #080;" c=
lass=3D"styled-by-prettify">"Your cart has %d item%s\n"</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> count</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> count </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">?</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"style=
d-by-prettify">"s"</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #080;" class=3D"styled-by-prettify">"&qu=
ot;</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</spa=
n></div></code></div><br></div><div>Your another extremely widespread idiom=
assert_with_loc, I haven't encountered either.<br></div><div>However i=
t can be easily fixable with explicit bool casts, or turning this assert_wi=
th_loc into macro, or converting it to a template that accepts convertible =
to bool types as first param, or by introducing a implicit_bool helper:</di=
v><div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, =
250); border-color: rgb(187, 187, 187); border-style: solid; border-width: =
1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subp=
rettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">struc=
t</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> implicit=
_bool<br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0=
=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">te=
mplate</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">typename</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">voi=
d_t</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">decltype</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">bool</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</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: #000;" class=
=3D"styled-by-prettify">declval</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify"><</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">const</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&>()))>></span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br>=C2=A0 =C2=A0 implicit_bool</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">const</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">&</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> v</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0=
=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> val=
ue</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">bool</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">v</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">))</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">{}</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">explicit</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">operator</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;"=
class=3D"styled-by-prettify">bool</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: #008;" class=3D"styled-by-pre=
ttify">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> value</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
private</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">boo=
l</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> value</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">};</span></div></code></div>=
<div><br></div></div><div><br><div>Basically, I am yet to see a good implic=
it bool conversion usage example, that wouldn't be easily fixable if we=
got rid of the implicit bool conversions.</div><div><br></div><div>Regards=
,</div><div>Maciej<br><div><br><br>W dniu =C5=9Broda, 28 lutego 2018 02:02:=
43 UTC+1 u=C5=BCytkownik Arthur O'Dwyer napisa=C5=82:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr">On Tuesday, February 27, 2018 =
at 3:28:55 AM UTC-8, <a>m.ce...@gmail.com</a> wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr">Hi,<div><br></div><div>I propose to remov=
e implicit conversion to and from bool type, and leave it only in as part o=
f contextual conversion (if, while, ?:, etc).<div><br></div><div><div>Reaso=
n: why would you ever want following code to compile?</div><div><br></div><=
div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187=
);border-style:solid;border-width:1px;word-wrap:break-word"><code><div><spa=
n style=3D"color:#800">#include</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#080"><string></span><span style=3D"color:#000"><b=
r><br><br></span><span style=3D"color:#008">int</span><span style=3D"color:=
#000"> bar</span><span style=3D"color:#660">(</span><span style=3D"color:#0=
08">int</span><span style=3D"color:#660">)</span><span style=3D"color:#000"=
> </span><span style=3D"color:#660">{</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#008">return</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#066">1</span><span style=3D"color:#660">;</span><=
span style=3D"color:#000"> </span><span style=3D"color:#660">}</span><span =
style=3D"color:#000"><br></span><span style=3D"color:#008">void</span><span=
style=3D"color:#000"> bar</span><span style=3D"color:#660">(</span><span s=
tyle=3D"color:#008">int</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#660">*)</span><span style=3D"color:#000"> </span><span style=3D=
"color:#660">{</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#660">}</span><span style=3D"color:#000"><br><br><br></span><span style=
=3D"color:#008">void</span><span style=3D"color:#000"> foo</span><span styl=
e=3D"color:#660">(</span><span style=3D"color:#000">std</span><span style=
=3D"color:#660">::</span><span style=3D"color:#008">string</span><span styl=
e=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=3D"=
color:#660">{}</span><span style=3D"color:#000"><br></span><span style=3D"c=
olor:#008">int</span><span style=3D"color:#000"> foo</span><span style=3D"c=
olor:#660">(</span><span style=3D"color:#008">bool</span><span style=3D"col=
or:#660">)</span><span style=3D"color:#000"> </span><span style=3D"color:#6=
60">{</span><span style=3D"color:#000"> </span><span style=3D"color:#008">r=
eturn</span><span style=3D"color:#000"> </span><span style=3D"color:#066">1=
</span><span style=3D"color:#660">;</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#660">}</span><span style=3D"color:#000"><br><br><br=
></span><span style=3D"color:#008">int</span><span style=3D"color:#000"> ma=
in</span><span style=3D"color:#660">()</span><span style=3D"color:#000"><br=
></span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=
=C2=A0 =C2=A0</span><span style=3D"color:#008">auto</span><span style=3D"co=
lor:#000"> t1 </span><span style=3D"color:#660">=3D</span><span style=3D"co=
lor:#000"> bar</span><span style=3D"color:#660">(</span><span style=3D"colo=
r:#008">false</span><span style=3D"color:#660">);</span><span style=3D"colo=
r:#000"><br>=C2=A0 =C2=A0</span><span style=3D"color:#008">auto</span><span=
style=3D"color:#000"> t2 </span><span style=3D"color:#660">=3D</span><span=
style=3D"color:#000"> foo</span><span style=3D"color:#660">(</span><span s=
tyle=3D"color:#080">""</span><span style=3D"color:#660">);</span>=
<span style=3D"color:#000"><br>=C2=A0 =C2=A0</span><span style=3D"color:#00=
8">auto</span><span style=3D"color:#000"> t3 </span><span style=3D"color:#6=
60">=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#008"=
>false</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=
+</span><span style=3D"color:#000"> </span><span style=3D"color:#008">true<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#660">+</span=
><span style=3D"color:#000"> </span><span style=3D"color:#008">true</span><=
span style=3D"color:#660">;</span><span style=3D"color:#000"><br></span><sp=
an style=3D"color:#660">}</span></div></code></div><div><div><br></div></di=
v><div><br></div><div>For bar(), we don't know what was users intent, s=
o it is in his best interest to cast the bool value to int or int *.</div><=
div>For foo() the user most likely wanted the foo(std::string) overload to =
be called.</div><div>For bool arithmetic operations, I think the user inten=
t would be much better stated if he used any_of(begin(range), end(range), i=
dentity) (or its hand written equivalent), or fold expression when possible=
..</div></div></div></div></blockquote><div><br></div><div>Your "t3&quo=
t; is uncomfortably close to the existing idiom</div><div><br></div><div>=
=C2=A0 =C2=A0 printf("Your cart has %d item%s\n", count, &&qu=
ot;s"[count =3D=3D 1]);</div><div><br></div><div>This relies on the im=
plicit integral promotion of bool to int.</div><div><br></div><div>Your &qu=
ot;t2" looks highly motivating, but it is uncomfortably close to the e=
xtremely widespread idiom</div><div><br></div><div>=C2=A0 =C2=A0 void asser=
t_with_loc(bool Assertion, const std::string &Str);</div><div>=C2=A0 =
=C2=A0 DagInit *DI =3D ...;</div><div>=C2=A0 =C2=A0 assert_with_loc(DI, &qu=
ot;Arguments must be...");</div><div><br></div><div>LLVM also (acciden=
tally?) relies on the implicit promotion of bool to int here:<br></div><div=
><br></div><div>=C2=A0 =C2=A0 llvm::raw_ostream::operator<<(<wbr>int =
N) =C2=A0 // many places try to stream out bools, which quietly selects thi=
s overload in present-day C++</div><div><br></div><div>So your suggestion s=
eems very likely to break a very large amount of real-world code.</div><div=
><br></div><div>=E2=80=93Arthur</div></div></blockquote></div></div></div><=
/div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/4db2a89f-2f1e-4a08-95fc-b529674499d9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4db2a89f-2f1e-4a08-95fc-b529674499d9=
%40isocpp.org</a>.<br />
------=_Part_4516_490967339.1519809416551--
------=_Part_4515_1605574133.1519809416550--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 28 Feb 2018 09:56:32 -0800
Raw View
--94eb2c04e7eea8163605664976d6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On 28 Feb 2018 01:16, <m.cencora@gmail.com> wrote:
I am aware that this is a breaking change, but IMO cost of possible bugs
caused by existing from/to bool conversions outweighs the cost of
adaptation (which can be done in automatic way with tools like clang-tidy,
and still remains backward compatible after adaptation).
Have you done any investigation into diagnostic rates (diagnostics per
million lines of code, true positive versus false positive rates, and so
on) for this change? These are things we'd consider when adding an
enabled-by-default warning into our compiler; surely the bar should be
higher for a language change.
Is there some existing compiler that implements exactly what you're
proposing as a warning? If so, what lessons have been learned from that
warning implementation? And if not, perhaps you should consider starting by
adding such a warning to get a handle on the impact of this change?
(Also of note: a QoI warning can employ arbitrarily complex heuristics to
get the false positive rate down and can adapt as more false positive cases
are discovered; a language rule cannot. Subtle semantic "this might be a
bug"" diagnostics are often better off being compiler warnings rather than
language rules as a result. This is a lesson I hope we would have learned
from the pain of "narrowing conversions".)
Question to all: do we want the language to follow developers intent as
much as possible (possibly with minor style inconvenience - e.g. explicit
casting to bool), or we say we can live with monsters hidden around the
corner. I vote for the former.
I have never encountered this printf idiom, and I find it rather strange
that you would use such a contrived expression, instead of ternary operator
printf("Your cart has %d item%s\n", count, count ? "s" : "");
Your another extremely widespread idiom assert_with_loc, I haven't
encountered either.
However it can be easily fixable with explicit bool casts, or turning this
assert_with_loc into macro, or converting it to a template that accepts
convertible to bool types as first param, or by introducing a implicit_bool
helper:
struct implicit_bool
{
template <typename T, typename =3D std::void_t<decltype(bool(std::declv=
al<
const T&>()))>>
implicit_bool(const T& v)
: value(bool(v))
{}
explicit operator bool() const
{
return value;
}
private:
bool value;
};
Basically, I am yet to see a good implicit bool conversion usage example,
that wouldn't be easily fixable if we got rid of the implicit bool
conversions.
Regards,
Maciej
W dniu =C5=9Broda, 28 lutego 2018 02:02:43 UTC+1 u=C5=BCytkownik Arthur O'D=
wyer
napisa=C5=82:
>
> On Tuesday, February 27, 2018 at 3:28:55 AM UTC-8, m.ce...@gmail.com
> wrote:
>>
>> Hi,
>>
>> I propose to remove implicit conversion to and from bool type, and leave
>> it only in as part of contextual conversion (if, while, ?:, etc).
>>
>> Reason: why would you ever want following code to compile?
>>
>> #include <string>
>>
>>
>> int bar(int) { return 1; }
>> void bar(int *) { }
>>
>>
>> void foo(std::string) {}
>> int foo(bool) { return 1; }
>>
>>
>> int main()
>> {
>> auto t1 =3D bar(false);
>> auto t2 =3D foo("");
>> auto t3 =3D false + true + true;
>> }
>>
>>
>> For bar(), we don't know what was users intent, so it is in his best
>> interest to cast the bool value to int or int *.
>> For foo() the user most likely wanted the foo(std::string) overload to b=
e
>> called.
>> For bool arithmetic operations, I think the user intent would be much
>> better stated if he used any_of(begin(range), end(range), identity) (or =
its
>> hand written equivalent), or fold expression when possible.
>>
>
> Your "t3" is uncomfortably close to the existing idiom
>
> printf("Your cart has %d item%s\n", count, &"s"[count =3D=3D 1]);
>
> This relies on the implicit integral promotion of bool to int.
>
> Your "t2" looks highly motivating, but it is uncomfortably close to the
> extremely widespread idiom
>
> void assert_with_loc(bool Assertion, const std::string &Str);
> DagInit *DI =3D ...;
> assert_with_loc(DI, "Arguments must be...");
>
> LLVM also (accidentally?) relies on the implicit promotion of bool to int
> here:
>
> llvm::raw_ostream::operator<<(int N) // many places try to stream
> out bools, which quietly selects this overload in present-day C++
>
> So your suggestion seems very likely to break a very large amount of
> real-world code.
>
> =E2=80=93Arthur
>
--=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
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/4db2a89f-2f1e-4a08-
95fc-b529674499d9%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4db2a89f-2f1e=
-4a08-95fc-b529674499d9%40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter=
>
..
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOfiQqmaxxfMNBeKn22UQE7%2B_WnR4tM7FgwxbDnBumqYj=
R0KuA%40mail.gmail.com.
--94eb2c04e7eea8163605664976d6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><div class=3D"gmail_extra"><div class=3D"gmail_quote=
">On 28 Feb 2018 01:16, <<a href=3D"mailto:m.cencora@gmail.com">m.cenco=
ra@gmail.com</a>> wrote:<br type=3D"attribution"><blockquote class=3D"qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr">I am aware that this is a breaking change, but IMO cost =
of possible bugs caused by existing from/to bool conversions outweighs the =
cost of adaptation (which can be done in automatic way with tools like clan=
g-tidy, and still remains backward compatible after adaptation).</div></blo=
ckquote></div></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">Hav=
e you done any investigation into diagnostic rates (diagnostics per million=
lines of code, true positive versus false positive rates, and so on) for t=
his change? These are things we'd consider when adding an enabled-by-de=
fault warning into our compiler; surely the bar should be higher for a lang=
uage change.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Is there so=
me existing compiler that implements exactly what you're proposing as a=
warning? If so, what lessons have been learned from that warning implement=
ation? And if not, perhaps you should consider starting by adding such a wa=
rning to get a handle on the impact of this change?</div><div dir=3D"auto">=
<span style=3D"font-family:sans-serif"><br></span></div><div dir=3D"auto"><=
span style=3D"font-family:sans-serif">(Also of note: a QoI warning can empl=
oy arbitrarily complex heuristics to get the false positive rate down and c=
an adapt as more false positive cases are discovered; a language rule canno=
t. Subtle semantic "this might be a bug"" diagnostics are of=
ten better off being compiler warnings rather than language rules as a resu=
lt. This is a lesson I hope we would have learned from the pain of "na=
rrowing conversions".)</span></div><div dir=3D"auto"><br></div><div di=
r=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquot=
e class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div>Question to all: do we want the langua=
ge to follow developers intent as much as possible (possibly with minor sty=
le inconvenience - e.g. explicit casting to bool), or we say we can live wi=
th monsters hidden around the corner. I vote for the former.<br><div><div><=
br></div><div>I have never encountered this printf idiom, and I find it rat=
her strange that you would use such a contrived expression, instead of tern=
ary operator</div><div><div class=3D"m_-2954288624805489521prettyprint" sty=
le=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);borde=
r-style:solid;border-width:1px;word-wrap:break-word"><code class=3D"m_-2954=
288624805489521prettyprint"><div class=3D"m_-2954288624805489521subprettypr=
int"><span style=3D"color:#000" class=3D"m_-2954288624805489521styled-by-pr=
ettify">printf</span><span style=3D"color:#660" class=3D"m_-295428862480548=
9521styled-by-prettify">(</span><span style=3D"color:#080" class=3D"m_-2954=
288624805489521styled-by-prettify">"Your cart has %d item%s\n"</s=
pan><span style=3D"color:#660" class=3D"m_-2954288624805489521styled-by-pre=
ttify">,</span><span style=3D"color:#000" class=3D"m_-2954288624805489521st=
yled-by-prettify"> count</span><span style=3D"color:#660" class=3D"m_-29542=
88624805489521styled-by-prettify">,</span><span style=3D"color:#000" class=
=3D"m_-2954288624805489521styled-by-prettify"> count </span><span style=3D"=
color:#660" class=3D"m_-2954288624805489521styled-by-prettify">?</span><spa=
n style=3D"color:#000" class=3D"m_-2954288624805489521styled-by-prettify"> =
</span><span style=3D"color:#080" class=3D"m_-2954288624805489521styled-by-=
prettify">"s"</span><span style=3D"color:#000" class=3D"m_-295428=
8624805489521styled-by-prettify"> </span><span style=3D"color:#660" class=
=3D"m_-2954288624805489521styled-by-prettify">:</span><span style=3D"color:=
#000" class=3D"m_-2954288624805489521styled-by-prettify"> </span><span styl=
e=3D"color:#080" class=3D"m_-2954288624805489521styled-by-prettify">"&=
quot;</span><span style=3D"color:#660" class=3D"m_-2954288624805489521style=
d-by-prettify">);</span></div></code></div><br></div><div>Your another extr=
emely widespread idiom assert_with_loc, I haven't encountered either.<b=
r></div><div>However it can be easily fixable with explicit bool casts, or =
turning this assert_with_loc into macro, or converting it to a template tha=
t accepts convertible to bool types as first param, or by introducing a imp=
licit_bool helper:</div><div><div class=3D"m_-2954288624805489521prettyprin=
t" style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187)=
;border-style:solid;border-width:1px;word-wrap:break-word"><code class=3D"m=
_-2954288624805489521prettyprint"><div class=3D"m_-2954288624805489521subpr=
ettyprint"><span style=3D"color:#008" class=3D"m_-2954288624805489521styled=
-by-prettify">struct</span><span style=3D"color:#000" class=3D"m_-295428862=
4805489521styled-by-prettify"> implicit_bool<br></span><span style=3D"color=
:#660" class=3D"m_-2954288624805489521styled-by-prettify">{</span><span sty=
le=3D"color:#000" class=3D"m_-2954288624805489521styled-by-prettify"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color:#008" class=3D"m_-295428862480548=
9521styled-by-prettify">template</span><span style=3D"color:#000" class=3D"=
m_-2954288624805489521styled-by-prettify"> </span><span style=3D"color:#660=
" class=3D"m_-2954288624805489521styled-by-prettify"><</span><span style=
=3D"color:#008" class=3D"m_-2954288624805489521styled-by-prettify">typename=
</span><span style=3D"color:#000" class=3D"m_-2954288624805489521styled-by-=
prettify"> T</span><span style=3D"color:#660" class=3D"m_-29542886248054895=
21styled-by-prettify">,</span><span style=3D"color:#000" class=3D"m_-295428=
8624805489521styled-by-prettify"> </span><span style=3D"color:#008" class=
=3D"m_-2954288624805489521styled-by-prettify">typename</span><span style=3D=
"color:#000" class=3D"m_-2954288624805489521styled-by-prettify"> </span><sp=
an style=3D"color:#660" class=3D"m_-2954288624805489521styled-by-prettify">=
=3D</span><span style=3D"color:#000" class=3D"m_-2954288624805489521styled-=
by-prettify"> std</span><span style=3D"color:#660" class=3D"m_-295428862480=
5489521styled-by-prettify">::</span><span style=3D"color:#000" class=3D"m_-=
2954288624805489521styled-by-prettify">void_t</span><span style=3D"color:#6=
60" class=3D"m_-2954288624805489521styled-by-prettify"><</span><span sty=
le=3D"color:#008" class=3D"m_-2954288624805489521styled-by-prettify">declty=
pe</span><span style=3D"color:#660" class=3D"m_-2954288624805489521styled-b=
y-prettify">(</span><span style=3D"color:#008" class=3D"m_-2954288624805489=
521styled-by-prettify">bool</span><span style=3D"color:#660" class=3D"m_-29=
54288624805489521styled-by-prettify">(</span><span style=3D"color:#000" cla=
ss=3D"m_-2954288624805489521styled-by-prettify">std</span><span style=3D"co=
lor:#660" class=3D"m_-2954288624805489521styled-by-prettify">:<wbr>:</span>=
<span style=3D"color:#000" class=3D"m_-2954288624805489521styled-by-prettif=
y">declval</span><span style=3D"color:#660" class=3D"m_-2954288624805489521=
styled-by-prettify"><</span><span style=3D"color:#008" class=3D"m_-29542=
88624805489521styled-by-prettify">const</span><span style=3D"color:#000" cl=
ass=3D"m_-2954288624805489521styled-by-prettify"> T</span><span style=3D"co=
lor:#660" class=3D"m_-2954288624805489521styled-by-prettify">&>()))&=
gt;></span><span style=3D"color:#000" class=3D"m_-2954288624805489521sty=
led-by-prettify"><br>=C2=A0 =C2=A0 implicit_bool</span><span style=3D"color=
:#660" class=3D"m_-2954288624805489521styled-by-prettify">(</span><span sty=
le=3D"color:#008" class=3D"m_-2954288624805489521styled-by-prettify">const<=
/span><span style=3D"color:#000" class=3D"m_-2954288624805489521styled-by-p=
rettify"> T</span><span style=3D"color:#660" class=3D"m_-295428862480548952=
1styled-by-prettify">&</span><span style=3D"color:#000" class=3D"m_-295=
4288624805489521styled-by-prettify"> v</span><span style=3D"color:#660" cla=
ss=3D"m_-2954288624805489521styled-by-prettify">)</span><span style=3D"colo=
r:#000" class=3D"m_-2954288624805489521styled-by-prettify"><br>=C2=A0 =C2=
=A0 =C2=A0 </span><span style=3D"color:#660" class=3D"m_-295428862480548952=
1styled-by-prettify">:</span><span style=3D"color:#000" class=3D"m_-2954288=
624805489521styled-by-prettify"> value</span><span style=3D"color:#660" cla=
ss=3D"m_-2954288624805489521styled-by-prettify">(</span><span style=3D"colo=
r:#008" class=3D"m_-2954288624805489521styled-by-prettify">bool</span><span=
style=3D"color:#660" class=3D"m_-2954288624805489521styled-by-prettify">(<=
/span><span style=3D"color:#000" class=3D"m_-2954288624805489521styled-by-p=
rettify">v</span><span style=3D"color:#660" class=3D"m_-2954288624805489521=
styled-by-prettify">))</span><span style=3D"color:#000" class=3D"m_-2954288=
624805489521styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"col=
or:#660" class=3D"m_-2954288624805489521styled-by-prettify">{}</span><span =
style=3D"color:#000" class=3D"m_-2954288624805489521styled-by-prettify"><br=
>=C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 </span><span style=3D"color:#008" class=3D=
"m_-2954288624805489521styled-by-prettify">explicit</span><span style=3D"co=
lor:#000" class=3D"m_-2954288624805489521styled-by-prettify"> </span><span =
style=3D"color:#008" class=3D"m_-2954288624805489521styled-by-prettify">ope=
rator</span><span style=3D"color:#000" class=3D"m_-2954288624805489521style=
d-by-prettify"> </span><span style=3D"color:#008" class=3D"m_-2954288624805=
489521styled-by-prettify">bool</span><span style=3D"color:#660" class=3D"m_=
-2954288624805489521styled-by-prettify">()</span><span style=3D"color:#000"=
class=3D"m_-2954288624805489521styled-by-prettify"> </span><span style=3D"=
color:#008" class=3D"m_-2954288624805489521styled-by-prettify">const</span>=
<span style=3D"color:#000" class=3D"m_-2954288624805489521styled-by-prettif=
y"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660" class=3D"m_-29542886=
24805489521styled-by-prettify">{</span><span style=3D"color:#000" class=3D"=
m_-2954288624805489521styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <=
/span><span style=3D"color:#008" class=3D"m_-2954288624805489521styled-by-p=
rettify">return</span><span style=3D"color:#000" class=3D"m_-29542886248054=
89521styled-by-prettify"> value</span><span style=3D"color:#660" class=3D"m=
_-2954288624805489521styled-by-prettify">;</span><span style=3D"color:#000"=
class=3D"m_-2954288624805489521styled-by-prettify"><br>=C2=A0 =C2=A0 </spa=
n><span style=3D"color:#660" class=3D"m_-2954288624805489521styled-by-prett=
ify">}</span><span style=3D"color:#000" class=3D"m_-2954288624805489521styl=
ed-by-prettify"><br></span><span style=3D"color:#008" class=3D"m_-295428862=
4805489521styled-by-prettify">private</span><span style=3D"color:#660" clas=
s=3D"m_-2954288624805489521styled-by-prettify">:</span><span style=3D"color=
:#000" class=3D"m_-2954288624805489521styled-by-prettify"><br>=C2=A0 =C2=A0=
</span><span style=3D"color:#008" class=3D"m_-2954288624805489521styled-by=
-prettify">bool</span><span style=3D"color:#000" class=3D"m_-29542886248054=
89521styled-by-prettify"> value</span><span style=3D"color:#660" class=3D"m=
_-2954288624805489521styled-by-prettify">;</span><span style=3D"color:#000"=
class=3D"m_-2954288624805489521styled-by-prettify"><br></span><span style=
=3D"color:#660" class=3D"m_-2954288624805489521styled-by-prettify">};</span=
></div></code></div><div><br></div></div><div><br><div>Basically, I am yet =
to see a good implicit bool conversion usage example, that wouldn't be =
easily fixable if we got rid of the implicit bool conversions.</div><div><b=
r></div><div>Regards,</div><div>Maciej<div class=3D"elided-text"><br><div><=
br><br>W dniu =C5=9Broda, 28 lutego 2018 02:02:43 UTC+1 u=C5=BCytkownik Art=
hur O'Dwyer napisa=C5=82:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">On Tuesday, February 27, 2018 at 3:28:55 AM UTC-8, <a>m.ce...@gm=
ail.com</a> 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"ltr">=
Hi,<div><br></div><div>I propose to remove implicit conversion to and from =
bool type, and leave it only in as part of contextual conversion (if, while=
, ?:, etc).<div><br></div><div><div>Reason: why would you ever want followi=
ng code to compile?</div><div><br></div><div style=3D"background-color:rgb(=
250,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:=
1px;word-wrap:break-word"><code><div><span style=3D"color:#800">#include</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#080"><strin=
g></span><span style=3D"color:#000"><br><br><br></span><span style=3D"co=
lor:#008">int</span><span style=3D"color:#000"> bar</span><span style=3D"co=
lor:#660">(</span><span style=3D"color:#008">int</span><span style=3D"color=
:#660">)</span><span style=3D"color:#000"> </span><span style=3D"color:#660=
">{</span><span style=3D"color:#000"> </span><span style=3D"color:#008">ret=
urn</span><span style=3D"color:#000"> </span><span style=3D"color:#066">1</=
span><span style=3D"color:#660">;</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#660">}</span><span style=3D"color:#000"><br></span><s=
pan style=3D"color:#008">void</span><span style=3D"color:#000"> bar</span><=
span style=3D"color:#660">(</span><span style=3D"color:#008">int</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#660">*)</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#660">{</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">}</span><span style=3D"c=
olor:#000"><br><br><br></span><span style=3D"color:#008">void</span><span s=
tyle=3D"color:#000"> foo</span><span style=3D"color:#660">(</span><span sty=
le=3D"color:#000">std</span><span style=3D"color:#660">::</span><span style=
=3D"color:#008">string</span><span style=3D"color:#660">)</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">{}</span><span style=3D"=
color:#000"><br></span><span style=3D"color:#008">int</span><span style=3D"=
color:#000"> foo</span><span style=3D"color:#660">(</span><span style=3D"co=
lor:#008">bool</span><span style=3D"color:#660">)</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#660">{</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#008">return</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#066">1</span><span style=3D"color:#660">;<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#660">}</span=
><span style=3D"color:#000"><br><br><br></span><span style=3D"color:#008">i=
nt</span><span style=3D"color:#000"> main</span><span style=3D"color:#660">=
()</span><span style=3D"color:#000"><br></span><span style=3D"color:#660">{=
</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0</span><span style=3D"co=
lor:#008">auto</span><span style=3D"color:#000"> t1 </span><span style=3D"c=
olor:#660">=3D</span><span style=3D"color:#000"> bar</span><span style=3D"c=
olor:#660">(</span><span style=3D"color:#008">false</span><span style=3D"co=
lor:#660">);</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0</span><span=
style=3D"color:#008">auto</span><span style=3D"color:#000"> t2 </span><spa=
n style=3D"color:#660">=3D</span><span style=3D"color:#000"> foo</span><spa=
n style=3D"color:#660">(</span><span style=3D"color:#080">""</spa=
n><span style=3D"color:#660">);</span><span style=3D"color:#000"><br>=C2=A0=
=C2=A0</span><span style=3D"color:#008">auto</span><span style=3D"color:#0=
00"> t3 </span><span style=3D"color:#660">=3D</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#008">false</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#660">+</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#008">true</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#660">+</span><span style=3D"color:#000"> </span><=
span style=3D"color:#008">true</span><span style=3D"color:#660">;</span><sp=
an style=3D"color:#000"><br></span><span style=3D"color:#660">}</span></div=
></code></div><div><div><br></div></div><div><br></div><div>For bar(), we d=
on't know what was users intent, so it is in his best interest to cast =
the bool value to int or int *.</div><div>For foo() the user most likely wa=
nted the foo(std::string) overload to be called.</div><div>For bool arithme=
tic operations, I think the user intent would be much better stated if he u=
sed any_of(begin(range), end(range), identity) (or its hand written equival=
ent), or fold expression when possible.</div></div></div></div></blockquote=
><div><br></div><div>Your "t3" is uncomfortably close to the exis=
ting idiom</div><div><br></div><div>=C2=A0 =C2=A0 printf("Your cart ha=
s %d item%s\n", count, &"s"[count =3D=3D 1]);</div><div>=
<br></div><div>This relies on the implicit integral promotion of bool to in=
t.</div><div><br></div><div>Your "t2" looks highly motivating, bu=
t it is uncomfortably close to the extremely widespread idiom</div><div><br=
></div><div>=C2=A0 =C2=A0 void assert_with_loc(bool Assertion, const std::s=
tring &Str);</div><div>=C2=A0 =C2=A0 DagInit *DI =3D ...;</div><div>=C2=
=A0 =C2=A0 assert_with_loc(DI, "Arguments must be...");</div><div=
><br></div><div>LLVM also (accidentally?) relies on the implicit promotion =
of bool to int here:<br></div><div><br></div><div>=C2=A0 =C2=A0 llvm::raw_o=
stream::operator<<(<wbr>int N) =C2=A0 // many places try to stream ou=
t bools, which quietly selects this overload in present-day C++</div><div><=
br></div><div>So your suggestion seems very likely to break a very large am=
ount of real-world code.</div><div><br></div><div>=E2=80=93Arthur</div></di=
v></blockquote></div></div></div></div></div></div></div><div class=3D"elid=
ed-text">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4db2a89f-2f1e-4a08-95fc-b529674499d9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/4db2=
a89f-2f1e-4a08-<wbr>95fc-b529674499d9%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAOfiQqmaxxfMNBeKn22UQE7%2B_WnR4tM7Fg=
wxbDnBumqYjR0KuA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqmaxxfMNB=
eKn22UQE7%2B_WnR4tM7FgwxbDnBumqYjR0KuA%40mail.gmail.com</a>.<br />
--94eb2c04e7eea8163605664976d6--
.
Author: m.cencora@gmail.com
Date: Fri, 2 Mar 2018 02:18:08 -0800 (PST)
Raw View
------=_Part_4221_700012868.1519985888670
Content-Type: multipart/alternative;
boundary="----=_Part_4222_479066810.1519985888671"
------=_Part_4222_479066810.1519985888671
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Of course I haven't - otherwise I'd state it instead of saying 'IMO'.
Compilers I use (gcc and clang) have no options that would report warnings=
=20
for all places where I propose to remove implicit bool conversions (as you=
=20
are aware for sure as one of main clang developers).
I am not compiler developer (as you most likely know - otherwise my name=20
would be familiar to you since there are so few), so no I'm not going to=20
spend weeks on understanding how compiler works in order to implement this=
=20
feature, then studying gcc/clang compiler code to implement this feature.
It is completely unreasonable to expect that anyone not already involved in=
=20
C++ compiler development would do this.
If that's a requirement for any new C++ language feature/change then just=
=20
state that, and you will save time of all one-time "contributors", and=20
everyone on this forum.
Regards,
Maciej
W dniu =C5=9Broda, 28 lutego 2018 18:56:41 UTC+1 u=C5=BCytkownik Richard Sm=
ith=20
napisa=C5=82:
>
> On 28 Feb 2018 01:16, <m.ce...@gmail.com <javascript:>> wrote:
>
> I am aware that this is a breaking change, but IMO cost of possible bugs=
=20
> caused by existing from/to bool conversions outweighs the cost of=20
> adaptation (which can be done in automatic way with tools like clang-tidy=
,=20
> and still remains backward compatible after adaptation).
>
>
> Have you done any investigation into diagnostic rates (diagnostics per=20
> million lines of code, true positive versus false positive rates, and so=
=20
> on) for this change? These are things we'd consider when adding an=20
> enabled-by-default warning into our compiler; surely the bar should be=20
> higher for a language change.
>
> Is there some existing compiler that implements exactly what you're=20
> proposing as a warning? If so, what lessons have been learned from that=
=20
> warning implementation? And if not, perhaps you should consider starting =
by=20
> adding such a warning to get a handle on the impact of this change?
>
> (Also of note: a QoI warning can employ arbitrarily complex heuristics to=
=20
> get the false positive rate down and can adapt as more false positive cas=
es=20
> are discovered; a language rule cannot. Subtle semantic "this might be a=
=20
> bug"" diagnostics are often better off being compiler warnings rather tha=
n=20
> language rules as a result. This is a lesson I hope we would have learned=
=20
> from the pain of "narrowing conversions".)
>
> Question to all: do we want the language to follow developers intent as=
=20
> much as possible (possibly with minor style inconvenience - e.g. explicit=
=20
> casting to bool), or we say we can live with monsters hidden around the=
=20
> corner. I vote for the former.
>
> I have never encountered this printf idiom, and I find it rather strange=
=20
> that you would use such a contrived expression, instead of ternary operat=
or
> printf("Your cart has %d item%s\n", count, count ? "s" : "");
>
> Your another extremely widespread idiom assert_with_loc, I haven't=20
> encountered either.
> However it can be easily fixable with explicit bool casts, or turning thi=
s=20
> assert_with_loc into macro, or converting it to a template that accepts=
=20
> convertible to bool types as first param, or by introducing a implicit_bo=
ol=20
> helper:
> struct implicit_bool
> {
> template <typename T, typename =3D std::void_t<decltype(bool(std::
> declval<const T&>()))>>
> implicit_bool(const T& v)
> : value(bool(v))
> {}
> =20
> explicit operator bool() const
> {
> return value;
> }
> private:
> bool value;
> };
>
>
> Basically, I am yet to see a good implicit bool conversion usage example,=
=20
> that wouldn't be easily fixable if we got rid of the implicit bool=20
> conversions.
>
> Regards,
> Maciej
>
>
>
> W dniu =C5=9Broda, 28 lutego 2018 02:02:43 UTC+1 u=C5=BCytkownik Arthur O=
'Dwyer=20
> napisa=C5=82:
>>
>> On Tuesday, February 27, 2018 at 3:28:55 AM UTC-8, m.ce...@gmail.com=20
>> wrote:
>>>
>>> Hi,
>>>
>>> I propose to remove implicit conversion to and from bool type, and leav=
e=20
>>> it only in as part of contextual conversion (if, while, ?:, etc).
>>>
>>> Reason: why would you ever want following code to compile?
>>>
>>> #include <string>
>>>
>>>
>>> int bar(int) { return 1; }
>>> void bar(int *) { }
>>>
>>>
>>> void foo(std::string) {}
>>> int foo(bool) { return 1; }
>>>
>>>
>>> int main()
>>> {
>>> auto t1 =3D bar(false);
>>> auto t2 =3D foo("");
>>> auto t3 =3D false + true + true;
>>> }
>>>
>>>
>>> For bar(), we don't know what was users intent, so it is in his best=20
>>> interest to cast the bool value to int or int *.
>>> For foo() the user most likely wanted the foo(std::string) overload to=
=20
>>> be called.
>>> For bool arithmetic operations, I think the user intent would be much=
=20
>>> better stated if he used any_of(begin(range), end(range), identity) (or=
its=20
>>> hand written equivalent), or fold expression when possible.
>>>
>>
>> Your "t3" is uncomfortably close to the existing idiom
>>
>> printf("Your cart has %d item%s\n", count, &"s"[count =3D=3D 1]);
>>
>> This relies on the implicit integral promotion of bool to int.
>>
>> Your "t2" looks highly motivating, but it is uncomfortably close to the=
=20
>> extremely widespread idiom
>>
>> void assert_with_loc(bool Assertion, const std::string &Str);
>> DagInit *DI =3D ...;
>> assert_with_loc(DI, "Arguments must be...");
>>
>> LLVM also (accidentally?) relies on the implicit promotion of bool to in=
t=20
>> here:
>>
>> llvm::raw_ostream::operator<<(int N) // many places try to stream=
=20
>> out bools, which quietly selects this overload in present-day C++
>>
>> So your suggestion seems very likely to break a very large amount of=20
>> real-world code.
>>
>> =E2=80=93Arthur
>>
> --=20
> You received this message because you are subscribed to the Google Groups=
=20
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
=20
> email to std-proposal...@isocpp.org <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4db2a89f-2f1=
e-4a08-95fc-b529674499d9%40isocpp.org=20
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4db2a89f-2f=
1e-4a08-95fc-b529674499d9%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
>
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/c765b49b-ccce-4490-9933-9559a790a6ef%40isocpp.or=
g.
------=_Part_4222_479066810.1519985888671
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Of course I haven't - otherwise I'd state it inste=
ad of saying 'IMO'.<br><br>Compilers I use (gcc and clang) have no =
options that would report warnings for all places where I propose to remove=
implicit bool conversions (as you are aware for sure as one of main clang =
developers).<br>I am not compiler developer (as you most likely know - othe=
rwise my name would be familiar to you since there are so few), so no I'=
;m not going to spend weeks on understanding how compiler works in order to=
implement this feature, then studying gcc/clang compiler code to implement=
this feature.<br>It is completely unreasonable to expect that anyone not a=
lready involved in C++ compiler development would do this.<br><br>If that&#=
39;s a requirement for any new C++ language feature/change then just state =
that, and you will save time of all one-time "contributors", and =
everyone on this forum.<br><br>Regards,<br>Maciej<br><br>W dniu =C5=9Broda,=
28 lutego 2018 18:56:41 UTC+1 u=C5=BCytkownik Richard Smith napisa=C5=82:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"auto"><div><div><di=
v class=3D"gmail_quote">On 28 Feb 2018 01:16, <<a href=3D"javascript:" =
target=3D"_blank" gdf-obfuscated-mailto=3D"si6EUEHPAwAJ" rel=3D"nofollow" o=
nmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"th=
is.href=3D'javascript:';return true;">m.ce...@gmail.com</a>> wro=
te:<br type=3D"attribution"><blockquote style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I am aware that this =
is a breaking change, but IMO cost of possible bugs caused by existing from=
/to bool conversions outweighs the cost of adaptation (which can be done in=
automatic way with tools like clang-tidy, and still remains backward compa=
tible after adaptation).</div></blockquote></div></div></div><div dir=3D"au=
to"><br></div><div dir=3D"auto">Have you done any investigation into diagno=
stic rates (diagnostics per million lines of code, true positive versus fal=
se positive rates, and so on) for this change? These are things we'd co=
nsider when adding an enabled-by-default warning into our compiler; surely =
the bar should be higher for a language change.</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">Is there some existing compiler that implements exa=
ctly what you're proposing as a warning? If so, what lessons have been =
learned from that warning implementation? And if not, perhaps you should co=
nsider starting by adding such a warning to get a handle on the impact of t=
his change?</div><div dir=3D"auto"><span style=3D"font-family:sans-serif"><=
br></span></div><div dir=3D"auto"><span style=3D"font-family:sans-serif">(A=
lso of note: a QoI warning can employ arbitrarily complex heuristics to get=
the false positive rate down and can adapt as more false positive cases ar=
e discovered; a language rule cannot. Subtle semantic "this might be a=
bug"" diagnostics are often better off being compiler warnings r=
ather than language rules as a result. This is a lesson I hope we would hav=
e learned from the pain of "narrowing conversions".)</span></div>=
<div dir=3D"auto"><br></div><div dir=3D"auto"><div><div class=3D"gmail_quot=
e"><blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr"><div>Question to all: do we want the language =
to follow developers intent as much as possible (possibly with minor style =
inconvenience - e.g. explicit casting to bool), or we say we can live with =
monsters hidden around the corner. I vote for the former.<br><div><div><br>=
</div><div>I have never encountered this printf idiom, and I find it rather=
strange that you would use such a contrived expression, instead of ternary=
operator</div><div><div style=3D"background-color:rgb(250,250,250);border-=
color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-=
word"><code><div><span style=3D"color:#000">printf</span><span style=3D"col=
or:#660">(</span><span style=3D"color:#080">"Your cart has %d item%s\n=
"</span><span style=3D"color:#660">,</span><span style=3D"color:#000">=
count</span><span style=3D"color:#660">,</span><span style=3D"color:#000">=
count </span><span style=3D"color:#660">?</span><span style=3D"color:#000"=
> </span><span style=3D"color:#080">"s"</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#660">:</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#080">""</span><span style=3D"col=
or:#660">);</span></div></code></div><br></div><div>Your another extremely =
widespread idiom assert_with_loc, I haven't encountered either.<br></di=
v><div>However it can be easily fixable with explicit bool casts, or turnin=
g this assert_with_loc into macro, or converting it to a template that acce=
pts convertible to bool types as first param, or by introducing a implicit_=
bool helper:</div><div><div style=3D"background-color:rgb(250,250,250);bord=
er-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:bre=
ak-word"><code><div><span style=3D"color:#008">struct</span><span style=3D"=
color:#000"> implicit_bool<br></span><span style=3D"color:#660">{</span><sp=
an style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008"=
>template</span><span style=3D"color:#000"> </span><span style=3D"color:#66=
0"><</span><span style=3D"color:#008">typename</span><span style=3D"colo=
r:#000"> T</span><span style=3D"color:#660">,</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#008">typename</span><span style=3D"color:=
#000"> </span><span style=3D"color:#660">=3D</span><span style=3D"color:#00=
0"> std</span><span style=3D"color:#660">::</span><span style=3D"color:#000=
">void_t</span><span style=3D"color:#660"><</span><span style=3D"color:#=
008">decltype</span><span style=3D"color:#660">(</span><span style=3D"color=
:#008">bool</span><span style=3D"color:#660">(</span><span style=3D"color:#=
000">std</span><span style=3D"color:#660">:<wbr>:</span><span style=3D"colo=
r:#000">declval</span><span style=3D"color:#660"><</span><span style=3D"=
color:#008">const</span><span style=3D"color:#000"> T</span><span style=3D"=
color:#660">&>()))>></span><span style=3D"color:#000"><br>=C2=
=A0 =C2=A0 implicit_bool</span><span style=3D"color:#660">(</span><span sty=
le=3D"color:#008">const</span><span style=3D"color:#000"> T</span><span sty=
le=3D"color:#660">&</span><span style=3D"color:#000"> v</span><span sty=
le=3D"color:#660">)</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=
=A0 </span><span style=3D"color:#660">:</span><span style=3D"color:#000"> v=
alue</span><span style=3D"color:#660">(</span><span style=3D"color:#008">bo=
ol</span><span style=3D"color:#660">(</span><span style=3D"color:#000">v</s=
pan><span style=3D"color:#660">))</span><span style=3D"color:#000"><br>=C2=
=A0 =C2=A0 </span><span style=3D"color:#660">{}</span><span style=3D"color:=
#000"><br>=C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 </span><span style=3D"color:#008"=
>explicit</span><span style=3D"color:#000"> </span><span style=3D"color:#00=
8">operator</span><span style=3D"color:#000"> </span><span style=3D"color:#=
008">bool</span><span style=3D"color:#660">()</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#008">const</span><span style=3D"color:#00=
0"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660">{</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color=
:#008">return</span><span style=3D"color:#000"> value</span><span style=3D"=
color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><sp=
an style=3D"color:#660">}</span><span style=3D"color:#000"><br></span><span=
style=3D"color:#008">private</span><span style=3D"color:#660">:</span><spa=
n style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">=
bool</span><span style=3D"color:#000"> value</span><span style=3D"color:#66=
0">;</span><span style=3D"color:#000"><br></span><span style=3D"color:#660"=
>};</span></div></code></div><div><br></div></div><div><br><div>Basically, =
I am yet to see a good implicit bool conversion usage example, that wouldn&=
#39;t be easily fixable if we got rid of the implicit bool conversions.</di=
v><div><br></div><div>Regards,</div><div>Maciej<div><br><div><br><br>W dniu=
=C5=9Broda, 28 lutego 2018 02:02:43 UTC+1 u=C5=BCytkownik Arthur O'Dwy=
er napisa=C5=82:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On=
Tuesday, February 27, 2018 at 3:28:55 AM UTC-8, <a>m.ce...@gmail.com</a> w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi,<div><br><=
/div><div>I propose to remove implicit conversion to and from bool type, an=
d leave it only in as part of contextual conversion (if, while, ?:, etc).<d=
iv><br></div><div><div>Reason: why would you ever want following code to co=
mpile?</div><div><br></div><div style=3D"background-color:rgb(250,250,250);=
border-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap=
:break-word"><code><div><span style=3D"color:#800">#include</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#080"><string></span><=
span style=3D"color:#000"><br><br><br></span><span style=3D"color:#008">int=
</span><span style=3D"color:#000"> bar</span><span style=3D"color:#660">(</=
span><span style=3D"color:#008">int</span><span style=3D"color:#660">)</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#660">{</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#008">return</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#066">1</span><span st=
yle=3D"color:#660">;</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">}</span><span style=3D"color:#000"><br></span><span style=
=3D"color:#008">void</span><span style=3D"color:#000"> bar</span><span styl=
e=3D"color:#660">(</span><span style=3D"color:#008">int</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">*)</span><span style=3D"=
color:#000"> </span><span style=3D"color:#660">{</span><span style=3D"color=
:#000"> </span><span style=3D"color:#660">}</span><span style=3D"color:#000=
"><br><br><br></span><span style=3D"color:#008">void</span><span style=3D"c=
olor:#000"> foo</span><span style=3D"color:#660">(</span><span style=3D"col=
or:#000">std</span><span style=3D"color:#660">::</span><span style=3D"color=
:#008">string</span><span style=3D"color:#660">)</span><span style=3D"color=
:#000"> </span><span style=3D"color:#660">{}</span><span style=3D"color:#00=
0"><br></span><span style=3D"color:#008">int</span><span style=3D"color:#00=
0"> foo</span><span style=3D"color:#660">(</span><span style=3D"color:#008"=
>bool</span><span style=3D"color:#660">)</span><span style=3D"color:#000"> =
</span><span style=3D"color:#660">{</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#008">return</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#066">1</span><span style=3D"color:#660">;</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#660">}</span><span st=
yle=3D"color:#000"><br><br><br></span><span style=3D"color:#008">int</span>=
<span style=3D"color:#000"> main</span><span style=3D"color:#660">()</span>=
<span style=3D"color:#000"><br></span><span style=3D"color:#660">{</span><s=
pan style=3D"color:#000"><br>=C2=A0 =C2=A0</span><span style=3D"color:#008"=
>auto</span><span style=3D"color:#000"> t1 </span><span style=3D"color:#660=
">=3D</span><span style=3D"color:#000"> bar</span><span style=3D"color:#660=
">(</span><span style=3D"color:#008">false</span><span style=3D"color:#660"=
>);</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0</span><span style=3D=
"color:#008">auto</span><span style=3D"color:#000"> t2 </span><span style=
=3D"color:#660">=3D</span><span style=3D"color:#000"> foo</span><span style=
=3D"color:#660">(</span><span style=3D"color:#080">""</span><span=
style=3D"color:#660">);</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0=
</span><span style=3D"color:#008">auto</span><span style=3D"color:#000"> t3=
</span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </=
span><span style=3D"color:#008">false</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#660">+</span><span style=3D"color:#000"> </span><=
span style=3D"color:#008">true</span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#660">+</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#008">true</span><span style=3D"color:#660">;</span><span styl=
e=3D"color:#000"><br></span><span style=3D"color:#660">}</span></div></code=
></div><div><div><br></div></div><div><br></div><div>For bar(), we don'=
t know what was users intent, so it is in his best interest to cast the boo=
l value to int or int *.</div><div>For foo() the user most likely wanted th=
e foo(std::string) overload to be called.</div><div>For bool arithmetic ope=
rations, I think the user intent would be much better stated if he used any=
_of(begin(range), end(range), identity) (or its hand written equivalent), o=
r fold expression when possible.</div></div></div></div></blockquote><div><=
br></div><div>Your "t3" is uncomfortably close to the existing id=
iom</div><div><br></div><div>=C2=A0 =C2=A0 printf("Your cart has %d it=
em%s\n", count, &"s"[count =3D=3D 1]);</div><div><br></d=
iv><div>This relies on the implicit integral promotion of bool to int.</div=
><div><br></div><div>Your "t2" looks highly motivating, but it is=
uncomfortably close to the extremely widespread idiom</div><div><br></div>=
<div>=C2=A0 =C2=A0 void assert_with_loc(bool Assertion, const std::string &=
amp;Str);</div><div>=C2=A0 =C2=A0 DagInit *DI =3D ...;</div><div>=C2=A0 =C2=
=A0 assert_with_loc(DI, "Arguments must be...");</div><div><br></=
div><div>LLVM also (accidentally?) relies on the implicit promotion of bool=
to int here:<br></div><div><br></div><div>=C2=A0 =C2=A0 llvm::raw_ostream:=
:operator<<(<wbr>int N) =C2=A0 // many places try to stream out bools=
, which quietly selects this overload in present-day C++</div><div><br></di=
v><div>So your suggestion seems very likely to break a very large amount of=
real-world code.</div><div><br></div><div>=E2=80=93Arthur</div></div></blo=
ckquote></div></div></div></div></div></div></div><div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
si6EUEHPAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"si6EUEHPAwAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@isocpp.org</a>.<br></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4db2a89f-2f1e-4a08-95fc-b529674499d9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/4db2a89f-2f1e-4a08-95fc-b529674499d9%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/4db2a89f-2f1e-4a08-95fc-b529674499d9%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/4db2a89f-2f1e-4a08-<wbr>95fc-=
b529674499d9%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div></div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/c765b49b-ccce-4490-9933-9559a790a6ef%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c765b49b-ccce-4490-9933-9559a790a6ef=
%40isocpp.org</a>.<br />
------=_Part_4222_479066810.1519985888671--
------=_Part_4221_700012868.1519985888670--
.
Author: =?UTF-8?B?R2HFoXBlciBBxb5tYW4=?= <gasper.azman@gmail.com>
Date: Fri, 2 Mar 2018 10:20:23 +0000
Raw View
--001a1144470e3d131505666b5451
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
My 2c: Richard's question is not as preposterous as you make it out to be.
You don't need to be a compiler developer to write a clang-tidy plugin, for
instance - and grepping the contextual bool conversions from the AST dump
should really not be that difficult.
G
On Fri, Mar 2, 2018 at 10:18 AM, <m.cencora@gmail.com> wrote:
> Of course I haven't - otherwise I'd state it instead of saying 'IMO'.
>
> Compilers I use (gcc and clang) have no options that would report warning=
s
> for all places where I propose to remove implicit bool conversions (as yo=
u
> are aware for sure as one of main clang developers).
> I am not compiler developer (as you most likely know - otherwise my name
> would be familiar to you since there are so few), so no I'm not going to
> spend weeks on understanding how compiler works in order to implement thi=
s
> feature, then studying gcc/clang compiler code to implement this feature.
> It is completely unreasonable to expect that anyone not already involved
> in C++ compiler development would do this.
>
> If that's a requirement for any new C++ language feature/change then just
> state that, and you will save time of all one-time "contributors", and
> everyone on this forum.
>
> Regards,
> Maciej
>
> W dniu =C5=9Broda, 28 lutego 2018 18:56:41 UTC+1 u=C5=BCytkownik Richard =
Smith
> napisa=C5=82:
>>
>> On 28 Feb 2018 01:16, <m.ce...@gmail.com> wrote:
>>
>> I am aware that this is a breaking change, but IMO cost of possible bugs
>> caused by existing from/to bool conversions outweighs the cost of
>> adaptation (which can be done in automatic way with tools like clang-tid=
y,
>> and still remains backward compatible after adaptation).
>>
>>
>> Have you done any investigation into diagnostic rates (diagnostics per
>> million lines of code, true positive versus false positive rates, and so
>> on) for this change? These are things we'd consider when adding an
>> enabled-by-default warning into our compiler; surely the bar should be
>> higher for a language change.
>>
>> Is there some existing compiler that implements exactly what you're
>> proposing as a warning? If so, what lessons have been learned from that
>> warning implementation? And if not, perhaps you should consider starting=
by
>> adding such a warning to get a handle on the impact of this change?
>>
>> (Also of note: a QoI warning can employ arbitrarily complex heuristics t=
o
>> get the false positive rate down and can adapt as more false positive ca=
ses
>> are discovered; a language rule cannot. Subtle semantic "this might be a
>> bug"" diagnostics are often better off being compiler warnings rather th=
an
>> language rules as a result. This is a lesson I hope we would have learne=
d
>> from the pain of "narrowing conversions".)
>>
>> Question to all: do we want the language to follow developers intent as
>> much as possible (possibly with minor style inconvenience - e.g. explici=
t
>> casting to bool), or we say we can live with monsters hidden around the
>> corner. I vote for the former.
>>
>> I have never encountered this printf idiom, and I find it rather strange
>> that you would use such a contrived expression, instead of ternary opera=
tor
>> printf("Your cart has %d item%s\n", count, count ? "s" : "");
>>
>> Your another extremely widespread idiom assert_with_loc, I haven't
>> encountered either.
>> However it can be easily fixable with explicit bool casts, or turning
>> this assert_with_loc into macro, or converting it to a template that
>> accepts convertible to bool types as first param, or by introducing a
>> implicit_bool helper:
>> struct implicit_bool
>> {
>> template <typename T, typename =3D std::void_t<decltype(bool(std::
>> declval<const T&>()))>>
>> implicit_bool(const T& v)
>> : value(bool(v))
>> {}
>>
>> explicit operator bool() const
>> {
>> return value;
>> }
>> private:
>> bool value;
>> };
>>
>>
>> Basically, I am yet to see a good implicit bool conversion usage example=
,
>> that wouldn't be easily fixable if we got rid of the implicit bool
>> conversions.
>>
>> Regards,
>> Maciej
>>
>>
>>
>> W dniu =C5=9Broda, 28 lutego 2018 02:02:43 UTC+1 u=C5=BCytkownik Arthur =
O'Dwyer
>> napisa=C5=82:
>>>
>>> On Tuesday, February 27, 2018 at 3:28:55 AM UTC-8, m.ce...@gmail.com
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I propose to remove implicit conversion to and from bool type, and
>>>> leave it only in as part of contextual conversion (if, while, ?:, etc)=
..
>>>>
>>>> Reason: why would you ever want following code to compile?
>>>>
>>>> #include <string>
>>>>
>>>>
>>>> int bar(int) { return 1; }
>>>> void bar(int *) { }
>>>>
>>>>
>>>> void foo(std::string) {}
>>>> int foo(bool) { return 1; }
>>>>
>>>>
>>>> int main()
>>>> {
>>>> auto t1 =3D bar(false);
>>>> auto t2 =3D foo("");
>>>> auto t3 =3D false + true + true;
>>>> }
>>>>
>>>>
>>>> For bar(), we don't know what was users intent, so it is in his best
>>>> interest to cast the bool value to int or int *.
>>>> For foo() the user most likely wanted the foo(std::string) overload to
>>>> be called.
>>>> For bool arithmetic operations, I think the user intent would be much
>>>> better stated if he used any_of(begin(range), end(range), identity) (o=
r its
>>>> hand written equivalent), or fold expression when possible.
>>>>
>>>
>>> Your "t3" is uncomfortably close to the existing idiom
>>>
>>> printf("Your cart has %d item%s\n", count, &"s"[count =3D=3D 1]);
>>>
>>> This relies on the implicit integral promotion of bool to int.
>>>
>>> Your "t2" looks highly motivating, but it is uncomfortably close to the
>>> extremely widespread idiom
>>>
>>> void assert_with_loc(bool Assertion, const std::string &Str);
>>> DagInit *DI =3D ...;
>>> assert_with_loc(DI, "Arguments must be...");
>>>
>>> LLVM also (accidentally?) relies on the implicit promotion of bool to
>>> int here:
>>>
>>> llvm::raw_ostream::operator<<(int N) // many places try to stream
>>> out bools, which quietly selects this overload in present-day C++
>>>
>>> So your suggestion seems very likely to break a very large amount of
>>> real-world code.
>>>
>>> =E2=80=93Arthur
>>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposal...@isocpp.org.
>> To post to this group, send email to std-pr...@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/is
>> ocpp.org/d/msgid/std-proposals/4db2a89f-2f1e-4a08-95fc-
>> b529674499d9%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4db2a89f-2=
f1e-4a08-95fc-b529674499d9%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/c765b49b-ccce-4490-
> 9933-9559a790a6ef%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c765b49b-cc=
ce-4490-9933-9559a790a6ef%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAANG%3DkWw7%2B6kXmEW-6rQxREf9_vkD8R_HzuG04Dn9Jp=
foN4%2B3A%40mail.gmail.com.
--001a1144470e3d131505666b5451
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">My 2c: Richard's question is not as preposterous as yo=
u make it out to be. You don't need to be a compiler developer to write=
a clang-tidy plugin, for instance - and grepping the contextual bool conve=
rsions from the AST dump should really not be that difficult.<div><br></div=
><div>G</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=
">On Fri, Mar 2, 2018 at 10:18 AM, <span dir=3D"ltr"><<a href=3D"mailto=
:m.cencora@gmail.com" target=3D"_blank">m.cencora@gmail.com</a>></span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Of course I haven=
't - otherwise I'd state it instead of saying 'IMO'.<br><br=
>Compilers I use (gcc and clang) have no options that would report warnings=
for all places where I propose to remove implicit bool conversions (as you=
are aware for sure as one of main clang developers).<br>I am not compiler =
developer (as you most likely know - otherwise my name would be familiar to=
you since there are so few), so no I'm not going to spend weeks on und=
erstanding how compiler works in order to implement this feature, then stud=
ying gcc/clang compiler code to implement this feature.<br>It is completely=
unreasonable to expect that anyone not already involved in C++ compiler de=
velopment would do this.<br><br>If that's a requirement for any new C++=
language feature/change then just state that, and you will save time of al=
l one-time "contributors", and everyone on this forum.<br><br>Reg=
ards,<br>Maciej<br><br>W dniu =C5=9Broda, 28 lutego 2018 18:56:41 UTC+1 u=
=C5=BCytkownik Richard Smith napisa=C5=82:<blockquote class=3D"gmail_quote"=
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"auto"><div><div class=3D"h5"><div><div><div class=3D"gma=
il_quote">On 28 Feb 2018 01:16, <<a rel=3D"nofollow">m.ce...@gmail.com<=
/a>> wrote:<br type=3D"attribution"><blockquote style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I am aware=
that this is a breaking change, but IMO cost of possible bugs caused by ex=
isting from/to bool conversions outweighs the cost of adaptation (which can=
be done in automatic way with tools like clang-tidy, and still remains bac=
kward compatible after adaptation).</div></blockquote></div></div></div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">Have you done any investigation =
into diagnostic rates (diagnostics per million lines of code, true positive=
versus false positive rates, and so on) for this change? These are things =
we'd consider when adding an enabled-by-default warning into our compil=
er; surely the bar should be higher for a language change.</div><div dir=3D=
"auto"><br></div><div dir=3D"auto">Is there some existing compiler that imp=
lements exactly what you're proposing as a warning? If so, what lessons=
have been learned from that warning implementation? And if not, perhaps yo=
u should consider starting by adding such a warning to get a handle on the =
impact of this change?</div><div dir=3D"auto"><span style=3D"font-family:sa=
ns-serif"><br></span></div><div dir=3D"auto"><span style=3D"font-family:san=
s-serif">(Also of note: a QoI warning can employ arbitrarily complex heuris=
tics to get the false positive rate down and can adapt as more false positi=
ve cases are discovered; a language rule cannot. Subtle semantic "this=
might be a bug"" diagnostics are often better off being compiler=
warnings rather than language rules as a result. This is a lesson I hope w=
e would have learned from the pain of "narrowing conversions".)</=
span></div><div dir=3D"auto"><br></div></div></div><div dir=3D"auto"><div><=
div class=3D"gmail_quote"><blockquote style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><div dir=3D"ltr">=
<div>Question to all: do we want the language to follow developers intent a=
s much as possible (possibly with minor style inconvenience - e.g. explicit=
casting to bool), or we say we can live with monsters hidden around the co=
rner. I vote for the former.<br><div><div><br></div><div>I have never encou=
ntered this printf idiom, and I find it rather strange that you would use s=
uch a contrived expression, instead of ternary operator</div><div><div styl=
e=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border=
-style:solid;border-width:1px;word-wrap:break-word"><code><div><span style=
=3D"color:#000">printf</span><span style=3D"color:#660">(</span><span style=
=3D"color:#080">"Your cart has %d item%s\n"</span><span style=3D"=
color:#660">,</span><span style=3D"color:#000"> count</span><span style=3D"=
color:#660">,</span><span style=3D"color:#000"> count </span><span style=3D=
"color:#660">?</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#080">"s"</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">:</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#080">""</span><span style=3D"color:#660">);</span></div></c=
ode></div><br></div><div>Your another extremely widespread idiom assert_wit=
h_loc, I haven't encountered either.<br></div><div>However it can be ea=
sily fixable with explicit bool casts, or turning this assert_with_loc into=
macro, or converting it to a template that accepts convertible to bool typ=
es as first param, or by introducing a implicit_bool helper:</div><div><div=
style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);b=
order-style:solid;border-width:1px;word-wrap:break-word"><code><div><span s=
tyle=3D"color:#008">struct</span><span style=3D"color:#000"> implicit_bool<=
br></span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br=
>=C2=A0 =C2=A0 </span><span style=3D"color:#008">template</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660"><</span><span style=
=3D"color:#008">typename</span><span style=3D"color:#000"> T</span><span st=
yle=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">typename</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#660">=3D</span><span style=3D"color:#000"> std</span><span sty=
le=3D"color:#660">::</span><span style=3D"color:#000">void_t</span><span st=
yle=3D"color:#660"><</span><span style=3D"color:#008">decltype</span><sp=
an style=3D"color:#660">(</span><span style=3D"color:#008">bool</span><span=
style=3D"color:#660">(</span><span style=3D"color:#000">std</span><span st=
yle=3D"color:#660">:<wbr>:</span><span style=3D"color:#000">declval</span><=
span style=3D"color:#660"><</span><span style=3D"color:#008">const</span=
><span style=3D"color:#000"> T</span><span style=3D"color:#660">&>()=
))>></span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 implicit_bool=
</span><span style=3D"color:#660">(</span><span style=3D"color:#008">const<=
/span><span style=3D"color:#000"> T</span><span style=3D"color:#660">&<=
/span><span style=3D"color:#000"> v</span><span style=3D"color:#660">)</spa=
n><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D=
"color:#660">:</span><span style=3D"color:#000"> value</span><span style=3D=
"color:#660">(</span><span style=3D"color:#008">bool</span><span style=3D"c=
olor:#660">(</span><span style=3D"color:#000">v</span><span style=3D"color:=
#660">))</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span st=
yle=3D"color:#660">{}</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 <b=
r>=C2=A0 =C2=A0 </span><span style=3D"color:#008">explicit</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#008">operator</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#008">bool</span><span styl=
e=3D"color:#660">()</span><span style=3D"color:#000"> </span><span style=3D=
"color:#008">const</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </spa=
n><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#008">return</span><span s=
tyle=3D"color:#000"> value</span><span style=3D"color:#660">;</span><span s=
tyle=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660">}</=
span><span style=3D"color:#000"><br></span><span style=3D"color:#008">priva=
te</span><span style=3D"color:#660">:</span><span style=3D"color:#000"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color:#008">bool</span><span style=3D"c=
olor:#000"> value</span><span style=3D"color:#660">;</span><span style=3D"c=
olor:#000"><br></span><span style=3D"color:#660">};</span></div></code></di=
v><div><br></div></div><div><br><div>Basically, I am yet to see a good impl=
icit bool conversion usage example, that wouldn't be easily fixable if =
we got rid of the implicit bool conversions.</div><div><br></div><div>Regar=
ds,</div><div>Maciej<div><br><div><br><br>W dniu =C5=9Broda, 28 lutego 2018=
02:02:43 UTC+1 u=C5=BCytkownik Arthur O'Dwyer napisa=C5=82:<blockquote=
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, February 27, 2018=
at 3:28:55 AM UTC-8, <a>m.ce...@gmail.com</a> wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr">Hi,<div><br></div><div>I propose to remo=
ve implicit conversion to and from bool type, and leave it only in as part =
of contextual conversion (if, while, ?:, etc).<div><br></div><div><div>Reas=
on: why would you ever want following code to compile?</div><div><br></div>=
<div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,18=
7);border-style:solid;border-width:1px;word-wrap:break-word"><code><div><sp=
an style=3D"color:#800">#include</span><span style=3D"color:#000"> </span><=
span style=3D"color:#080"><string></span><span style=3D"color:#000"><=
br><br><br></span><span style=3D"color:#008">int</span><span style=3D"color=
:#000"> bar</span><span style=3D"color:#660">(</span><span style=3D"color:#=
008">int</span><span style=3D"color:#660">)</span><span style=3D"color:#000=
"> </span><span style=3D"color:#660">{</span><span style=3D"color:#000"> </=
span><span style=3D"color:#008">return</span><span style=3D"color:#000"> </=
span><span style=3D"color:#066">1</span><span style=3D"color:#660">;</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#660">}</span><span=
style=3D"color:#000"><br></span><span style=3D"color:#008">void</span><spa=
n style=3D"color:#000"> bar</span><span style=3D"color:#660">(</span><span =
style=3D"color:#008">int</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#660">*)</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">{</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#660">}</span><span style=3D"color:#000"><br><br><br></span><span styl=
e=3D"color:#008">void</span><span style=3D"color:#000"> foo</span><span sty=
le=3D"color:#660">(</span><span style=3D"color:#000">std</span><span style=
=3D"color:#660">::</span><span style=3D"color:#008">string</span><span styl=
e=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=3D"=
color:#660">{}</span><span style=3D"color:#000"><br></span><span style=3D"c=
olor:#008">int</span><span style=3D"color:#000"> foo</span><span style=3D"c=
olor:#660">(</span><span style=3D"color:#008">bool</span><span style=3D"col=
or:#660">)</span><span style=3D"color:#000"> </span><span style=3D"color:#6=
60">{</span><span style=3D"color:#000"> </span><span style=3D"color:#008">r=
eturn</span><span style=3D"color:#000"> </span><span style=3D"color:#066">1=
</span><span style=3D"color:#660">;</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#660">}</span><span style=3D"color:#000"><br><br><br=
></span><span style=3D"color:#008">int</span><span style=3D"color:#000"> ma=
in</span><span style=3D"color:#660">()</span><span style=3D"color:#000"><br=
></span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=
=C2=A0 =C2=A0</span><span style=3D"color:#008">auto</span><span style=3D"co=
lor:#000"> t1 </span><span style=3D"color:#660">=3D</span><span style=3D"co=
lor:#000"> bar</span><span style=3D"color:#660">(</span><span style=3D"colo=
r:#008">false</span><span style=3D"color:#660">);</span><span style=3D"colo=
r:#000"><br>=C2=A0 =C2=A0</span><span style=3D"color:#008">auto</span><span=
style=3D"color:#000"> t2 </span><span style=3D"color:#660">=3D</span><span=
style=3D"color:#000"> foo</span><span style=3D"color:#660">(</span><span s=
tyle=3D"color:#080">""</span><span style=3D"color:#660">);</span>=
<span style=3D"color:#000"><br>=C2=A0 =C2=A0</span><span style=3D"color:#00=
8">auto</span><span style=3D"color:#000"> t3 </span><span style=3D"color:#6=
60">=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#008"=
>false</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=
+</span><span style=3D"color:#000"> </span><span style=3D"color:#008">true<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#660">+</span=
><span style=3D"color:#000"> </span><span style=3D"color:#008">true</span><=
span style=3D"color:#660">;</span><span style=3D"color:#000"><br></span><sp=
an style=3D"color:#660">}</span></div></code></div><div><div><br></div></di=
v><div><br></div><div>For bar(), we don't know what was users intent, s=
o it is in his best interest to cast the bool value to int or int *.</div><=
div>For foo() the user most likely wanted the foo(std::string) overload to =
be called.</div><div>For bool arithmetic operations, I think the user inten=
t would be much better stated if he used any_of(begin(range), end(range), i=
dentity) (or its hand written equivalent), or fold expression when possible=
..</div></div></div></div></blockquote><div><br></div><div>Your "t3&quo=
t; is uncomfortably close to the existing idiom</div><div><br></div><div>=
=C2=A0 =C2=A0 printf("Your cart has %d item%s\n", count, &&qu=
ot;s"[count =3D=3D 1]);</div><div><br></div><div>This relies on the im=
plicit integral promotion of bool to int.</div><div><br></div><div>Your &qu=
ot;t2" looks highly motivating, but it is uncomfortably close to the e=
xtremely widespread idiom</div><div><br></div><div>=C2=A0 =C2=A0 void asser=
t_with_loc(bool Assertion, const std::string &Str);</div><div>=C2=A0 =
=C2=A0 DagInit *DI =3D ...;</div><div>=C2=A0 =C2=A0 assert_with_loc(DI, &qu=
ot;Arguments must be...");</div><div><br></div><div>LLVM also (acciden=
tally?) relies on the implicit promotion of bool to int here:<br></div><div=
><br></div><div>=C2=A0 =C2=A0 llvm::raw_ostream::operator<<(<wbr>int =
N) =C2=A0 // many places try to stream out bools, which quietly selects thi=
s overload in present-day C++</div><div><br></div><div>So your suggestion s=
eems very likely to break a very large amount of real-world code.</div><div=
><br></div><div>=E2=80=93Arthur</div></div></blockquote></div></div></div><=
/div></div></div></div></div></div><div><div><div class=3D"h5">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></div></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br></div><span class=3D"">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4db2a89f-2f1e-4a08-95fc-b529674499d9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-pr=
oposals<wbr>/4db2a89f-2f1e-4a08-95fc-<wbr>b529674499d9%40isocpp.org</a>.<br=
>
</span></blockquote></div><br></div></div></div>
</blockquote></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c765b49b-ccce-4490-9933-9559a790a6ef%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/c765=
b49b-ccce-4490-<wbr>9933-9559a790a6ef%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkWw7%2B6kXmEW-6rQxREf9_vkD8R_=
HzuG04Dn9JpfoN4%2B3A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkWw=
7%2B6kXmEW-6rQxREf9_vkD8R_HzuG04Dn9JpfoN4%2B3A%40mail.gmail.com</a>.<br />
--001a1144470e3d131505666b5451--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 2 Mar 2018 07:01:04 -0800 (PST)
Raw View
------=_Part_5099_1786845839.1520002864195
Content-Type: multipart/alternative;
boundary="----=_Part_5100_882466537.1520002864195"
------=_Part_5100_882466537.1520002864195
Content-Type: text/plain; charset="UTF-8"
On Friday, March 2, 2018 at 5:18:08 AM UTC-5, m.ce...@gmail.com wrote:
>
> Of course I haven't - otherwise I'd state it instead of saying 'IMO'.
>
> Compilers I use (gcc and clang) have no options that would report warnings
> for all places where I propose to remove implicit bool conversions (as you
> are aware for sure as one of main clang developers).
> I am not compiler developer (as you most likely know - otherwise my name
> would be familiar to you since there are so few), so no I'm not going to
> spend weeks on understanding how compiler works in order to implement this
> feature, then studying gcc/clang compiler code to implement this feature.
> It is completely unreasonable to expect that anyone not already involved
> in C++ compiler development would do this.
>
Why is that "completely unreasonable"?
Your feature is not backwards compatible. It is not unreasonable to say
that such a proposal is poorly founded if its proposer have done nothing to
actually verify their opinion on how much of a break it is.
Your proposal is only viable if it doesn't break very much code, after all.
It is your opinion that not much code will be broken by this, but you have
zero evidence to back up that opinion. Do you think that other people
should have to do the research that you failed to do? That the burden of
proof is on others to disprove your unfounded opinion?
That's not how this works. You're making the proposal. The burden of
proving any assertions that proposal makes is therefore *on you*. If you
feel that this is unreasonable, then just consider how your idea would work
in practice.
Any number of people could post on a forum or write a paper document about
some backwards incompatible change. If it then fell to "compiler
developers" to prove that there is a lot of code that would be broken just
to stop such proposals, compiler developers wouldn't be able to do *anything
else* with their time. It's just not workable long-term.
So the burden of proof is where it ought to be: on the person making the
backwards-incompatible proposal.
If that's a requirement for any new C++ language feature/change then just
> state that, and you will save time of all one-time "contributors", and
> everyone on this forum.
>
Yes, the C++ committee expects people who make real proposals to have real
evidence to back up their claims. Why is that "unreasonable"?
--
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/43fe0a4e-b62d-4bab-9b09-3711039f4ece%40isocpp.org.
------=_Part_5100_882466537.1520002864195
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, March 2, 2018 at 5:18:08 AM UTC-5, m.ce...@gmai=
l.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">O=
f course I haven't - otherwise I'd state it instead of saying '=
IMO'.<br><br>Compilers I use (gcc and clang) have no options that would=
report warnings for all places where I propose to remove implicit bool con=
versions (as you are aware for sure as one of main clang developers).<br>I =
am not compiler developer (as you most likely know - otherwise my name woul=
d be familiar to you since there are so few), so no I'm not going to sp=
end weeks on understanding how compiler works in order to implement this fe=
ature, then studying gcc/clang compiler code to implement this feature.<br>=
It is completely unreasonable to expect that anyone not already involved in=
C++ compiler development would do this.<br></div></blockquote><div><br>Why=
is that "completely unreasonable"?<br><br>Your feature is not ba=
ckwards compatible. It is not unreasonable to say that such a proposal is p=
oorly founded if its proposer have done nothing to actually verify their op=
inion on how much of a break it is.<br><br>Your proposal is only viable if =
it doesn't break very much code, after all. It is your opinion that not=
much code will be broken by this, but you have zero evidence to back up th=
at opinion. Do you think that other people should have to do the research t=
hat you failed to do? That the burden of proof is on others to disprove you=
r unfounded opinion?<br><br>That's not how this works. You're makin=
g the proposal. The burden of proving any assertions that proposal makes is=
therefore <i>on you</i>. If you feel that this is unreasonable, then just =
consider how your idea would work in practice.<br><br>Any number of people =
could post on a forum or write a paper document about some backwards incomp=
atible change. If it then fell to "compiler developers" to prove =
that there is a lot of code that would be broken just to stop such proposal=
s, compiler developers wouldn't be able to do <i>anything else</i> with=
their time. It's just not workable long-term.<br><br>So the burden of =
proof is where it ought to be: on the person making the backwards-incompati=
ble proposal.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr">If that's a requirement for any new C++ language feature/=
change then just state that, and you will save time of all one-time "c=
ontributors", and everyone on this forum.<br></div></blockquote><div><=
br>Yes, the C++ committee expects people who make real proposals to have re=
al evidence to back up their claims. Why is that "unreasonable"?<=
br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/43fe0a4e-b62d-4bab-9b09-3711039f4ece%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/43fe0a4e-b62d-4bab-9b09-3711039f4ece=
%40isocpp.org</a>.<br />
------=_Part_5100_882466537.1520002864195--
------=_Part_5099_1786845839.1520002864195--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Fri, 2 Mar 2018 11:35:43 -0800
Raw View
--001a114edde4112a1805667315e6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Fri, Mar 2, 2018 at 2:18 AM, <m.cencora@gmail.com> wrote:
> Of course I haven't - otherwise I'd state it instead of saying 'IMO'.
>
> Compilers I use (gcc and clang) have no options that would report warning=
s
> for all places where I propose to remove implicit bool conversions (as yo=
u
> are aware for sure as one of main clang developers).
> I am not compiler developer (as you most likely know - otherwise my name
> would be familiar to you since there are so few), so no I'm not going to
> spend weeks on understanding how compiler works in order to implement thi=
s
> feature, then studying gcc/clang compiler code to implement this feature.
> It is completely unreasonable to expect that anyone not already involved
> in C++ compiler development would do this.
>
To +1 the sentiments of Nicol and Gasper, with more of Gasper's tone (I
hope) but Nicol's verbosity... ;)
It is completely unreasonable to expect that *anyone* would go implement a
Clang diagnostic, sure. But you're not *anyone*. You're a person who's got
a very specific hypothesis about a harmful behavior that current C++
programs might be using, might even be using by accident, and which might
(in your opinion) reasonably be banned from C++ programs in the future.
This is a hypothesis. The scientific method suggests that you should devise
a *test* of this hypothesis. The easiest way to test this hypothesis is to
write the diagnostic and run it over a large codebase, and see whether it
generates any "false positives," and if so, whether fixing them in the
codebase would be burdensome.
FYI, I have done this (half-assedly); I did this before responding to your
original message. That's how I was able to find those places where LLVM's
codebase uses implicit conversion to and from bool. However, the places I
reported are not the only places; they're just the first ones I ran into
before deciding that the false-positive rate was too high for my own
liking, so I stopped investing my own time.
*You* are the person in this thread with the most motivation to keep going
and test your hypothesis. Everyone else is *encouraging* you to do so. If
you come up with evidence for or against your hypothesis, we encourage you
to share that data; it will be interesting even if it ends up disproving
your hypothesis.
=E2=80=93Arthur
P.S. =E2=80=94 I would not be surprised if Richard Smith has also done his =
own
experiment in this area, in the past. He asks leading =E2=80=94 but utterly=
valid =E2=80=94
questions. :)
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0JRZ7E%2BVTSRSHuXg2QmMo51CTU-Ze7m2NsZubBD_=
yjHgw%40mail.gmail.com.
--001a114edde4112a1805667315e6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Fri, Mar 2, 2018 at 2:18 AM, <span dir=3D"ltr"><<a =
href=3D"mailto:m.cencora@gmail.com" target=3D"_blank">m.cencora@gmail.com</=
a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Of course I haven't =
- otherwise I'd state it instead of saying 'IMO'.<br><br>Compil=
ers I use (gcc and clang) have no options that would report warnings for al=
l places where I propose to remove implicit bool conversions (as you are aw=
are for sure as one of main clang developers).<br>I am not compiler develop=
er (as you most likely know - otherwise my name would be familiar to you si=
nce there are so few), so no I'm not going to spend weeks on understand=
ing how compiler works in order to implement this feature, then studying gc=
c/clang compiler code to implement this feature.<br>It is completely unreas=
onable to expect that anyone not already involved in C++ compiler developme=
nt would do this.<br></div></blockquote><div><br></div><div>To +1 the senti=
ments of Nicol and Gasper, with more of Gasper's tone (I hope) but Nico=
l's verbosity... ;)</div><div><br></div><div>It is completely unreasona=
ble to expect that <i>anyone</i> would go implement a Clang diagnostic, sur=
e. But you're not <i>anyone</i>. You're a person who's got a ve=
ry specific hypothesis about a harmful behavior that current C++ programs m=
ight be using, might even be using by accident, and which might (in your op=
inion) reasonably be banned from C++ programs in the future.</div><div><br>=
</div><div>This is a hypothesis. The scientific method suggests that you sh=
ould devise a <i>test</i> of this hypothesis. The easiest way to test this =
hypothesis is to write the diagnostic and run it over a large codebase, and=
see whether it generates any "false positives," and if so, wheth=
er fixing them in the codebase would be burdensome.</div><div><br></div><di=
v>FYI, I have done this (half-assedly); I did this before responding to you=
r original message. That's how I was able to find those places where LL=
VM's codebase uses implicit conversion to and from bool.=C2=A0 However,=
the places I reported are not the only places; they're just the first =
ones I ran into before deciding that the false-positive rate was too high f=
or my own liking, so I stopped investing my own time.</div><div><br></div><=
div><i>You</i> are the person in this thread with the most motivation to ke=
ep going and test your hypothesis. Everyone else is <i>encouraging</i> you =
to do so. If you come up with evidence for or against your hypothesis, we e=
ncourage you to share that data; it will be interesting even if it ends up =
disproving your hypothesis.</div><div><br></div><div>=E2=80=93Arthur</div><=
div><br></div><div>P.S. =E2=80=94 I would not be surprised if Richard Smith=
has also done his own experiment in this area, in the past. He asks leadin=
g =E2=80=94 but utterly valid =E2=80=94 questions. :)</div></div></div></di=
v>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0JRZ7E%2BVTSRSHuXg2QmMo51CTU-Ze=
7m2NsZubBD_yjHgw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0JRZ7E%2B=
VTSRSHuXg2QmMo51CTU-Ze7m2NsZubBD_yjHgw%40mail.gmail.com</a>.<br />
--001a114edde4112a1805667315e6--
.