Topic: Why is c++ still allowing UB in when a return
Author: Richard Hodges <hodges.r@gmail.com>
Date: Tue, 19 Dec 2017 04:54:50 -0800 (PST)
Raw View
------=_Part_5906_1408030631.1513688090877
Content-Type: multipart/alternative;
boundary="----=_Part_5907_158826097.1513688090877"
------=_Part_5907_158826097.1513688090877
Content-Type: text/plain; charset="UTF-8"
In c++, this is legal but UB. You may get a warning if you're lucky.
int foo()
{
// oops! forgot to return anything
}
In my view, this not good enough. It seems to me that there is no
reasonable case where a developer would want this compile. It should be an
error.
This of course is fine:
int foo()
{
throw std::logic_error("not implemented yet!");
}
And this of course would allow developers who like this sort of thing to
still get away with it, but force them to explain themselves.
int foo()
{
int result = 0;
while(1)
{
result = will_eventually_be_nonzero();
if (result)
return result;
}
[[not_reached]];
// ok, a program reaching here could be allowed to express UB.
// if the compiler can prove that this is reachable, it should fail to
compile, because it knows you're lying.
[[assert_not_reached]]
// a program reaching here should by default, std::abort(), ideally with
a stack dump.
// if the compiler can prove that this is reachable, it should fail to
compile, because it knows you're lying.
// intentional non-return
}
In short, if your function says it returns something, it must return
something, otherwise compilation error. Anything other outcome is a
hard-to-track bug in waiting.
Thoughts?
--
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/c81df9d8-e2f3-4dae-9cf5-6c8eefd7f8ce%40isocpp.org.
------=_Part_5907_158826097.1513688090877
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">In c++, this is legal but UB. You may get a warning if you=
're lucky.<div><br></div><div><font face=3D"courier new, monospace">int=
foo()</font></div><div><font face=3D"courier new, monospace">{</font></div=
><div><font face=3D"courier new, monospace">=C2=A0 // oops! forgot to retur=
n anything</font></div><div><font face=3D"courier new, monospace">}</font><=
/div><div><br></div><div>In my view, this not good enough. It seems to me t=
hat there is no reasonable case where a developer would want this compile. =
It should be an error.<br></div><div><br></div><div>This of course is fine:=
</div><div><br></div><div><div><font face=3D"courier new, monospace">int fo=
o()</font></div><div><font face=3D"courier new, monospace">{</font></div><d=
iv><font face=3D"courier new, monospace">=C2=A0 throw std::logic_error(&quo=
t;not implemented yet!");</font></div><div><font face=3D"courier new, =
monospace">}</font></div></div><div><font face=3D"courier new, monospace"><=
br></font></div><div><div>And this of course would allow developers who lik=
e this sort of thing to still get away with it, but force them to explain t=
hemselves.</div></div><div><br></div><div><div><font face=3D"courier new, m=
onospace">int foo()</font></div><div><font face=3D"courier new, monospace">=
{</font></div><div><font face=3D"courier new, monospace">=C2=A0 int result =
=3D 0;</font></div><div><font face=3D"courier new, monospace">=C2=A0 while(=
1)</font></div><div><font face=3D"courier new, monospace">=C2=A0 {</font></=
div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 result =3D wil=
l_eventually_be_nonzero();</font></div><div><font face=3D"courier new, mono=
space">=C2=A0 =C2=A0 if (result)</font></div><div><font face=3D"courier new=
, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 return result;</font></div><div><s=
pan style=3D"font-family: "courier new", monospace;">=C2=A0 }</sp=
an><br></div><div><span style=3D"font-family: "courier new", mono=
space;"><br></span></div><div><div><span style=3D"font-family: "courie=
r new", monospace;">=C2=A0 [[not_reached]];=C2=A0 =C2=A0</span></div><=
/div><div><span style=3D"font-family: "courier new", monospace;">=
<br></span></div><div><span style=3D"font-family: "courier new", =
monospace;">=C2=A0=C2=A0</span><span style=3D"font-family: "courier ne=
w", monospace;">// ok, a program reaching here could be allowed to exp=
ress UB.</span></div><div><span style=3D"font-family: "courier new&quo=
t;, monospace;">=C2=A0 // if the compiler can prove that this is reachable,=
it should fail to compile, because it knows you're lying.</span></div>=
<div><span style=3D"font-family: "courier new", monospace;"><br><=
/span></div><div><span style=3D"font-family: "courier new", monos=
pace;">=C2=A0 [[assert_not_reached]]</span></div><div><span style=3D"font-f=
amily: "courier new", monospace;"><br></span></div><div><div><spa=
n style=3D"font-family: "courier new", monospace;">=C2=A0=C2=A0</=
span><span style=3D"font-family: "courier new", monospace;">// a =
program reaching here should by default, std::abort(), ideally with a stack=
dump.</span></div><div><span style=3D"font-family: "courier new"=
, monospace;">=C2=A0 // if the compiler can prove that this is reachable, i=
t should fail to compile, because it knows you're lying.</span></div></=
div></div><div><span style=3D"font-family: "courier new", monospa=
ce;"><br></span></div><div><span style=3D"font-family: "courier new&qu=
ot;, monospace;">=C2=A0 // intentional non-return</span></div><div><span st=
yle=3D"font-family: "courier new", monospace;">}</span></div><div=
><font face=3D"courier new, monospace"><br></font></div><div>In short, if y=
our function says it returns something, it must return something, otherwise=
compilation error. Anything other outcome is a hard-to-track bug in waitin=
g.</div><div><br></div><div>Thoughts?</div><div><br></div><div><br></div><d=
iv><br></div><div>=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/c81df9d8-e2f3-4dae-9cf5-6c8eefd7f8ce%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c81df9d8-e2f3-4dae-9cf5-6c8eefd7f8ce=
%40isocpp.org</a>.<br />
------=_Part_5907_158826097.1513688090877--
------=_Part_5906_1408030631.1513688090877--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Tue, 19 Dec 2017 16:00:03 +0300
Raw View
On 12/19/17 15:54, Richard Hodges wrote:
>
> In short, if your function says it returns something, it must return
> something, otherwise compilation error. Anything other outcome is a
> hard-to-track bug in waiting.
>
> Thoughts?
Sometimes it is difficult to say if the UB actually happens.
int foo(int x)
{
switch (x)
{
case 0:
return 10;
case 1:
return 20;
}
}
The compiler cannot tell if the function is ever called with x other
than 0 or 1. Adding a `default:` section with some fallback code might
mean pessimizing the code and `[[unreachable]]`, as any other attribute,
is not required to have any effect (and even if it does, it is still UB).
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4972f96c-f7c0-1f8f-ad62-bae2ec62df58%40gmail.com.
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Tue, 19 Dec 2017 13:37:01 +0000
Raw View
--94eb2c1c1accd00f5b0560b18f60
Content-Type: text/plain; charset="UTF-8"
The problem depends on various things, but one of them is the discrepancy
between value ranges allowed by type and the value ranges that will
actually be used. If your function is inaccessible to the outside world and
could only ever be given a subset of possible values, then it could make
sense to only consider those values.
I do like the idea of aborting if the end of the function is reached
without a return, though. I don't think anyone can actually utilise that
undefined behaviour for a useful reason because it changes between
implementations and optimisation levels (and often does something that
makes no sense. Piotr Padlewski's talks on UB make use of this to serve as
entertainment).
What I'm wondering is if there are any optimisations that would be lost,
e.g. if the compiler is NOT allowed to assume that a return must be
encountered in some branch before the end is reached. Judging by Clang's
behaviour of choosing a different (paradoxial) branch when certain
optimisations are enabled, I'm going to guess that this is the case -
otherwise the behaviour wouldn't change depending on optimisation level.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCOaq_WMiuYjtqBCGBA1YbYOuZxgZcCkikzeuZO5ZoB0yQ%40mail.gmail.com.
--94eb2c1c1accd00f5b0560b18f60
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div class=3D"gmail_extra" dir=3D"auto"><div class=3D"gma=
il_quote">The problem depends on various things, but one of them is the dis=
crepancy between value ranges allowed by type and the value ranges that wil=
l actually be used. If your function is inaccessible to the outside world a=
nd could only ever be given a subset of possible values, then it could make=
sense to only consider those values.</div><div class=3D"gmail_quote" dir=
=3D"auto"><br></div><div class=3D"gmail_quote" dir=3D"auto">I do like the i=
dea of aborting if the end of the function is reached without a return, tho=
ugh. I don't think anyone can actually utilise that undefined behaviour=
for a useful reason because it changes between implementations and optimis=
ation levels (and often does something that makes no sense. Piotr Padlewski=
's talks on UB make use of this to serve as entertainment).<br></div><d=
iv class=3D"gmail_quote" dir=3D"auto"><br></div><div class=3D"gmail_quote" =
dir=3D"auto">What I'm wondering is if there are any optimisations that =
would be lost, e.g. if the compiler is NOT allowed to assume that a return =
must be encountered in some branch before the end is reached. Judging by Cl=
ang's behaviour of choosing a different (paradoxial) branch when certai=
n optimisations are enabled, I'm going to guess that this is the case -=
otherwise the behaviour wouldn't change depending on optimisation leve=
l.</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/CAC%2B0CCOaq_WMiuYjtqBCGBA1YbYOuZxgZc=
CkikzeuZO5ZoB0yQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCOaq_WM=
iuYjtqBCGBA1YbYOuZxgZcCkikzeuZO5ZoB0yQ%40mail.gmail.com</a>.<br />
--94eb2c1c1accd00f5b0560b18f60--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 19 Dec 2017 05:41:33 -0800 (PST)
Raw View
------=_Part_27943_264694847.1513690893150
Content-Type: multipart/alternative;
boundary="----=_Part_27944_1650878426.1513690893150"
------=_Part_27944_1650878426.1513690893150
Content-Type: text/plain; charset="UTF-8"
On Tuesday, December 19, 2017 at 7:54:51 AM UTC-5, Richard Hodges wrote:
>
> In c++, this is legal but UB. You may get a warning if you're lucky.
>
>
> int foo()
> {
> // oops! forgot to return anything
> }
>
> In my view, this not good enough. It seems to me that there is no
> reasonable case where a developer would want this compile. It should be an
> error.
>
> This of course is fine:
>
> int foo()
> {
> throw std::logic_error("not implemented yet!");
> }
>
> And this of course would allow developers who like this sort of thing to
> still get away with it, but force them to explain themselves.
>
> int foo()
> {
> int result = 0;
> while(1)
> {
> result = will_eventually_be_nonzero();
> if (result)
> return result;
> }
>
> [[not_reached]];
>
> // ok, a program reaching here could be allowed to express UB.
> // if the compiler can prove that this is reachable, it should fail to
> compile, because it knows you're lying.
>
But the compiler cannot* prove* that any particular statement is reachable.
Not so long as there is a condition. The compiler doesn't know what runtime
values you will pass in.
This is halting-problem levels of hard.
In short, if your function says it returns something, it must return
> something, otherwise compilation error. Anything other outcome is a
> hard-to-track bug in waiting.
>
So, what do you return in return statements that will* never be reached*?
If the return type is not default-constructible, what can you return?
Note this is not "*can* never be reached", where it is theoretically
possible that some set of input parameters or global state can allow you to
get to the unreachable code. It simply won't be reached so long as the
program is working correctly.
--
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/419e3005-9e07-4fa6-92fb-b62219541eda%40isocpp.org.
------=_Part_27944_1650878426.1513690893150
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, December 19, 2017 at 7:54:51 AM UTC-5, Richard=
Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>In c++, this is legal but UB. You may get a warning if you're lucky.</=
div></blockquote><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><div><br></div><div><font face=3D"couri=
er new, monospace">int foo()</font></div><div><font face=3D"courier new, mo=
nospace">{</font></div><div><font face=3D"courier new, monospace">=C2=A0 //=
oops! forgot to return anything</font></div><div><font face=3D"courier new=
, monospace">}</font></div><div><br></div><div>In my view, this not good en=
ough. It seems to me that there is no reasonable case where a developer wou=
ld want this compile. It should be an error.<br></div><div><br></div><div>T=
his of course is fine:</div><div><br></div><div><div><font face=3D"courier =
new, monospace">int foo()</font></div><div><font face=3D"courier new, monos=
pace">{</font></div><div><font face=3D"courier new, monospace">=C2=A0 throw=
std::logic_error("not implemented yet!");</font></div><div><font=
face=3D"courier new, monospace">}</font></div></div><div><font face=3D"cou=
rier new, monospace"><br></font></div><div><div>And this of course would al=
low developers who like this sort of thing to still get away with it, but f=
orce them to explain themselves.</div></div><div><br></div><div><div><font =
face=3D"courier new, monospace">int foo()</font></div><div><font face=3D"co=
urier new, monospace">{</font></div><div><font face=3D"courier new, monospa=
ce">=C2=A0 int result =3D 0;</font></div><div><font face=3D"courier new, mo=
nospace">=C2=A0 while(1)</font></div><div><font face=3D"courier new, monosp=
ace">=C2=A0 {</font></div><div><font face=3D"courier new, monospace">=C2=A0=
=C2=A0 result =3D will_eventually_be_nonzero();</font></div><div><font fac=
e=3D"courier new, monospace">=C2=A0 =C2=A0 if (result)</font></div><div><fo=
nt face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 return resul=
t;</font></div><div><span style=3D"font-family:"courier new",mono=
space">=C2=A0 }</span><br></div><div><span style=3D"font-family:"couri=
er new",monospace"><br></span></div><div><div><span style=3D"font-fami=
ly:"courier new",monospace">=C2=A0 [[not_reached]];=C2=A0 =C2=A0<=
/span></div></div><div><span style=3D"font-family:"courier new",m=
onospace"><br></span></div><div><span style=3D"font-family:"courier ne=
w",monospace">=C2=A0=C2=A0</span><span style=3D"font-family:"cour=
ier new",monospace">// ok, a program reaching here could be allowed to=
express UB.</span></div><div><span style=3D"font-family:"courier new&=
quot;,monospace">=C2=A0 // if the compiler can prove that this is reachable=
, it should fail to compile, because it knows you're lying.</span></div=
></div></div></blockquote><div><br></div><div>But the compiler cannot<i> pr=
ove</i> that any particular statement is reachable. Not so long as there is=
a condition. The compiler doesn't know what runtime values you will pa=
ss in.</div><div><br></div><div>This is halting-problem levels of hard.</di=
v><div><font face=3D"courier new, monospace"><br></font></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>In short, if your fun=
ction says it returns something, it must return something, otherwise compil=
ation error. Anything other outcome is a hard-to-track bug in waiting.</div=
></div></blockquote><div><br></div><div>So, what do you return in return st=
atements that will<i> never be reached</i>? If the return type is not defau=
lt-constructible, what can you return?</div><div><br></div><div>Note this i=
s not "<i><u>can</u></i> never be reached", where it is theoretic=
ally possible that some set of input parameters or global state can allow y=
ou to get to the unreachable code. It simply won't be reached so long a=
s the program is working correctly.</div><div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/419e3005-9e07-4fa6-92fb-b62219541eda%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/419e3005-9e07-4fa6-92fb-b62219541eda=
%40isocpp.org</a>.<br />
------=_Part_27944_1650878426.1513690893150--
------=_Part_27943_264694847.1513690893150--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Tue, 19 Dec 2017 05:42:05 -0800 (PST)
Raw View
------=_Part_6925_1336333207.1513690925831
Content-Type: multipart/alternative;
boundary="----=_Part_6926_359115623.1513690925831"
------=_Part_6926_359115623.1513690925831
Content-Type: text/plain; charset="UTF-8"
On Tuesday, 19 December 2017 14:00:07 UTC+1, Andrey Semashev wrote:
>
> On 12/19/17 15:54, Richard Hodges wrote:
> >
> > In short, if your function says it returns something, it must return
> > something, otherwise compilation error. Anything other outcome is a
> > hard-to-track bug in waiting.
> >
> > Thoughts?
>
> Sometimes it is difficult to say if the UB actually happens.
>
> int foo(int x)
> {
> switch (x)
> {
> case 0:
> return 10;
> case 1:
> return 20;
> }
> }
>
> The compiler cannot tell if the function is ever called with x other
> than 0 or 1. Adding a `default:` section with some fallback code might
> mean pessimizing the code and `[[unreachable]]`, as any other attribute,
> is not required to have any effect (and even if it does, it is still UB).
>
The example above is simply a transform with constrained inputs. If you
want UB you can code for it with no overhead:
int foo(int x)
{
// express preconditions...
assert(x == 0 or x == 1);
// transform
switch (x)
{
case 0: x = 10;
case 1: x = 20;
}
// always return something
return x; // now we're always returning something but have
deliberately preserved the UB for the sake of 'performance'
}
--
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/3bc8e19d-eb09-4c43-bd4e-9acc7a02ef30%40isocpp.org.
------=_Part_6926_359115623.1513690925831
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, 19 December 2017 14:00:07 UTC+1, Andre=
y Semashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 12/19/17 =
15:54, Richard Hodges wrote:
<br>>=20
<br>> In short, if your function says it returns something, it must retu=
rn=20
<br>> something, otherwise compilation error. Anything other outcome is =
a=20
<br>> hard-to-track bug in waiting.
<br>>=20
<br>> Thoughts?
<br>
<br>Sometimes it is difficult to say if the UB actually happens.
<br>
<br>=C2=A0 =C2=A0int foo(int x)
<br>=C2=A0 =C2=A0{
<br>=C2=A0 =C2=A0 =C2=A0switch (x)
<br>=C2=A0 =C2=A0 =C2=A0{
<br>=C2=A0 =C2=A0 =C2=A0case 0:
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0return 10;
<br>=C2=A0 =C2=A0 =C2=A0case 1:
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0return 20;
<br>=C2=A0 =C2=A0 =C2=A0}
<br>=C2=A0 =C2=A0}
<br>
<br>The compiler cannot tell if the function is ever called with x other=20
<br>than 0 or 1. Adding a `default:` section with some fallback code might=
=20
<br>mean pessimizing the code and `[[unreachable]]`, as any other attribute=
,=20
<br>is not required to have any effect (and even if it does, it is still UB=
).
<br></blockquote><div><br></div><div>The example above is simply a transfor=
m with constrained inputs. If you want UB you can code for it with no overh=
ead:</div><div><br></div><font face=3D"courier new, monospace">=C2=A0 =C2=
=A0int foo(int x)=C2=A0<br>=C2=A0 =C2=A0{=C2=A0<br></font><div><span style=
=3D"font-family: "courier new", monospace;">=C2=A0 =C2=A0 =C2=A0/=
/ express preconditions...</span></div><div><font face=3D"courier new, mono=
space">=C2=A0 =C2=A0 =C2=A0assert(x =3D=3D 0 or x =3D=3D 1);=C2=A0</font></=
div><div><font face=3D"courier new, monospace"><br></font></div><div><font =
face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0// transform</font></di=
v><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0switch (x)=
=C2=A0<br>=C2=A0 =C2=A0 =C2=A0{=C2=A0<br>=C2=A0 =C2=A0 =C2=A0case 0:=C2=A0x=
=3D 10;=C2=A0<br>=C2=A0 =C2=A0 =C2=A0case 1:=C2=A0x =3D=C2=A020;</font></d=
iv><div><span style=3D"font-family: "courier new", monospace;">=
=C2=A0 =C2=A0 =C2=A0}</span></div><div><span style=3D"font-family: "co=
urier new", monospace;"><br></span></div><div><span style=3D"font-fami=
ly: "courier new", monospace;">=C2=A0 =C2=A0 =C2=A0// always retu=
rn something=C2=A0</span><br></div><div><font face=3D"courier new, monospac=
e">=C2=A0 =C2=A0 =C2=A0return x;=C2=A0 // now we're always returning so=
mething but have deliberately preserved the UB for the sake of 'perform=
ance'<br>=C2=A0 =C2=A0}=C2=A0<br></font><div>=C2=A0</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/3bc8e19d-eb09-4c43-bd4e-9acc7a02ef30%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3bc8e19d-eb09-4c43-bd4e-9acc7a02ef30=
%40isocpp.org</a>.<br />
------=_Part_6926_359115623.1513690925831--
------=_Part_6925_1336333207.1513690925831--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Tue, 19 Dec 2017 05:44:31 -0800 (PST)
Raw View
------=_Part_7589_1021017970.1513691071758
Content-Type: multipart/alternative;
boundary="----=_Part_7590_968608472.1513691071758"
------=_Part_7590_968608472.1513691071758
Content-Type: text/plain; charset="UTF-8"
On Tuesday, 19 December 2017 14:41:33 UTC+1, Nicol Bolas wrote:
>
> On Tuesday, December 19, 2017 at 7:54:51 AM UTC-5, Richard Hodges wrote:
>>
>> In c++, this is legal but UB. You may get a warning if you're lucky.
>>
>
>
>
>>
>> int foo()
>> {
>> // oops! forgot to return anything
>> }
>>
>> In my view, this not good enough. It seems to me that there is no
>> reasonable case where a developer would want this compile. It should be an
>> error.
>>
>> This of course is fine:
>>
>> int foo()
>> {
>> throw std::logic_error("not implemented yet!");
>> }
>>
>> And this of course would allow developers who like this sort of thing to
>> still get away with it, but force them to explain themselves.
>>
>> int foo()
>> {
>> int result = 0;
>> while(1)
>> {
>> result = will_eventually_be_nonzero();
>> if (result)
>> return result;
>> }
>>
>> [[not_reached]];
>>
>> // ok, a program reaching here could be allowed to express UB.
>> // if the compiler can prove that this is reachable, it should fail to
>> compile, because it knows you're lying.
>>
>
> But the compiler cannot* prove* that any particular statement is
> reachable. Not so long as there is a condition. The compiler doesn't know
> what runtime values you will pass in.
>
> This is halting-problem levels of hard.
>
> In short, if your function says it returns something, it must return
>> something, otherwise compilation error. Anything other outcome is a
>> hard-to-track bug in waiting.
>>
>
> So, what do you return in return statements that will* never be reached*?
> If the return type is not default-constructible, what can you return?
>
I've already covered this. You don't return anything, but you tell the
compiler to trust you. It's a deliberate act, not a default one. You see
the difference, I am sure.
>
> Note this is not "*can* never be reached", where it is theoretically
> possible that some set of input parameters or global state can allow you to
> get to the unreachable code. It simply won't be reached so long as the
> program is working correctly.
>
>
--
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/81b62054-bd8c-458d-a8ad-0f36c18bff42%40isocpp.org.
------=_Part_7590_968608472.1513691071758
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, 19 December 2017 14:41:33 UTC+1, Nicol=
Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>On Tuesday, December 19, 2017 at 7:54:51 AM UTC-5, Richard Hodges wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">In c++, this is lega=
l but UB. You may get a warning if you're lucky.</div></blockquote><div=
><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div><br></div><div><font face=3D"courier new, monospace">int foo=
()</font></div><div><font face=3D"courier new, monospace">{</font></div><di=
v><font face=3D"courier new, monospace">=C2=A0 // oops! forgot to return an=
ything</font></div><div><font face=3D"courier new, monospace">}</font></div=
><div><br></div><div>In my view, this not good enough. It seems to me that =
there is no reasonable case where a developer would want this compile. It s=
hould be an error.<br></div><div><br></div><div>This of course is fine:</di=
v><div><br></div><div><div><font face=3D"courier new, monospace">int foo()<=
/font></div><div><font face=3D"courier new, monospace">{</font></div><div><=
font face=3D"courier new, monospace">=C2=A0 throw std::logic_error("no=
t implemented yet!");</font></div><div><font face=3D"courier new, mono=
space">}</font></div></div><div><font face=3D"courier new, monospace"><br><=
/font></div><div><div>And this of course would allow developers who like th=
is sort of thing to still get away with it, but force them to explain thems=
elves.</div></div><div><br></div><div><div><font face=3D"courier new, monos=
pace">int foo()</font></div><div><font face=3D"courier new, monospace">{</f=
ont></div><div><font face=3D"courier new, monospace">=C2=A0 int result =3D =
0;</font></div><div><font face=3D"courier new, monospace">=C2=A0 while(1)</=
font></div><div><font face=3D"courier new, monospace">=C2=A0 {</font></div>=
<div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 result =3D will_ev=
entually_be_nonzero();</font></div><div><font face=3D"courier new, monospac=
e">=C2=A0 =C2=A0 if (result)</font></div><div><font face=3D"courier new, mo=
nospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 return result;</font></div><div><span =
style=3D"font-family:"courier new",monospace">=C2=A0 }</span><br>=
</div><div><span style=3D"font-family:"courier new",monospace"><b=
r></span></div><div><div><span style=3D"font-family:"courier new"=
,monospace">=C2=A0 [[not_reached]];=C2=A0 =C2=A0</span></div></div><div><sp=
an style=3D"font-family:"courier new",monospace"><br></span></div=
><div><span style=3D"font-family:"courier new",monospace">=C2=A0=
=C2=A0</span><span style=3D"font-family:"courier new",monospace">=
// ok, a program reaching here could be allowed to express UB.</span></div>=
<div><span style=3D"font-family:"courier new",monospace">=C2=A0 /=
/ if the compiler can prove that this is reachable, it should fail to compi=
le, because it knows you're lying.</span></div></div></div></blockquote=
><div><br></div><div>But the compiler cannot<i> prove</i> that any particul=
ar statement is reachable. Not so long as there is a condition. The compile=
r doesn't know what runtime values you will pass in.</div><div><br></di=
v><div>This is halting-problem levels of hard.</div><div><font face=3D"cour=
ier new, monospace"><br></font></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div>In short, if your function says it returns somethin=
g, it must return something, otherwise compilation error. Anything other ou=
tcome is a hard-to-track bug in waiting.</div></div></blockquote><div><br><=
/div><div>So, what do you return in return statements that will<i> never be=
reached</i>? If the return type is not default-constructible, what can you=
return?</div></div></blockquote><div><br></div><div>I've already cover=
ed this. You don't return anything, but you tell the compiler to trust =
you. It's a deliberate act, not a default one. You see the difference, =
I am sure.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div dir=3D"ltr"><div><br></div><div>Note this is not "<i><u>can</u=
></i> never be reached", where it is theoretically possible that some =
set of input parameters or global state can allow you to get to the unreach=
able code. It simply won't be reached so long as the program is working=
correctly.</div><div><br></div></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/81b62054-bd8c-458d-a8ad-0f36c18bff42%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/81b62054-bd8c-458d-a8ad-0f36c18bff42=
%40isocpp.org</a>.<br />
------=_Part_7590_968608472.1513691071758--
------=_Part_7589_1021017970.1513691071758--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 19 Dec 2017 05:48:13 -0800 (PST)
Raw View
------=_Part_27951_459757366.1513691293470
Content-Type: multipart/alternative;
boundary="----=_Part_27952_2140508837.1513691293470"
------=_Part_27952_2140508837.1513691293470
Content-Type: text/plain; charset="UTF-8"
On Tuesday, December 19, 2017 at 8:44:32 AM UTC-5, Richard Hodges wrote:
>
>
>
> On Tuesday, 19 December 2017 14:41:33 UTC+1, Nicol Bolas wrote:
>>
>> On Tuesday, December 19, 2017 at 7:54:51 AM UTC-5, Richard Hodges wrote:
>>>
>>> In c++, this is legal but UB. You may get a warning if you're lucky.
>>>
>>
>>
>>
>>>
>>> int foo()
>>> {
>>> // oops! forgot to return anything
>>> }
>>>
>>> In my view, this not good enough. It seems to me that there is no
>>> reasonable case where a developer would want this compile. It should be an
>>> error.
>>>
>>> This of course is fine:
>>>
>>> int foo()
>>> {
>>> throw std::logic_error("not implemented yet!");
>>> }
>>>
>>> And this of course would allow developers who like this sort of thing to
>>> still get away with it, but force them to explain themselves.
>>>
>>> int foo()
>>> {
>>> int result = 0;
>>> while(1)
>>> {
>>> result = will_eventually_be_nonzero();
>>> if (result)
>>> return result;
>>> }
>>>
>>> [[not_reached]];
>>>
>>> // ok, a program reaching here could be allowed to express UB.
>>> // if the compiler can prove that this is reachable, it should fail to
>>> compile, because it knows you're lying.
>>>
>>
>> But the compiler cannot* prove* that any particular statement is
>> reachable. Not so long as there is a condition. The compiler doesn't know
>> what runtime values you will pass in.
>>
>> This is halting-problem levels of hard.
>>
>> In short, if your function says it returns something, it must return
>>> something, otherwise compilation error. Anything other outcome is a
>>> hard-to-track bug in waiting.
>>>
>>
>> So, what do you return in return statements that will* never be reached*?
>> If the return type is not default-constructible, what can you return?
>>
>
> I've already covered this. You don't return anything, but you tell the
> compiler to trust you.
>
How? With what? You can't use an attribute, as an attribute cannot make an
ill-formed program well-formed.
> It's a deliberate act, not a default one. You see the difference, I am
> sure.
>
>
>>
>> Note this is not "*can* never be reached", where it is theoretically
>> possible that some set of input parameters or global state can allow you to
>> get to the unreachable code. It simply won't be reached so long as the
>> program is working correctly.
>>
>>
--
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/fbee2094-5cd7-4ecc-b186-3aee0d5b3bac%40isocpp.org.
------=_Part_27952_2140508837.1513691293470
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, December 19, 2017 at 8:44:32 AM UTC-5,=
Richard Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br><br>On Tuesday, 19 December 2017 14:41:33 UTC+1, Nicol Bolas =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, =
December 19, 2017 at 7:54:51 AM UTC-5, Richard Hodges wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr">In c++, this is legal but UB. You=
may get a warning if you're lucky.</div></blockquote><div><br></div><d=
iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v><br></div><div><font face=3D"courier new, monospace">int foo()</font></di=
v><div><font face=3D"courier new, monospace">{</font></div><div><font face=
=3D"courier new, monospace">=C2=A0 // oops! forgot to return anything</font=
></div><div><font face=3D"courier new, monospace">}</font></div><div><br></=
div><div>In my view, this not good enough. It seems to me that there is no =
reasonable case where a developer would want this compile. It should be an =
error.<br></div><div><br></div><div>This of course is fine:</div><div><br><=
/div><div><div><font face=3D"courier new, monospace">int foo()</font></div>=
<div><font face=3D"courier new, monospace">{</font></div><div><font face=3D=
"courier new, monospace">=C2=A0 throw std::logic_error("not implemente=
d yet!");</font></div><div><font face=3D"courier new, monospace">}</fo=
nt></div></div><div><font face=3D"courier new, monospace"><br></font></div>=
<div><div>And this of course would allow developers who like this sort of t=
hing to still get away with it, but force them to explain themselves.</div>=
</div><div><br></div><div><div><font face=3D"courier new, monospace">int fo=
o()</font></div><div><font face=3D"courier new, monospace">{</font></div><d=
iv><font face=3D"courier new, monospace">=C2=A0 int result =3D 0;</font></d=
iv><div><font face=3D"courier new, monospace">=C2=A0 while(1)</font></div><=
div><font face=3D"courier new, monospace">=C2=A0 {</font></div><div><font f=
ace=3D"courier new, monospace">=C2=A0 =C2=A0 result =3D will_eventually_be_=
nonzero();</font></div><div><font face=3D"courier new, monospace">=C2=A0 =
=C2=A0 if (result)</font></div><div><font face=3D"courier new, monospace">=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return result;</font></div><div><span style=3D"=
font-family:"courier new",monospace">=C2=A0 }</span><br></div><di=
v><span style=3D"font-family:"courier new",monospace"><br></span>=
</div><div><div><span style=3D"font-family:"courier new",monospac=
e">=C2=A0 [[not_reached]];=C2=A0 =C2=A0</span></div></div><div><span style=
=3D"font-family:"courier new",monospace"><br></span></div><div><s=
pan style=3D"font-family:"courier new",monospace">=C2=A0=C2=A0</s=
pan><span style=3D"font-family:"courier new",monospace">// ok, a =
program reaching here could be allowed to express UB.</span></div><div><spa=
n style=3D"font-family:"courier new",monospace">=C2=A0 // if the =
compiler can prove that this is reachable, it should fail to compile, becau=
se it knows you're lying.</span></div></div></div></blockquote><div><br=
></div><div>But the compiler cannot<i> prove</i> that any particular statem=
ent is reachable. Not so long as there is a condition. The compiler doesn&#=
39;t know what runtime values you will pass in.</div><div><br></div><div>Th=
is is halting-problem levels of hard.</div><div><font face=3D"courier new, =
monospace"><br></font></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div>In short, if your function says it returns something, it mus=
t return something, otherwise compilation error. Anything other outcome is =
a hard-to-track bug in waiting.</div></div></blockquote><div><br></div><div=
>So, what do you return in return statements that will<i> never be reached<=
/i>? If the return type is not default-constructible, what can you return?<=
/div></div></blockquote><div><br></div><div>I've already covered this. =
You don't return anything, but you tell the compiler to trust you.</div=
></div></blockquote><div><br></div><div>How? With what? You can't use a=
n attribute, as an attribute cannot make an ill-formed program well-formed.=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><div>It's a deliberate act, not a default one. You see the di=
fference, I am sure.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div><br></div><div>Note this is not "<i><u>c=
an</u></i> never be reached", where it is theoretically possible that =
some set of input parameters or global state can allow you to get to the un=
reachable code. It simply won't be reached so long as the program is wo=
rking correctly.</div><div><br></div></div></blockquote></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/fbee2094-5cd7-4ecc-b186-3aee0d5b3bac%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fbee2094-5cd7-4ecc-b186-3aee0d5b3bac=
%40isocpp.org</a>.<br />
------=_Part_27952_2140508837.1513691293470--
------=_Part_27951_459757366.1513691293470--
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Tue, 19 Dec 2017 13:58:41 +0000
Raw View
--001a11495e1857d9ce0560b1dd5d
Content-Type: text/plain; charset="UTF-8"
On 19 Dec 2017 13:41, "Nicol Bolas" <jmckesson@gmail.com> wrote:
But the compiler cannot* prove* that any particular statement is reachable.
Not so long as there is a condition. The compiler doesn't know what runtime
values you will pass in.
This is halting-problem levels of hard.
It needn't be. Simply by adding an abort, throw, or whatever to the very
end of each function if there are branches without returns (in the absence
of some code that allows the user to tell the compiler to relax). It
doesn't affect well formed functions because they have already returned by
that point. It only actually affects anything that reaches the end without
returning. As I said in a different reply, this probably messes up with
some optimisations (obbiously code size, but I'm thinking about speed), so
I'm dubious, but it certainly isn't halting-problem hard if you take into
account that post-return code does nothing.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCOQLjK-tcWq-k8snEsJyAmtFda1Sqo1JLa8JEzNgn2dtA%40mail.gmail.com.
--001a11495e1857d9ce0560b1dd5d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div class=3D"gmail_extra" dir=3D"auto"><div class=3D"gma=
il_quote">On 19 Dec 2017 13:41, "Nicol Bolas" <<a href=3D"mail=
to:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>> wrote=
:<br type=3D"attribution"><blockquote class=3D"m_-4705348703384289694quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div class=3D"m_-4705348703384289694quoted-text"><div>But th=
e compiler cannot<i> prove</i> that any particular statement is reachable. =
Not so long as there is a condition. The compiler doesn't know what run=
time values you will pass in.<br></div></div><div><br></div><div>This is ha=
lting-problem levels of hard.</div></div></blockquote></div></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">It needn't be. Simply by adding a=
n abort, throw, or whatever to the very end of each function if there are b=
ranches without returns (in the absence of some code that allows the user t=
o tell the compiler to relax). It doesn't affect well formed functions =
because they have already returned by that point. It only actually affects =
anything that reaches the end without returning. As I said in a different r=
eply, this probably messes up with some optimisations (obbiously code size,=
but I'm thinking about speed), so I'm dubious, but it certainly is=
n't halting-problem hard if you take into account that post-return code=
does nothing.</div><div class=3D"gmail_extra" dir=3D"auto"></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCOQLjK-tcWq-k8snEsJyAmtFda1Sq=
o1JLa8JEzNgn2dtA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCOQLjK-=
tcWq-k8snEsJyAmtFda1Sqo1JLa8JEzNgn2dtA%40mail.gmail.com</a>.<br />
--001a11495e1857d9ce0560b1dd5d--
.
Author: Jan Wilmans <janwilmans@gmail.com>
Date: Tue, 19 Dec 2017 15:12:38 +0100
Raw View
--94eb2c058af66054670560b2108c
Content-Type: text/plain; charset="UTF-8"
On 19 December 2017 at 14:58, Jake Arkinstall <jake.arkinstall@gmail.com>
wrote:
> On 19 Dec 2017 13:41, "Nicol Bolas" <jmckesson@gmail.com> wrote:
>
> But the compiler cannot* prove* that any particular statement is
> reachable. Not so long as there is a condition. The compiler doesn't know
> what runtime values you will pass in.
>
> This is halting-problem levels of hard.
>
>
> It needn't be. Simply by adding an abort, throw, or whatever to the very
> end of each function if there are branches without returns (in the absence
> of some code that allows the user to tell the compiler to relax). It
> doesn't affect well formed functions because they have already returned by
> that point. It only actually affects anything that reaches the end without
> returning. As I said in a different reply, this probably messes up with
> some optimisations (obviously code size, but I'm thinking about speed), so
> I'm dubious, but it certainly isn't halting-problem hard if you take into
> account that post-return code does nothing.
>
I agree, the question might be: why was it specified as being UB in the
first place. About the complexity of the problem: the compiler could assume
all path are always taking at some point and that could pessimize some
optimizations that are currently done. What kind of code is currently out
there that would rely on this?
--
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/CADtNNhhHAaXcvO-p4vd8hr8X8w8ixgAR3RJWEDoY5r8o6cz8Bw%40mail.gmail.com.
--94eb2c058af66054670560b2108c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1=
9 December 2017 at 14:58, Jake Arkinstall <span dir=3D"ltr"><<a href=3D"=
mailto:jake.arkinstall@gmail.com" target=3D"_blank">jake.arkinstall@gmail.c=
om</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto=
"><span class=3D""><div class=3D"gmail_extra" dir=3D"auto"><div class=3D"gm=
ail_quote">On 19 Dec 2017 13:41, "Nicol Bolas" <<a href=3D"mai=
lto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>> wrot=
e:<br type=3D"attribution"><blockquote class=3D"m_1596452103187820604m_-470=
5348703384289694quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div class=3D"m_1596452103187820604m_-=
4705348703384289694quoted-text"><div>But the compiler cannot<i> prove</i> t=
hat any particular statement is reachable. Not so long as there is a condit=
ion. The compiler doesn't know what runtime values you will pass in.<br=
></div></div><div><br></div><div>This is halting-problem levels of hard.</d=
iv></div></blockquote></div></div><div dir=3D"auto"><br></div></span><div d=
ir=3D"auto">It needn't be. Simply by adding an abort, throw, or whateve=
r to the very end of each function if there are branches without returns (i=
n the absence of some code that allows the user to tell the compiler to rel=
ax). It doesn't affect well formed functions because they have already =
returned by that point. It only actually affects anything that reaches the =
end without returning. As I said in a different reply, this probably messes=
up with some optimisations (obviously code size, but I'm thinking abou=
t speed), so I'm dubious, but it certainly isn't halting-problem ha=
rd if you take into account that post-return code does nothing.</div></div>=
</blockquote><div><br></div><div>I agree, the question might be: why was it=
specified as being UB in the first place. About the complexity of the prob=
lem: the compiler could assume all path are always taking at some point and=
that could pessimize some optimizations that are currently done. What kind=
of code is currently out there that would rely on this?</div><div><br></di=
v><div>=C2=A0</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/CADtNNhhHAaXcvO-p4vd8hr8X8w8ixgAR3RJW=
EDoY5r8o6cz8Bw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADtNNhhHAaXcvO-p=
4vd8hr8X8w8ixgAR3RJWEDoY5r8o6cz8Bw%40mail.gmail.com</a>.<br />
--94eb2c058af66054670560b2108c--
.
Author: inkwizytoryankes@gmail.com
Date: Tue, 19 Dec 2017 06:18:22 -0800 (PST)
Raw View
------=_Part_7876_1938828996.1513693102194
Content-Type: multipart/alternative;
boundary="----=_Part_7877_641705610.1513693102194"
------=_Part_7877_641705610.1513693102194
Content-Type: text/plain; charset="UTF-8"
On Tuesday, December 19, 2017 at 2:58:44 PM UTC+1, Jake Arkinstall wrote:
>
> On 19 Dec 2017 13:41, "Nicol Bolas" <jmck...@gmail.com <javascript:>>
> wrote:
>
> But the compiler cannot* prove* that any particular statement is
> reachable. Not so long as there is a condition. The compiler doesn't know
> what runtime values you will pass in.
>
> This is halting-problem levels of hard.
>
>
> It needn't be. Simply by adding an abort, throw, or whatever to the very
> end of each function if there are branches without returns (in the absence
> of some code that allows the user to tell the compiler to relax). It
> doesn't affect well formed functions because they have already returned by
> that point. It only actually affects anything that reaches the end without
> returning. As I said in a different reply, this probably messes up with
> some optimisations (obbiously code size, but I'm thinking about speed), so
> I'm dubious, but it certainly isn't halting-problem hard if you take into
> account that post-return code does nothing.
>
Isn't this QoI thing? UB mean that abort is possible action. If every
implementation agree on this (or at least main ones) then we could add this
to standard to enforce this.
Another thing is cost of handling this. Can we terminate using only
unconditional jump or some cleanups/fix are always needed before we call
abort?
--
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/9c798a94-15bf-43ff-84bc-edfa4b61e988%40isocpp.org.
------=_Part_7877_641705610.1513693102194
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, December 19, 2017 at 2:58:44 PM UTC+1,=
Jake Arkinstall wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"auto"><div dir=3D"auto"><div class=3D"gmail_quote">On 19 Dec 2017 13:4=
1, "Nicol Bolas" <<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"oiZ-QWNgAgAJ" rel=3D"nofollow" onmousedown=3D"this.h=
ref=3D'javascript:';return true;" onclick=3D"this.href=3D'javas=
cript:';return true;">jmck...@gmail.com</a>> wrote:<br type=3D"attri=
bution"><blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div><div>But the compiler cannot<i> prov=
e</i> that any particular statement is reachable. Not so long as there is a=
condition. The compiler doesn't know what runtime values you will pass=
in.<br></div></div><div><br></div><div>This is halting-problem levels of h=
ard.</div></div></blockquote></div></div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">It needn't be. Simply by adding an abort, throw, or whateve=
r to the very end of each function if there are branches without returns (i=
n the absence of some code that allows the user to tell the compiler to rel=
ax). It doesn't affect well formed functions because they have already =
returned by that point. It only actually affects anything that reaches the =
end without returning. As I said in a different reply, this probably messes=
up with some optimisations (obbiously code size, but I'm thinking abou=
t speed), so I'm dubious, but it certainly isn't halting-problem ha=
rd if you take into account that post-return code does nothing.</div></div>=
</blockquote><div>=C2=A0</div><div>Isn't this QoI thing? UB mean that a=
bort is possible action. If every implementation agree on this (or at least=
main ones) then we could add this to standard to enforce this.</div><div>A=
nother thing is cost of handling this. Can we terminate using only uncondit=
ional jump or some cleanups/fix are always needed before we call abort?<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/9c798a94-15bf-43ff-84bc-edfa4b61e988%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9c798a94-15bf-43ff-84bc-edfa4b61e988=
%40isocpp.org</a>.<br />
------=_Part_7877_641705610.1513693102194--
------=_Part_7876_1938828996.1513693102194--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Tue, 19 Dec 2017 15:18:45 +0100
Raw View
--94eb2c05b4ba1a31980560b2259f
Content-Type: text/plain; charset="UTF-8"
On 19 December 2017 at 14:48, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Tuesday, December 19, 2017 at 8:44:32 AM UTC-5, Richard Hodges wrote:
>>
>>
>>
>> On Tuesday, 19 December 2017 14:41:33 UTC+1, Nicol Bolas wrote:
>>>
>>> On Tuesday, December 19, 2017 at 7:54:51 AM UTC-5, Richard Hodges wrote:
>>>>
>>>> In c++, this is legal but UB. You may get a warning if you're lucky.
>>>>
>>>
>>>
>>>
>>>>
>>>> int foo()
>>>> {
>>>> // oops! forgot to return anything
>>>> }
>>>>
>>>> In my view, this not good enough. It seems to me that there is no
>>>> reasonable case where a developer would want this compile. It should be an
>>>> error.
>>>>
>>>> This of course is fine:
>>>>
>>>> int foo()
>>>> {
>>>> throw std::logic_error("not implemented yet!");
>>>> }
>>>>
>>>> And this of course would allow developers who like this sort of thing
>>>> to still get away with it, but force them to explain themselves.
>>>>
>>>> int foo()
>>>> {
>>>> int result = 0;
>>>> while(1)
>>>> {
>>>> result = will_eventually_be_nonzero();
>>>> if (result)
>>>> return result;
>>>> }
>>>>
>>>> [[not_reached]];
>>>>
>>>> // ok, a program reaching here could be allowed to express UB.
>>>> // if the compiler can prove that this is reachable, it should fail
>>>> to compile, because it knows you're lying.
>>>>
>>>
>>> But the compiler cannot* prove* that any particular statement is
>>> reachable. Not so long as there is a condition. The compiler doesn't know
>>> what runtime values you will pass in.
>>>
>>> This is halting-problem levels of hard.
>>>
>>> In short, if your function says it returns something, it must return
>>>> something, otherwise compilation error. Anything other outcome is a
>>>> hard-to-track bug in waiting.
>>>>
>>>
>>> So, what do you return in return statements that will* never be reached*?
>>> If the return type is not default-constructible, what can you return?
>>>
>>
>> I've already covered this. You don't return anything, but you tell the
>> compiler to trust you.
>>
>
> How? With what? You can't use an attribute, as an attribute cannot make an
> ill-formed program well-formed.
>
Putting aside for one moment that this is an artificial restriction (since
a new standard can simply overrule this arbitrary rule).
I am not a purist. I don't mind the appearance of new keywords or syntax,
and I don't care if my c++20 program will be incompatible with a c++17
program.
So simply make it so from c++20 that a function shall return or throw. i.e.
programmers shall be honest or their programs shall not compile.
Back to attributes...
What are they really? They're new keywords that the c++ committee felt too
timid to enforce on compiler writers.
The answer is to stop being insipid and simply mandate that they shall, as
of c++20, be implemented and that they damn well will make a well-formed
program ill-formed or vice-versa.
If developers don't want to go forward, they are completely at liberty to
stay behind.
You see how simple that is?
>
>
>> It's a deliberate act, not a default one. You see the difference, I am
>> sure.
>>
>>
>>>
>>> Note this is not "*can* never be reached", where it is theoretically
>>> possible that some set of input parameters or global state can allow you to
>>> get to the unreachable code. It simply won't be reached so long as the
>>> program is working correctly.
>>>
>>> --
> 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/fbee2094-5cd7-4ecc-
> b186-3aee0d5b3bac%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fbee2094-5cd7-4ecc-b186-3aee0d5b3bac%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CALvx3hZRyMiRtuAw8d7uKXpqxDtOJCCgGnXr7U2jCjL128Ejfg%40mail.gmail.com.
--94eb2c05b4ba1a31980560b2259f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 19 December 2017 at 14:48, Nicol Bolas <span dir=3D"ltr"><<a href=
=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><d=
iv class=3D"h5"><br><br>On Tuesday, December 19, 2017 at 8:44:32 AM UTC-5, =
Richard Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><br><br>On Tuesday, 19 December 2017 14:41:33 UTC+1, Nicol Bolas wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, Decemb=
er 19, 2017 at 7:54:51 AM UTC-5, Richard Hodges wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr">In c++, this is legal but UB. You may g=
et a warning if you're lucky.</div></blockquote><div><br></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>=
</div><div><font face=3D"courier new, monospace">int foo()</font></div><div=
><font face=3D"courier new, monospace">{</font></div><div><font face=3D"cou=
rier new, monospace">=C2=A0 // oops! forgot to return anything</font></div>=
<div><font face=3D"courier new, monospace">}</font></div><div><br></div><di=
v>In my view, this not good enough. It seems to me that there is no reasona=
ble case where a developer would want this compile. It should be an error.<=
br></div><div><br></div><div>This of course is fine:</div><div><br></div><d=
iv><div><font face=3D"courier new, monospace">int foo()</font></div><div><f=
ont face=3D"courier new, monospace">{</font></div><div><font face=3D"courie=
r new, monospace">=C2=A0 throw std::logic_error("not implemented yet!&=
quot;);</font></div><div><font face=3D"courier new, monospace">}</font></di=
v></div><div><font face=3D"courier new, monospace"><br></font></div><div><d=
iv>And this of course would allow developers who like this sort of thing to=
still get away with it, but force them to explain themselves.</div></div><=
div><br></div><div><div><font face=3D"courier new, monospace">int foo()</fo=
nt></div><div><font face=3D"courier new, monospace">{</font></div><div><fon=
t face=3D"courier new, monospace">=C2=A0 int result =3D 0;</font></div><div=
><font face=3D"courier new, monospace">=C2=A0 while(1)</font></div><div><fo=
nt face=3D"courier new, monospace">=C2=A0 {</font></div><div><font face=3D"=
courier new, monospace">=C2=A0 =C2=A0 result =3D will_eventually_be_nonzero=
();</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 if=
(result)</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 return result;</font></div><div><span style=3D"font-famil=
y:"courier new",monospace">=C2=A0 }</span><br></div><div><span st=
yle=3D"font-family:"courier new",monospace"><br></span></div><div=
><div><span style=3D"font-family:"courier new",monospace">=C2=A0 =
[[not_reached]];=C2=A0 =C2=A0</span></div></div><div><span style=3D"font-fa=
mily:"courier new",monospace"><br></span></div><div><span style=
=3D"font-family:"courier new",monospace">=C2=A0=C2=A0</span><span=
style=3D"font-family:"courier new",monospace">// ok, a program r=
eaching here could be allowed to express UB.</span></div><div><span style=
=3D"font-family:"courier new",monospace">=C2=A0 // if the compile=
r can prove that this is reachable, it should fail to compile, because it k=
nows you're lying.</span></div></div></div></blockquote><div><br></div>=
<div>But the compiler cannot<i> prove</i> that any particular statement is =
reachable. Not so long as there is a condition. The compiler doesn't kn=
ow what runtime values you will pass in.</div><div><br></div><div>This is h=
alting-problem levels of hard.</div><div><font face=3D"courier new, monospa=
ce"><br></font></div><blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div>In short, if your function says it returns something, it must retur=
n something, otherwise compilation error. Anything other outcome is a hard-=
to-track bug in waiting.</div></div></blockquote><div><br></div><div>So, wh=
at do you return in return statements that will<i> never be reached</i>? If=
the return type is not default-constructible, what can you return?</div></=
div></blockquote><div><br></div><div>I've already covered this. You don=
't return anything, but you tell the compiler to trust you.</div></div>=
</blockquote><div><br></div></div></div><div>How? With what? You can't =
use an attribute, as an attribute cannot make an ill-formed program well-fo=
rmed.</div></div></blockquote><div><br></div><div>Putting aside for one mom=
ent that this is an artificial restriction (since a new standard can simply=
overrule this arbitrary rule).</div><div><br></div><div>I am not a purist.=
I don't mind the appearance of new keywords or syntax, and I don't=
care if my c++20 program will be incompatible with a c++17 program.</div><=
div><br></div><div>So simply make it so from c++20 that a function shall re=
turn or throw. i.e. programmers shall be honest or their programs shall not=
compile.</div><div><br></div><div>Back to attributes...</div><div><br></di=
v><div>What are they really? They're new keywords that the c++ committe=
e felt too timid to enforce on compiler writers.</div><div><br></div><div>T=
he answer is to stop being insipid and simply mandate that they shall, as o=
f c++20, be implemented and that they damn well will make a well-formed pro=
gram ill-formed or vice-versa.</div><div><br></div><div>If developers don&#=
39;t want to go forward, they are completely at liberty to stay behind.</di=
v><div><br></div><div>You see how simple that is?=C2=A0</div><div><br></div=
><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr"><span class=3D""><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div>It's a deliberate act, not a default one. Yo=
u see the difference, I am sure.</div><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>Note this is not &=
quot;<i><u>can</u></i> never be reached", where it is theoretically po=
ssible that some set of input parameters or global state can allow you to g=
et to the unreachable code. It simply won't be reached so long as the p=
rogram is working correctly.</div><div><br></div></div></blockquote></div><=
/blockquote></span></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/fbee2094-5cd7-4ecc-b186-3aee0d5b3bac%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/fbee=
2094-5cd7-4ecc-<wbr>b186-3aee0d5b3bac%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CALvx3hZRyMiRtuAw8d7uKXpqxDtOJCCgGnXr=
7U2jCjL128Ejfg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZRyMiRtuAw=
8d7uKXpqxDtOJCCgGnXr7U2jCjL128Ejfg%40mail.gmail.com</a>.<br />
--94eb2c05b4ba1a31980560b2259f--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 19 Dec 2017 06:20:23 -0800 (PST)
Raw View
------=_Part_28499_1555214322.1513693224015
Content-Type: multipart/alternative;
boundary="----=_Part_28500_1603343140.1513693224015"
------=_Part_28500_1603343140.1513693224015
Content-Type: text/plain; charset="UTF-8"
On Tuesday, December 19, 2017 at 9:13:01 AM UTC-5, Jan Wilmans wrote:
>
> On 19 December 2017 at 14:58, Jake Arkinstall <jake.ar...@gmail.com
> <javascript:>> wrote:
>
>> On 19 Dec 2017 13:41, "Nicol Bolas" <jmck...@gmail.com <javascript:>>
>> wrote:
>>
>> But the compiler cannot* prove* that any particular statement is
>> reachable. Not so long as there is a condition. The compiler doesn't know
>> what runtime values you will pass in.
>>
>> This is halting-problem levels of hard.
>>
>>
>> It needn't be. Simply by adding an abort, throw, or whatever to the very
>> end of each function if there are branches without returns (in the absence
>> of some code that allows the user to tell the compiler to relax). It
>> doesn't affect well formed functions because they have already returned by
>> that point. It only actually affects anything that reaches the end without
>> returning. As I said in a different reply, this probably messes up with
>> some optimisations (obviously code size, but I'm thinking about speed), so
>> I'm dubious, but it certainly isn't halting-problem hard if you take into
>> account that post-return code does nothing.
>>
>
> I agree, the question might be: why was it specified as being UB in the
> first place.
>
As opposed to what? Adding yet another keyword, one which serves only as a
indicator of the programmer's intent? After all, this won't affect code
generation. And if it doesn't affect the generated code... why is it there?
Having an [[unreachable]] attribute is good enough; we don't need to make
it ill-formed in every case.
About the complexity of the problem: the compiler could assume all path are
> always taking at some point and that could pessimize some optimizations
> that are currently done. What kind of code is currently out there that
> would rely on this?
>
>
>
>
>
--
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/8965fff3-daeb-4a81-9822-fb7f99a8bd33%40isocpp.org.
------=_Part_28500_1603343140.1513693224015
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, December 19, 2017 at 9:13:01 AM UTC-5,=
Jan Wilmans wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div><div class=3D"gmail_quote">On 19 December 2017 at 14:58, Jake Ar=
kinstall <span dir=3D"ltr"><<a onmousedown=3D"this.href=3D'javascrip=
t:';return true;" onclick=3D"this.href=3D'javascript:';return t=
rue;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscate=
d-mailto=3D"GjXmzyphAgAJ">jake.ar...@gmail.com</a>></span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"auto"><span><div dir=3D"auto"><div =
class=3D"gmail_quote">On 19 Dec 2017 13:41, "Nicol Bolas" <<a =
onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"t=
his.href=3D'javascript:';return true;" href=3D"javascript:" target=
=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"GjXmzyphAgAJ">jmck...=
@gmail.com</a>> wrote:<br type=3D"attribution"><blockquote style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div><div>But the compiler cannot<i> prove</i> that any particular stateme=
nt is reachable. Not so long as there is a condition. The compiler doesn=
9;t know what runtime values you will pass in.<br></div></div><div><br></di=
v><div>This is halting-problem levels of hard.</div></div></blockquote></di=
v></div><div dir=3D"auto"><br></div></span><div dir=3D"auto">It needn't=
be. Simply by adding an abort, throw, or whatever to the very end of each =
function if there are branches without returns (in the absence of some code=
that allows the user to tell the compiler to relax). It doesn't affect=
well formed functions because they have already returned by that point. It=
only actually affects anything that reaches the end without returning. As =
I said in a different reply, this probably messes up with some optimisation=
s (obviously code size, but I'm thinking about speed), so I'm dubio=
us, but it certainly isn't halting-problem hard if you take into accoun=
t that post-return code does nothing.</div></div></blockquote><div><br></di=
v><div>I agree, the question might be: why was it specified as being UB in =
the first place.</div></div></div></div></blockquote><div><br></div><div>As=
opposed to what? Adding yet another keyword, one which serves only as a in=
dicator of the programmer's intent? After all, this won't affect co=
de generation. And if it doesn't affect the generated code... why is it=
there?</div><div><br></div><div>Having an [[unreachable]] attribute is goo=
d enough; we don't need to make it ill-formed in every case.</div><div>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v><div class=3D"gmail_quote"><div>About the complexity of the problem: the =
compiler could assume all path are always taking at some point and that cou=
ld pessimize some optimizations that are currently done. What kind of code =
is currently out there that would rely on this?</div><div><br></div><div>=
=C2=A0</div><div><br></div><div><br></div></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/8965fff3-daeb-4a81-9822-fb7f99a8bd33%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8965fff3-daeb-4a81-9822-fb7f99a8bd33=
%40isocpp.org</a>.<br />
------=_Part_28500_1603343140.1513693224015--
------=_Part_28499_1555214322.1513693224015--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 19 Dec 2017 06:39:34 -0800 (PST)
Raw View
------=_Part_28713_6771599.1513694374586
Content-Type: multipart/alternative;
boundary="----=_Part_28714_919128488.1513694374587"
------=_Part_28714_919128488.1513694374587
Content-Type: text/plain; charset="UTF-8"
On Tuesday, December 19, 2017 at 9:18:48 AM UTC-5, Richard Hodges wrote:
>
> On 19 December 2017 at 14:48, Nicol Bolas <jmck...@gmail.com <javascript:>
> > wrote:
>
>> On Tuesday, December 19, 2017 at 8:44:32 AM UTC-5, Richard Hodges wrote:
>>>
>>> On Tuesday, 19 December 2017 14:41:33 UTC+1, Nicol Bolas wrote:
>>>>
>>>> On Tuesday, December 19, 2017 at 7:54:51 AM UTC-5, Richard Hodges wrote:
>>>>>
>>>>> In c++, this is legal but UB. You may get a warning if you're lucky.
>>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> int foo()
>>>>> {
>>>>> // oops! forgot to return anything
>>>>> }
>>>>>
>>>>> In my view, this not good enough. It seems to me that there is no
>>>>> reasonable case where a developer would want this compile. It should be an
>>>>> error.
>>>>>
>>>>> This of course is fine:
>>>>>
>>>>> int foo()
>>>>> {
>>>>> throw std::logic_error("not implemented yet!");
>>>>> }
>>>>>
>>>>> And this of course would allow developers who like this sort of thing
>>>>> to still get away with it, but force them to explain themselves.
>>>>>
>>>>> int foo()
>>>>> {
>>>>> int result = 0;
>>>>> while(1)
>>>>> {
>>>>> result = will_eventually_be_nonzero();
>>>>> if (result)
>>>>> return result;
>>>>> }
>>>>>
>>>>> [[not_reached]];
>>>>>
>>>>> // ok, a program reaching here could be allowed to express UB.
>>>>> // if the compiler can prove that this is reachable, it should fail
>>>>> to compile, because it knows you're lying.
>>>>>
>>>>
>>>> But the compiler cannot* prove* that any particular statement is
>>>> reachable. Not so long as there is a condition. The compiler doesn't know
>>>> what runtime values you will pass in.
>>>>
>>>> This is halting-problem levels of hard.
>>>>
>>>> In short, if your function says it returns something, it must return
>>>>> something, otherwise compilation error. Anything other outcome is a
>>>>> hard-to-track bug in waiting.
>>>>>
>>>>
>>>> So, what do you return in return statements that will* never be
>>>> reached*? If the return type is not default-constructible, what can
>>>> you return?
>>>>
>>>
>>> I've already covered this. You don't return anything, but you tell the
>>> compiler to trust you.
>>>
>>
>> How? With what? You can't use an attribute, as an attribute cannot make
>> an ill-formed program well-formed.
>>
>
> Putting aside for one moment that this is an artificial restriction (since
> a new standard can simply overrule this arbitrary rule).
>
> I am not a purist. I don't mind the appearance of new keywords or syntax,
> and I don't care if my c++20 program will be incompatible with a c++17
> program.
>
> So simply make it so from c++20 that a function shall return or throw.
> i.e. programmers shall be honest or their programs shall not compile.
>
This is what we call a breaking change. So named because it breaks people's
perfectly functioning code.
Breaking people's code is not good. It's doubly not good to do so without
fair warning. It's triply not good to do so for so little *genuine* gain.
Remember: we're not talking about something major. We're not talking about
a feature that will dramatically improve how C++ is used, change how we
write functions (the way structured binding does), or dramatically lower
the bar for some of C++'s esoteric features (the way concepts does). We're
talking about a purely notational issue. This will not make anyone's code
one iota faster or easier to write.
Breaking perfectly functioning code for that? Not worth it.
> Back to attributes...
>
> What are they really? They're new keywords that the c++ committee felt too
> timid to enforce on compiler writers.
>
No, they're not. The C++ committee had a real proposal for making adding
new keywords easier (P0056
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0056r0.html>),
and they rejected it precisely* because* they want adding keywords to be
hard
<https://botondballo.wordpress.com/2015/11/09/trip-report-c-standards-meeting-in-kona-october-2015/>
..
Attributes were originally used for `override` and `final`, but that was
redacted and they were made context-sensitive keywords. Why? Specifically
because the committee* doesn't want* attributes to be used in this way.
The answer is to stop being insipid and simply mandate that they shall, as
> of c++20, be implemented and that they damn well will make a well-formed
> program ill-formed or vice-versa.
>
> If developers don't want to go forward, they are completely at liberty to
> stay behind.
>
> You see how simple that is?
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/54de1e6b-1ff5-4b47-ab03-c29ece6abde3%40isocpp.org.
------=_Part_28714_919128488.1513694374587
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, December 19, 2017 at 9:18:48 AM UTC-5, Richard=
Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div><div class=3D"gmail_quote">On 19 December 2017 at 14:48, Nicol Bolas =
<span dir=3D"ltr"><<a onmousedown=3D"this.href=3D'javascript:';r=
eturn true;" onclick=3D"this.href=3D'javascript:';return true;" hre=
f=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=
=3D"tYWEt3thAgAJ">jmck...@gmail.com</a>></span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div><div>On Tuesday, December 19, 2017 a=
t 8:44:32 AM UTC-5, Richard Hodges wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr">On Tuesday, 19 December 2017 14:41:33 UTC+1, Nicol B=
olas wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Tue=
sday, December 19, 2017 at 7:54:51 AM UTC-5, Richard Hodges wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">In c++, this is legal but U=
B. You may get a warning if you're lucky.</div></blockquote><div><br></=
div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div><br></div><div><font face=3D"courier new, monospace">int foo()</fon=
t></div><div><font face=3D"courier new, monospace">{</font></div><div><font=
face=3D"courier new, monospace">=C2=A0 // oops! forgot to return anything<=
/font></div><div><font face=3D"courier new, monospace">}</font></div><div><=
br></div><div>In my view, this not good enough. It seems to me that there i=
s no reasonable case where a developer would want this compile. It should b=
e an error.<br></div><div><br></div><div>This of course is fine:</div><div>=
<br></div><div><div><font face=3D"courier new, monospace">int foo()</font><=
/div><div><font face=3D"courier new, monospace">{</font></div><div><font fa=
ce=3D"courier new, monospace">=C2=A0 throw std::logic_error("not imple=
mented yet!");</font></div><div><font face=3D"courier new, monospace">=
}</font></div></div><div><font face=3D"courier new, monospace"><br></font><=
/div><div><div>And this of course would allow developers who like this sort=
of thing to still get away with it, but force them to explain themselves.<=
/div></div><div><br></div><div><div><font face=3D"courier new, monospace">i=
nt foo()</font></div><div><font face=3D"courier new, monospace">{</font></d=
iv><div><font face=3D"courier new, monospace">=C2=A0 int result =3D 0;</fon=
t></div><div><font face=3D"courier new, monospace">=C2=A0 while(1)</font></=
div><div><font face=3D"courier new, monospace">=C2=A0 {</font></div><div><f=
ont face=3D"courier new, monospace">=C2=A0 =C2=A0 result =3D will_eventuall=
y_be_nonzero();</font></div><div><font face=3D"courier new, monospace">=C2=
=A0 =C2=A0 if (result)</font></div><div><font face=3D"courier new, monospac=
e">=C2=A0 =C2=A0 =C2=A0 =C2=A0 return result;</font></div><div><span style=
=3D"font-family:"courier new",monospace">=C2=A0 }</span><br></div=
><div><span style=3D"font-family:"courier new",monospace"><br></s=
pan></div><div><div><span style=3D"font-family:"courier new",mono=
space">=C2=A0 [[not_reached]];=C2=A0 =C2=A0</span></div></div><div><span st=
yle=3D"font-family:"courier new",monospace"><br></span></div><div=
><span style=3D"font-family:"courier new",monospace">=C2=A0=C2=A0=
</span><span style=3D"font-family:"courier new",monospace">// ok,=
a program reaching here could be allowed to express UB.</span></div><div><=
span style=3D"font-family:"courier new",monospace">=C2=A0 // if t=
he compiler can prove that this is reachable, it should fail to compile, be=
cause it knows you're lying.</span></div></div></div></blockquote><div>=
<br></div><div>But the compiler cannot<i> prove</i> that any particular sta=
tement is reachable. Not so long as there is a condition. The compiler does=
n't know what runtime values you will pass in.</div><div><br></div><div=
>This is halting-problem levels of hard.</div><div><font face=3D"courier ne=
w, monospace"><br></font></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr"><div>In short, if your function says it returns something, it =
must return something, otherwise compilation error. Anything other outcome =
is a hard-to-track bug in waiting.</div></div></blockquote><div><br></div><=
div>So, what do you return in return statements that will<i> never be reach=
ed</i>? If the return type is not default-constructible, what can you retur=
n?</div></div></blockquote><div><br></div><div>I've already covered thi=
s. You don't return anything, but you tell the compiler to trust you.</=
div></div></blockquote><div><br></div></div></div><div>How? With what? You =
can't use an attribute, as an attribute cannot make an ill-formed progr=
am well-formed.</div></div></blockquote><div><br></div><div>Putting aside f=
or one moment that this is an artificial restriction (since a new standard =
can simply overrule this arbitrary rule).</div><div><br></div><div>I am not=
a purist. I don't mind the appearance of new keywords or syntax, and I=
don't care if my c++20 program will be incompatible with a c++17 progr=
am.</div><div><br></div><div>So simply make it so from c++20 that a functio=
n shall return or throw. i.e. programmers shall be honest or their programs=
shall not compile.</div></div></div></div></blockquote><div><br></div><div=
>This is what we call a breaking change. So named because it breaks people&=
#39;s perfectly functioning code.</div><div><br></div><div>Breaking people&=
#39;s code is not good. It's doubly not good to do so without fair warn=
ing. It's triply not good to do so for so little <i>genuine</i> gain.</=
div><div><br></div><div>Remember: we're not talking about something maj=
or. We're not talking about a feature that will dramatically improve ho=
w C++ is used, change how we write functions (the way structured binding do=
es), or dramatically lower the bar for some of C++'s esoteric features =
(the way concepts does). We're talking about a purely notational issue.=
This will not make anyone's code one iota faster or easier to write.</=
div><div><br></div><div>Breaking perfectly functioning code for that? Not w=
orth it.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Back to attributes..=
..</div><div><br></div><div>What are they really? They're new keywords t=
hat the c++ committee felt too timid to enforce on compiler writers.</div><=
/div></div></div></blockquote><div><br></div><div>No, they're not. The =
C++ committee had a real proposal for making adding new keywords easier (<a=
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0056r0.ht=
ml">P0056</a>), and they rejected it precisely<i> because</i> they <a href=
=3D"https://botondballo.wordpress.com/2015/11/09/trip-report-c-standards-me=
eting-in-kona-october-2015/">want adding keywords to be hard</a>.</div><div=
><br></div><div>Attributes were originally used for `override` and `final`,=
but that was redacted and they were made context-sensitive keywords. Why? =
Specifically because the committee<i> doesn't want</i> attributes to be=
used in this way.</div><div><i><br></i></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>The a=
nswer is to stop being insipid and simply mandate that they shall, as of c+=
+20, be implemented and that they damn well will make a well-formed program=
ill-formed or vice-versa.</div><div><br></div><div>If developers don't=
want to go forward, they are completely at liberty to stay behind.</div><d=
iv><br></div><div>You see how simple that is?<br></div></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/54de1e6b-1ff5-4b47-ab03-c29ece6abde3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/54de1e6b-1ff5-4b47-ab03-c29ece6abde3=
%40isocpp.org</a>.<br />
------=_Part_28714_919128488.1513694374587--
------=_Part_28713_6771599.1513694374586--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 19 Dec 2017 06:40:55 -0800 (PST)
Raw View
------=_Part_28681_646303788.1513694456047
Content-Type: multipart/alternative;
boundary="----=_Part_28682_1523520213.1513694456047"
------=_Part_28682_1523520213.1513694456047
Content-Type: text/plain; charset="UTF-8"
On Tuesday, December 19, 2017 at 9:18:22 AM UTC-5, Marcin Jaczewski wrote:
>
> On Tuesday, December 19, 2017 at 2:58:44 PM UTC+1, Jake Arkinstall wrote:
>>
>> On 19 Dec 2017 13:41, "Nicol Bolas" <jmck...@gmail.com> wrote:
>>
>> But the compiler cannot* prove* that any particular statement is
>> reachable. Not so long as there is a condition. The compiler doesn't know
>> what runtime values you will pass in.
>>
>> This is halting-problem levels of hard.
>>
>>
>> It needn't be. Simply by adding an abort, throw, or whatever to the very
>> end of each function if there are branches without returns (in the absence
>> of some code that allows the user to tell the compiler to relax). It
>> doesn't affect well formed functions because they have already returned by
>> that point. It only actually affects anything that reaches the end without
>> returning. As I said in a different reply, this probably messes up with
>> some optimisations (obbiously code size, but I'm thinking about speed), so
>> I'm dubious, but it certainly isn't halting-problem hard if you take into
>> account that post-return code does nothing.
>>
>
> Isn't this QoI thing? UB mean that abort is possible action. If every
> implementation agree on this (or at least main ones) then we could add this
> to standard to enforce this.
>
How is the compiler inserting code where code need not exist "quality"?
Maybe in debug builds, but in release?
Another thing is cost of handling this. Can we terminate using only
> unconditional jump or some cleanups/fix are always needed before we call
> abort?
>
--
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/b153ce5a-858a-4e81-bd06-69a4b996ab14%40isocpp.org.
------=_Part_28682_1523520213.1513694456047
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, December 19, 2017 at 9:18:22 AM UTC-5, Marcin =
Jaczewski wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">On Tuesday, December 19, 2017 at 2:58:44 PM UTC+1, Jake Arkinstall wrote=
:<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 dir=3D"auto=
"><div class=3D"gmail_quote">On 19 Dec 2017 13:41, "Nicol Bolas" =
<<a rel=3D"nofollow">jmck...@gmail.com</a>> wrote:<br type=3D"attribu=
tion"><blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div><div>But the compiler cannot<i> prove<=
/i> that any particular statement is reachable. Not so long as there is a c=
ondition. The compiler doesn't know what runtime values you will pass i=
n.<br></div></div><div><br></div><div>This is halting-problem levels of har=
d.</div></div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">It needn't be. Simply by adding an abort, throw, or whatever =
to the very end of each function if there are branches without returns (in =
the absence of some code that allows the user to tell the compiler to relax=
). It doesn't affect well formed functions because they have already re=
turned by that point. It only actually affects anything that reaches the en=
d without returning. As I said in a different reply, this probably messes u=
p with some optimisations (obbiously code size, but I'm thinking about =
speed), so I'm dubious, but it certainly isn't halting-problem hard=
if you take into account that post-return code does nothing.</div></div></=
blockquote><div>=C2=A0</div><div>Isn't this QoI thing? UB mean that abo=
rt is possible action. If every implementation agree on this (or at least m=
ain ones) then we could add this to standard to enforce this.</div></div></=
blockquote><div><br></div><div>How is the compiler inserting code where cod=
e need not exist "quality"? Maybe in debug builds, but in release=
?</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>Another thing is cost of handling this. Can we terminate usin=
g only unconditional jump or some cleanups/fix are always needed before we =
call abort?<br></div></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/b153ce5a-858a-4e81-bd06-69a4b996ab14%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b153ce5a-858a-4e81-bd06-69a4b996ab14=
%40isocpp.org</a>.<br />
------=_Part_28682_1523520213.1513694456047--
------=_Part_28681_646303788.1513694456047--
.
Author: Jan Wilmans <janwilmans@gmail.com>
Date: Tue, 19 Dec 2017 15:40:36 +0100
Raw View
--001a113ec5706d95ae0560b27472
Content-Type: text/plain; charset="UTF-8"
>
>
> Putting aside for one moment that this is an artificial restriction (since
> a new standard can simply overrule this arbitrary rule).
> I am not a purist. I don't mind the appearance of new keywords or syntax,
> and I don't care if my c++20 program will be incompatible with a c++17
> program.
>
unfortunately, there are millions of lines of code that we cant break even
if you don't care.
> So simply make it so from c++20 that a function shall return or throw.
> i.e. programmers shall be honest or their programs shall not compile.
>
this casual thinking causes major headaches, first of all exceptions are
not an option in every environment, also no longer compiling / breaking
existing code will make adoption of newer c++ versions that much
harder/slower.
Back to attributes...
> What are they really? They're new keywords that the c++ committee felt too
> timid to enforce on compiler writers.
> The answer is to stop being insipid and simply mandate that they shall, as
> of c++20, be implemented and that they damn well will make a well-formed
> program ill-formed or vice-versa.
> If developers don't want to go forward, they are completely at liberty to
> stay behind.
>
You see how simple that is?
no.
On the other hand, I would like very much to see a way (standardized
compiler options?) to subset the language, so that we can prevent more
legacy code from being written.
And adding rules that introduce breaking changes is a more or less natural
counterpart of that.
Richard: interested to write a proposal?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADtNNhjzUGOH5Ta8b8jju2Nga6FAFRif-MNpjv3YvrS_SN0Vyg%40mail.gmail.com.
--001a113ec5706d95ae0560b27472
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>Putt=
ing aside for one moment that this is an artificial restriction (since a ne=
w standard can simply overrule this arbitrary rule).<br>I am not a purist. =
I don't mind the appearance of new keywords or syntax, and I don't =
care if my c++20 program will be incompatible with a c++17 program.<br></bl=
ockquote><div><br></div><div>unfortunately, there are millions of lines of =
code that we cant break even if you don't care.</div><div>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">So simply make it so from =
c++20 that a function shall return or throw. i.e. programmers shall be hone=
st or their programs shall not compile.<br></blockquote><div><br></div><div=
>this casual thinking causes major headaches, first of all exceptions are n=
ot an option in every environment, also no longer compiling / breaking exis=
ting code will make adoption of newer c++ versions that much harder/slower.=
</div><div><br></div><div>=C2=A0Back to attributes...</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">What are they really? They're new key=
words that the c++ committee felt too timid to enforce on compiler writers.=
<br>The answer is to stop being insipid and simply mandate that they shall,=
as of c++20, be implemented and that they damn well will make a well-forme=
d program ill-formed or vice-versa.<br>If developers don't want to go f=
orward, they are completely at liberty to stay behind.<br></blockquote><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">You see how simple that is?</=
blockquote><div><br></div><div>no.</div><div><br></div><div>On the other ha=
nd, I would like very much to see a way (standardized compiler options?) to=
subset the language, so that we can prevent more legacy code from being wr=
itten.</div><div>And adding rules that introduce breaking changes is a more=
or less natural counterpart of that.</div><div><br></div><div>Richard: int=
erested to write a proposal?</div><div><br></div><div><br></div><div><br></=
div><div>=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CADtNNhjzUGOH5Ta8b8jju2Nga6FAFRif-MNp=
jv3YvrS_SN0Vyg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADtNNhjzUGOH5Ta8=
b8jju2Nga6FAFRif-MNpjv3YvrS_SN0Vyg%40mail.gmail.com</a>.<br />
--001a113ec5706d95ae0560b27472--
.
Author: inkwizytoryankes@gmail.com
Date: Tue, 19 Dec 2017 06:51:38 -0800 (PST)
Raw View
------=_Part_7647_1867402592.1513695098364
Content-Type: multipart/alternative;
boundary="----=_Part_7648_471325946.1513695098365"
------=_Part_7648_471325946.1513695098365
Content-Type: text/plain; charset="UTF-8"
On Tuesday, December 19, 2017 at 3:40:56 PM UTC+1, Nicol Bolas wrote:
>
> On Tuesday, December 19, 2017 at 9:18:22 AM UTC-5, Marcin Jaczewski wrote:
>>
>> On Tuesday, December 19, 2017 at 2:58:44 PM UTC+1, Jake Arkinstall wrote:
>>>
>>> On 19 Dec 2017 13:41, "Nicol Bolas" <jmck...@gmail.com> wrote:
>>>
>>> But the compiler cannot* prove* that any particular statement is
>>> reachable. Not so long as there is a condition. The compiler doesn't know
>>> what runtime values you will pass in.
>>>
>>> This is halting-problem levels of hard.
>>>
>>>
>>> It needn't be. Simply by adding an abort, throw, or whatever to the very
>>> end of each function if there are branches without returns (in the absence
>>> of some code that allows the user to tell the compiler to relax). It
>>> doesn't affect well formed functions because they have already returned by
>>> that point. It only actually affects anything that reaches the end without
>>> returning. As I said in a different reply, this probably messes up with
>>> some optimisations (obbiously code size, but I'm thinking about speed), so
>>> I'm dubious, but it certainly isn't halting-problem hard if you take into
>>> account that post-return code does nothing.
>>>
>>
>> Isn't this QoI thing? UB mean that abort is possible action. If every
>> implementation agree on this (or at least main ones) then we could add this
>> to standard to enforce this.
>>
>
> How is the compiler inserting code where code need not exist "quality"?
> Maybe in debug builds, but in release?
>
>
Less UB? For some people this is very big quality even bigger than speed
(this thread and many others show it). This could be even already
implemented by some sanitizer in GCC or Clang.
My point was if everyone was comply to use it and this would be default for
most of compilers then C++ should standardize this. Not other way around.
--
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/d20ab3ef-a515-47d8-a3ec-44a9407415cc%40isocpp.org.
------=_Part_7648_471325946.1513695098365
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, December 19, 2017 at 3:40:56 PM UTC+1,=
Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">On Tuesday, December 19, 2017 at 9:18:22 AM UTC-5, Marcin Jaczewski 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">On Tuesday, D=
ecember 19, 2017 at 2:58:44 PM UTC+1, Jake Arkinstall wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto"><div class=3D"=
gmail_quote">On 19 Dec 2017 13:41, "Nicol Bolas" <<a rel=3D"no=
follow">jmck...@gmail.com</a>> wrote:<br type=3D"attribution"><blockquot=
e style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><div><div>But the compiler cannot<i> prove</i> that any par=
ticular statement is reachable. Not so long as there is a condition. The co=
mpiler doesn't know what runtime values you will pass in.<br></div></di=
v><div><br></div><div>This is halting-problem levels of hard.</div></div></=
blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">It nee=
dn't be. Simply by adding an abort, throw, or whatever to the very end =
of each function if there are branches without returns (in the absence of s=
ome code that allows the user to tell the compiler to relax). It doesn'=
t affect well formed functions because they have already returned by that p=
oint. It only actually affects anything that reaches the end without return=
ing. As I said in a different reply, this probably messes up with some opti=
misations (obbiously code size, but I'm thinking about speed), so I'=
;m dubious, but it certainly isn't halting-problem hard if you take int=
o account that post-return code does nothing.</div></div></blockquote><div>=
=C2=A0</div><div>Isn't this QoI thing? UB mean that abort is possible a=
ction. If every implementation agree on this (or at least main ones) then w=
e could add this to standard to enforce this.</div></div></blockquote><div>=
<br></div><div>How is the compiler inserting code where code need not exist=
"quality"? Maybe in debug builds, but in release?</div><br></div=
></blockquote><div>=C2=A0</div><div>Less UB? For some people this is very b=
ig quality even bigger than speed (this thread and many others show it). Th=
is could be even already implemented by some sanitizer in GCC or Clang.</di=
v><div>My point was if everyone was comply to use it and this would be defa=
ult for most of compilers then C++ should standardize this. Not other way a=
round.<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/d20ab3ef-a515-47d8-a3ec-44a9407415cc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d20ab3ef-a515-47d8-a3ec-44a9407415cc=
%40isocpp.org</a>.<br />
------=_Part_7648_471325946.1513695098365--
------=_Part_7647_1867402592.1513695098364--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Tue, 19 Dec 2017 15:51:55 +0100
Raw View
--001a113f6476afcf970560b29b2f
Content-Type: text/plain; charset="UTF-8"
> This is what we call a breaking change. So named because it breaks
people's perfectly functioning code.
No, it's a "time to fix your broken code or stay with your old UB-inducing
complier" change.
> Breaking people's code is not good. It's doubly not good to do so without
fair warning. It's triply not good to do so for so little *genuine* gain.
We're not breaking working code, we're breaking not-working code. This is
*very good*. Code that didn't have UB would not break.
> Remember: we're not talking about something major
UB in production code is about as major as it gets. It's the reason that
c++ has such a terrible reputation.
On 19 December 2017 at 15:39, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Tuesday, December 19, 2017 at 9:18:48 AM UTC-5, Richard Hodges wrote:
>
>> On 19 December 2017 at 14:48, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> On Tuesday, December 19, 2017 at 8:44:32 AM UTC-5, Richard Hodges wrote:
>>>>
>>>> On Tuesday, 19 December 2017 14:41:33 UTC+1, Nicol Bolas wrote:
>>>>>
>>>>> On Tuesday, December 19, 2017 at 7:54:51 AM UTC-5, Richard Hodges
>>>>> wrote:
>>>>>>
>>>>>> In c++, this is legal but UB. You may get a warning if you're lucky.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> int foo()
>>>>>> {
>>>>>> // oops! forgot to return anything
>>>>>> }
>>>>>>
>>>>>> In my view, this not good enough. It seems to me that there is no
>>>>>> reasonable case where a developer would want this compile. It should be an
>>>>>> error.
>>>>>>
>>>>>> This of course is fine:
>>>>>>
>>>>>> int foo()
>>>>>> {
>>>>>> throw std::logic_error("not implemented yet!");
>>>>>> }
>>>>>>
>>>>>> And this of course would allow developers who like this sort of thing
>>>>>> to still get away with it, but force them to explain themselves.
>>>>>>
>>>>>> int foo()
>>>>>> {
>>>>>> int result = 0;
>>>>>> while(1)
>>>>>> {
>>>>>> result = will_eventually_be_nonzero();
>>>>>> if (result)
>>>>>> return result;
>>>>>> }
>>>>>>
>>>>>> [[not_reached]];
>>>>>>
>>>>>> // ok, a program reaching here could be allowed to express UB.
>>>>>> // if the compiler can prove that this is reachable, it should fail
>>>>>> to compile, because it knows you're lying.
>>>>>>
>>>>>
>>>>> But the compiler cannot* prove* that any particular statement is
>>>>> reachable. Not so long as there is a condition. The compiler doesn't know
>>>>> what runtime values you will pass in.
>>>>>
>>>>> This is halting-problem levels of hard.
>>>>>
>>>>> In short, if your function says it returns something, it must return
>>>>>> something, otherwise compilation error. Anything other outcome is a
>>>>>> hard-to-track bug in waiting.
>>>>>>
>>>>>
>>>>> So, what do you return in return statements that will* never be
>>>>> reached*? If the return type is not default-constructible, what can
>>>>> you return?
>>>>>
>>>>
>>>> I've already covered this. You don't return anything, but you tell the
>>>> compiler to trust you.
>>>>
>>>
>>> How? With what? You can't use an attribute, as an attribute cannot make
>>> an ill-formed program well-formed.
>>>
>>
>> Putting aside for one moment that this is an artificial restriction
>> (since a new standard can simply overrule this arbitrary rule).
>>
>> I am not a purist. I don't mind the appearance of new keywords or syntax,
>> and I don't care if my c++20 program will be incompatible with a c++17
>> program.
>>
>> So simply make it so from c++20 that a function shall return or throw.
>> i.e. programmers shall be honest or their programs shall not compile.
>>
>
> This is what we call a breaking change. So named because it breaks
> people's perfectly functioning code.
>
> Breaking people's code is not good. It's doubly not good to do so without
> fair warning. It's triply not good to do so for so little *genuine* gain.
>
> Remember: we're not talking about something major. We're not talking about
> a feature that will dramatically improve how C++ is used, change how we
> write functions (the way structured binding does), or dramatically lower
> the bar for some of C++'s esoteric features (the way concepts does). We're
> talking about a purely notational issue. This will not make anyone's code
> one iota faster or easier to write.
>
> Breaking perfectly functioning code for that? Not worth it.
>
>
>> Back to attributes...
>>
>> What are they really? They're new keywords that the c++ committee felt
>> too timid to enforce on compiler writers.
>>
>
> No, they're not. The C++ committee had a real proposal for making adding
> new keywords easier (P0056
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0056r0.html>),
> and they rejected it precisely* because* they want adding keywords to be
> hard
> <https://botondballo.wordpress.com/2015/11/09/trip-report-c-standards-meeting-in-kona-october-2015/>
> .
>
> Attributes were originally used for `override` and `final`, but that was
> redacted and they were made context-sensitive keywords. Why? Specifically
> because the committee* doesn't want* attributes to be used in this way.
>
> The answer is to stop being insipid and simply mandate that they shall, as
>> of c++20, be implemented and that they damn well will make a well-formed
>> program ill-formed or vice-versa.
>>
>> If developers don't want to go forward, they are completely at liberty to
>> stay behind.
>>
>> You see how simple that is?
>>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/54de1e6b-1ff5-4b47-
> ab03-c29ece6abde3%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/54de1e6b-1ff5-4b47-ab03-c29ece6abde3%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CALvx3hYdxO%2B6k75S8yAOOj3jCHktJPh-CVLvrTvdKCbCXABxdQ%40mail.gmail.com.
--001a113f6476afcf970560b29b2f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">> This is what we call a breaking change. So named beca=
use it breaks people's perfectly functioning code.<div><br></div><div>N=
o, it's a "time to fix your broken code or stay with your old UB-i=
nducing complier" change.=C2=A0</div><div><br><div>> Breaking peopl=
e's code is not good. It's doubly not good to do so without fair wa=
rning. It's triply not good to do so for so little=C2=A0<i>genuine</i>=
=C2=A0gain.</div><div><br></div><div>We're not breaking working code, w=
e're breaking not-working code. This is *very good*. Code that didn'=
;t have UB would not break.</div><div><br></div><div>> Remember: we'=
re not talking about something major</div><div><br></div><div>UB in product=
ion code is about as major as it gets. It's the reason that c++ has suc=
h a terrible reputation.</div><div><br></div><div><br><div class=3D"gmail_e=
xtra"><br><div class=3D"gmail_quote">On 19 December 2017 at 15:39, Nicol Bo=
las <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com" target=3D"=
_blank">jmckesson@gmail.com</a>></span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex"><div dir=3D"ltr">On Tuesday, December 19, 2017 =
at 9:18:48 AM UTC-5, Richard Hodges wrote:<div><div class=3D"gmail-h5"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div cl=
ass=3D"gmail_quote">On 19 December 2017 at 14:48, Nicol Bolas <span dir=3D"=
ltr"><<a rel=3D"nofollow">jmck...@gmail.com</a>></span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div>O=
n Tuesday, December 19, 2017 at 8:44:32 AM UTC-5, Richard Hodges wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">On Tuesday, =
19 December 2017 14:41:33 UTC+1, Nicol Bolas wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex"><div dir=3D"ltr">On Tuesday, December 19, 2017 a=
t 7:54:51 AM UTC-5, Richard Hodges wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr">In c++, this is legal but UB. You may get =
a warning if you're lucky.</div></blockquote><div><br></div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><d=
iv><br></div><div><font face=3D"courier new, monospace">int foo()</font></d=
iv><div><font face=3D"courier new, monospace">{</font></div><div><font face=
=3D"courier new, monospace">=C2=A0 // oops! forgot to return anything</font=
></div><div><font face=3D"courier new, monospace">}</font></div><div><br></=
div><div>In my view, this not good enough. It seems to me that there is no =
reasonable case where a developer would want this compile. It should be an =
error.<br></div><div><br></div><div>This of course is fine:</div><div><br><=
/div><div><div><font face=3D"courier new, monospace">int foo()</font></div>=
<div><font face=3D"courier new, monospace">{</font></div><div><font face=3D=
"courier new, monospace">=C2=A0 throw std::logic_error("not implemente=
d yet!");</font></div><div><font face=3D"courier new, monospace">}</fo=
nt></div></div><div><font face=3D"courier new, monospace"><br></font></div>=
<div><div>And this of course would allow developers who like this sort of t=
hing to still get away with it, but force them to explain themselves.</div>=
</div><div><br></div><div><div><font face=3D"courier new, monospace">int fo=
o()</font></div><div><font face=3D"courier new, monospace">{</font></div><d=
iv><font face=3D"courier new, monospace">=C2=A0 int result =3D 0;</font></d=
iv><div><font face=3D"courier new, monospace">=C2=A0 while(1)</font></div><=
div><font face=3D"courier new, monospace">=C2=A0 {</font></div><div><font f=
ace=3D"courier new, monospace">=C2=A0 =C2=A0 result =3D will_eventually_be_=
nonzero();</font></div><div><font face=3D"courier new, monospace">=C2=A0 =
=C2=A0 if (result)</font></div><div><font face=3D"courier new, monospace">=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return result;</font></div><div><span style=3D"=
font-family:"courier new",monospace">=C2=A0 }</span><br></div><di=
v><span style=3D"font-family:"courier new",monospace"><br></span>=
</div><div><div><span style=3D"font-family:"courier new",monospac=
e">=C2=A0 [[not_reached]];=C2=A0 =C2=A0</span></div></div><div><span style=
=3D"font-family:"courier new",monospace"><br></span></div><div><s=
pan style=3D"font-family:"courier new",monospace">=C2=A0=C2=A0</s=
pan><span style=3D"font-family:"courier new",monospace">// ok, a =
program reaching here could be allowed to express UB.</span></div><div><spa=
n style=3D"font-family:"courier new",monospace">=C2=A0 // if the =
compiler can prove that this is reachable, it should fail to compile, becau=
se it knows you're lying.</span></div></div></div></blockquote><div><br=
></div><div>But the compiler cannot<i> prove</i> that any particular statem=
ent is reachable. Not so long as there is a condition. The compiler doesn&#=
39;t know what runtime values you will pass in.</div><div><br></div><div>Th=
is is halting-problem levels of hard.</div><div><font face=3D"courier new, =
monospace"><br></font></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div dir=3D"ltr"><div>In short, if your function says it returns somethi=
ng, it must return something, otherwise compilation error. Anything other o=
utcome is a hard-to-track bug in waiting.</div></div></blockquote><div><br>=
</div><div>So, what do you return in return statements that will<i> never b=
e reached</i>? If the return type is not default-constructible, what can yo=
u return?</div></div></blockquote><div><br></div><div>I've already cove=
red this. You don't return anything, but you tell the compiler to trust=
you.</div></div></blockquote><div><br></div></div></div><div>How? With wha=
t? You can't use an attribute, as an attribute cannot make an ill-forme=
d program well-formed.</div></div></blockquote><div><br></div><div>Putting =
aside for one moment that this is an artificial restriction (since a new st=
andard can simply overrule this arbitrary rule).</div><div><br></div><div>I=
am not a purist. I don't mind the appearance of new keywords or syntax=
, and I don't care if my c++20 program will be incompatible with a c++1=
7 program.</div><div><br></div><div>So simply make it so from c++20 that a =
function shall return or throw. i.e. programmers shall be honest or their p=
rograms shall not compile.</div></div></div></div></blockquote><div><br></d=
iv></div></div><div>This is what we call a breaking change. So named becaus=
e it breaks people's perfectly functioning code.</div><div><br></div><d=
iv>Breaking people's code is not good. It's doubly not good to do s=
o without fair warning. It's triply not good to do so for so little <i>=
genuine</i> gain.</div><div><br></div><div>Remember: we're not talking =
about something major. We're not talking about a feature that will dram=
atically improve how C++ is used, change how we write functions (the way st=
ructured binding does), or dramatically lower the bar for some of C++'s=
esoteric features (the way concepts does). We're talking about a purel=
y notational issue. This will not make anyone's code one iota faster or=
easier to write.</div><div><br></div><div>Breaking perfectly functioning c=
ode for that? Not worth it.</div><span class=3D"gmail-"><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div =
class=3D"gmail_quote"><div>Back to attributes...</div><div><br></div><div>W=
hat are they really? They're new keywords that the c++ committee felt t=
oo timid to enforce on compiler writers.</div></div></div></div></blockquot=
e><div><br></div></span><div>No, they're not. The C++ committee had a r=
eal proposal for making adding new keywords easier (<a href=3D"http://www.o=
pen-std.org/jtc1/sc22/wg21/docs/papers/2015/p0056r0.html" target=3D"_blank"=
>P0056</a>), and they rejected it precisely<i> because</i> they <a href=3D"=
https://botondballo.wordpress.com/2015/11/09/trip-report-c-standards-meetin=
g-in-kona-october-2015/" target=3D"_blank">want adding keywords to be hard<=
/a>.</div><div><br></div><div>Attributes were originally used for `override=
` and `final`, but that was redacted and they were made context-sensitive k=
eywords. Why? Specifically because the committee<i> doesn't want</i> at=
tributes to be used in this way.</div><span class=3D"gmail-"><div><i><br></=
i></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote"><div>The answer is to stop being insipid an=
d simply mandate that they shall, as of c++20, be implemented and that they=
damn well will make a well-formed program ill-formed or vice-versa.</div><=
div><br></div><div>If developers don't want to go forward, they are com=
pletely at liberty to stay behind.</div><div><br></div><div>You see how sim=
ple that is?<br></div></div></div></div>
</blockquote></span></div><span class=3D"gmail-">
<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/54de1e6b-1ff5-4b47-ab03-c29ece6abde3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/54de=
1e6b-1ff5-4b47-<wbr>ab03-c29ece6abde3%40isocpp.org</a><wbr>.<br>
</blockquote></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/CALvx3hYdxO%2B6k75S8yAOOj3jCHktJPh-CV=
LvrTvdKCbCXABxdQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hYdxO%2B6=
k75S8yAOOj3jCHktJPh-CVLvrTvdKCbCXABxdQ%40mail.gmail.com</a>.<br />
--001a113f6476afcf970560b29b2f--
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Tue, 19 Dec 2017 14:57:30 +0000
Raw View
--f403043e9f80a17d020560b2af3c
Content-Type: text/plain; charset="UTF-8"
On 19 Dec 2017 14:40, "Nicol Bolas" <jmckesson@gmail.com> wrote:
How is the compiler inserting code where code need not exist "quality"?
Maybe in debug builds, but in release?
Which sounds like quality to you: a newbie spending hours trying to
understand why false is evaluating as true when optimisation is on, or code
that actually crashes when the programmer messed up instead of leading them
on and pretending that it's all fine?
If you ever reach the end of a non-void function without returning, your
code is broken and you should know about it on the strongest of terms.
Aborting a program is generally less damaging than letting it continue
onwards, doing whatever it shouldn't be doing with files, databases, you
name it. This is a case where undefined behaviour really can cause damage.
Again with Piotr's talks, he demonstrates how you can format a harddrive
unintentionally by failing to return properly. It's very much a contrived
example, but nonetheless it is a fact that something so trivial to solve
can have devastating impacts. Devastating impacts as a result of something
ill-formed being compiled.
I will state this as a question because it's honestly something I would
love to know: what harm does killing this undefined behaviour do? It
doesn't break old code except code which could hardly be described as
"working" beforehand, that much is obvious, but I'm wondering about
optimisation in particular.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPkqVgrqinCDgWxLA5NPL5dU_E3Nmkq5-aOyTeR4an29w%40mail.gmail.com.
--f403043e9f80a17d020560b2af3c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><br><div class=3D"gmail_extra" dir=3D"auto"><br><div clas=
s=3D"gmail_quote">On 19 Dec 2017 14:40, "Nicol Bolas" <<a href=
=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>> wrote:<br type=
=3D"attribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"qu=
oted-text">How is the compiler inserting code where code need not exist &qu=
ot;quality"? Maybe in debug builds, but in release?</div></div></block=
quote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">Which sound=
s like quality to you: a newbie spending hours trying to understand why fal=
se is evaluating as true when optimisation is on, or code that actually cra=
shes when the programmer messed up instead of leading them on and pretendin=
g that it's all fine?</div><div dir=3D"auto"><br></div><div dir=3D"auto=
">If you ever reach the end of a non-void function without returning, your =
code is broken and you should know about it on the strongest of terms. Abor=
ting a program is generally less damaging than letting it continue onwards,=
doing whatever it shouldn't be doing with files, databases, you name i=
t. This is a case where undefined behaviour really can cause damage. Again =
with Piotr's talks, he demonstrates how you can format a harddrive unin=
tentionally by failing to return properly. It's very much a contrived e=
xample, but nonetheless it is a fact that something so trivial to solve can=
have devastating impacts. Devastating impacts as a result of something ill=
-formed being compiled.</div><div dir=3D"auto"><br></div><div dir=3D"auto">=
I will state this as a question because it's honestly something I would=
love to know: what harm does killing this undefined behaviour do? It doesn=
't break old code except code which could hardly be described as "=
working" beforehand, that much is obvious, but I'm wondering about=
optimisation in particular.</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/CAC%2B0CCPkqVgrqinCDgWxLA5NPL5dU_E3Nm=
kq5-aOyTeR4an29w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPkqVgr=
qinCDgWxLA5NPL5dU_E3Nmkq5-aOyTeR4an29w%40mail.gmail.com</a>.<br />
--f403043e9f80a17d020560b2af3c--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 19 Dec 2017 06:57:28 -0800 (PST)
Raw View
------=_Part_28589_353070230.1513695448447
Content-Type: multipart/alternative;
boundary="----=_Part_28590_1181991609.1513695448448"
------=_Part_28590_1181991609.1513695448448
Content-Type: text/plain; charset="UTF-8"
On Tuesday, December 19, 2017 at 9:51:58 AM UTC-5, Richard Hodges wrote:
>
> > This is what we call a breaking change. So named because it breaks
> people's perfectly functioning code.
>
> No, it's a "time to fix your broken code or stay with your old UB-inducing
> complier" change.
>
> > Breaking people's code is not good. It's doubly not good to do so
> without fair warning. It's triply not good to do so for so little
> *genuine* gain.
>
> We're not breaking working code, we're breaking not-working code.
>
Words do not mean what you choose for them to mean. "Working code" is code
that currently works. You may not like how it looks, but it does undeniably*
work*.
This is *very good*. Code that didn't have UB would not break.
>
> > Remember: we're not talking about something major
>
> UB in production code is about as major as it gets.
>
But it's not UB if the UB part is never executed. It's like saying this
code has UB:
void foo(T *t)
{
t->bar();
}
Simply because it is* theoretically* possible to pass NULL to this function
does not make this function "UB in production code".
It's the reason that c++ has such a terrible reputation.
>
--
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/82dec53c-f1cb-4422-8af7-ffd637b2cc25%40isocpp.org.
------=_Part_28590_1181991609.1513695448448
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, December 19, 2017 at 9:51:58 AM UTC-5, Richard=
Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>> This is what we call a breaking change. So named because it breaks pe=
ople's perfectly functioning code.<div><br></div><div>No, it's a &q=
uot;time to fix your broken code or stay with your old UB-inducing complier=
" change.=C2=A0</div><div><br><div>> Breaking people's code is =
not good. It's doubly not good to do so without fair warning. It's =
triply not good to do so for so little=C2=A0<i>genuine</i>=C2=A0gain.</div>=
<div><br></div><div>We're not breaking working code, we're breaking=
not-working code.</div></div></div></blockquote><div><br></div><div>Words =
do not mean what you choose for them to mean. "Working code" is c=
ode that currently works. You may not like how it looks, but it does undeni=
ably<i> work</i>.</div><div><i><br></i></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><div><div> This is *very good*. Code that d=
idn't have UB would not break.</div><div><br></div><div>> Remember: =
we're not talking about something major</div><div><br></div><div>UB in =
production code is about as major as it gets.</div></div></div></blockquote=
><div><br></div><div>But it's not UB if the UB part is never executed. =
It's like saying this code has UB:</div><div><br></div><div class=3D"pr=
ettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-=
word; background-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><d=
iv class=3D"subprettyprint"><span class=3D"styled-by-prettify" style=3D"col=
or: #008;">void</span><span class=3D"styled-by-prettify" style=3D"color: #0=
00;"> foo</span><span class=3D"styled-by-prettify" style=3D"color: #660;">(=
</span><span class=3D"styled-by-prettify" style=3D"color: #000;">T </span><=
span class=3D"styled-by-prettify" style=3D"color: #660;">*</span><span clas=
s=3D"styled-by-prettify" style=3D"color: #000;">t</span><span class=3D"styl=
ed-by-prettify" style=3D"color: #660;">)</span><span class=3D"styled-by-pre=
ttify" style=3D"color: #000;"><br></span><span class=3D"styled-by-prettify"=
style=3D"color: #660;">{</span><span class=3D"styled-by-prettify" style=3D=
"color: #000;"><br>=C2=A0 t</span><span class=3D"styled-by-prettify" style=
=3D"color: #660;">-></span><span class=3D"styled-by-prettify" style=3D"c=
olor: #000;">bar</span><span class=3D"styled-by-prettify" style=3D"color: #=
660;">();</span><span class=3D"styled-by-prettify" style=3D"color: #000;"><=
br></span><span class=3D"styled-by-prettify" style=3D"color: #660;">}</span=
></div></code></div><div><br></div><div>Simply because it is<i> theoretical=
ly</i> possible to pass NULL to this function does not make this function &=
quot;UB in production code".</div><div><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr"><div><div>It's the reason that=
c++ has such a terrible reputation.<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/82dec53c-f1cb-4422-8af7-ffd637b2cc25%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/82dec53c-f1cb-4422-8af7-ffd637b2cc25=
%40isocpp.org</a>.<br />
------=_Part_28590_1181991609.1513695448448--
------=_Part_28589_353070230.1513695448447--
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Tue, 19 Dec 2017 15:00:11 +0000
Raw View
--001a113db2c64bfa700560b2b997
Content-Type: text/plain; charset="UTF-8"
On 19 Dec 2017 14:57, "Nicol Bolas" <jmckesson@gmail.com> wrote:
But it's not UB if the UB part is never executed.
Is anyone saying that it shouldn't pass through a compiler? Adding safety
code at the very end of functions that assume some branch returns does not
affect those functions where the assumption holds.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCN6bt1piSXsHn9AGEWP2o7dURc%2BTRdkMZtC8NE8ge%3DuOw%40mail.gmail.com.
--001a113db2c64bfa700560b2b997
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><br><div class=3D"gmail_extra" dir=3D"auto"><br><div clas=
s=3D"gmail_quote">On 19 Dec 2017 14:57, "Nicol Bolas" <<a href=
=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>> wrote:<br type=
=3D"attribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"qu=
oted-text">But it's not UB if the UB part is never executed.</div></div=
></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">Is =
anyone saying that it shouldn't pass through a compiler? Adding safety =
code at the very end of functions that assume some branch returns does not =
affect those functions where the assumption holds.</div><div class=3D"gmail=
_extra" dir=3D"auto"></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCN6bt1piSXsHn9AGEWP2o7dURc%2B=
TRdkMZtC8NE8ge%3DuOw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCN6=
bt1piSXsHn9AGEWP2o7dURc%2BTRdkMZtC8NE8ge%3DuOw%40mail.gmail.com</a>.<br />
--001a113db2c64bfa700560b2b997--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Tue, 19 Dec 2017 16:02:31 +0100
Raw View
--001a1140a4fa9a3b5d0560b2c186
Content-Type: text/plain; charset="UTF-8"
>
>
> > unfortunately, there are millions of lines of code that we cant break
even if you don't care.
That's fine. If you want old-school behaviour and buggy code, simply
compile with with -std=c++17. Problem solved.
> this casual thinking causes major headaches, first of all exceptions are
not an option in every environment,
Right, so return something or tell the compiler that you intended not to.
Hardly a headache. Why are you people so negative?
> also no longer compiling / breaking existing code will make adoption of
newer c++ versions that much harder/slower
The only code this will break is code that should not be in any program.
That's good! it means you find everyone's bugs for them instantly. They can
then fix the bugs. UB in a program is a BUG of the most major an insidious
kind.
> On the other hand, I would like very much to see a way (standardized
compiler options?) to subset the language, so that we can prevent more
legacy code from being written.
You have one. It's called -std=c++20
You simply do the right thing and make c++20 better and safer than c++(<20)
> Richard: interested to write a proposal?
Yes, once I am convinced that it's not going to be pushed back with:
"We can't make the language safer, it might annoy some die-hard UB-lovers",
"We can't break broken code",
"We can't make attributes do anything"
Once I see one response from a committee member saying something like,
"obviously this would be a good thing - there might be a more acceptable
way to get it done but I think we *can* and *should* find a way"
Otherwise what's the point?
I already have Nicol arguing that we shouldn't help people uncover their
inadvertent UB because of hand-wavy "reasons".
On 19 December 2017 at 15:40, Jan Wilmans <janwilmans@gmail.com> wrote:
>
>> Putting aside for one moment that this is an artificial restriction
>> (since a new standard can simply overrule this arbitrary rule).
>> I am not a purist. I don't mind the appearance of new keywords or syntax,
>> and I don't care if my c++20 program will be incompatible with a c++17
>> program.
>>
>
> unfortunately, there are millions of lines of code that we cant break even
> if you don't care.
>
>
>
>> So simply make it so from c++20 that a function shall return or throw.
>> i.e. programmers shall be honest or their programs shall not compile.
>>
>
> this casual thinking causes major headaches, first of all exceptions are
> not an option in every environment, also no longer compiling / breaking
> existing code will make adoption of newer c++ versions that much
> harder/slower.
>
> Back to attributes...
>
>> What are they really? They're new keywords that the c++ committee felt
>> too timid to enforce on compiler writers.
>> The answer is to stop being insipid and simply mandate that they shall,
>> as of c++20, be implemented and that they damn well will make a well-formed
>> program ill-formed or vice-versa.
>> If developers don't want to go forward, they are completely at liberty to
>> stay behind.
>>
> You see how simple that is?
>
>
> no.
>
> On the other hand, I would like very much to see a way (standardized
> compiler options?) to subset the language, so that we can prevent more
> legacy code from being written.
> And adding rules that introduce breaking changes is a more or less natural
> counterpart of that.
>
> Richard: interested to write a proposal?
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CADtNNhjzUGOH5Ta8b8jju2Nga6FAF
> Rif-MNpjv3YvrS_SN0Vyg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADtNNhjzUGOH5Ta8b8jju2Nga6FAFRif-MNpjv3YvrS_SN0Vyg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CALvx3ha2oMU6_yedxY9tkDEqSdGGdwp-rwOfKwU5krd_PL5ing%40mail.gmail.com.
--001a1140a4fa9a3b5d0560b2c186
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><br></div></blockquote><div>> unfortunately, there are millions=
of lines of code that we cant break even if you don't care.<br></div><=
div><br></div><div>That's fine. If you want old-school behaviour and bu=
ggy code, simply compile with with -std=3Dc++17. Problem solved.</div><div>=
=C2=A0</div><div>> this casual thinking causes major headaches, first of=
all exceptions are not an option in every environment,=C2=A0</div><div><br=
></div><div>Right, so return something or tell the compiler that you intend=
ed not to. Hardly a headache. Why are you people so negative?</div><div><br=
></div><div>> also no longer compiling / breaking existing code will mak=
e adoption of newer c++ versions that much harder/slower</div><div><br></di=
v><div>The only code this will break is code that should not be in any prog=
ram. That's good! it means you find everyone's bugs for them instan=
tly. They can then fix the bugs. UB in a program is a BUG of the most major=
an insidious kind.</div><div><br></div><div>> On the other hand, I woul=
d like very much to see a way (standardized compiler options?) to subset th=
e language, so that we can prevent more legacy code from being written.</di=
v><div><br></div><div>You have one. It's called -std=3Dc++20</div><div>=
<br></div><div>You simply do the right thing and make c++20 better and safe=
r than c++(<20)</div><div><br></div><div>> Richard: interested to wri=
te a proposal?</div><div><br></div><div>Yes, once I am convinced that it=
9;s not going to be pushed back with:</div><div><br></div><div>"We can=
't make the language safer, it might annoy some die-hard UB-lovers"=
;,</div><div>"We can't break broken code",</div><div>"We=
can't make attributes do anything"</div><div><br></div><div>Once =
I see one response from a committee member saying something like,=C2=A0</di=
v><div><br></div><div>"obviously this would be a good thing - there mi=
ght be a more acceptable way to get it done but I think we *can* and *shoul=
d* find a way"</div><div><br></div><div>Otherwise what's the point=
?</div><div><br></div><div>I already have Nicol arguing that we shouldn'=
;t help people uncover their inadvertent UB because of hand-wavy "reas=
ons".</div><div><br></div><div><br></div><div><br></div><div><br></div=
><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 19 December 2=
017 at 15:40, Jan Wilmans <span dir=3D"ltr"><<a href=3D"mailto:janwilman=
s@gmail.com" target=3D"_blank">janwilmans@gmail.com</a>></span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span =
class=3D"gmail-"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>Putt=
ing aside for one moment that this is an artificial restriction (since a ne=
w standard can simply overrule this arbitrary rule).<br>I am not a purist. =
I don't mind the appearance of new keywords or syntax, and I don't =
care if my c++20 program will be incompatible with a c++17 program.<br></bl=
ockquote><div><br></div></span><div>unfortunately, there are millions of li=
nes of code that we cant break even if you don't care.</div></div></blo=
ckquote><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><span class=3D"gmail-"><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex">So simply make it so from c+=
+20 that a function shall return or throw. i.e. programmers shall be honest=
or their programs shall not compile.<br></blockquote><div><br></div></span=
><div>this casual thinking causes major headaches, first of all exceptions =
are not an option in every environment, also no longer compiling / breaking=
existing code will make adoption of newer c++ versions that much harder/sl=
ower.</div><span class=3D"gmail-"><div><br></div><div>=C2=A0Back to attribu=
tes...</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What are they=
really? They're new keywords that the c++ committee felt too timid to =
enforce on compiler writers.<br>The answer is to stop being insipid and sim=
ply mandate that they shall, as of c++20, be implemented and that they damn=
well will make a well-formed program ill-formed or vice-versa.<br>If devel=
opers don't want to go forward, they are completely at liberty to stay =
behind.<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Y=
ou see how simple that is?</blockquote><div><br></div></span><div>no.</div>=
<div><br></div><div>On the other hand, I would like very much to see a way =
(standardized compiler options?) to subset the language, so that we can pre=
vent more legacy code from being written.</div><div>And adding rules that i=
ntroduce breaking changes is a more or less natural counterpart of that.</d=
iv><div><br></div><div>Richard: interested to write a proposal?</div><div><=
br></div><div><br></div><div><br></div><div>=C2=A0</div></div><span class=
=3D"gmail-">
<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/CADtNNhjzUGOH5Ta8b8jju2Nga6FAFRif-MNp=
jv3YvrS_SN0Vyg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-=
<wbr>proposals/<wbr>CADtNNhjzUGOH5Ta8b8jju2Nga6FAF<wbr>Rif-MNpjv3YvrS_SN0Vy=
g%40mail.<wbr>gmail.com</a>.<br>
</blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CALvx3ha2oMU6_yedxY9tkDEqSdGGdwp-rwOf=
KwU5krd_PL5ing%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3ha2oMU6_yed=
xY9tkDEqSdGGdwp-rwOfKwU5krd_PL5ing%40mail.gmail.com</a>.<br />
--001a1140a4fa9a3b5d0560b2c186--
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Tue, 19 Dec 2017 15:11:47 +0000
Raw View
--001a11495e18b9b64c0560b2e272
Content-Type: text/plain; charset="UTF-8"
On 19 Dec 2017 15:02, "Richard Hodges" <hodges.r@gmail.com> wrote:
> > unfortunately, there are millions of lines of code that we cant break
even if you don't care.
That's fine. If you want old-school behaviour and buggy code, simply
compile with with -std=c++17. Problem solved.
My issue with this, Richard, is that I also use python. I usually get the
question "is it python 2 or python 3?" when python 3 was released 9 years
ago. This is why I'm not a fan of forcing people to stick with an old
version if they must use something - because that isn't a threat to them,
it's an instruction, and they'll gladly use it for a very long time.
I don't like breaking changes unless they only break broken code (try
saying that after too much coffee). Code that COULD break but is only used
in places where it DOESN'T break is lazy code, but not broken code. It
becomes broken code as soon as someone uses it in ways it was not intended
(I mean, the same applies to every function that takes an unsigned int and
returns a bigger unsigned int - they aren't broken just because unsigned
overflow is UB, and unsigned overflow is UB because different processors
are faster at handling it in different ways).
This is why I can't see this being solvable at compilation time, but I do
believe that it should be decorated at compilation time.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPfXPPGEfaVpmRjKA4KoCg%3D-iM%2BMm0uLawS%3D8vDAkHrCQ%40mail.gmail.com.
--001a11495e18b9b64c0560b2e272
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><br><div class=3D"gmail_extra" dir=3D"auto"><br><div clas=
s=3D"gmail_quote">On 19 Dec 2017 15:02, "Richard Hodges" <<a h=
ref=3D"mailto:hodges.r@gmail.com">hodges.r@gmail.com</a>> wrote:<br type=
=3D"attribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"qu=
oted-text"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"lt=
r"><br></div></blockquote><div>> unfortunately, there are millions of li=
nes of code that we cant break even if you don't care.<br></div><div><b=
r></div></div><div>That's fine. If you want old-school behaviour and bu=
ggy code, simply compile with with -std=3Dc++17. Problem solved.</div></div=
></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">My =
issue with this, Richard, is that I also use python. I usually get the ques=
tion "is it python 2 or python 3?" when python 3 was released 9 y=
ears ago. This is why I'm not a fan of forcing people to stick with an =
old version if they must use something - because that isn't a threat to=
them, it's an instruction, and they'll gladly use it for a very lo=
ng time.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I don't lik=
e breaking changes unless they only break broken code (try saying that afte=
r too much coffee). Code that COULD break but is only used in places where =
it DOESN'T break is lazy code, but not broken code. It becomes broken c=
ode as soon as someone uses it in ways it was not intended (I mean, the sam=
e applies to every function that takes an unsigned int and returns a bigger=
unsigned int - they aren't broken just because unsigned overflow is UB=
, and unsigned overflow is UB because different processors are faster at ha=
ndling it in different ways).</div><div dir=3D"auto"><br></div><div dir=3D"=
auto">This is why I can't see this being solvable at compilation time, =
but I do believe that it should be decorated at compilation time.</div><div=
class=3D"gmail_extra" dir=3D"auto"></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPfXPPGEfaVpmRjKA4KoCg%3D-iM%=
2BMm0uLawS%3D8vDAkHrCQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CC=
PfXPPGEfaVpmRjKA4KoCg%3D-iM%2BMm0uLawS%3D8vDAkHrCQ%40mail.gmail.com</a>.<br=
/>
--001a11495e18b9b64c0560b2e272--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Tue, 19 Dec 2017 16:14:04 +0100
Raw View
--f403045c4866eae0f80560b2ea12
Content-Type: text/plain; charset="UTF-8"
Nicol Bols wrote:
void foo(T *t)
{
t->bar();
}
This is a very good reason for always passing by reference rather than
pointer.
When I first learned C++ back in 1992 I used to write code like this.
As you well know, a pointer is an optional reference to an object. If you
are dealing with an optional, you are obliged to check that it represents
something.
If you don't you have no place coding in 2017.
Prefer to pass by reference. If you must use a pointer, check it. Here
endeth the lesson.
Holding back the evolution of c++ because of the behaviour of a few
miscreants is a crime against everyone else.
On 19 December 2017 at 16:00, Jake Arkinstall <jake.arkinstall@gmail.com>
wrote:
>
>
> On 19 Dec 2017 14:57, "Nicol Bolas" <jmckesson@gmail.com> wrote:
>
> But it's not UB if the UB part is never executed.
>
>
> Is anyone saying that it shouldn't pass through a compiler? Adding safety
> code at the very end of functions that assume some branch returns does not
> affect those functions where the assumption holds.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAC%2B0CCN6bt1piSXsHn9AGEWP2o7dURc
> %2BTRdkMZtC8NE8ge%3DuOw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCN6bt1piSXsHn9AGEWP2o7dURc%2BTRdkMZtC8NE8ge%3DuOw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CALvx3haJULyCrV1OOhU%3DCMYKbrA4TkG4555MmqkAG%2BzaOxRhNQ%40mail.gmail.com.
--f403045c4866eae0f80560b2ea12
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Nicol Bols wrote:<div><br></div><div><span class=3D"gmail-=
m_3237809663472964857styled-by-prettify" style=3D"font-family:monospace;fon=
t-size:10.4px;background-color:rgb(250,250,250);color:rgb(0,0,136)">void</s=
pan><span class=3D"gmail-m_3237809663472964857styled-by-prettify" style=3D"=
font-family:monospace;font-size:10.4px;background-color:rgb(250,250,250);co=
lor:rgb(0,0,0)">=C2=A0foo</span><span class=3D"gmail-m_3237809663472964857s=
tyled-by-prettify" style=3D"font-family:monospace;font-size:10.4px;backgrou=
nd-color:rgb(250,250,250);color:rgb(102,102,0)">(</span><span class=3D"gmai=
l-m_3237809663472964857styled-by-prettify" style=3D"font-family:monospace;f=
ont-size:10.4px;background-color:rgb(250,250,250);color:rgb(0,0,0)">T=C2=A0=
</span><span class=3D"gmail-m_3237809663472964857styled-by-prettify" style=
=3D"font-family:monospace;font-size:10.4px;background-color:rgb(250,250,250=
);color:rgb(102,102,0)">*</span><span class=3D"gmail-m_3237809663472964857s=
tyled-by-prettify" style=3D"font-family:monospace;font-size:10.4px;backgrou=
nd-color:rgb(250,250,250);color:rgb(0,0,0)">t</span><span class=3D"gmail-m_=
3237809663472964857styled-by-prettify" style=3D"font-family:monospace;font-=
size:10.4px;background-color:rgb(250,250,250);color:rgb(102,102,0)">)</span=
><span class=3D"gmail-m_3237809663472964857styled-by-prettify" style=3D"fon=
t-family:monospace;font-size:10.4px;background-color:rgb(250,250,250);color=
:rgb(0,0,0)"><br></span><span class=3D"gmail-m_3237809663472964857styled-by=
-prettify" style=3D"font-family:monospace;font-size:10.4px;background-color=
:rgb(250,250,250);color:rgb(102,102,0)">{</span><span class=3D"gmail-m_3237=
809663472964857styled-by-prettify" style=3D"font-family:monospace;font-size=
:10.4px;background-color:rgb(250,250,250);color:rgb(0,0,0)"><br>=C2=A0 t</s=
pan><span class=3D"gmail-m_3237809663472964857styled-by-prettify" style=3D"=
font-family:monospace;font-size:10.4px;background-color:rgb(250,250,250);co=
lor:rgb(102,102,0)">-></span><span class=3D"gmail-m_3237809663472964857s=
tyled-by-prettify" style=3D"font-family:monospace;font-size:10.4px;backgrou=
nd-color:rgb(250,250,250);color:rgb(0,0,0)">bar</span><span class=3D"gmail-=
m_3237809663472964857styled-by-prettify" style=3D"font-family:monospace;fon=
t-size:10.4px;background-color:rgb(250,250,250);color:rgb(102,102,0)">();</=
span><span class=3D"gmail-m_3237809663472964857styled-by-prettify" style=3D=
"font-family:monospace;font-size:10.4px;background-color:rgb(250,250,250);c=
olor:rgb(0,0,0)"><br></span><span class=3D"gmail-m_3237809663472964857style=
d-by-prettify" style=3D"font-family:monospace;font-size:10.4px;background-c=
olor:rgb(250,250,250);color:rgb(102,102,0)">}</span><br></div><div><span cl=
ass=3D"gmail-m_3237809663472964857styled-by-prettify" style=3D"font-family:=
monospace;font-size:10.4px;background-color:rgb(250,250,250);color:rgb(102,=
102,0)"><br></span></div><div><span class=3D"gmail-m_3237809663472964857sty=
led-by-prettify" style=3D"font-family:monospace;font-size:10.4px;background=
-color:rgb(250,250,250);color:rgb(102,102,0)"><span style=3D"color:rgb(34,3=
4,34);font-family:arial,sans-serif;font-size:small;background-color:rgb(255=
,255,255)">This is a very good reason for always passing by reference rathe=
r than pointer.</span></span></div><div><span class=3D"gmail-m_323780966347=
2964857styled-by-prettify" style=3D"font-family:monospace;font-size:10.4px;=
background-color:rgb(250,250,250);color:rgb(102,102,0)"><span style=3D"colo=
r:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;background-col=
or:rgb(255,255,255)"><br></span></span></div><div><span class=3D"gmail-m_32=
37809663472964857styled-by-prettify" style=3D"font-family:monospace;font-si=
ze:10.4px;background-color:rgb(250,250,250);color:rgb(102,102,0)"><div styl=
e=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small">When=
I first learned C++ back in 1992 I used to write code like this.</div><div=
style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small"=
><br></div><div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;f=
ont-size:small">As you well know, a pointer is an optional reference to an =
object. If you are dealing with an optional, you are obliged to check that =
it represents something.</div><div style=3D"color:rgb(34,34,34);font-family=
:arial,sans-serif;font-size:small"><br></div><div style=3D"color:rgb(34,34,=
34);font-family:arial,sans-serif;font-size:small">If you don't you have=
no place coding in 2017.</div><div><br></div></span></div><div>Prefer to p=
ass by reference. If you must use a pointer, check it. Here endeth the less=
on.</div><div><br></div><div>Holding back the evolution of c++ because of t=
he behaviour of a few miscreants is a crime against everyone else.</div><di=
v>=C2=A0</div><div><br></div></div><div class=3D"gmail_extra"><br><div clas=
s=3D"gmail_quote">On 19 December 2017 at 16:00, Jake Arkinstall <span dir=
=3D"ltr"><<a href=3D"mailto:jake.arkinstall@gmail.com" target=3D"_blank"=
>jake.arkinstall@gmail.com</a>></span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"auto"><span class=3D""><br><div class=3D"gmail_extra" d=
ir=3D"auto"><br><div class=3D"gmail_quote">On 19 Dec 2017 14:57, "Nico=
l Bolas" <<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">=
jmckesson@gmail.com</a>> wrote:<br type=3D"attribution"><blockquote clas=
s=3D"m_5747792836024115383quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"m_574779283602=
4115383quoted-text">But it's not UB if the UB part is never executed.</=
div></div></blockquote></div></div><div dir=3D"auto"><br></div></span><div =
dir=3D"auto">Is anyone saying that it shouldn't pass through a compiler=
? Adding safety code at the very end of functions that assume some branch r=
eturns does not affect those functions where the assumption holds.</div><di=
v class=3D"gmail_extra" dir=3D"auto"></div></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/CAC%2B0CCN6bt1piSXsHn9AGEWP2o7dURc%2B=
TRdkMZtC8NE8ge%3DuOw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgi=
d/std-<wbr>proposals/CAC%<wbr>2B0CCN6bt1piSXsHn9AGEWP2o7dURc<wbr>%2BTRdkMZt=
C8NE8ge%3DuOw%<wbr>40mail.gmail.com</a>.<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/CALvx3haJULyCrV1OOhU%3DCMYKbrA4TkG455=
5MmqkAG%2BzaOxRhNQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3haJULyC=
rV1OOhU%3DCMYKbrA4TkG4555MmqkAG%2BzaOxRhNQ%40mail.gmail.com</a>.<br />
--f403045c4866eae0f80560b2ea12--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Tue, 19 Dec 2017 10:22:01 -0500
Raw View
--001a11467c609078760560b3082e
Content-Type: text/plain; charset="UTF-8"
On Tue, Dec 19, 2017 at 10:14 AM, Richard Hodges <hodges.r@gmail.com> wrote:
> Nicol Bols wrote:
>
> void foo(T *t)
> {
> t->bar();
> }
>
> This is a very good reason for always passing by reference rather than
> pointer.
>
> When I first learned C++ back in 1992 I used to write code like this.
>
> As you well know, a pointer is an optional reference to an object. If you
> are dealing with an optional, you are obliged to check that it represents
> something.
>
> If you don't you have no place coding in 2017.
>
> Prefer to pass by reference. If you must use a pointer, check it. Here
> endeth the lesson.
>
My boss would disagree with you. He very much favors narrow contracts; if
you say
in the function contract that the behavior is undefined if t is null, then
you do not add
checks in the function for that, as it pessimizes in-contract code. (You
should add
assertions that would catch this problem when compiled with a checking
mode.)
Pointer vs. reference is something of a red herring, because it's a
particular circumstance
where the check appears simple (but what is the result of failing it?) Now
imagine that
the requirements are that the pointer is valid, or that a range given by a
pair of iterators is
sorted.
--
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/CAHSYqda%3DMH9htzM5LJ1%2BzFg8DcmqnpPtn0Z9RwUYt%3DRtBPAJVA%40mail.gmail.com.
--001a11467c609078760560b3082e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Dec 19, 2017 at 10:14 AM, Richard Hodges <span dir=3D"ltr"><<a href=
=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a>>=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span cla=
ss=3D"">Nicol Bols wrote:<div><br></div><div><span class=3D"m_-172664916757=
0532430gmail-m_3237809663472964857styled-by-prettify" style=3D"font-family:=
monospace;font-size:10.4px;background-color:rgb(250,250,250);color:rgb(0,0,=
136)">void</span><span class=3D"m_-1726649167570532430gmail-m_3237809663472=
964857styled-by-prettify" style=3D"font-family:monospace;font-size:10.4px;b=
ackground-color:rgb(250,250,250);color:rgb(0,0,0)">=C2=A0foo</span><span cl=
ass=3D"m_-1726649167570532430gmail-m_3237809663472964857styled-by-prettify"=
style=3D"font-family:monospace;font-size:10.4px;background-color:rgb(250,2=
50,250);color:rgb(102,102,0)">(</span><span class=3D"m_-1726649167570532430=
gmail-m_3237809663472964857styled-by-prettify" style=3D"font-family:monospa=
ce;font-size:10.4px;background-color:rgb(250,250,250);color:rgb(0,0,0)">T=
=C2=A0</span><span class=3D"m_-1726649167570532430gmail-m_32378096634729648=
57styled-by-prettify" style=3D"font-family:monospace;font-size:10.4px;backg=
round-color:rgb(250,250,250);color:rgb(102,102,0)">*</span><span class=3D"m=
_-1726649167570532430gmail-m_3237809663472964857styled-by-prettify" style=
=3D"font-family:monospace;font-size:10.4px;background-color:rgb(250,250,250=
);color:rgb(0,0,0)">t</span><span class=3D"m_-1726649167570532430gmail-m_32=
37809663472964857styled-by-prettify" style=3D"font-family:monospace;font-si=
ze:10.4px;background-color:rgb(250,250,250);color:rgb(102,102,0)">)</span><=
span class=3D"m_-1726649167570532430gmail-m_3237809663472964857styled-by-pr=
ettify" style=3D"font-family:monospace;font-size:10.4px;background-color:rg=
b(250,250,250);color:rgb(0,0,0)"><br></span><span class=3D"m_-1726649167570=
532430gmail-m_3237809663472964857styled-by-prettify" style=3D"font-family:m=
onospace;font-size:10.4px;background-color:rgb(250,250,250);color:rgb(102,1=
02,0)">{</span><span class=3D"m_-1726649167570532430gmail-m_323780966347296=
4857styled-by-prettify" style=3D"font-family:monospace;font-size:10.4px;bac=
kground-color:rgb(250,250,250);color:rgb(0,0,0)"><br>=C2=A0 t</span><span c=
lass=3D"m_-1726649167570532430gmail-m_3237809663472964857styled-by-prettify=
" style=3D"font-family:monospace;font-size:10.4px;background-color:rgb(250,=
250,250);color:rgb(102,102,0)">-></span><span class=3D"m_-17266491675705=
32430gmail-m_3237809663472964857styled-by-prettify" style=3D"font-family:mo=
nospace;font-size:10.4px;background-color:rgb(250,250,250);color:rgb(0,0,0)=
">bar</span><span class=3D"m_-1726649167570532430gmail-m_323780966347296485=
7styled-by-prettify" style=3D"font-family:monospace;font-size:10.4px;backgr=
ound-color:rgb(250,250,250);color:rgb(102,102,0)">();</span><span class=3D"=
m_-1726649167570532430gmail-m_3237809663472964857styled-by-prettify" style=
=3D"font-family:monospace;font-size:10.4px;background-color:rgb(250,250,250=
);color:rgb(0,0,0)"><br></span><span class=3D"m_-1726649167570532430gmail-m=
_3237809663472964857styled-by-prettify" style=3D"font-family:monospace;font=
-size:10.4px;background-color:rgb(250,250,250);color:rgb(102,102,0)">}</spa=
n><br></div><div><span class=3D"m_-1726649167570532430gmail-m_3237809663472=
964857styled-by-prettify" style=3D"font-family:monospace;font-size:10.4px;b=
ackground-color:rgb(250,250,250);color:rgb(102,102,0)"><br></span></div></s=
pan><div><span class=3D"m_-1726649167570532430gmail-m_3237809663472964857st=
yled-by-prettify" style=3D"font-family:monospace;font-size:10.4px;backgroun=
d-color:rgb(250,250,250);color:rgb(102,102,0)"><span style=3D"color:rgb(34,=
34,34);font-family:arial,sans-serif;font-size:small;background-color:rgb(25=
5,255,255)">This is a very good reason for always passing by reference rath=
er than pointer.</span></span></div><div><span class=3D"m_-1726649167570532=
430gmail-m_3237809663472964857styled-by-prettify" style=3D"font-family:mono=
space;font-size:10.4px;background-color:rgb(250,250,250);color:rgb(102,102,=
0)"><span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-si=
ze:small;background-color:rgb(255,255,255)"><br></span></span></div><div><s=
pan class=3D"m_-1726649167570532430gmail-m_3237809663472964857styled-by-pre=
ttify" style=3D"font-family:monospace;font-size:10.4px;background-color:rgb=
(250,250,250);color:rgb(102,102,0)"><div style=3D"color:rgb(34,34,34);font-=
family:arial,sans-serif;font-size:small">When I first learned C++ back in 1=
992 I used to write code like this.</div><div style=3D"color:rgb(34,34,34);=
font-family:arial,sans-serif;font-size:small"><br></div><div style=3D"color=
:rgb(34,34,34);font-family:arial,sans-serif;font-size:small">As you well kn=
ow, a pointer is an optional reference to an object. If you are dealing wit=
h an optional, you are obliged to check that it represents something.</div>=
<div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:sm=
all"><br></div><div style=3D"color:rgb(34,34,34);font-family:arial,sans-ser=
if;font-size:small">If you don't you have no place coding in 2017.</div=
><div><br></div></span></div><div>Prefer to pass by reference. If you must =
use a pointer, check it. Here endeth the lesson.</div></div></blockquote><d=
iv><br>My boss would disagree with you.=C2=A0 He very much favors narrow co=
ntracts; if you say<br>in the function contract that the behavior is undefi=
ned if <font face=3D"monospace, monospace">t</font> is null, then you do no=
t add<br>checks in the function for that, as it pessimizes in-contract code=
..=C2=A0 (You should add<br>assertions that would catch this problem when co=
mpiled with a checking mode.)<br><br>Pointer vs. reference is something of =
a red herring, because it's a particular circumstance<br>where the chec=
k appears simple (but what is the result of failing it?)=C2=A0 Now imagine =
that<br>the requirements are that the pointer is valid, or that a range giv=
en by a pair of iterators is<br>sorted.</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/CAHSYqda%3DMH9htzM5LJ1%2BzFg8DcmqnpPt=
n0Z9RwUYt%3DRtBPAJVA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqda%3D=
MH9htzM5LJ1%2BzFg8DcmqnpPtn0Z9RwUYt%3DRtBPAJVA%40mail.gmail.com</a>.<br />
--001a11467c609078760560b3082e--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Tue, 19 Dec 2017 16:27:39 +0100
Raw View
--001a1143e71e77622d0560b31b96
Content-Type: text/plain; charset="UTF-8"
Hymen Rosen Wrote:
> My boss would disagree with you. He very much favors narrow contracts;
if you say
in the function contract that the behavior is undefined if t is null, then
you do not add
checks in the function for that, as it pessimizes in-contract code. (You
should add
assertions that would catch this problem when compiled with a checking
mode.)
I think he and I are on the same page here. As far as I am concerned, an
assert is a check.
If it would be undefined behaviour to pass a null pointer here, then don't
pass a pointer. It's the wrong tool. Pass a reference.
If you want a pair of bidirectional or random-access iterators whose end()
is after the begin(), pass a structure that encapsulates that contract and
assert in its constructor.
There is no reason at all to allow UB anywhere in a program.
'performance' is not an argument. UB is simply the result of using the
wrong tools.
It should be punished if at all possible, at compile time.
On 19 December 2017 at 16:22, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> On Tue, Dec 19, 2017 at 10:14 AM, Richard Hodges <hodges.r@gmail.com>
> wrote:
>
>> Nicol Bols wrote:
>>
>> void foo(T *t)
>> {
>> t->bar();
>> }
>>
>> This is a very good reason for always passing by reference rather than
>> pointer.
>>
>> When I first learned C++ back in 1992 I used to write code like this.
>>
>> As you well know, a pointer is an optional reference to an object. If you
>> are dealing with an optional, you are obliged to check that it represents
>> something.
>>
>> If you don't you have no place coding in 2017.
>>
>> Prefer to pass by reference. If you must use a pointer, check it. Here
>> endeth the lesson.
>>
>
> My boss would disagree with you. He very much favors narrow contracts; if
> you say
> in the function contract that the behavior is undefined if t is null,
> then you do not add
> checks in the function for that, as it pessimizes in-contract code. (You
> should add
> assertions that would catch this problem when compiled with a checking
> mode.)
>
> Pointer vs. reference is something of a red herring, because it's a
> particular circumstance
> where the check appears simple (but what is the result of failing it?)
> Now imagine that
> the requirements are that the pointer is valid, or that a range given by a
> pair of iterators is
> sorted.
>
> --
> 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/CAHSYqda%3DMH9htzM5LJ1%
> 2BzFg8DcmqnpPtn0Z9RwUYt%3DRtBPAJVA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqda%3DMH9htzM5LJ1%2BzFg8DcmqnpPtn0Z9RwUYt%3DRtBPAJVA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CALvx3hY4mOgopyoH3PGWeD%3DCeR_OkJ0TqgV2qkaCw3XB%3D3%3DiyQ%40mail.gmail.com.
--001a1143e71e77622d0560b31b96
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hymen Rosen Wrote:</div><div><br></div>>=C2=A0<spa=
n style=3D"font-size:12.8px">My boss would disagree with you.=C2=A0 He very=
much favors narrow contracts; if you say</span><br style=3D"font-size:12.8=
px"><span style=3D"font-size:12.8px">in the function contract that the beha=
vior is undefined if=C2=A0</span><font face=3D"monospace, monospace" style=
=3D"font-size:12.8px">t</font><span style=3D"font-size:12.8px">=C2=A0is nul=
l, then you do not add</span><br style=3D"font-size:12.8px"><span style=3D"=
font-size:12.8px">checks in the function for that, as it pessimizes in-cont=
ract code.=C2=A0 (You should add</span><br style=3D"font-size:12.8px"><span=
style=3D"font-size:12.8px">assertions that would catch this problem when c=
ompiled with a checking mode.)</span><div><span style=3D"font-size:12.8px">=
<br></span></div><div><span style=3D"font-size:12.8px">I think he and I are=
on the same page here. As far as I am concerned, an assert is a check.</sp=
an></div><div><span style=3D"font-size:12.8px"><br></span></div><div><span =
style=3D"font-size:12.8px">If it would be undefined behaviour to pass a nul=
l pointer here, then don't pass a pointer. It's the wrong tool. Pas=
s a reference.</span></div><div><span style=3D"font-size:12.8px"><br></span=
></div><div><span style=3D"font-size:12.8px">If you want a pair of bidirect=
ional or random-access iterators whose end() is after the begin(), pass a s=
tructure that encapsulates that contract and assert in its constructor.</sp=
an></div><div><span style=3D"font-size:12.8px"><br></span></div><div><span =
style=3D"font-size:12.8px">There is no reason at all to allow UB anywhere i=
n a program.</span></div><div><span style=3D"font-size:12.8px"><br></span><=
/div><div><span style=3D"font-size:12.8px">'performance' is not an =
argument. UB is simply the result of using the wrong tools.</span></div><di=
v><span style=3D"font-size:12.8px">=C2=A0</span></div><div><span style=3D"f=
ont-size:12.8px">It should be punished if at all possible, at compile time.=
</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><s=
pan style=3D"font-size:12.8px"><br></span></div></div><div class=3D"gmail_e=
xtra"><br><div class=3D"gmail_quote">On 19 December 2017 at 16:22, Hyman Ro=
sen <span dir=3D"ltr"><<a href=3D"mailto:hyman.rosen@gmail.com" target=
=3D"_blank">hyman.rosen@gmail.com</a>></span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><span class=3D"">On Tue, Dec 19, 2017 at 10:14 AM, Richard Hodge=
s <span dir=3D"ltr"><<a href=3D"mailto:hodges.r@gmail.com" target=3D"_bl=
ank">hodges.r@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><span>Nicol Bols wrote:<div><br></div><div><span clas=
s=3D"m_5831373462919658610m_-1726649167570532430gmail-m_3237809663472964857=
styled-by-prettify" style=3D"font-family:monospace;font-size:10.4px;backgro=
und-color:rgb(250,250,250);color:rgb(0,0,136)">void</span><span class=3D"m_=
5831373462919658610m_-1726649167570532430gmail-m_3237809663472964857styled-=
by-prettify" style=3D"font-family:monospace;font-size:10.4px;background-col=
or:rgb(250,250,250);color:rgb(0,0,0)">=C2=A0foo</span><span class=3D"m_5831=
373462919658610m_-1726649167570532430gmail-m_3237809663472964857styled-by-p=
rettify" style=3D"font-family:monospace;font-size:10.4px;background-color:r=
gb(250,250,250);color:rgb(102,102,0)">(</span><span class=3D"m_583137346291=
9658610m_-1726649167570532430gmail-m_3237809663472964857styled-by-prettify"=
style=3D"font-family:monospace;font-size:10.4px;background-color:rgb(250,2=
50,250);color:rgb(0,0,0)">T=C2=A0</span><span class=3D"m_583137346291965861=
0m_-1726649167570532430gmail-m_3237809663472964857styled-by-prettify" style=
=3D"font-family:monospace;font-size:10.4px;background-color:rgb(250,250,250=
);color:rgb(102,102,0)">*</span><span class=3D"m_5831373462919658610m_-1726=
649167570532430gmail-m_3237809663472964857styled-by-prettify" style=3D"font=
-family:monospace;font-size:10.4px;background-color:rgb(250,250,250);color:=
rgb(0,0,0)">t</span><span class=3D"m_5831373462919658610m_-1726649167570532=
430gmail-m_3237809663472964857styled-by-prettify" style=3D"font-family:mono=
space;font-size:10.4px;background-color:rgb(250,250,250);color:rgb(102,102,=
0)">)</span><span class=3D"m_5831373462919658610m_-1726649167570532430gmail=
-m_3237809663472964857styled-by-prettify" style=3D"font-family:monospace;fo=
nt-size:10.4px;background-color:rgb(250,250,250);color:rgb(0,0,0)"><br></sp=
an><span class=3D"m_5831373462919658610m_-1726649167570532430gmail-m_323780=
9663472964857styled-by-prettify" style=3D"font-family:monospace;font-size:1=
0.4px;background-color:rgb(250,250,250);color:rgb(102,102,0)">{</span><span=
class=3D"m_5831373462919658610m_-1726649167570532430gmail-m_32378096634729=
64857styled-by-prettify" style=3D"font-family:monospace;font-size:10.4px;ba=
ckground-color:rgb(250,250,250);color:rgb(0,0,0)"><br>=C2=A0 t</span><span =
class=3D"m_5831373462919658610m_-1726649167570532430gmail-m_323780966347296=
4857styled-by-prettify" style=3D"font-family:monospace;font-size:10.4px;bac=
kground-color:rgb(250,250,250);color:rgb(102,102,0)">-></span><span clas=
s=3D"m_5831373462919658610m_-1726649167570532430gmail-m_3237809663472964857=
styled-by-prettify" style=3D"font-family:monospace;font-size:10.4px;backgro=
und-color:rgb(250,250,250);color:rgb(0,0,0)">bar</span><span class=3D"m_583=
1373462919658610m_-1726649167570532430gmail-m_3237809663472964857styled-by-=
prettify" style=3D"font-family:monospace;font-size:10.4px;background-color:=
rgb(250,250,250);color:rgb(102,102,0)">();</span><span class=3D"m_583137346=
2919658610m_-1726649167570532430gmail-m_3237809663472964857styled-by-pretti=
fy" style=3D"font-family:monospace;font-size:10.4px;background-color:rgb(25=
0,250,250);color:rgb(0,0,0)"><br></span><span class=3D"m_583137346291965861=
0m_-1726649167570532430gmail-m_3237809663472964857styled-by-prettify" style=
=3D"font-family:monospace;font-size:10.4px;background-color:rgb(250,250,250=
);color:rgb(102,102,0)">}</span><br></div><div><span class=3D"m_58313734629=
19658610m_-1726649167570532430gmail-m_3237809663472964857styled-by-prettify=
" style=3D"font-family:monospace;font-size:10.4px;background-color:rgb(250,=
250,250);color:rgb(102,102,0)"><br></span></div></span><div><span class=3D"=
m_5831373462919658610m_-1726649167570532430gmail-m_3237809663472964857style=
d-by-prettify" style=3D"font-family:monospace;font-size:10.4px;background-c=
olor:rgb(250,250,250);color:rgb(102,102,0)"><span style=3D"color:rgb(34,34,=
34);font-family:arial,sans-serif;font-size:small;background-color:rgb(255,2=
55,255)">This is a very good reason for always passing by reference rather =
than pointer.</span></span></div><div><span class=3D"m_5831373462919658610m=
_-1726649167570532430gmail-m_3237809663472964857styled-by-prettify" style=
=3D"font-family:monospace;font-size:10.4px;background-color:rgb(250,250,250=
);color:rgb(102,102,0)"><span style=3D"color:rgb(34,34,34);font-family:aria=
l,sans-serif;font-size:small;background-color:rgb(255,255,255)"><br></span>=
</span></div><div><span class=3D"m_5831373462919658610m_-172664916757053243=
0gmail-m_3237809663472964857styled-by-prettify" style=3D"font-family:monosp=
ace;font-size:10.4px;background-color:rgb(250,250,250);color:rgb(102,102,0)=
"><div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:=
small">When I first learned C++ back in 1992 I used to write code like this=
..</div><div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-=
size:small"><br></div><div style=3D"color:rgb(34,34,34);font-family:arial,s=
ans-serif;font-size:small">As you well know, a pointer is an optional refer=
ence to an object. If you are dealing with an optional, you are obliged to =
check that it represents something.</div><div style=3D"color:rgb(34,34,34);=
font-family:arial,sans-serif;font-size:small"><br></div><div style=3D"color=
:rgb(34,34,34);font-family:arial,sans-serif;font-size:small">If you don'=
;t you have no place coding in 2017.</div><div><br></div></span></div><div>=
Prefer to pass by reference. If you must use a pointer, check it. Here ende=
th the lesson.</div></div></blockquote></span><div><br>My boss would disagr=
ee with you.=C2=A0 He very much favors narrow contracts; if you say<br>in t=
he function contract that the behavior is undefined if <font face=3D"monosp=
ace, monospace">t</font> is null, then you do not add<br>checks in the func=
tion for that, as it pessimizes in-contract code.=C2=A0 (You should add<br>=
assertions that would catch this problem when compiled with a checking mode=
..)<br><br>Pointer vs. reference is something of a red herring, because it&#=
39;s a particular circumstance<br>where the check appears simple (but what =
is the result of failing it?)=C2=A0 Now imagine that<br>the requirements ar=
e that the pointer is valid, or that a range given by a pair of iterators i=
s<br>sorted.</div></div></div></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/CAHSYqda%3DMH9htzM5LJ1%2BzFg8DcmqnpPt=
n0Z9RwUYt%3DRtBPAJVA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgi=
d/std-<wbr>proposals/CAHSYqda%<wbr>3DMH9htzM5LJ1%<wbr>2BzFg8DcmqnpPtn0Z9RwU=
Yt%<wbr>3DRtBPAJVA%40mail.gmail.com</a>.<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/CALvx3hY4mOgopyoH3PGWeD%3DCeR_OkJ0Tqg=
V2qkaCw3XB%3D3%3DiyQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hY4mO=
gopyoH3PGWeD%3DCeR_OkJ0TqgV2qkaCw3XB%3D3%3DiyQ%40mail.gmail.com</a>.<br />
--001a1143e71e77622d0560b31b96--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 19 Dec 2017 07:27:59 -0800 (PST)
Raw View
------=_Part_29570_1201887909.1513697279202
Content-Type: multipart/alternative;
boundary="----=_Part_29571_1862779439.1513697279202"
------=_Part_29571_1862779439.1513697279202
Content-Type: text/plain; charset="UTF-8"
On Tuesday, December 19, 2017 at 10:14:07 AM UTC-5, Richard Hodges wrote:
>
> Nicol Bols wrote:
>
> void foo(T *t)
> {
> t->bar();
> }
>
> This is a very good reason for always passing by reference rather than
> pointer.
>
And do you want to make it ill-formed for code to not follow this
convention too? How many other conventions do you want to enforce through
the language?
Let's have `new` return a `unique_ptr`, no matter how much perfectly
functioning code gets broken along the way.
Because that's what we're talking about: not an objective "this code is
non-functional" statement, but a "this code may not work" or "this code has
a narrow contract".
A language should not be a* cudgel* used to beat programmers into doing
things the way you believe they should be done. Or at the very least,
that's not how C++ does things.
If you feel differently, then go fork the language.
When I first learned C++ back in 1992 I used to write code like this.
>
> As you well know, a pointer is an optional reference to an object.
>
No, it's not. It's a pointer.
If you are dealing with an optional, you are obliged to check that it
> represents something.
>
No, you're not "obliged" to do anything. If someone else already verified
that it's a valid pointer, why do you need to?
If you don't you have no place coding in 2017.
>
> Prefer to pass by reference. If you must use a pointer, check it. Here
> endeth the lesson.
>
> Holding back the evolution of c++ because of the behaviour of a few
> miscreants is a crime against everyone else.
>
Ignoring the fact that C++ has billions of lines of code out there which
still needs to compile is a crime against every working C++ programmer.
--
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/2141f505-487b-49bc-953d-64c0580357ed%40isocpp.org.
------=_Part_29571_1862779439.1513697279202
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, December 19, 2017 at 10:14:07 AM UTC-5, Richar=
d Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
">Nicol Bols wrote:<div><br></div><div><span style=3D"font-family:monospace=
;font-size:10.4px;background-color:rgb(250,250,250);color:rgb(0,0,136)">voi=
d</span><span style=3D"font-family:monospace;font-size:10.4px;background-co=
lor:rgb(250,250,250);color:rgb(0,0,0)">=C2=A0foo</span><span style=3D"font-=
family:monospace;font-size:10.4px;background-color:rgb(250,250,250);color:r=
gb(102,102,0)">(</span><span style=3D"font-family:monospace;font-size:10.4p=
x;background-color:rgb(250,250,250);color:rgb(0,0,0)">T=C2=A0</span><span s=
tyle=3D"font-family:monospace;font-size:10.4px;background-color:rgb(250,250=
,250);color:rgb(102,102,0)">*</span><span style=3D"font-family:monospace;fo=
nt-size:10.4px;background-color:rgb(250,250,250);color:rgb(0,0,0)">t</span>=
<span style=3D"font-family:monospace;font-size:10.4px;background-color:rgb(=
250,250,250);color:rgb(102,102,0)">)</span><span style=3D"font-family:monos=
pace;font-size:10.4px;background-color:rgb(250,250,250);color:rgb(0,0,0)"><=
br></span><span style=3D"font-family:monospace;font-size:10.4px;background-=
color:rgb(250,250,250);color:rgb(102,102,0)">{</span><span style=3D"font-fa=
mily:monospace;font-size:10.4px;background-color:rgb(250,250,250);color:rgb=
(0,0,0)"><br>=C2=A0 t</span><span style=3D"font-family:monospace;font-size:=
10.4px;background-color:rgb(250,250,250);color:rgb(102,102,0)">-></span>=
<span style=3D"font-family:monospace;font-size:10.4px;background-color:rgb(=
250,250,250);color:rgb(0,0,0)">bar</span><span style=3D"font-family:monospa=
ce;font-size:10.4px;background-color:rgb(250,250,250);color:rgb(102,102,0)"=
>();</span><span style=3D"font-family:monospace;font-size:10.4px;background=
-color:rgb(250,250,250);color:rgb(0,0,0)"><br></span><span style=3D"font-fa=
mily:monospace;font-size:10.4px;background-color:rgb(250,250,250);color:rgb=
(102,102,0)">}</span><br></div><div><span style=3D"font-family:monospace;fo=
nt-size:10.4px;background-color:rgb(250,250,250);color:rgb(102,102,0)"><br>=
</span></div><div><span style=3D"font-family:monospace;font-size:10.4px;bac=
kground-color:rgb(250,250,250);color:rgb(102,102,0)"><span style=3D"color:r=
gb(34,34,34);font-family:arial,sans-serif;font-size:small;background-color:=
rgb(255,255,255)">This is a very good reason for always passing by referenc=
e rather than pointer.</span></span></div></div></blockquote><div><br></div=
><div>And do you want to make it ill-formed for code to not follow this con=
vention too? How many other conventions do you want to enforce through the =
language?</div><div><br></div><div>Let's have `new` return a `unique_pt=
r`, no matter how much perfectly functioning code gets broken along the way=
..</div><div><br></div><div><span style=3D"display: inline !important; float=
: none; background-color: transparent; color: rgb(34, 34, 34); font-family:=
"Arial","Helvetica",sans-serif; font-size: 13px; font-=
style: normal; font-variant: normal; font-weight: 400; letter-spacing: norm=
al; orphans: 2; text-align: left; text-decoration: none; text-indent: 0px; =
text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal; =
word-spacing: 0px;">Because that's what we're talking about: not an=
objective "this code is non-functional" statement, but a "t=
his code may not work" or "this code has a narrow contract".=
</span><b></b></div><div><b><br></b></div><div>A language should not be a<i=
> cudgel</i> used to beat programmers into doing things the way you believe=
they should be done. Or at the very least, that's not how C++ does thi=
ngs.</div><div><br></div><div>If you feel differently, then go fork the lan=
guage.</div><div><span style=3D"font-family:monospace;font-size:10.4px;back=
ground-color:rgb(250,250,250);color:rgb(102,102,0)"><span style=3D"color:rg=
b(34,34,34);font-family:arial,sans-serif;font-size:small;background-color:r=
gb(255,255,255)"><br></span></span></div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><div><span style=3D"font-family:monospace;font-=
size:10.4px;background-color:rgb(250,250,250);color:rgb(102,102,0)"><div st=
yle=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small">Wh=
en I first learned C++ back in 1992 I used to write code like this.</div><d=
iv style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:smal=
l"><br></div><div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif=
;font-size:small">As you well know, a pointer is an optional reference to a=
n object.</div></span></div></div></blockquote><div><br></div><div>No, it&#=
39;s not. It's a pointer.</div><div><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr"><div><span style=3D"font-family:monosp=
ace;font-size:10.4px;background-color:rgb(250,250,250);color:rgb(102,102,0)=
"><div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:=
small">If you are dealing with an optional, you are obliged to check that i=
t represents something.</div></span></div></div></blockquote><div><br></div=
><div>No, you're not "obliged" to do anything. If someone els=
e already verified that it's a valid pointer, why do you need to?</div>=
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><div><span style=3D"font-family:monospace;font-size:10.4px;background-col=
or:rgb(250,250,250);color:rgb(102,102,0)"><div style=3D"color:rgb(34,34,34)=
;font-family:arial,sans-serif;font-size:small">If you don't you have no=
place coding in 2017.</div><div><br></div></span></div><div>Prefer to pass=
by reference. If you must use a pointer, check it. Here endeth the lesson.=
</div><div><br></div><div>Holding back the evolution of c++ because of the =
behaviour of a few miscreants is a crime against everyone else.<br></div></=
div></blockquote><div>=C2=A0</div><div>Ignoring the fact that C++ has billi=
ons of lines of code out there which still needs to compile is a crime agai=
nst every working C++ programmer.</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/2141f505-487b-49bc-953d-64c0580357ed%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2141f505-487b-49bc-953d-64c0580357ed=
%40isocpp.org</a>.<br />
------=_Part_29571_1862779439.1513697279202--
------=_Part_29570_1201887909.1513697279202--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 19 Dec 2017 07:30:15 -0800 (PST)
Raw View
------=_Part_29304_42430941.1513697415671
Content-Type: multipart/alternative;
boundary="----=_Part_29305_1449220372.1513697415671"
------=_Part_29305_1449220372.1513697415671
Content-Type: text/plain; charset="UTF-8"
On Tuesday, December 19, 2017 at 10:27:42 AM UTC-5, Richard Hodges wrote:
>
> Hymen Rosen Wrote:
>
> > My boss would disagree with you. He very much favors narrow contracts;
> if you say
> in the function contract that the behavior is undefined if t is null,
> then you do not add
> checks in the function for that, as it pessimizes in-contract code. (You
> should add
> assertions that would catch this problem when compiled with a checking
> mode.)
>
> I think he and I are on the same page here. As far as I am concerned, an
> assert is a check.
>
> If it would be undefined behaviour to pass a null pointer here, then don't
> pass a pointer. It's the wrong tool. Pass a reference.
>
> If you want a pair of bidirectional or random-access iterators whose end()
> is after the begin(), pass a structure that encapsulates that contract and
> assert in its constructor.
>
> There is no reason at all to allow UB anywhere in a program.
>
> 'performance' is not an argument. UB is simply the result of using the
> wrong tools.
>
> It should be punished if at all possible, at compile time.
>
Any ideal, no matter how well-meaning or well-considered, which is taken as
an unassailable, uncritical article of faith always ends in tears for
everyone involved.
>
--
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/8744c92d-7b17-47a6-bc89-e07e934c4fb3%40isocpp.org.
------=_Part_29305_1449220372.1513697415671
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, December 19, 2017 at 10:27:42 AM UTC-5, Richar=
d Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><div>Hymen Rosen Wrote:</div><div><br></div>>=C2=A0<span style=3D"font=
-size:12.8px">My boss would disagree with you.=C2=A0 He very much favors na=
rrow contracts; if you say</span><br style=3D"font-size:12.8px"><span style=
=3D"font-size:12.8px">in the function contract that the behavior is undefin=
ed if=C2=A0</span><font face=3D"monospace, monospace" style=3D"font-size:12=
..8px">t</font><span style=3D"font-size:12.8px">=C2=A0is null, then you do n=
ot add</span><br style=3D"font-size:12.8px"><span style=3D"font-size:12.8px=
">checks in the function for that, as it pessimizes in-contract code.=C2=A0=
(You should add</span><br style=3D"font-size:12.8px"><span style=3D"font-s=
ize:12.8px">assertions that would catch this problem when compiled with a c=
hecking mode.)</span><div><span style=3D"font-size:12.8px"><br></span></div=
><div><span style=3D"font-size:12.8px">I think he and I are on the same pag=
e here. As far as I am concerned, an assert is a check.</span></div><div><s=
pan style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-si=
ze:12.8px">If it would be undefined behaviour to pass a null pointer here, =
then don't pass a pointer. It's the wrong tool. Pass a reference.</=
span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><spa=
n style=3D"font-size:12.8px">If you want a pair of bidirectional or random-=
access iterators whose end() is after the begin(), pass a structure that en=
capsulates that contract and assert in its constructor.</span></div><div><s=
pan style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-si=
ze:12.8px">There is no reason at all to allow UB anywhere in a program.</sp=
an></div><div><span style=3D"font-size:12.8px"><br></span></div><div><span =
style=3D"font-size:12.8px">'performance' is not an argument. UB is =
simply the result of using the wrong tools.</span></div><div><span style=3D=
"font-size:12.8px">=C2=A0</span></div><div><span style=3D"font-size:12.8px"=
>It should be punished if at all possible, at compile time.</span></div></d=
iv></blockquote><div><br></div><div>Any ideal, no matter how well-meaning o=
r well-considered, which is taken as an unassailable, uncritical article of=
faith always ends in tears for everyone involved.<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;">
</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/8744c92d-7b17-47a6-bc89-e07e934c4fb3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8744c92d-7b17-47a6-bc89-e07e934c4fb3=
%40isocpp.org</a>.<br />
------=_Part_29305_1449220372.1513697415671--
------=_Part_29304_42430941.1513697415671--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Tue, 19 Dec 2017 16:30:57 +0100
Raw View
--001a113fbc0846eeac0560b3274f
Content-Type: text/plain; charset="UTF-8"
> Ignoring the fact that C++ has billions of lines of code out there which
still needs to compile is a crime against every working C++ programmer.
With a little courage, we can have our cake and eat it.
If you want legacy behaviour, simply compile with -std=c++17.
If you want a better world and predictable, functioning programs that
forbid UB, use -std=c++20+
> If you feel differently, then go fork the language.
unproductive. Please rephrase.
On 19 December 2017 at 16:27, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Tuesday, December 19, 2017 at 10:14:07 AM UTC-5, Richard Hodges wrote:
>>
>> Nicol Bols wrote:
>>
>> void foo(T *t)
>> {
>> t->bar();
>> }
>>
>> This is a very good reason for always passing by reference rather than
>> pointer.
>>
>
> And do you want to make it ill-formed for code to not follow this
> convention too? How many other conventions do you want to enforce through
> the language?
>
> Let's have `new` return a `unique_ptr`, no matter how much perfectly
> functioning code gets broken along the way.
>
> Because that's what we're talking about: not an objective "this code is
> non-functional" statement, but a "this code may not work" or "this code has
> a narrow contract".
>
> A language should not be a* cudgel* used to beat programmers into doing
> things the way you believe they should be done. Or at the very least,
> that's not how C++ does things.
>
> If you feel differently, then go fork the language.
>
> When I first learned C++ back in 1992 I used to write code like this.
>>
>> As you well know, a pointer is an optional reference to an object.
>>
>
> No, it's not. It's a pointer.
>
> If you are dealing with an optional, you are obliged to check that it
>> represents something.
>>
>
> No, you're not "obliged" to do anything. If someone else already verified
> that it's a valid pointer, why do you need to?
>
> If you don't you have no place coding in 2017.
>>
>> Prefer to pass by reference. If you must use a pointer, check it. Here
>> endeth the lesson.
>>
>> Holding back the evolution of c++ because of the behaviour of a few
>> miscreants is a crime against everyone else.
>>
>
> Ignoring the fact that C++ has billions of lines of code out there which
> still needs to compile is a crime against every working C++ programmer.
>
> --
> 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/2141f505-487b-49bc-
> 953d-64c0580357ed%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2141f505-487b-49bc-953d-64c0580357ed%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CALvx3haTSWXZG5BMQJSQLVxp06pZe916_hhNFPmitOEpj8MG1Q%40mail.gmail.com.
--001a113fbc0846eeac0560b3274f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">Ignoring the fa=
ct that C++ has billions of lines of code out there which still needs to co=
mpile is a crime against every working C++ programmer.</span><div><span sty=
le=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8=
px">With a little courage, we can have our cake and eat it.</span></div><di=
v><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"fon=
t-size:12.8px">If you want legacy behaviour, simply compile with -std=3Dc++=
17.</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div=
><span style=3D"font-size:12.8px">If you want a better world and predictabl=
e, functioning programs that forbid UB, use -std=3Dc++20+</span></div><div>=
<span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-=
size:12.8px">>=C2=A0</span><span style=3D"font-size:12.8px">If you feel =
differently, then go fork the language.</span></div><div><span style=3D"fon=
t-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">unpro=
ductive. Please rephrase.</span></div><div><span style=3D"font-size:12.8px"=
><br></span></div><div><span style=3D"font-size:12.8px"><br></span></div><d=
iv><span style=3D"font-size:12.8px"><br></span></div></div><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">On 19 December 2017 at 16:27, Nic=
ol Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com" targe=
t=3D"_blank">jmckesson@gmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><span class=3D"">On Tuesday, December 19, 20=
17 at 10:14:07 AM UTC-5, Richard Hodges wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr">Nicol Bols wrote:<div><br></div><div><span styl=
e=3D"font-family:monospace;font-size:10.4px;background-color:rgb(250,250,25=
0);color:rgb(0,0,136)">void</span><span style=3D"font-family:monospace;font=
-size:10.4px;background-color:rgb(250,250,250);color:rgb(0,0,0)">=C2=A0foo<=
/span><span style=3D"font-family:monospace;font-size:10.4px;background-colo=
r:rgb(250,250,250);color:rgb(102,102,0)">(</span><span style=3D"font-family=
:monospace;font-size:10.4px;background-color:rgb(250,250,250);color:rgb(0,0=
,0)">T=C2=A0</span><span style=3D"font-family:monospace;font-size:10.4px;ba=
ckground-color:rgb(250,250,250);color:rgb(102,102,0)">*</span><span style=
=3D"font-family:monospace;font-size:10.4px;background-color:rgb(250,250,250=
);color:rgb(0,0,0)">t</span><span style=3D"font-family:monospace;font-size:=
10.4px;background-color:rgb(250,250,250);color:rgb(102,102,0)">)</span><spa=
n style=3D"font-family:monospace;font-size:10.4px;background-color:rgb(250,=
250,250);color:rgb(0,0,0)"><br></span><span style=3D"font-family:monospace;=
font-size:10.4px;background-color:rgb(250,250,250);color:rgb(102,102,0)">{<=
/span><span style=3D"font-family:monospace;font-size:10.4px;background-colo=
r:rgb(250,250,250);color:rgb(0,0,0)"><br>=C2=A0 t</span><span style=3D"font=
-family:monospace;font-size:10.4px;background-color:rgb(250,250,250);color:=
rgb(102,102,0)">-></span><span style=3D"font-family:monospace;font-size:=
10.4px;background-color:rgb(250,250,250);color:rgb(0,0,0)">bar</span><span =
style=3D"font-family:monospace;font-size:10.4px;background-color:rgb(250,25=
0,250);color:rgb(102,102,0)">();</span><span style=3D"font-family:monospace=
;font-size:10.4px;background-color:rgb(250,250,250);color:rgb(0,0,0)"><br><=
/span><span style=3D"font-family:monospace;font-size:10.4px;background-colo=
r:rgb(250,250,250);color:rgb(102,102,0)">}</span><br></div><div><span style=
=3D"font-family:monospace;font-size:10.4px;background-color:rgb(250,250,250=
);color:rgb(102,102,0)"><br></span></div><div><span style=3D"font-family:mo=
nospace;font-size:10.4px;background-color:rgb(250,250,250);color:rgb(102,10=
2,0)"><span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-=
size:small;background-color:rgb(255,255,255)">This is a very good reason fo=
r always passing by reference rather than pointer.</span></span></div></div=
></blockquote><div><br></div></span><div>And do you want to make it ill-for=
med for code to not follow this convention too? How many other conventions =
do you want to enforce through the language?</div><div><br></div><div>Let&#=
39;s have `new` return a `unique_ptr`, no matter how much perfectly functio=
ning code gets broken along the way.</div><div><br></div><div><span style=
=3D"display:inline!important;float:none;background-color:transparent;color:=
rgb(34,34,34);font-family:"Arial","Helvetica",sans-seri=
f;font-size:13px;font-style:normal;font-variant:normal;font-weight:400;lett=
er-spacing:normal;text-align:left;text-decoration:none;text-indent:0px;text=
-transform:none;white-space:normal;word-spacing:0px">Because that's wha=
t we're talking about: not an objective "this code is non-function=
al" statement, but a "this code may not work" or "this =
code has a narrow contract".</span><b></b></div><div><b><br></b></div>=
<div>A language should not be a<i> cudgel</i> used to beat programmers into=
doing things the way you believe they should be done. Or at the very least=
, that's not how C++ does things.</div><div><br></div><div>If you feel =
differently, then go fork the language.</div><span class=3D""><div><span st=
yle=3D"font-family:monospace;font-size:10.4px;background-color:rgb(250,250,=
250);color:rgb(102,102,0)"><span style=3D"color:rgb(34,34,34);font-family:a=
rial,sans-serif;font-size:small;background-color:rgb(255,255,255)"><br></sp=
an></span></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv><span style=3D"font-family:monospace;font-size:10.4px;background-color:r=
gb(250,250,250);color:rgb(102,102,0)"><div style=3D"color:rgb(34,34,34);fon=
t-family:arial,sans-serif;font-size:small">When I first learned C++ back in=
1992 I used to write code like this.</div><div style=3D"color:rgb(34,34,34=
);font-family:arial,sans-serif;font-size:small"><br></div><div style=3D"col=
or:rgb(34,34,34);font-family:arial,sans-serif;font-size:small">As you well =
know, a pointer is an optional reference to an object.</div></span></div></=
div></blockquote><div><br></div></span><div>No, it's not. It's a po=
inter.</div><span class=3D""><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div><span style=3D"font-family:monospace;font-si=
ze:10.4px;background-color:rgb(250,250,250);color:rgb(102,102,0)"><div styl=
e=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small">If y=
ou are dealing with an optional, you are obliged to check that it represent=
s something.</div></span></div></div></blockquote><div><br></div></span><di=
v>No, you're not "obliged" to do anything. If someone else al=
ready verified that it's a valid pointer, why do you need to?</div><spa=
n class=3D""><div><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div><span style=3D"font-family:monospace;font-size:10.4px;backgr=
ound-color:rgb(250,250,250);color:rgb(102,102,0)"><div style=3D"color:rgb(3=
4,34,34);font-family:arial,sans-serif;font-size:small">If you don't you=
have no place coding in 2017.</div><div><br></div></span></div><div>Prefer=
to pass by reference. If you must use a pointer, check it. Here endeth the=
lesson.</div><div><br></div><div>Holding back the evolution of c++ because=
of the behaviour of a few miscreants is a crime against everyone else.<br>=
</div></div></blockquote><div>=C2=A0</div></span><div>Ignoring the fact tha=
t C++ has billions of lines of code out there which still needs to compile =
is a crime against every working C++ programmer.</div></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/2141f505-487b-49bc-953d-64c0580357ed%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/2141=
f505-487b-49bc-<wbr>953d-64c0580357ed%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/CALvx3haTSWXZG5BMQJSQLVxp06pZe916_hhN=
FPmitOEpj8MG1Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3haTSWXZG5BM=
QJSQLVxp06pZe916_hhNFPmitOEpj8MG1Q%40mail.gmail.com</a>.<br />
--001a113fbc0846eeac0560b3274f--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Tue, 19 Dec 2017 16:32:23 +0100
Raw View
--f403045c48666cabf50560b32c6c
Content-Type: text/plain; charset="UTF-8"
> Any ideal, no matter how well-meaning or well-considered, which is taken
as an unassailable, uncritical article of faith always ends in tears for
everyone involved.
I happen to agree with you on this.
Hence,
[[not_reached]]
removes the compilation error.
Everyone's needs are served.
On 19 December 2017 at 16:30, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Tuesday, December 19, 2017 at 10:27:42 AM UTC-5, Richard Hodges wrote:
>>
>> Hymen Rosen Wrote:
>>
>> > My boss would disagree with you. He very much favors narrow
>> contracts; if you say
>> in the function contract that the behavior is undefined if t is null,
>> then you do not add
>> checks in the function for that, as it pessimizes in-contract code. (You
>> should add
>> assertions that would catch this problem when compiled with a checking
>> mode.)
>>
>> I think he and I are on the same page here. As far as I am concerned, an
>> assert is a check.
>>
>> If it would be undefined behaviour to pass a null pointer here, then
>> don't pass a pointer. It's the wrong tool. Pass a reference.
>>
>> If you want a pair of bidirectional or random-access iterators whose
>> end() is after the begin(), pass a structure that encapsulates that
>> contract and assert in its constructor.
>>
>> There is no reason at all to allow UB anywhere in a program.
>>
>> 'performance' is not an argument. UB is simply the result of using the
>> wrong tools.
>>
>> It should be punished if at all possible, at compile time.
>>
>
> Any ideal, no matter how well-meaning or well-considered, which is taken
> as an unassailable, uncritical article of faith always ends in tears for
> everyone involved.
>
>> --
> 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/8744c92d-7b17-47a6-
> bc89-e07e934c4fb3%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8744c92d-7b17-47a6-bc89-e07e934c4fb3%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CALvx3hZC8%2BtL%3DKd8k4OaSmfc0JzG7J5BQikpMem%3DFQczn9Q1yg%40mail.gmail.com.
--f403045c48666cabf50560b32c6c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">Any ideal, no m=
atter how well-meaning or well-considered, which is taken as an unassailabl=
e, uncritical article of faith always ends in tears for everyone involved.<=
/span><div><span style=3D"font-size:12.8px"><br></span></div><div><span sty=
le=3D"font-size:12.8px">I happen to agree with you on this.</span></div><di=
v><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"fon=
t-size:12.8px">Hence,=C2=A0</span></div><div><span style=3D"font-size:12.8p=
x"><br></span></div><div><span style=3D"font-size:12.8px"><font face=3D"mon=
ospace, monospace">[[not_reached]]</font></span></div><div><span style=3D"f=
ont-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">rem=
oves the compilation error.</span></div><div><span style=3D"font-size:12.8p=
x"><br></span></div><div><span style=3D"font-size:12.8px">Everyone's ne=
eds are served.</span></div><div><span style=3D"font-size:12.8px"><br></spa=
n></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On =
19 December 2017 at 16:30, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mai=
lto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D=
"">On Tuesday, December 19, 2017 at 10:27:42 AM UTC-5, Richard Hodges wrote=
:<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"ltr"><div>Hymen Rosen =
Wrote:</div><div><br></div>>=C2=A0<span style=3D"font-size:12.8px">My bo=
ss would disagree with you.=C2=A0 He very much favors narrow contracts; if =
you say</span><br style=3D"font-size:12.8px"><span style=3D"font-size:12.8p=
x">in the function contract that the behavior is undefined if=C2=A0</span><=
font face=3D"monospace, monospace" style=3D"font-size:12.8px">t</font><span=
style=3D"font-size:12.8px">=C2=A0is null, then you do not add</span><br st=
yle=3D"font-size:12.8px"><span style=3D"font-size:12.8px">checks in the fun=
ction for that, as it pessimizes in-contract code.=C2=A0 (You should add</s=
pan><br style=3D"font-size:12.8px"><span style=3D"font-size:12.8px">asserti=
ons that would catch this problem when compiled with a checking mode.)</spa=
n><div><span style=3D"font-size:12.8px"><br></span></div><div><span style=
=3D"font-size:12.8px">I think he and I are on the same page here. As far as=
I am concerned, an assert is a check.</span></div><div><span style=3D"font=
-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">If it =
would be undefined behaviour to pass a null pointer here, then don't pa=
ss a pointer. It's the wrong tool. Pass a reference.</span></div><div><=
span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-s=
ize:12.8px">If you want a pair of bidirectional or random-access iterators =
whose end() is after the begin(), pass a structure that encapsulates that c=
ontract and assert in its constructor.</span></div><div><span style=3D"font=
-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">There =
is no reason at all to allow UB anywhere in a program.</span></div><div><sp=
an style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-siz=
e:12.8px">'performance' is not an argument. UB is simply the result=
of using the wrong tools.</span></div><div><span style=3D"font-size:12.8px=
">=C2=A0</span></div><div><span style=3D"font-size:12.8px">It should be pun=
ished if at all possible, at compile time.</span></div></div></blockquote><=
div><br></div></span><div>Any ideal, no matter how well-meaning or well-con=
sidered, which is taken as an unassailable, uncritical article of faith alw=
ays ends in tears for everyone involved.<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">
</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/8744c92d-7b17-47a6-bc89-e07e934c4fb3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/8744=
c92d-7b17-47a6-<wbr>bc89-e07e934c4fb3%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/CALvx3hZC8%2BtL%3DKd8k4OaSmfc0JzG7J5B=
QikpMem%3DFQczn9Q1yg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZC8%=
2BtL%3DKd8k4OaSmfc0JzG7J5BQikpMem%3DFQczn9Q1yg%40mail.gmail.com</a>.<br />
--f403045c48666cabf50560b32c6c--
.
Author: Bo Persson <bop@gmb.dk>
Date: Tue, 19 Dec 2017 16:34:43 +0100
Raw View
On 2017-12-19 15:12, Jan Wilmans wrote:
> On 19 December 2017 at 14:58, Jake Arkinstall <jake.arkinstall@gmail.com
> <mailto:jake.arkinstall@gmail.com>> wrote:
>
> On 19 Dec 2017 13:41, "Nicol Bolas" <jmckesson@gmail.com
> <mailto:jmckesson@gmail.com>> wrote:
>
> But the compiler cannot/prove/ that any particular statement is
> reachable. Not so long as there is a condition. The compiler
> doesn't know what runtime values you will pass in.
>
> This is halting-problem levels of hard.
>
>
> It needn't be. Simply by adding an abort, throw, or whatever to the
> very end of each function if there are branches without returns (in
> the absence of some code that allows the user to tell the compiler
> to relax). It doesn't affect well formed functions because they have
> already returned by that point. It only actually affects anything
> that reaches the end without returning. As I said in a different
> reply, this probably messes up with some optimisations (obviously
> code size, but I'm thinking about speed), so I'm dubious, but it
> certainly isn't halting-problem hard if you take into account that
> post-return code does nothing.
>
>
> I agree, the question might be: why was it specified as being UB in the
> first place. About the complexity of the problem: the compiler could
> assume all path are always taking at some point and that could pessimize
> some optimizations that are currently done. What kind of code is
> currently out there that would rely on this?
It was made UB because we cannot require the compiler to *always* detect
the error. See halting-problem above.
In practice, good compilers will warn you that you might reach the end
without returning anything.
Bo Persson
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/p1bben%24t86%241%40blaine.gmane.org.
.
Author: Edward Catmur <ed@catmur.co.uk>
Date: Tue, 19 Dec 2017 07:37:25 -0800 (PST)
Raw View
------=_Part_7917_1831239395.1513697845154
Content-Type: multipart/alternative;
boundary="----=_Part_7918_1698081165.1513697845155"
------=_Part_7918_1698081165.1513697845155
Content-Type: text/plain; charset="UTF-8"
On Tuesday, 19 December 2017 15:30:59 UTC, Richard Hodges wrote:
>
> > Ignoring the fact that C++ has billions of lines of code out there
> which still needs to compile is a crime against every working C++
> programmer.
>
> With a little courage, we can have our cake and eat it.
>
> If you want legacy behaviour, simply compile with -std=c++17.
>
C++ version is set on a per-TU basis, and setting different versions for
TUs in the same program is inviting UB so in practice it has to be the same
for every TU in a program. That means that if one single header included by
one single TU in my program is broken by your change, I am unable to
upgrade. Worse, it means that if anyone who might use any of my library
code is unable to upgrade, then I cannot use any C++20 features.
If you want a better world and predictable, functioning programs that
> forbid UB, use -std=c++20+
>
> > If you feel differently, then go fork the language.
>
> unproductive. Please rephrase.
>
>
>
>
> On 19 December 2017 at 16:27, Nicol Bolas <jmck...@gmail.com <javascript:>
> > wrote:
>
>> On Tuesday, December 19, 2017 at 10:14:07 AM UTC-5, Richard Hodges wrote:
>>>
>>> Nicol Bols wrote:
>>>
>>> void foo(T *t)
>>> {
>>> t->bar();
>>> }
>>>
>>> This is a very good reason for always passing by reference rather than
>>> pointer.
>>>
>>
>> And do you want to make it ill-formed for code to not follow this
>> convention too? How many other conventions do you want to enforce through
>> the language?
>>
>> Let's have `new` return a `unique_ptr`, no matter how much perfectly
>> functioning code gets broken along the way.
>>
>> Because that's what we're talking about: not an objective "this code is
>> non-functional" statement, but a "this code may not work" or "this code has
>> a narrow contract".
>>
>> A language should not be a* cudgel* used to beat programmers into doing
>> things the way you believe they should be done. Or at the very least,
>> that's not how C++ does things.
>>
>> If you feel differently, then go fork the language.
>>
>> When I first learned C++ back in 1992 I used to write code like this.
>>>
>>> As you well know, a pointer is an optional reference to an object.
>>>
>>
>> No, it's not. It's a pointer.
>>
>> If you are dealing with an optional, you are obliged to check that it
>>> represents something.
>>>
>>
>> No, you're not "obliged" to do anything. If someone else already verified
>> that it's a valid pointer, why do you need to?
>>
>> If you don't you have no place coding in 2017.
>>>
>>> Prefer to pass by reference. If you must use a pointer, check it. Here
>>> endeth the lesson.
>>>
>>> Holding back the evolution of c++ because of the behaviour of a few
>>> miscreants is a crime against everyone else.
>>>
>>
>> Ignoring the fact that C++ has billions of lines of code out there which
>> still needs to compile is a crime against every working C++ programmer.
>>
>> --
>> 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-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
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2141f505-487b-49bc-953d-64c0580357ed%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2141f505-487b-49bc-953d-64c0580357ed%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
>
--
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/ec0e032a-ca64-4160-b06a-fdd49ccf2512%40isocpp.org.
------=_Part_7918_1698081165.1513697845155
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, 19 December 2017 15:30:59 UTC, Richard Hodges =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">>=
=C2=A0<span style=3D"font-size:12.8px">Ignoring the fact that C++ has billi=
ons of lines of code out there which still needs to compile is a crime agai=
nst every working C++ programmer.</span><div><span style=3D"font-size:12.8p=
x"><br></span></div><div><span style=3D"font-size:12.8px">With a little cou=
rage, we can have our cake and eat it.</span></div><div><span style=3D"font=
-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">If you=
want legacy behaviour, simply compile with -std=3Dc++17.</span></div></div=
></blockquote><div><br></div><div>C++ version is set on a per-TU basis, and=
setting different versions for TUs in the same program is inviting UB so i=
n practice it has to be the same for every TU in a program. That means that=
if one single header included by one single TU in my program is broken by =
your change, I am unable to upgrade. Worse, it means that if anyone who mig=
ht use any of my library code is unable to upgrade, then I cannot use any C=
++20 features.</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div><span style=3D"font-size:12.8px"></span></div><=
div><span style=3D"font-size:12.8px">If you want a better world and predict=
able, functioning programs that forbid UB, use -std=3Dc++20+</span></div><d=
iv><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"fo=
nt-size:12.8px">>=C2=A0</span><span style=3D"font-size:12.8px">If you fe=
el differently, then go fork the language.</span></div><div><span style=3D"=
font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">un=
productive. Please rephrase.</span></div><div><span style=3D"font-size:12.8=
px"><br></span></div><div><span style=3D"font-size:12.8px"><br></span></div=
><div><span style=3D"font-size:12.8px"><br></span></div></div><div><br><div=
class=3D"gmail_quote">On 19 December 2017 at 16:27, Nicol Bolas <span dir=
=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"EcKGGmxlAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascr=
ipt:';return true;" onclick=3D"this.href=3D'javascript:';return=
true;">jmck...@gmail.com</a>></span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><span>On Tuesday, December 19, 2017 at 10:14:07 AM =
UTC-5, Richard Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr">Nicol Bols wrote:<div><br></div><div><span style=3D"font-family:m=
onospace;font-size:10.4px;background-color:rgb(250,250,250);color:rgb(0,0,1=
36)">void</span><span style=3D"font-family:monospace;font-size:10.4px;backg=
round-color:rgb(250,250,250);color:rgb(0,0,0)">=C2=A0foo</span><span style=
=3D"font-family:monospace;font-size:10.4px;background-color:rgb(250,250,250=
);color:rgb(102,102,0)">(</span><span style=3D"font-family:monospace;font-s=
ize:10.4px;background-color:rgb(250,250,250);color:rgb(0,0,0)">T=C2=A0</spa=
n><span style=3D"font-family:monospace;font-size:10.4px;background-color:rg=
b(250,250,250);color:rgb(102,102,0)">*</span><span style=3D"font-family:mon=
ospace;font-size:10.4px;background-color:rgb(250,250,250);color:rgb(0,0,0)"=
>t</span><span style=3D"font-family:monospace;font-size:10.4px;background-c=
olor:rgb(250,250,250);color:rgb(102,102,0)">)</span><span style=3D"font-fam=
ily:monospace;font-size:10.4px;background-color:rgb(250,250,250);color:rgb(=
0,0,0)"><br></span><span style=3D"font-family:monospace;font-size:10.4px;ba=
ckground-color:rgb(250,250,250);color:rgb(102,102,0)">{</span><span style=
=3D"font-family:monospace;font-size:10.4px;background-color:rgb(250,250,250=
);color:rgb(0,0,0)"><br>=C2=A0 t</span><span style=3D"font-family:monospace=
;font-size:10.4px;background-color:rgb(250,250,250);color:rgb(102,102,0)">-=
></span><span style=3D"font-family:monospace;font-size:10.4px;background=
-color:rgb(250,250,250);color:rgb(0,0,0)">bar</span><span style=3D"font-fam=
ily:monospace;font-size:10.4px;background-color:rgb(250,250,250);color:rgb(=
102,102,0)">();</span><span style=3D"font-family:monospace;font-size:10.4px=
;background-color:rgb(250,250,250);color:rgb(0,0,0)"><br></span><span style=
=3D"font-family:monospace;font-size:10.4px;background-color:rgb(250,250,250=
);color:rgb(102,102,0)">}</span><br></div><div><span style=3D"font-family:m=
onospace;font-size:10.4px;background-color:rgb(250,250,250);color:rgb(102,1=
02,0)"><br></span></div><div><span style=3D"font-family:monospace;font-size=
:10.4px;background-color:rgb(250,250,250);color:rgb(102,102,0)"><span style=
=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;backgr=
ound-color:rgb(255,255,255)">This is a very good reason for always passing =
by reference rather than pointer.</span></span></div></div></blockquote><di=
v><br></div></span><div>And do you want to make it ill-formed for code to n=
ot follow this convention too? How many other conventions do you want to en=
force through the language?</div><div><br></div><div>Let's have `new` r=
eturn a `unique_ptr`, no matter how much perfectly functioning code gets br=
oken along the way.</div><div><br></div><div><span style=3D"display:inline!=
important;float:none;background-color:transparent;color:rgb(34,34,34);font-=
family:"Arial","Helvetica",sans-serif;font-size:13px;fo=
nt-style:normal;font-variant:normal;font-weight:400;letter-spacing:normal;t=
ext-align:left;text-decoration:none;text-indent:0px;text-transform:none;whi=
te-space:normal;word-spacing:0px">Because that's what we're talking=
about: not an objective "this code is non-functional" statement,=
but a "this code may not work" or "this code has a narrow c=
ontract".</span><b></b></div><div><b><br></b></div><div>A language sho=
uld not be a<i> cudgel</i> used to beat programmers into doing things the w=
ay you believe they should be done. Or at the very least, that's not ho=
w C++ does things.</div><div><br></div><div>If you feel differently, then g=
o fork the language.</div><span><div><span style=3D"font-family:monospace;f=
ont-size:10.4px;background-color:rgb(250,250,250);color:rgb(102,102,0)"><sp=
an style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:smal=
l;background-color:rgb(255,255,255)"><br></span></span></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><div><span style=3D"font-family:=
monospace;font-size:10.4px;background-color:rgb(250,250,250);color:rgb(102,=
102,0)"><div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font=
-size:small">When I first learned C++ back in 1992 I used to write code lik=
e this.</div><div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif=
;font-size:small"><br></div><div style=3D"color:rgb(34,34,34);font-family:a=
rial,sans-serif;font-size:small">As you well know, a pointer is an optional=
reference to an object.</div></span></div></div></blockquote><div><br></di=
v></span><div>No, it's not. It's a pointer.</div><span><div><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><span styl=
e=3D"font-family:monospace;font-size:10.4px;background-color:rgb(250,250,25=
0);color:rgb(102,102,0)"><div style=3D"color:rgb(34,34,34);font-family:aria=
l,sans-serif;font-size:small">If you are dealing with an optional, you are =
obliged to check that it represents something.</div></span></div></div></bl=
ockquote><div><br></div></span><div>No, you're not "obliged" =
to do anything. If someone else already verified that it's a valid poin=
ter, why do you need to?</div><span><div><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div><span style=3D"font-family:monospace;=
font-size:10.4px;background-color:rgb(250,250,250);color:rgb(102,102,0)"><d=
iv style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:smal=
l">If you don't you have no place coding in 2017.</div><div><br></div><=
/span></div><div>Prefer to pass by reference. If you must use a pointer, ch=
eck it. Here endeth the lesson.</div><div><br></div><div>Holding back the e=
volution of c++ because of the behaviour of a few miscreants is a crime aga=
inst everyone else.<br></div></div></blockquote><div>=C2=A0</div></span><di=
v>Ignoring the fact that C++ has billions of lines of code out there which =
still needs to compile is a crime against every working C++ programmer.</di=
v></div><span>
<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"=
EcKGGmxlAgAJ" 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"EcKGGmxlAgAJ" 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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2141f505-487b-49bc-953d-64c0580357ed%=
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/2141f505-487b-49bc-953d-64c0580357ed%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/2141f505-487b-49bc-953d-64c0580357ed%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/2141f505-487b-49bc-<wbr>953d-=
64c0580357ed%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/ec0e032a-ca64-4160-b06a-fdd49ccf2512%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ec0e032a-ca64-4160-b06a-fdd49ccf2512=
%40isocpp.org</a>.<br />
------=_Part_7918_1698081165.1513697845155--
------=_Part_7917_1831239395.1513697845154--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 19 Dec 2017 09:38:06 -0600
Raw View
--94eb2c1901a240caa00560b3432f
Content-Type: text/plain; charset="UTF-8"
On Tue, Dec 19, 2017 at 9:00 AM, Jake Arkinstall <jake.arkinstall@gmail.com>
wrote:
>
> Is anyone saying that it shouldn't pass through a compiler? Adding safety
> code at the very end of functions that assume some branch returns does not
> affect those functions where the assumption holds.
>
But it isn't safety code.
Safe would be not compiling, but as you pointed out we cannot always detect
that at compile time. In general it would be solving the halting problem.
UB means compilers can add detection code (such as sanitizers) when we can
afford to (say, during test instead of production).
Defined behavior means you have to assume the programmer knows what they
are doing, because an accidental use is indistinguishable from a deliberate
use. For instance people throw; from non-exception handling code or
throw through
a noexcept clause because they know it'll terminate their program.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
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/CAGg_6%2BNC92f1L8f2ywn3rmhmiWxwoEScfdk5QppRvOQeVAyzOg%40mail.gmail.com.
--94eb2c1901a240caa00560b3432f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tue, Dec 19, 2017 at 9:00 AM, Jake Arkinstall <span dir=
=3D"ltr"><<a href=3D"mailto:jake.arkinstall@gmail.com" target=3D"_blank"=
>jake.arkinstall@gmail.com</a>></span> wrote:<br><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"a=
uto"><span class=3D""><br><div class=3D"gmail_extra" dir=3D"auto">Is anyone=
saying that it shouldn't pass through a compiler? Adding safety code a=
t the very end of functions that assume some branch returns does not affect=
those functions where the assumption holds.<br></div></span></div></blockq=
uote><div><br></div><div>But it isn't safety code.</div><div><br></div>=
<div>Safe would be not compiling, but as you pointed out we cannot always d=
etect that at compile time.=C2=A0 In general it would be solving the haltin=
g problem.</div><div><br></div><div>UB means compilers can add detection co=
de (such as sanitizers) when we can afford to (say, during test instead of =
production).</div><div><br></div><div>Defined behavior means you have to as=
sume the programmer knows what they are doing, because an accidental use is=
indistinguishable from a deliberate use. For instance people <font face=3D=
"monospace, monospace">throw;</font> from non-exception handling code or <f=
ont face=3D"monospace, monospace">throw</font>=C2=A0through a <font face=3D=
"monospace, monospace">noexcept</font> clause because they know it'll t=
erminate their program.</div></div>-- <br><div class=3D"gmail_signature" da=
ta-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><di=
v>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevi=
n@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>> =C2=A0=
+1-847-691-1404</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"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/CAGg_6%2BNC92f1L8f2ywn3rmhmiWxwoEScfd=
k5QppRvOQeVAyzOg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNC92f1=
L8f2ywn3rmhmiWxwoEScfdk5QppRvOQeVAyzOg%40mail.gmail.com</a>.<br />
--94eb2c1901a240caa00560b3432f--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 19 Dec 2017 07:41:06 -0800 (PST)
Raw View
------=_Part_29107_354356867.1513698066761
Content-Type: multipart/alternative;
boundary="----=_Part_29108_593644466.1513698066761"
------=_Part_29108_593644466.1513698066761
Content-Type: text/plain; charset="UTF-8"
On Tuesday, December 19, 2017 at 10:30:59 AM UTC-5, Richard Hodges wrote:
>
> > Ignoring the fact that C++ has billions of lines of code out there
> which still needs to compile is a crime against every working C++
> programmer.
>
> With a little courage, we can have our cake and eat it.
>
The phrase "have your cake and eat it too" refers to being able to
side-step the problems associated with a particular solution. That is, you
can have all of the good aspects of the solution without the bad aspects.
Breaking changes are the bad aspects. You cannot divorce your idea from the
bad aspects because *that is your idea*. Your entire idea is to break
people's code.
The fact that you add a way for them to change their code to make it
compile again does not change the fact that you're severely impacting the
"not you" demographic.
That's a bad thing, even if you refuse to accept it as such.
If you want legacy behaviour, simply compile with -std=c++17.
>
> If you want a better world and predictable, functioning programs that
> forbid UB, use -std=c++20+
>
> > If you feel differently, then go fork the language.
>
> unproductive. Please rephrase.
>
.... I'm not sure what you mean. Yes, if you forked the language, odds are
good that nobody would adopt your "not-C++" language due to all of the
breaking changes you would impose. And thus such an act would be
unproductive.
But a fork is very much what you seem to want. You want to divide
everything between "C++17 programs" and "post-C++17 programs". Such that
"C++17 programs" cannot compile as "post-C++17 programs" and vice-versa.
Or did you think I misspelled a word?
--
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/e3876f61-e347-40c6-8590-f77f7afeddbc%40isocpp.org.
------=_Part_29108_593644466.1513698066761
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, December 19, 2017 at 10:30:59 AM UTC-5=
, Richard Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">Ignoring the fact that=
C++ has billions of lines of code out there which still needs to compile i=
s a crime against every working C++ programmer.</span><div><span style=3D"f=
ont-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">Wit=
h a little courage, we can have our cake and eat it.</span></div></div></bl=
ockquote><div><br></div><div><div>The phrase "have your cake and eat i=
t too" refers to being able to=20
side-step the problems associated with a particular solution. That is,=20
you can have all of the good aspects of the solution without the bad=20
aspects.<br></div><div><br></div><div>Breaking changes are the bad aspects.=
You cannot divorce your idea from the bad aspects because <i>that is your =
idea</i>. Your entire idea is to break people's code.</div><div><br></d=
iv><div>The
fact that you add a way for them to change their code to make it=20
compile again does not change the fact that you're severely impacting=
=20
the "not you" demographic.</div><div><br></div><div>That's a =
bad thing, even if you refuse to accept it as such.</div></div><div><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><span=
style=3D"font-size:12.8px">If you want legacy behaviour, simply compile wi=
th -std=3Dc++17.</span></div><div><span style=3D"font-size:12.8px"><br></sp=
an></div><div><span style=3D"font-size:12.8px">If you want a better world a=
nd predictable, functioning programs that forbid UB, use -std=3Dc++20+</spa=
n></div><div><span style=3D"font-size:12.8px"><br></span></div><div><span s=
tyle=3D"font-size:12.8px">>=C2=A0</span><span style=3D"font-size:12.8px"=
>If you feel differently, then go fork the language.</span></div><div><span=
style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:=
12.8px">unproductive. Please rephrase.</span></div></div></blockquote><div>=
<br></div><div><div>... I'm not sure what you mean. Yes, if you forked =
the language,=20
odds are good that nobody would adopt your "not-C++" language due=
to all
of the breaking changes you would impose. And thus such an act would be
unproductive.</div><div><br></div><div>But a fork is very much what you se=
em to want. You want to divide everything between "C++17 programs"=
; and "post-C++17 programs". Such that "C++17 programs"=
cannot compile as "post-C++17 programs" and vice-versa.</div></d=
iv><div><br></div><div>Or did you think I misspelled a word?=C2=A0</div></d=
iv>
<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/e3876f61-e347-40c6-8590-f77f7afeddbc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e3876f61-e347-40c6-8590-f77f7afeddbc=
%40isocpp.org</a>.<br />
------=_Part_29108_593644466.1513698066761--
------=_Part_29107_354356867.1513698066761--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Tue, 19 Dec 2017 16:43:15 +0100
Raw View
--f403045c486644404b0560b35394
Content-Type: text/plain; charset="UTF-8"
> In practice, good compilers will warn you that you might reach the end
without returning anything.
Only if explicitly made to. This is not good enough for something so
important.
I think gcc is a "good compiler", but unless decorated with the right
command line options, allows this inevitable crash to compile without the
slightest concern.
const char* foo(int x)
{
if (x == 0) return "no";
if (x == 1) return "yes";
}
Where's the harm in this alternative?
const char* foo(int x)
{
if (x == 0) return "no";
if (x == 1) return "yes";
assert(!"if you got here, you're doomed");
[[not_reached]]
}
In a release build, no overhead at all. And we've expressed intent
succinctly.
If we forget to fully express intent, the compiler can tell us. I cannot
imagine any rational argument why this might be construed as a bad thing.
On 19 December 2017 at 16:34, Bo Persson <bop@gmb.dk> wrote:
> On 2017-12-19 15:12, Jan Wilmans wrote:
>
>> On 19 December 2017 at 14:58, Jake Arkinstall <jake.arkinstall@gmail.com
>> <mailto:jake.arkinstall@gmail.com>> wrote:
>>
>> On 19 Dec 2017 13:41, "Nicol Bolas" <jmckesson@gmail.com
>> <mailto:jmckesson@gmail.com>> wrote:
>>
>> But the compiler cannot/prove/ that any particular statement is
>> reachable. Not so long as there is a condition. The compiler
>> doesn't know what runtime values you will pass in.
>>
>> This is halting-problem levels of hard.
>>
>>
>> It needn't be. Simply by adding an abort, throw, or whatever to the
>> very end of each function if there are branches without returns (in
>> the absence of some code that allows the user to tell the compiler
>> to relax). It doesn't affect well formed functions because they have
>> already returned by that point. It only actually affects anything
>> that reaches the end without returning. As I said in a different
>> reply, this probably messes up with some optimisations (obviously
>> code size, but I'm thinking about speed), so I'm dubious, but it
>> certainly isn't halting-problem hard if you take into account that
>> post-return code does nothing.
>>
>>
>> I agree, the question might be: why was it specified as being UB in the
>> first place. About the complexity of the problem: the compiler could assume
>> all path are always taking at some point and that could pessimize some
>> optimizations that are currently done. What kind of code is currently out
>> there that would rely on this?
>>
>
> It was made UB because we cannot require the compiler to *always* detect
> the error. See halting-problem above.
>
> In practice, good compilers will warn you that you might reach the end
> without returning anything.
>
>
> Bo Persson
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/is
> ocpp.org/d/msgid/std-proposals/p1bben%24t86%241%40blaine.gmane.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/CALvx3hae6Bo%2B_RG2ii4r-Ww%3Dsip1P9G_OLmeDLAwVgwkuTsDog%40mail.gmail.com.
--f403045c486644404b0560b35394
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">In practice, go=
od compilers will warn you that you might reach the end without returning a=
nything.</span><div><span style=3D"font-size:12.8px"><br></span></div><div>=
<span style=3D"font-size:12.8px">Only if explicitly made to. This is not go=
od enough for something so important.</span></div><div><span style=3D"font-=
size:12.8px"><br></span><div>I think gcc is a "good compiler", bu=
t unless decorated with the right command line options, allows this inevita=
ble crash to compile without the slightest concern.<br></div></div><div><br=
></div><div><div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,254=
);font-size:14px;line-height:21px;white-space:pre"><div><span style=3D"font=
-family:monospace,monospace;color:rgb(0,0,255)">const</span><span style=3D"=
font-family:monospace,monospace"> </span><span style=3D"font-family:monospa=
ce,monospace;color:rgb(0,0,255)">char</span><span style=3D"font-family:mono=
space,monospace">* foo(</span><span style=3D"font-family:monospace,monospac=
e;color:rgb(0,0,255)">int</span><span style=3D"font-family:monospace,monosp=
ace"> x)</span><br></div><div><font face=3D"monospace, monospace">{</font><=
/div><div><font face=3D"monospace, monospace"> <span style=3D"color:rgb(=
0,0,255)">if</span> (x =3D=3D <span style=3D"color:rgb(9,136,90)">0</span>)=
<span style=3D"color:rgb(0,0,255)">return</span> <span style=3D"color:rgb(=
163,21,21)">"no"</span>;</font></div><div><font face=3D"monospace=
, monospace"> <span style=3D"color:rgb(0,0,255)">if</span> (x =3D=3D <sp=
an style=3D"color:rgb(9,136,90)">1</span>) <span style=3D"color:rgb(0,0,255=
)">return</span> <span style=3D"color:rgb(163,21,21)">"yes"</span=
>;</font></div><div><font face=3D"monospace, monospace">}</font></div><br><=
/div></div><div>Where's the harm in this alternative?</div><div><br></d=
iv><div><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><spa=
n style=3D"font-family:monospace,monospace;color:rgb(0,0,255)">const</span>=
<span style=3D"font-family:monospace,monospace"> </span><span style=3D"font=
-family:monospace,monospace;color:rgb(0,0,255)">char</span><span style=3D"f=
ont-family:monospace,monospace">* foo(</span><span style=3D"font-family:mon=
ospace,monospace;color:rgb(0,0,255)">int</span><span style=3D"font-family:m=
onospace,monospace"> x)</span><br></div><div style=3D"color:rgb(0,0,0);font=
-size:14px;white-space:pre"><font face=3D"monospace, monospace">{</font></d=
iv><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><font fac=
e=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">if</span>=
(x =3D=3D <span style=3D"color:rgb(9,136,90)">0</span>) <span style=3D"col=
or:rgb(0,0,255)">return</span> <span style=3D"color:rgb(163,21,21)">"n=
o"</span>;</font></div><div style=3D"color:rgb(0,0,0);font-size:14px;w=
hite-space:pre"><font face=3D"monospace, monospace"> <span style=3D"colo=
r:rgb(0,0,255)">if</span> (x =3D=3D <span style=3D"color:rgb(9,136,90)">1</=
span>) <span style=3D"color:rgb(0,0,255)">return</span> <span style=3D"colo=
r:rgb(163,21,21)">"yes"</span>;</font></div><div style=3D"color:r=
gb(0,0,0);font-size:14px;white-space:pre"><font face=3D"monospace, monospac=
e"> assert(!"if you got here, you're doomed");</font></div=
><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><font face=
=3D"monospace, monospace"> [[not_reached]]</font></div><div style=3D"col=
or:rgb(0,0,0);font-size:14px;white-space:pre"><font face=3D"monospace, mono=
space">}</font></div></div><div><font face=3D"monospace, monospace"><br></f=
ont></div><div>In a release build, no overhead at all. And we've expres=
sed intent succinctly.</div><div><br></div><div>If we forget to fully expre=
ss intent, the compiler can tell us. I cannot imagine any rational argument=
why this might be construed as a bad thing.</div><div><br></div><div><br><=
/div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 19 =
December 2017 at 16:34, Bo Persson <span dir=3D"ltr"><<a href=3D"mailto:=
bop@gmb.dk" target=3D"_blank">bop@gmb.dk</a>></span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">On 2017-12-19 15:12, Jan Wilmans wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><span class=3D"">
On 19 December 2017 at 14:58, Jake Arkinstall <<a href=3D"mailto:jake.ar=
kinstall@gmail.com" target=3D"_blank">jake.arkinstall@gmail.com</a> <mai=
lto:<a href=3D"mailto:jake.arkinstall@gmail.com" target=3D"_blank">jake.ark=
install@gmail.<wbr>com</a>>> wrote:<br>
<br>
=C2=A0 =C2=A0 On 19 Dec 2017 13:41, "Nicol Bolas" <<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a><br></=
span>
=C2=A0 =C2=A0 <mailto:<a href=3D"mailto:jmckesson@gmail.com" target=3D"_=
blank">jmckesson@gmail.com</a>>> wrote:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 But the compiler cannot/prove/ that any particu=
lar statement is<span class=3D""><br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reachable. Not so long as there is a condition.=
The compiler<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 doesn't know what runtime values you will p=
ass in.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 This is halting-problem levels of hard.<br>
<br>
<br>
=C2=A0 =C2=A0 It needn't be. Simply by adding an abort, throw, or whate=
ver to the<br>
=C2=A0 =C2=A0 very end of each function if there are branches without retur=
ns (in<br>
=C2=A0 =C2=A0 the absence of some code that allows the user to tell the com=
piler<br>
=C2=A0 =C2=A0 to relax). It doesn't affect well formed functions becaus=
e they have<br>
=C2=A0 =C2=A0 already returned by that point. It only actually affects anyt=
hing<br>
=C2=A0 =C2=A0 that reaches the end without returning. As I said in a differ=
ent<br>
=C2=A0 =C2=A0 reply, this probably messes up with some optimisations (obvio=
usly<br>
=C2=A0 =C2=A0 code size, but I'm thinking about speed), so I'm dubi=
ous, but it<br>
=C2=A0 =C2=A0 certainly isn't halting-problem hard if you take into acc=
ount that<br>
=C2=A0 =C2=A0 post-return code does nothing.<br>
<br>
<br>
I agree, the question might be: why was it specified as being UB in the fir=
st place. About the complexity of the problem: the compiler could assume al=
l path are always taking at some point and that could pessimize some optimi=
zations that are currently done. What kind of code is currently out there t=
hat would rely on this?<br>
</span></blockquote>
<br>
It was made UB because we cannot require the compiler to *always* detect th=
e error. See halting-problem above.<br>
<br>
In practice, good compilers will warn you that you might reach the end with=
out returning anything.<br>
<br>
<br>
=C2=A0 =C2=A0 Bo Persson<span class=3D""><br>
<br>
<br>
-- <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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.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/p1bben%24t86%241%40blaine.gmane.org" =
rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/is<wbr>ocp=
p.org/d/msgid/std-proposals<wbr>/p1bben%24t86%241%40blaine.<wbr>gmane.org</=
a>.<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/CALvx3hae6Bo%2B_RG2ii4r-Ww%3Dsip1P9G_=
OLmeDLAwVgwkuTsDog%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hae6Bo%=
2B_RG2ii4r-Ww%3Dsip1P9G_OLmeDLAwVgwkuTsDog%40mail.gmail.com</a>.<br />
--f403045c486644404b0560b35394--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Tue, 19 Dec 2017 16:52:14 +0100
Raw View
--94eb2c05b4ba64bf820560b3734c
Content-Type: text/plain; charset="UTF-8"
> That means that if one single header included by one single TU in my
program is broken by your change, I am unable to upgrade. Worse, it means
that if anyone who might use any of my library code is unable to upgrade,
then I cannot use any C++20 features.
This is a (the only) valid concern I have seen expressed.
If the atmosphere were slightly more "let's make things better" and less
"let's keep things rubbish", I'd be tempted to think of it as nudging the
general idea of preventing UB forward while providing a way to interact
with legacy headers.
Being a positive person, I hereby choose to see your valid concern as a
driver for innovation.
Here's one idea, just off the top of my head:
extern "UBAllowed" {
#include <nasty_old_ub_filled_header.hpp>
}
Here's another
#pragma turn_a_blind_eye_to_ub(true)
#include <nasty_old_ub_filled_header.hpp>
#pragma turn_a_blind_eye_to_ub(true)
Of course we all know that the hardest problem in computer science is
naming things. I'll open the floor to better names, but shall we all choose
to agree on the general principle that anything we can do to help
programmers not shoot themselves in their extremities is a good thing?
On 19 December 2017 at 16:41, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Tuesday, December 19, 2017 at 10:30:59 AM UTC-5, Richard Hodges wrote:
>>
>> > Ignoring the fact that C++ has billions of lines of code out there
>> which still needs to compile is a crime against every working C++
>> programmer.
>>
>> With a little courage, we can have our cake and eat it.
>>
>
> The phrase "have your cake and eat it too" refers to being able to
> side-step the problems associated with a particular solution. That is, you
> can have all of the good aspects of the solution without the bad aspects.
>
> Breaking changes are the bad aspects. You cannot divorce your idea from
> the bad aspects because *that is your idea*. Your entire idea is to break
> people's code.
>
> The fact that you add a way for them to change their code to make it
> compile again does not change the fact that you're severely impacting the
> "not you" demographic.
>
> That's a bad thing, even if you refuse to accept it as such.
>
> If you want legacy behaviour, simply compile with -std=c++17.
>>
>> If you want a better world and predictable, functioning programs that
>> forbid UB, use -std=c++20+
>>
>> > If you feel differently, then go fork the language.
>>
>> unproductive. Please rephrase.
>>
>
> ... I'm not sure what you mean. Yes, if you forked the language, odds are
> good that nobody would adopt your "not-C++" language due to all of the
> breaking changes you would impose. And thus such an act would be
> unproductive.
>
> But a fork is very much what you seem to want. You want to divide
> everything between "C++17 programs" and "post-C++17 programs". Such that
> "C++17 programs" cannot compile as "post-C++17 programs" and vice-versa.
>
> Or did you think I misspelled a word?
>
> --
> 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/e3876f61-e347-40c6-
> 8590-f77f7afeddbc%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e3876f61-e347-40c6-8590-f77f7afeddbc%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CALvx3hZ0VrA2mT--LZBB5G6Ai5T66yUVt_vg7o3ezR8c8K0Ofg%40mail.gmail.com.
--94eb2c05b4ba64bf820560b3734c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">That means that=
if one single header included by one single TU in my program is broken by =
your change, I am unable to upgrade. Worse, it means that if anyone who mig=
ht use any of my library code is unable to upgrade, then I cannot use any C=
++20 features.</span><div><span style=3D"font-size:12.8px"><br></span></div=
><div><span style=3D"font-size:12.8px">This is a (the only) valid concern I=
have seen expressed.</span></div><div><br></div><div>If the atmosphere wer=
e slightly more "let's make things better" and less "let=
's keep things rubbish", I'd be tempted to think of it as nudg=
ing the general idea of preventing UB forward while providing a way to inte=
ract with legacy headers.</div><div><br></div><div>Being a positive person,=
I hereby choose to see your valid concern as a driver for innovation.</div=
><div><br></div><div>Here's one idea, just off the top of my head:</div=
><div><br></div><div><font face=3D"monospace, monospace">extern "UBAll=
owed" {</font></div><div><font face=3D"monospace, monospace">=C2=A0 #i=
nclude <nasty_old_ub_filled_header.hpp></font></div><div><font face=
=3D"monospace, monospace">}</font></div><div><br></div><div>Here's anot=
her</div><div><br></div><div><div><font face=3D"monospace, monospace">#prag=
ma turn_a_blind_eye_to_ub(true)</font></div></div><div><div><font face=3D"m=
onospace, monospace">=C2=A0 #include <nasty_old_ub_filled_header.hpp>=
</font></div><div><font face=3D"monospace, monospace">#pragma turn_a_blind_=
eye_to_ub(true)</font></div></div><div><br></div><div>Of course we all know=
that the hardest problem in computer science is naming things. I'll op=
en the floor to better names, but shall we all choose to agree on the gener=
al principle that anything we can do to help programmers not shoot themselv=
es in their extremities is a good thing?</div><div><br></div></div><div cla=
ss=3D"gmail_extra"><br><div class=3D"gmail_quote">On 19 December 2017 at 16=
:41, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.co=
m" target=3D"_blank">jmckesson@gmail.com</a>></span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><br><br>On Tuesday,=
December 19, 2017 at 10:30:59 AM UTC-5, Richard Hodges wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr">>=C2=A0<span style=3D"font-s=
ize:12.8px">Ignoring the fact that C++ has billions of lines of code out th=
ere which still needs to compile is a crime against every working C++ progr=
ammer.</span><div><span style=3D"font-size:12.8px"><br></span></div><div><s=
pan style=3D"font-size:12.8px">With a little courage, we can have our cake =
and eat it.</span></div></div></blockquote><div><br></div></span><div><div>=
The phrase "have your cake and eat it too" refers to being able t=
o=20
side-step the problems associated with a particular solution. That is,=20
you can have all of the good aspects of the solution without the bad=20
aspects.<br></div><div><br></div><div>Breaking changes are the bad aspects.=
You cannot divorce your idea from the bad aspects because <i>that is your =
idea</i>. Your entire idea is to break people's code.</div><div><br></d=
iv><div>The
fact that you add a way for them to change their code to make it=20
compile again does not change the fact that you're severely impacting=
=20
the "not you" demographic.</div><div><br></div><div>That's a =
bad thing, even if you refuse to accept it as such.</div></div><span class=
=3D""><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div><span style=3D"font-size:12.8px">If you want legacy behaviour, simp=
ly compile with -std=3Dc++17.</span></div><div><span style=3D"font-size:12.=
8px"><br></span></div><div><span style=3D"font-size:12.8px">If you want a b=
etter world and predictable, functioning programs that forbid UB, use -std=
=3Dc++20+</span></div><div><span style=3D"font-size:12.8px"><br></span></di=
v><div><span style=3D"font-size:12.8px">>=C2=A0</span><span style=3D"fon=
t-size:12.8px">If you feel differently, then go fork the language.</span></=
div><div><span style=3D"font-size:12.8px"><br></span></div><div><span style=
=3D"font-size:12.8px">unproductive. Please rephrase.</span></div></div></bl=
ockquote><div><br></div></span><div><div>... I'm not sure what you mean=
.. Yes, if you forked the language,=20
odds are good that nobody would adopt your "not-C++" language due=
to all
of the breaking changes you would impose. And thus such an act would be
unproductive.</div><div><br></div><div>But a fork is very much what you se=
em to want. You want to divide everything between "C++17 programs"=
; and "post-C++17 programs". Such that "C++17 programs"=
cannot compile as "post-C++17 programs" and vice-versa.</div></d=
iv><div><br></div><div>Or did you think I misspelled a word?=C2=A0</div></d=
iv><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/e3876f61-e347-40c6-8590-f77f7afeddbc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/e387=
6f61-e347-40c6-<wbr>8590-f77f7afeddbc%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/CALvx3hZ0VrA2mT--LZBB5G6Ai5T66yUVt_vg=
7o3ezR8c8K0Ofg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ0VrA2mT--=
LZBB5G6Ai5T66yUVt_vg7o3ezR8c8K0Ofg%40mail.gmail.com</a>.<br />
--94eb2c05b4ba64bf820560b3734c--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Tue, 19 Dec 2017 16:53:04 +0100
Raw View
--001a1143e71e6de3e90560b376e8
Content-Type: text/plain; charset="UTF-8"
or even:
#pragma turn_a_blind_eye_to_ub(push)
#pragma turn_a_blind_eye_to_ub(true)
#include <nasty_old_ub_filled_header.hpp>
#pragma turn_a_blind_eye_to_ub(pop)
On 19 December 2017 at 16:52, Richard Hodges <hodges.r@gmail.com> wrote:
> > That means that if one single header included by one single TU in my
> program is broken by your change, I am unable to upgrade. Worse, it means
> that if anyone who might use any of my library code is unable to upgrade,
> then I cannot use any C++20 features.
>
> This is a (the only) valid concern I have seen expressed.
>
> If the atmosphere were slightly more "let's make things better" and less
> "let's keep things rubbish", I'd be tempted to think of it as nudging the
> general idea of preventing UB forward while providing a way to interact
> with legacy headers.
>
> Being a positive person, I hereby choose to see your valid concern as a
> driver for innovation.
>
> Here's one idea, just off the top of my head:
>
> extern "UBAllowed" {
> #include <nasty_old_ub_filled_header.hpp>
> }
>
> Here's another
>
> #pragma turn_a_blind_eye_to_ub(true)
> #include <nasty_old_ub_filled_header.hpp>
> #pragma turn_a_blind_eye_to_ub(true)
>
> Of course we all know that the hardest problem in computer science is
> naming things. I'll open the floor to better names, but shall we all choose
> to agree on the general principle that anything we can do to help
> programmers not shoot themselves in their extremities is a good thing?
>
>
> On 19 December 2017 at 16:41, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>>
>>
>> On Tuesday, December 19, 2017 at 10:30:59 AM UTC-5, Richard Hodges wrote:
>>>
>>> > Ignoring the fact that C++ has billions of lines of code out there
>>> which still needs to compile is a crime against every working C++
>>> programmer.
>>>
>>> With a little courage, we can have our cake and eat it.
>>>
>>
>> The phrase "have your cake and eat it too" refers to being able to
>> side-step the problems associated with a particular solution. That is, you
>> can have all of the good aspects of the solution without the bad aspects.
>>
>> Breaking changes are the bad aspects. You cannot divorce your idea from
>> the bad aspects because *that is your idea*. Your entire idea is to
>> break people's code.
>>
>> The fact that you add a way for them to change their code to make it
>> compile again does not change the fact that you're severely impacting the
>> "not you" demographic.
>>
>> That's a bad thing, even if you refuse to accept it as such.
>>
>> If you want legacy behaviour, simply compile with -std=c++17.
>>>
>>> If you want a better world and predictable, functioning programs that
>>> forbid UB, use -std=c++20+
>>>
>>> > If you feel differently, then go fork the language.
>>>
>>> unproductive. Please rephrase.
>>>
>>
>> ... I'm not sure what you mean. Yes, if you forked the language, odds are
>> good that nobody would adopt your "not-C++" language due to all of the
>> breaking changes you would impose. And thus such an act would be
>> unproductive.
>>
>> But a fork is very much what you seem to want. You want to divide
>> everything between "C++17 programs" and "post-C++17 programs". Such that
>> "C++17 programs" cannot compile as "post-C++17 programs" and vice-versa.
>>
>> Or did you think I misspelled a word?
>>
>> --
>> 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/is
>> ocpp.org/d/msgid/std-proposals/e3876f61-e347-40c6-8590-
>> f77f7afeddbc%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e3876f61-e347-40c6-8590-f77f7afeddbc%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
>
--
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/CALvx3hZY7gA_GD8N--ohN0c1PofOXF%3DdwQW0a2kWT7p37L_P%3Dg%40mail.gmail.com.
--001a1143e71e6de3e90560b376e8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">or even:<br><br><div style=3D"font-size:12.8px"><font face=
=3D"monospace, monospace">#pragma turn_a_blind_eye_to_ub(push)</font></div>=
<div style=3D"font-size:12.8px"></div><div style=3D"font-size:12.8px"><font=
face=3D"monospace, monospace">#pragma turn_a_blind_eye_to_ub(true)</font><=
/div><div style=3D"font-size:12.8px"></div><div style=3D"font-size:12.8px">=
<span style=3D"font-family:monospace,monospace;font-size:12.8px">=C2=A0 #in=
clude <nasty_old_ub_filled_header.</span><wbr style=3D"font-family:monos=
pace,monospace;font-size:12.8px"><span style=3D"font-family:monospace,monos=
pace;font-size:12.8px">hpp></span><br></div><div style=3D"font-size:12.8=
px"><div><font face=3D"monospace, monospace">#pragma turn_a_blind_eye_to_ub=
(pop)</font></div><div><font face=3D"monospace, monospace"><br></font></div=
></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 1=
9 December 2017 at 16:52, Richard Hodges <span dir=3D"ltr"><<a href=3D"m=
ailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a>></spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D=
"">>=C2=A0<span style=3D"font-size:12.8px">That means that if one single=
header included by one single TU in my program is broken by your change, I=
am unable to upgrade. Worse, it means that if anyone who might use any of =
my library code is unable to upgrade, then I cannot use any C++20 features.=
</span><div><span style=3D"font-size:12.8px"><br></span></div></span><div><=
span style=3D"font-size:12.8px">This is a (the only) valid concern I have s=
een expressed.</span></div><div><br></div><div>If the atmosphere were sligh=
tly more "let's make things better" and less "let's =
keep things rubbish", I'd be tempted to think of it as nudging the=
general idea of preventing UB forward while providing a way to interact wi=
th legacy headers.</div><div><br></div><div>Being a positive person, I here=
by choose to see your valid concern as a driver for innovation.</div><div><=
br></div><div>Here's one idea, just off the top of my head:</div><div><=
br></div><div><font face=3D"monospace, monospace">extern "UBAllowed&qu=
ot; {</font></div><div><font face=3D"monospace, monospace">=C2=A0 #include =
<nasty_old_ub_filled_header.<wbr>hpp></font></div><div><font face=3D"=
monospace, monospace">}</font></div><div><br></div><div>Here's another<=
/div><div><br></div><div><div><font face=3D"monospace, monospace">#pragma t=
urn_a_blind_eye_to_ub(true)</font></div></div><div><div><font face=3D"monos=
pace, monospace">=C2=A0 #include <nasty_old_ub_filled_header.<wbr>hpp>=
;</font></div><div><font face=3D"monospace, monospace">#pragma turn_a_blind=
_eye_to_ub(true)</font></div></div><div><br></div><div>Of course we all kno=
w that the hardest problem in computer science is naming things. I'll o=
pen the floor to better names, but shall we all choose to agree on the gene=
ral principle that anything we can do to help programmers not shoot themsel=
ves in their extremities is a good thing?</div><div><br></div></div><div cl=
ass=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On 19 December 2017 at 16:41, Nicol Bolas <span dir=3D"ltr=
"><<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gm=
ail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr"><span><br><br>On Tuesday, December 19, 2017 at 10:30:59 AM UTC-5, Ric=
hard Hodges 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">=
>=C2=A0<span style=3D"font-size:12.8px">Ignoring the fact that C++ has b=
illions of lines of code out there which still needs to compile is a crime =
against every working C++ programmer.</span><div><span style=3D"font-size:1=
2.8px"><br></span></div><div><span style=3D"font-size:12.8px">With a little=
courage, we can have our cake and eat it.</span></div></div></blockquote><=
div><br></div></span><div><div>The phrase "have your cake and eat it t=
oo" refers to being able to=20
side-step the problems associated with a particular solution. That is,=20
you can have all of the good aspects of the solution without the bad=20
aspects.<br></div><div><br></div><div>Breaking changes are the bad aspects.=
You cannot divorce your idea from the bad aspects because <i>that is your =
idea</i>. Your entire idea is to break people's code.</div><div><br></d=
iv><div>The
fact that you add a way for them to change their code to make it=20
compile again does not change the fact that you're severely impacting=
=20
the "not you" demographic.</div><div><br></div><div>That's a =
bad thing, even if you refuse to accept it as such.</div></div><span><div><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><spa=
n style=3D"font-size:12.8px">If you want legacy behaviour, simply compile w=
ith -std=3Dc++17.</span></div><div><span style=3D"font-size:12.8px"><br></s=
pan></div><div><span style=3D"font-size:12.8px">If you want a better world =
and predictable, functioning programs that forbid UB, use -std=3Dc++20+</sp=
an></div><div><span style=3D"font-size:12.8px"><br></span></div><div><span =
style=3D"font-size:12.8px">>=C2=A0</span><span style=3D"font-size:12.8px=
">If you feel differently, then go fork the language.</span></div><div><spa=
n style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size=
:12.8px">unproductive. Please rephrase.</span></div></div></blockquote><div=
><br></div></span><div><div>... I'm not sure what you mean. Yes, if you=
forked the language,=20
odds are good that nobody would adopt your "not-C++" language due=
to all
of the breaking changes you would impose. And thus such an act would be
unproductive.</div><div><br></div><div>But a fork is very much what you se=
em to want. You want to divide everything between "C++17 programs"=
; and "post-C++17 programs". Such that "C++17 programs"=
cannot compile as "post-C++17 programs" and vice-versa.</div></d=
iv><div><br></div><div>Or did you think I misspelled a word?=C2=A0</div></d=
iv><span>
<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@isoc<wbr>pp.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/e3876f61-e347-40c6-8590-f77f7afeddbc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/e387=
6f61-e347-40c6-8590-<wbr>f77f7afeddbc%40isocpp.org</a>.<br>
</blockquote></div><br></div>
</div></div></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/CALvx3hZY7gA_GD8N--ohN0c1PofOXF%3DdwQ=
W0a2kWT7p37L_P%3Dg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZY7gA_=
GD8N--ohN0c1PofOXF%3DdwQW0a2kWT7p37L_P%3Dg%40mail.gmail.com</a>.<br />
--001a1143e71e6de3e90560b376e8--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 19 Dec 2017 07:56:18 -0800 (PST)
Raw View
------=_Part_29449_767896134.1513698978270
Content-Type: multipart/alternative;
boundary="----=_Part_29450_1157858641.1513698978271"
------=_Part_29450_1157858641.1513698978271
Content-Type: text/plain; charset="UTF-8"
On Tuesday, December 19, 2017 at 10:43:22 AM UTC-5, Richard Hodges wrote:
>
> > In practice, good compilers will warn you that you might reach the end
> without returning anything.
>
> Only if explicitly made to. This is not good enough for something so
> important.
>
> I think gcc is a "good compiler", but unless decorated with the right
> command line options, allows this inevitable crash to compile without the
> slightest concern.
>
> const char* foo(int x)
> {
> if (x == 0) return "no";
> if (x == 1) return "yes";
> }
>
> Where's the harm in this alternative?
>
> const char* foo(int x)
> {
> if (x == 0) return "no";
> if (x == 1) return "yes";
> assert(!"if you got here, you're doomed");
> [[not_reached]]
> }
>
> In a release build, no overhead at all. And we've expressed intent
> succinctly.
>
> If we forget to fully express intent, the compiler can tell us. I cannot
> imagine any rational argument why this might be construed as a bad thing.
>
The harm comes when you say that* not* doing that is ill-formed. Everything
else is fine up until then.
>
--
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/f001ebc9-b64a-47a3-862b-5fa6aff6fa36%40isocpp.org.
------=_Part_29450_1157858641.1513698978271
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, December 19, 2017 at 10:43:22 AM UTC-5=
, Richard Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">In practice, good comp=
ilers will warn you that you might reach the end without returning anything=
..</span><div><span style=3D"font-size:12.8px"><br></span></div><div><span s=
tyle=3D"font-size:12.8px">Only if explicitly made to. This is not good enou=
gh for something so important.</span></div><div><span style=3D"font-size:12=
..8px"><br></span><div>I think gcc is a "good compiler", but unles=
s decorated with the right command line options, allows this inevitable cra=
sh to compile without the slightest concern.<br></div></div><div><br></div>=
<div><div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,254);font-=
size:14px;line-height:21px;white-space:pre"><div><span style=3D"font-family=
:monospace,monospace;color:rgb(0,0,255)">const</span><span style=3D"font-fa=
mily:monospace,monospace"> </span><span style=3D"font-family:monospace,mono=
space;color:rgb(0,0,255)">char</span><span style=3D"font-family:monospace,m=
onospace">* foo(</span><span style=3D"font-family:monospace,monospace;color=
:rgb(0,0,255)">int</span><span style=3D"font-family:monospace,monospace"> x=
)</span><br></div><div><font face=3D"monospace, monospace">{</font></div><d=
iv><font face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255=
)">if</span> (x =3D=3D <span style=3D"color:rgb(9,136,90)">0</span>) <span =
style=3D"color:rgb(0,0,255)">return</span> <span style=3D"color:rgb(163,21,=
21)">"no"</span>;</font></div><div><font face=3D"monospace, monos=
pace"> <span style=3D"color:rgb(0,0,255)">if</span> (x =3D=3D <span styl=
e=3D"color:rgb(9,136,90)">1</span>) <span style=3D"color:rgb(0,0,255)">retu=
rn</span> <span style=3D"color:rgb(163,21,21)">"yes"</span>;</fon=
t></div><div><font face=3D"monospace, monospace">}</font></div><br></div></=
div><div>Where's the harm in this alternative?</div><div><br></div><div=
><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><span style=
=3D"font-family:monospace,monospace;color:rgb(0,0,255)">const</span><span s=
tyle=3D"font-family:monospace,monospace"> </span><span style=3D"font-family=
:monospace,monospace;color:rgb(0,0,255)">char</span><span style=3D"font-fam=
ily:monospace,monospace">* foo(</span><span style=3D"font-family:monospace,=
monospace;color:rgb(0,0,255)">int</span><span style=3D"font-family:monospac=
e,monospace"> x)</span><br></div><div style=3D"color:rgb(0,0,0);font-size:1=
4px;white-space:pre"><font face=3D"monospace, monospace">{</font></div><div=
style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><font face=3D"mo=
nospace, monospace"> <span style=3D"color:rgb(0,0,255)">if</span> (x =3D=
=3D <span style=3D"color:rgb(9,136,90)">0</span>) <span style=3D"color:rgb(=
0,0,255)">return</span> <span style=3D"color:rgb(163,21,21)">"no"=
</span>;</font></div><div style=3D"color:rgb(0,0,0);font-size:14px;white-sp=
ace:pre"><font face=3D"monospace, monospace"> <span style=3D"color:rgb(0=
,0,255)">if</span> (x =3D=3D <span style=3D"color:rgb(9,136,90)">1</span>) =
<span style=3D"color:rgb(0,0,255)">return</span> <span style=3D"color:rgb(1=
63,21,21)">"yes"</span>;</font></div><div style=3D"color:rgb(0,0,=
0);font-size:14px;white-space:pre"><font face=3D"monospace, monospace"> =
assert(!"if you got here, you're doomed");</font></div><div s=
tyle=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><font face=3D"mono=
space, monospace"> [[not_reached]]</font></div><div style=3D"color:rgb(0=
,0,0);font-size:14px;white-space:pre"><font face=3D"monospace, monospace">}=
</font></div></div><div><font face=3D"monospace, monospace"><br></font></di=
v><div>In a release build, no overhead at all. And we've expressed inte=
nt succinctly.</div><div><br></div><div>If we forget to fully express inten=
t, the compiler can tell us. I cannot imagine any rational argument why thi=
s might be construed as a bad thing.</div></div></blockquote><div><br></div=
><div>The harm comes when you say that<i> not</i> doing that is ill-formed.=
Everything else is fine up until then.<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;">
</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/f001ebc9-b64a-47a3-862b-5fa6aff6fa36%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f001ebc9-b64a-47a3-862b-5fa6aff6fa36=
%40isocpp.org</a>.<br />
------=_Part_29450_1157858641.1513698978271--
------=_Part_29449_767896134.1513698978270--
.
Author: Ren Industries <renindustries@gmail.com>
Date: Tue, 19 Dec 2017 10:57:21 -0500
Raw View
--f403045c4934bd51360560b38576
Content-Type: text/plain; charset="UTF-8"
Performance is absolutely an argument; having narrow contracts on small,
inlinable functions makes them very fast and efficient (in many cases, with
small switch statements or for loops, they can be compiled down to 2-3
instructions even). Forcing them to specify a return statement or open
their contract will make them slower, and with applications like game
design, these optimizations are very important. I don't know how many leaf
functions I have that inline perfectly, but would be hampered in these
efforts by any sort of throw logic.
C++ is all about "pay for what you use", not "pay for what someone else
thinks you need".
--
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/CAMD6iD-cx4B1QA%2B4ygnn6y5fcrvvmuN2ostBmqjTMM45kGNdJg%40mail.gmail.com.
--f403045c4934bd51360560b38576
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">Performance is absolutely an ar=
gument; having narrow contracts on small, inlinable functions makes them ve=
ry fast and efficient (in many cases, with small switch statements or for l=
oops, they can be compiled down to 2-3 instructions even). Forcing them to =
specify a return statement or open their contract will make them slower, an=
d with applications like game design, these optimizations are very importan=
t. I don't know how many leaf functions I have that inline perfectly, b=
ut would be hampered in these efforts by any sort of throw logic.</div><div=
class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">C++ is all abou=
t "pay for what you use", not "pay for what someone else thi=
nks you need".</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/CAMD6iD-cx4B1QA%2B4ygnn6y5fcrvvmuN2os=
tBmqjTMM45kGNdJg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD-cx4B1QA=
%2B4ygnn6y5fcrvvmuN2ostBmqjTMM45kGNdJg%40mail.gmail.com</a>.<br />
--f403045c4934bd51360560b38576--
.
Author: Edward Catmur <ed@catmur.co.uk>
Date: Tue, 19 Dec 2017 08:02:13 -0800 (PST)
Raw View
------=_Part_7723_1194470126.1513699333692
Content-Type: multipart/alternative;
boundary="----=_Part_7724_713521807.1513699333693"
------=_Part_7724_713521807.1513699333693
Content-Type: text/plain; charset="UTF-8"
On Tuesday, 19 December 2017 15:43:22 UTC, Richard Hodges wrote:
>
> > In practice, good compilers will warn you that you might reach the end
> without returning anything.
>
> Only if explicitly made to. This is not good enough for something so
> important.
>
The reason that -Wreturn-type is part of -Wextra and not -Wall is that
there is far too much existing code that would trigger the warning.
> I think gcc is a "good compiler", but unless decorated with the right
> command line options, allows this inevitable crash to compile without the
> slightest concern.
>
> const char* foo(int x)
> {
> if (x == 0) return "no";
> if (x == 1) return "yes";
> }
>
struct S {
S(bool b) { puts(foo(b)); }
private:
const char* foo(int x) { ... }
};
Where is the inevitable crash in this code?
> Where's the harm in this alternative?
>
> const char* foo(int x)
> {
> if (x == 0) return "no";
> if (x == 1) return "yes";
> assert(!"if you got here, you're doomed");
> [[not_reached]]
> }
>
We do not yet have the not_reached attribute. Once we have had not_reached
available for a few years, we can consider making it compulsory.
> In a release build, no overhead at all. And we've expressed intent
> succinctly.
>
> If we forget to fully express intent, the compiler can tell us. I cannot
> imagine any rational argument why this might be construed as a bad thing.
>
As an end goal, this would be a good thing. As an immediate breaking
change, there is no viable upgrade path.
>
>
> On 19 December 2017 at 16:34, Bo Persson <b...@gmb.dk <javascript:>>
> wrote:
>
>> On 2017-12-19 15:12, Jan Wilmans wrote:
>>
>>> On 19 December 2017 at 14:58, Jake Arkinstall <jake.ar...@gmail.com
>>> <javascript:> <mailto:jake.ar...@gmail.com <javascript:>>> wrote:
>>>
>>> On 19 Dec 2017 13:41, "Nicol Bolas" <jmck...@gmail.com <javascript:>
>>> <mailto:jmck...@gmail.com <javascript:>>> wrote:
>>>
>>> But the compiler cannot/prove/ that any particular statement is
>>> reachable. Not so long as there is a condition. The compiler
>>> doesn't know what runtime values you will pass in.
>>>
>>> This is halting-problem levels of hard.
>>>
>>>
>>> It needn't be. Simply by adding an abort, throw, or whatever to the
>>> very end of each function if there are branches without returns (in
>>> the absence of some code that allows the user to tell the compiler
>>> to relax). It doesn't affect well formed functions because they have
>>> already returned by that point. It only actually affects anything
>>> that reaches the end without returning. As I said in a different
>>> reply, this probably messes up with some optimisations (obviously
>>> code size, but I'm thinking about speed), so I'm dubious, but it
>>> certainly isn't halting-problem hard if you take into account that
>>> post-return code does nothing.
>>>
>>>
>>> I agree, the question might be: why was it specified as being UB in the
>>> first place. About the complexity of the problem: the compiler could assume
>>> all path are always taking at some point and that could pessimize some
>>> optimizations that are currently done. What kind of code is currently out
>>> there that would rely on this?
>>>
>>
>> It was made UB because we cannot require the compiler to *always* detect
>> the error. See halting-problem above.
>>
>> In practice, good compilers will warn you that you might reach the end
>> without returning anything.
>>
>>
>> Bo Persson
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-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
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/p1bben%24t86%241%40blaine.gmane.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/2469097a-ee73-46a9-ac6e-afc28d05236a%40isocpp.org.
------=_Part_7724_713521807.1513699333693
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, 19 December 2017 15:43:22 UTC, Richard=
Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
">>=C2=A0<span style=3D"font-size:12.8px">In practice, good compilers wi=
ll warn you that you might reach the end without returning anything.</span>=
<div><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"=
font-size:12.8px">Only if explicitly made to. This is not good enough for s=
omething so important.</span></div></div></blockquote><div><br></div><div>T=
he reason that -Wreturn-type is part of -Wextra and not -Wall is that there=
is far too much existing code that would trigger the warning.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div><span style=3D"font-size:12.8px"></span><div>I think gcc is a "goo=
d compiler", but unless decorated with the right command line options,=
allows this inevitable crash to compile without the slightest concern.<br>=
</div></div><div><br></div><div><div style=3D"color:rgb(0,0,0);background-c=
olor:rgb(255,255,254);font-size:14px;line-height:21px;white-space:pre"><div=
><span style=3D"font-family:monospace,monospace;color:rgb(0,0,255)">const</=
span><span style=3D"font-family:monospace,monospace"> </span><span style=3D=
"font-family:monospace,monospace;color:rgb(0,0,255)">char</span><span style=
=3D"font-family:monospace,monospace">* foo(</span><span style=3D"font-famil=
y:monospace,monospace;color:rgb(0,0,255)">int</span><span style=3D"font-fam=
ily:monospace,monospace"> x)</span><br></div><div><font face=3D"monospace, =
monospace">{</font></div><div><font face=3D"monospace, monospace"> <span=
style=3D"color:rgb(0,0,255)">if</span> (x =3D=3D <span style=3D"color:rgb(=
9,136,90)">0</span>) <span style=3D"color:rgb(0,0,255)">return</span> <span=
style=3D"color:rgb(163,21,21)">"no"</span>;</font></div><div><fo=
nt face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">if<=
/span> (x =3D=3D <span style=3D"color:rgb(9,136,90)">1</span>) <span style=
=3D"color:rgb(0,0,255)">return</span> <span style=3D"color:rgb(163,21,21)">=
"yes"</span>;</font></div><div><font face=3D"monospace, monospace=
">}</font></div></div></div></div></blockquote><div><br></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: brea=
k-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> S </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br>=C2=A0 S</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">bool</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> b</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: #660;" class=3D"styled-by-prettify">{</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> puts</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">foo</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">b</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">));</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">private</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">char</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" 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-pr=
ettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">};</span></div></code></div><div><br></div><div>Where is the inevitable c=
rash in this code?</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><div>Where's the harm in this alternative?<=
/div><div><br></div><div><div style=3D"color:rgb(0,0,0);font-size:14px;whit=
e-space:pre"><span style=3D"font-family:monospace,monospace;color:rgb(0,0,2=
55)">const</span><span style=3D"font-family:monospace,monospace"> </span><s=
pan style=3D"font-family:monospace,monospace;color:rgb(0,0,255)">char</span=
><span style=3D"font-family:monospace,monospace">* foo(</span><span style=
=3D"font-family:monospace,monospace;color:rgb(0,0,255)">int</span><span sty=
le=3D"font-family:monospace,monospace"> x)</span><br></div><div style=3D"co=
lor:rgb(0,0,0);font-size:14px;white-space:pre"><font face=3D"monospace, mon=
ospace">{</font></div><div style=3D"color:rgb(0,0,0);font-size:14px;white-s=
pace:pre"><font face=3D"monospace, monospace"> <span style=3D"color:rgb(=
0,0,255)">if</span> (x =3D=3D <span style=3D"color:rgb(9,136,90)">0</span>)=
<span style=3D"color:rgb(0,0,255)">return</span> <span style=3D"color:rgb(=
163,21,21)">"no"</span>;</font></div><div style=3D"color:rgb(0,0,=
0);font-size:14px;white-space:pre"><font face=3D"monospace, monospace"> =
<span style=3D"color:rgb(0,0,255)">if</span> (x =3D=3D <span style=3D"color=
:rgb(9,136,90)">1</span>) <span style=3D"color:rgb(0,0,255)">return</span> =
<span style=3D"color:rgb(163,21,21)">"yes"</span>;</font></div><d=
iv style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><font face=3D"=
monospace, monospace"> assert(!"if you got here, you're doomed&=
quot;);</font></div><div style=3D"color:rgb(0,0,0);font-size:14px;white-spa=
ce:pre"><font face=3D"monospace, monospace"> [[not_reached]]</font></div=
><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><font face=
=3D"monospace, monospace">}</font></div></div></div></blockquote><div><br><=
/div><div>We do not yet have the not_reached attribute. Once we have had no=
t_reached available for a few years, we can consider making it compulsory.<=
/div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><font face=3D"monospace, monospace"></font></div><div>In a re=
lease build, no overhead at all. And we've expressed intent succinctly.=
</div><div><br></div><div>If we forget to fully express intent, the compile=
r can tell us. I cannot imagine any rational argument why this might be con=
strued as a bad thing.</div></div></blockquote><div><br></div><div>As an en=
d goal, this would be a good thing. As an immediate breaking change, there =
is no viable upgrade path.=C2=A0</div><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div><br></div></div><=
div><br><div class=3D"gmail_quote">On 19 December 2017 at 16:34, Bo Persson=
<span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfusc=
ated-mailto=3D"PbUa8BhmAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;javascript:';return true;" onclick=3D"this.href=3D'javascript:&#=
39;;return true;">b...@gmb.dk</a>></span> wrote:<br><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">On 2017-12-19 15:12, Jan Wilmans wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><span>
On 19 December 2017 at 14:58, Jake Arkinstall <<a href=3D"javascript:" t=
arget=3D"_blank" gdf-obfuscated-mailto=3D"PbUa8BhmAgAJ" rel=3D"nofollow" on=
mousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"thi=
s.href=3D'javascript:';return true;">jake.ar...@gmail.com</a> <m=
ailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Pb=
Ua8BhmAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:=
9;;return true;" onclick=3D"this.href=3D'javascript:';return true;"=
>jake.ar...@gmail.<wbr>com</a>>> wrote:<br>
<br>
=C2=A0 =C2=A0 On 19 Dec 2017 13:41, "Nicol Bolas" <<a href=3D"=
javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"PbUa8BhmAgAJ" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;=
" onclick=3D"this.href=3D'javascript:';return true;">jmck...@gmail.=
com</a><br></span>
=C2=A0 =C2=A0 <mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"PbUa8BhmAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
'javascript:';return true;" onclick=3D"this.href=3D'javascript:=
';return true;">jmck...@gmail.com</a>>> wrote:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 But the compiler cannot/prove/ that any particu=
lar statement is<span><br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reachable. Not so long as there is a condition.=
The compiler<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 doesn't know what runtime values you will p=
ass in.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 This is halting-problem levels of hard.<br>
<br>
<br>
=C2=A0 =C2=A0 It needn't be. Simply by adding an abort, throw, or whate=
ver to the<br>
=C2=A0 =C2=A0 very end of each function if there are branches without retur=
ns (in<br>
=C2=A0 =C2=A0 the absence of some code that allows the user to tell the com=
piler<br>
=C2=A0 =C2=A0 to relax). It doesn't affect well formed functions becaus=
e they have<br>
=C2=A0 =C2=A0 already returned by that point. It only actually affects anyt=
hing<br>
=C2=A0 =C2=A0 that reaches the end without returning. As I said in a differ=
ent<br>
=C2=A0 =C2=A0 reply, this probably messes up with some optimisations (obvio=
usly<br>
=C2=A0 =C2=A0 code size, but I'm thinking about speed), so I'm dubi=
ous, but it<br>
=C2=A0 =C2=A0 certainly isn't halting-problem hard if you take into acc=
ount that<br>
=C2=A0 =C2=A0 post-return code does nothing.<br>
<br>
<br>
I agree, the question might be: why was it specified as being UB in the fir=
st place. About the complexity of the problem: the compiler could assume al=
l path are always taking at some point and that could pessimize some optimi=
zations that are currently done. What kind of code is currently out there t=
hat would rely on this?<br>
</span></blockquote>
<br>
It was made UB because we cannot require the compiler to *always* detect th=
e error. See halting-problem above.<br>
<br>
In practice, good compilers will warn you that you might reach the end with=
out returning anything.<br>
<br>
<br>
=C2=A0 =C2=A0 Bo Persson<span><br>
<br>
<br>
-- <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"=
PbUa8BhmAgAJ" 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"PbUa8BhmAgAJ" 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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/p1bben%24t86%241%40blaine.gmane.org" =
rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'https://=
groups.google.com/a/isocpp.org/d/msgid/std-proposals/p1bben%24t86%241%40bla=
ine.gmane.org';return true;" onclick=3D"this.href=3D'https://groups=
..google.com/a/isocpp.org/d/msgid/std-proposals/p1bben%24t86%241%40blaine.gm=
ane.org';return true;">https://groups.google.com/a/<wbr>isocpp.org/d/ms=
gid/std-<wbr>proposals/p1bben%24t86%241%<wbr>40blaine.gmane.org</a>.<br>
</blockquote></div><br></div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/2469097a-ee73-46a9-ac6e-afc28d05236a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2469097a-ee73-46a9-ac6e-afc28d05236a=
%40isocpp.org</a>.<br />
------=_Part_7724_713521807.1513699333693--
------=_Part_7723_1194470126.1513699333692--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Tue, 19 Dec 2017 17:07:42 +0100
Raw View
--001a11448e4eb30e780560b3aa4e
Content-Type: text/plain; charset="UTF-8"
> Performance is absolutely an argument; having narrow contracts on small,
inlinable functions makes them very fast and efficient (in many cases, with
small switch statements or for loops, they can be compiled down to 2-3
instructions even).
I completely agree with you, having written some graphics engines myself.
In K&R C with inline assembler, no less.
> Forcing them to specify a return statement or open their contract will
make them slower,
This is nonsense. I have provided a proposal on expressing the intent to
not provide a return statement. You would have the same optimisation
opportunities that you enjoy today.
> and with applications like game design, these optimizations are very
important.
Yes, agree.
> I don't know how many leaf functions I have that inline perfectly, but
would be hampered in these efforts by any sort of throw logic.
No-one is arguing that you have to have any throw logic.
> C++ is all about "pay for what you use", not "pay for what someone else
thinks you need".
Right. I don't use UB. Your game-players have no use for it either. UB in a
game means random spawns, crashes, the quest didn't complete and now my 100
hours of gameplay was for nothing, and other events that cause the players
to throw their arms up, yell "what is this b*llsh*t?" and give you awful
reviews on Steam. I know you don't want that.
I'm trying to help you here...
On 19 December 2017 at 16:57, Ren Industries <renindustries@gmail.com>
wrote:
> Performance is absolutely an argument; having narrow contracts on small,
> inlinable functions makes them very fast and efficient (in many cases, with
> small switch statements or for loops, they can be compiled down to 2-3
> instructions even). Forcing them to specify a return statement or open
> their contract will make them slower, and with applications like game
> design, these optimizations are very important. I don't know how many leaf
> functions I have that inline perfectly, but would be hampered in these
> efforts by any sort of throw logic.
>
> C++ is all about "pay for what you use", not "pay for what someone else
> thinks you need".
>
> --
> 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/CAMD6iD-cx4B1QA%
> 2B4ygnn6y5fcrvvmuN2ostBmqjTMM45kGNdJg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD-cx4B1QA%2B4ygnn6y5fcrvvmuN2ostBmqjTMM45kGNdJg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CALvx3hZVjLE9Lc_6bdpSxH6Odie-9wgR0Pg56Y-pnU04fDC%2BDw%40mail.gmail.com.
--001a11448e4eb30e780560b3aa4e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">Performance is =
absolutely an argument; having narrow contracts on small, inlinable functio=
ns makes them very fast and efficient (in many cases, with small switch sta=
tements or for loops, they can be compiled down to 2-3 instructions even).=
=C2=A0</span><div><span style=3D"font-size:12.8px"><br></span></div><div><s=
pan style=3D"font-size:12.8px">I completely agree with you, having written =
some graphics engines myself. In K&R C with inline assembler, no less.<=
/span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><sp=
an style=3D"font-size:12.8px">> Forcing them to specify a return stateme=
nt or open their contract will make them slower,=C2=A0</span></div><div><sp=
an style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-siz=
e:12.8px">This is nonsense. I have provided a proposal on expressing the in=
tent to not provide a return statement. You would have the same optimisatio=
n opportunities that you enjoy today.</span></div><div><span style=3D"font-=
size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">> an=
d with applications like game design, these optimizations are very importan=
t.=C2=A0</span></div><div><span style=3D"font-size:12.8px"><br></span></div=
><div><span style=3D"font-size:12.8px">Yes, agree.</span></div><div><span s=
tyle=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12=
..8px">> I don't know how many leaf functions I have that inline perf=
ectly, but would be hampered in these efforts by any sort of throw logic.</=
span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><spa=
n style=3D"font-size:12.8px">No-one is arguing that you have to have any th=
row logic.</span></div><div><span style=3D"font-size:12.8px"><br></span><di=
v class=3D"gmail_extra" style=3D"font-size:12.8px"><span style=3D"font-size=
:12.8px">> C++ is all about "pay for what you use", not "=
pay for what someone else thinks you need".</span><br></div></div><div=
class=3D"gmail_extra" style=3D"font-size:12.8px"><span style=3D"font-size:=
12.8px"><br></span></div><div class=3D"gmail_extra" style=3D"font-size:12.8=
px"><span style=3D"font-size:12.8px">Right. I don't use UB. Your game-p=
layers have no use for it either. UB in a game means random spawns, crashes=
, the quest didn't complete and now my 100 hours of gameplay was for no=
thing, and other events that cause the players to throw their arms up, yell=
"what is this b*llsh*t?" and give you awful reviews on Steam. I =
know you don't want that.</span></div><div class=3D"gmail_extra" style=
=3D"font-size:12.8px"><span style=3D"font-size:12.8px"><br></span></div><di=
v class=3D"gmail_extra" style=3D"font-size:12.8px"><span style=3D"font-size=
:12.8px">I'm trying to help you here...</span></div><div class=3D"gmail=
_extra" style=3D"font-size:12.8px"><span style=3D"font-size:12.8px"><br></s=
pan></div><div class=3D"gmail_extra" style=3D"font-size:12.8px"><span style=
=3D"font-size:12.8px"><br></span></div></div><div class=3D"gmail_extra"><br=
><div class=3D"gmail_quote">On 19 December 2017 at 16:57, Ren Industries <s=
pan dir=3D"ltr"><<a href=3D"mailto:renindustries@gmail.com" target=3D"_b=
lank">renindustries@gmail.com</a>></span> wrote:<br><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">Performance is absol=
utely an argument; having narrow contracts on small, inlinable functions ma=
kes them very fast and efficient (in many cases, with small switch statemen=
ts or for loops, they can be compiled down to 2-3 instructions even). Forci=
ng them to specify a return statement or open their contract will make them=
slower, and with applications like game design, these optimizations are ve=
ry important. I don't know how many leaf functions I have that inline p=
erfectly, but would be hampered in these efforts by any sort of throw logic=
..</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">C++ =
is all about "pay for what you use", not "pay for what someo=
ne else thinks you need".</div></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/CAMD6iD-cx4B1QA%2B4ygnn6y5fcrvvmuN2os=
tBmqjTMM45kGNdJg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/CAMD6iD-cx4B1QA%<wbr>2B4ygnn6y5fcrvvmuN2ostBmqjTMM4<wbr>5k=
GNdJg%40mail.gmail.com</a>.<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/CALvx3hZVjLE9Lc_6bdpSxH6Odie-9wgR0Pg5=
6Y-pnU04fDC%2BDw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZVjLE9Lc=
_6bdpSxH6Odie-9wgR0Pg56Y-pnU04fDC%2BDw%40mail.gmail.com</a>.<br />
--001a11448e4eb30e780560b3aa4e--
.
Author: Ren Industries <renindustries@gmail.com>
Date: Tue, 19 Dec 2017 11:15:15 -0500
Raw View
--f403045c10bcbd096b0560b3c5e3
Content-Type: text/plain; charset="UTF-8"
> > Performance is absolutely an argument; having narrow contracts on
> small, inlinable functions makes them very fast and efficient (in many
> cases, with small switch statements or for loops, they can be compiled down
> to 2-3 instructions even).
>
> I completely agree with you, having written some graphics engines myself.
> In K&R C with inline assembler, no less.
>
> > Forcing them to specify a return statement or open their contract will
> make them slower,
>
> This is nonsense. I have provided a proposal on expressing the intent to
> not provide a return statement. You would have the same optimisation
> opportunities that you enjoy today.
>
Right, which I now need to transform hundreds to thousands of lines of code
to use. No.
>
> > and with applications like game design, these optimizations are very
> important.
>
> Yes, agree.
>
> > I don't know how many leaf functions I have that inline perfectly, but
> would be hampered in these efforts by any sort of throw logic.
>
> No-one is arguing that you have to have any throw logic.
>
It was mentioned several times in this thread. I don't exactly see how else
you are going to enforce these constraints at runtime otherwise. It is
haltingly difficult to do so at compile time, and there is absolutely no
way I would be behind anything that requires code changes to currently
working code. And no, if you do not violate the contract, it is NOT BROKEN,
so by enforcing these things at compile time, you WILL be breaking my code.
>
> > C++ is all about "pay for what you use", not "pay for what someone else
> thinks you need".
>
> Right. I don't use UB. Your game-players have no use for it either. UB in
> a game means random spawns, crashes, the quest didn't complete and now my
> 100 hours of gameplay was for nothing, and other events that cause the
> players to throw their arms up, yell "what is this b*llsh*t?" and give you
> awful reviews on Steam. I know you don't want that.
>
> I'm trying to help you here...
>
>
But you aren't being helpful. You are forcing me to overhaul enormous
amounts of code to prevent errors I do not experience. I am not using UB: I
am depending on my contract being narrow to allow inlining and tight
optimizations, and it's on me to ensure that is safe.
I don't need you to ensure I'm safe.
--
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/CAMD6iD_Ycf3a5rueBfoEkqy0azNmz2ts-Xi8PaF%3D8K1gQH8ucw%40mail.gmail.com.
--f403045c10bcbd096b0560b3c5e3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">>=C2=A0=
<span style=3D"font-size:12.8px">Performance is absolutely an argument; hav=
ing narrow contracts on small, inlinable functions makes them very fast and=
efficient (in many cases, with small switch statements or for loops, they =
can be compiled down to 2-3 instructions even).=C2=A0</span><div><span styl=
e=3D"font-size:12.8px"><br></span></div></span><div><span style=3D"font-siz=
e:12.8px">I completely agree with you, having written some graphics engines=
myself. In K&R C with inline assembler, no less.</span></div><span cla=
ss=3D""><div><span style=3D"font-size:12.8px"><br></span></div><div><span s=
tyle=3D"font-size:12.8px">> Forcing them to specify a return statement o=
r open their contract will make them slower,=C2=A0</span></div><div><span s=
tyle=3D"font-size:12.8px"><br></span></div></span><div><span style=3D"font-=
size:12.8px">This is nonsense. I have provided a proposal on expressing the=
intent to not provide a return statement. You would have the same optimisa=
tion opportunities that you enjoy today.</span></div></div></blockquote><di=
v><br></div><div>Right, which I now need to transform hundreds to thousands=
of lines of code to use. No.</div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><span class=3D""><div><span style=3D"font-size:12.=
8px"><br></span></div><div><span style=3D"font-size:12.8px">> and with a=
pplications like game design, these optimizations are very important.=C2=A0=
</span></div><div><span style=3D"font-size:12.8px"><br></span></div></span>=
<div><span style=3D"font-size:12.8px">Yes, agree.</span></div><span class=
=3D""><div><span style=3D"font-size:12.8px"><br></span></div><div><span sty=
le=3D"font-size:12.8px">> I don't know how many leaf functions I hav=
e that inline perfectly, but would be hampered in these efforts by any sort=
of throw logic.</span></div><div><span style=3D"font-size:12.8px"><br></sp=
an></div></span><div><span style=3D"font-size:12.8px">No-one is arguing tha=
t you have to have any throw logic.</span></div></div></blockquote><div><br=
></div><div>It was mentioned several times in this thread. I don't exac=
tly see how else you are going to enforce these constraints at runtime othe=
rwise. It is haltingly difficult to do so at compile time, and there is abs=
olutely no way I would be behind anything that requires code changes to cur=
rently working code. And no, if you do not violate the contract, it is NOT =
BROKEN, so by enforcing these things at compile time, you WILL be breaking =
my code.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><span class=3D""><div><span style=3D"font-size:12.8px"><br></span><div =
class=3D"gmail_extra" style=3D"font-size:12.8px"><span style=3D"font-size:1=
2.8px">> C++ is all about "pay for what you use", not "pa=
y for what someone else thinks you need".</span><br></div></div><div c=
lass=3D"gmail_extra" style=3D"font-size:12.8px"><span style=3D"font-size:12=
..8px"><br></span></div></span><div class=3D"gmail_extra" style=3D"font-size=
:12.8px"><span style=3D"font-size:12.8px">Right. I don't use UB. Your g=
ame-players have no use for it either. UB in a game means random spawns, cr=
ashes, the quest didn't complete and now my 100 hours of gameplay was f=
or nothing, and other events that cause the players to throw their arms up,=
yell "what is this b*llsh*t?" and give you awful reviews on Stea=
m. I know you don't want that.</span></div><div class=3D"gmail_extra" s=
tyle=3D"font-size:12.8px"><span style=3D"font-size:12.8px"><br></span></div=
><div class=3D"gmail_extra" style=3D"font-size:12.8px"><span style=3D"font-=
size:12.8px">I'm trying to help you here...</span></div><div class=3D"g=
mail_extra" style=3D"font-size:12.8px"><span style=3D"font-size:12.8px"><br=
></span></div></div></blockquote><div><br></div><div>But you aren't bei=
ng helpful. You are forcing me to overhaul enormous amounts of code to prev=
ent errors I do not experience. I am not using UB: I am depending on my con=
tract being narrow to allow inlining and tight optimizations, and it's =
on me to ensure that is safe.</div><div><br></div><div>I don't need you=
to ensure I'm safe.</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/CAMD6iD_Ycf3a5rueBfoEkqy0azNmz2ts-Xi8=
PaF%3D8K1gQH8ucw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD_Ycf3a5r=
ueBfoEkqy0azNmz2ts-Xi8PaF%3D8K1gQH8ucw%40mail.gmail.com</a>.<br />
--f403045c10bcbd096b0560b3c5e3--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Tue, 19 Dec 2017 17:23:40 +0100
Raw View
--001a113f6476d2b6570560b3e395
Content-Type: text/plain; charset="UTF-8"
> Where is the inevitable crash in this code?
We're basically in agreement. By all means write this code, and annotate it
so that intent is expressed. The more intent we express, the better choices
a compiler can make, and the more it can inform us of our (well
intentioned) errors.
It's worth saying that the code would be better expressed as:
/// contract: a always_cstr is never null
template<class T> struct always_cstr {
always_cstr(T* psz) : sz_(psz) {
assert(sz_);
}
operator T*() const {
return sz_;
}
private:
T* sz_;
};
struct S {
S(bool b) { puts(foo(b)); }
private:
always_cstr<const char> foo(int x) {
if (x == 0) return "no";
if (x == 1) return "yes";
}
};
Total overhead, zero. Contract defined and expressed? Check!
> We do not yet have the not_reached attribute. Once we have had
not_reached available for a few years, we can consider making it compulsory.
This is the kind of thinking that keeps c++ in the dark ages compared to
any other high level language.
I'll give you one year. You don't need more.
> As an end goal, this would be a good thing.
Great! Some affirmation that preventing bugs is a good idea!
> As an immediate breaking change, there is no viable upgrade path.
Of course there is a viable upgrade path. You guys need to leave your dark
programming caves once in a while, smell the fresh air. Think positively.
i.e.
"cool! how can we make this happen", rather than,
"nah, better not. It might involve having to think a little."
On 19 December 2017 at 17:02, Edward Catmur <ed@catmur.co.uk> wrote:
>
>
> On Tuesday, 19 December 2017 15:43:22 UTC, Richard Hodges wrote:
>>
>> > In practice, good compilers will warn you that you might reach the end
>> without returning anything.
>>
>> Only if explicitly made to. This is not good enough for something so
>> important.
>>
>
> The reason that -Wreturn-type is part of -Wextra and not -Wall is that
> there is far too much existing code that would trigger the warning.
>
>
>> I think gcc is a "good compiler", but unless decorated with the right
>> command line options, allows this inevitable crash to compile without the
>> slightest concern.
>>
>> const char* foo(int x)
>> {
>> if (x == 0) return "no";
>> if (x == 1) return "yes";
>> }
>>
>
> struct S {
> S(bool b) { puts(foo(b)); }
> private:
> const char* foo(int x) { ... }
> };
>
> Where is the inevitable crash in this code?
>
>
>> Where's the harm in this alternative?
>>
>> const char* foo(int x)
>> {
>> if (x == 0) return "no";
>> if (x == 1) return "yes";
>> assert(!"if you got here, you're doomed");
>> [[not_reached]]
>> }
>>
>
> We do not yet have the not_reached attribute. Once we have had not_reached
> available for a few years, we can consider making it compulsory.
>
>
>> In a release build, no overhead at all. And we've expressed intent
>> succinctly.
>>
>> If we forget to fully express intent, the compiler can tell us. I cannot
>> imagine any rational argument why this might be construed as a bad thing.
>>
>
> As an end goal, this would be a good thing. As an immediate breaking
> change, there is no viable upgrade path.
>
>
>>
>>
>> On 19 December 2017 at 16:34, Bo Persson <b...@gmb.dk> wrote:
>>
>>> On 2017-12-19 15:12, Jan Wilmans wrote:
>>>
>>>> On 19 December 2017 at 14:58, Jake Arkinstall <jake.ar...@gmail.com
>>>> <mailto:jake.ar...@gmail.com>> wrote:
>>>>
>>>> On 19 Dec 2017 13:41, "Nicol Bolas" <jmck...@gmail.com
>>>> <mailto:jmck...@gmail.com>> wrote:
>>>>
>>>> But the compiler cannot/prove/ that any particular statement is
>>>> reachable. Not so long as there is a condition. The compiler
>>>> doesn't know what runtime values you will pass in.
>>>>
>>>> This is halting-problem levels of hard.
>>>>
>>>>
>>>> It needn't be. Simply by adding an abort, throw, or whatever to the
>>>> very end of each function if there are branches without returns (in
>>>> the absence of some code that allows the user to tell the compiler
>>>> to relax). It doesn't affect well formed functions because they have
>>>> already returned by that point. It only actually affects anything
>>>> that reaches the end without returning. As I said in a different
>>>> reply, this probably messes up with some optimisations (obviously
>>>> code size, but I'm thinking about speed), so I'm dubious, but it
>>>> certainly isn't halting-problem hard if you take into account that
>>>> post-return code does nothing.
>>>>
>>>>
>>>> I agree, the question might be: why was it specified as being UB in the
>>>> first place. About the complexity of the problem: the compiler could assume
>>>> all path are always taking at some point and that could pessimize some
>>>> optimizations that are currently done. What kind of code is currently out
>>>> there that would rely on this?
>>>>
>>>
>>> It was made UB because we cannot require the compiler to *always* detect
>>> the error. See halting-problem above.
>>>
>>> In practice, good compilers will warn you that you might reach the end
>>> without returning anything.
>>>
>>>
>>> Bo Persson
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-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/p1bben%24t86%241%40blaine.gmane.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/2469097a-ee73-46a9-
> ac6e-afc28d05236a%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2469097a-ee73-46a9-ac6e-afc28d05236a%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CALvx3hbPy2Byyn%3DphSa2QFSkr1x%3D3Kh7Re1qfr5dv1%2BjEsWv3A%40mail.gmail.com.
--001a113f6476d2b6570560b3e395
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">Where is the in=
evitable crash in this code?</span><div><span style=3D"font-size:12.8px"><b=
r></span></div><div><span style=3D"font-size:12.8px">We're basically in=
agreement. By all means write this code, and annotate it so that intent is=
expressed. The more intent we express, the better choices a compiler can m=
ake, and the more it can inform us of our (well intentioned) errors.</span>=
</div><div><span style=3D"font-size:12.8px">It's worth saying that the =
code would be better expressed as:</span></div><div><span style=3D"font-siz=
e:12.8px"><br></span></div><div><div style=3D"color:rgb(0,0,0);background-c=
olor:rgb(255,255,254);font-size:14px;line-height:21px;white-space:pre"><div=
style=3D""><span style=3D"color:rgb(0,128,0)"><font face=3D"monospace, mon=
ospace">/// contract: a always_cstr is never null</font></span></div><div s=
tyle=3D""><font face=3D"monospace, monospace"><span style=3D"color:rgb(0,0,=
255)">template</span><<span style=3D"color:rgb(0,0,255)">class</span> T&=
gt; <span style=3D"color:rgb(0,0,255)">struct</span> always_cstr {</font></=
div><div style=3D""><font face=3D"monospace, monospace"> always_cstr(T* =
psz) : sz_(psz) {</font></div><div style=3D""><font face=3D"monospace, mono=
space"> assert(sz_);</font></div><div style=3D""><font face=3D"monos=
pace, monospace"> }</font></div><font face=3D"monospace, monospace"><br>=
</font><div style=3D""><font face=3D"monospace, monospace"> <span style=
=3D"color:rgb(0,0,255)">operator</span> T*() <span style=3D"color:rgb(0,0,2=
55)">const</span> {</font></div><div style=3D""><font face=3D"monospace, mo=
nospace"> <span style=3D"color:rgb(0,0,255)">return</span> sz_;</fon=
t></div><div style=3D""><font face=3D"monospace, monospace"> }</font></d=
iv><font face=3D"monospace, monospace"><br></font><div style=3D""><font fac=
e=3D"monospace, monospace"><span style=3D"color:rgb(0,0,255)">private</span=
>:</font></div><div style=3D""><font face=3D"monospace, monospace"> T* s=
z_;</font></div><div style=3D""><font face=3D"monospace, monospace">};</fon=
t></div><font face=3D"monospace, monospace"><br></font><div style=3D""><fon=
t face=3D"monospace, monospace"><span style=3D"color:rgb(0,0,255)">struct</=
span> S {</font></div><div style=3D""><font face=3D"monospace, monospace"> =
S(<span style=3D"color:rgb(0,0,255)">bool</span> b) { puts(foo(b)); }</fon=
t></div><div style=3D""><font face=3D"monospace, monospace"><span style=3D"=
color:rgb(0,0,255)">private</span>:</font></div><div style=3D""><font face=
=3D"monospace, monospace"> always_cstr<<span style=3D"color:rgb(0,0,255=
)">const</span> <span style=3D"color:rgb(0,0,255)">char</span>> foo(<spa=
n style=3D"color:rgb(0,0,255)">int</span> x) { </font></div><div style=3D""=
><font face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255=
)">if</span> (x =3D=3D <span style=3D"color:rgb(9,136,90)">0</span>) <span =
style=3D"color:rgb(0,0,255)">return</span> <span style=3D"color:rgb(163,21,=
21)">"no"</span>;</font></div><div style=3D""><font face=3D"monos=
pace, monospace"> <span style=3D"color:rgb(0,0,255)">if</span> (x =3D=
=3D <span style=3D"color:rgb(9,136,90)">1</span>) <span style=3D"color:rgb(=
0,0,255)">return</span> <span style=3D"color:rgb(163,21,21)">"yes"=
;</span>;</font></div><div style=3D""><font face=3D"monospace, monospace"> =
}</font></div><div style=3D""><font face=3D"monospace, monospace">};</fon=
t></div><br></div></div><div><span style=3D"font-size:12.8px">Total overhea=
d, zero. Contract defined and expressed? Check!=C2=A0</span></div><div><spa=
n style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size=
:12.8px">>=C2=A0</span><span style=3D"font-size:12.8px">We do not yet ha=
ve the not_reached attribute. Once we have had not_reached available for a =
few years, we can consider making it compulsory.</span></div><div><span sty=
le=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8=
px">This is the kind of thinking that keeps c++ in the dark ages compared t=
o any other high level language.</span></div><div><span style=3D"font-size:=
12.8px"><br></span></div><div><span style=3D"font-size:12.8px">I'll giv=
e you one year. You don't need more.</span></div><div><span style=3D"fo=
nt-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">>=
=C2=A0</span><span style=3D"font-size:12.8px">As an end goal, this would be=
a good thing.=C2=A0</span></div><div><span style=3D"font-size:12.8px"><br>=
</span></div><div><span style=3D"font-size:12.8px">Great! Some affirmation =
that preventing bugs is a good idea!</span></div><div><span style=3D"font-s=
ize:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">> As =
an immediate breaking change, there is no viable upgrade path.=C2=A0</span>=
</div><div><span style=3D"font-size:12.8px"><br></span></div><div><span sty=
le=3D"font-size:12.8px">Of course there is a viable upgrade path. You guys =
need to leave your dark programming caves once in a while, smell the fresh =
air. Think positively.=C2=A0</span></div><div><br></div><div>i.e.</div><div=
><br></div><div>"cool! how can we make this happen", rather than,=
</div><div><br></div><div>"nah, better not. It might involve having to=
think a little."</div><div><br></div><div><span style=3D"font-size:12=
..8px"><br></span></div></div><div class=3D"gmail_extra"><br><div class=3D"g=
mail_quote">On 19 December 2017 at 17:02, Edward Catmur <span dir=3D"ltr">&=
lt;<a href=3D"mailto:ed@catmur.co.uk" target=3D"_blank">ed@catmur.co.uk</a>=
></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span=
class=3D""><br><br>On Tuesday, 19 December 2017 15:43:22 UTC, Richard Hodg=
es wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">>=C2=
=A0<span style=3D"font-size:12.8px">In practice, good compilers will warn y=
ou that you might reach the end without returning anything.</span><div><spa=
n style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size=
:12.8px">Only if explicitly made to. This is not good enough for something =
so important.</span></div></div></blockquote><div><br></div></span><div>The=
reason that -Wreturn-type is part of -Wextra and not -Wall is that there i=
s far too much existing code that would trigger the warning.</div><span cla=
ss=3D""><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div><span style=3D"font-size:12.8px"></span><div>I think gcc is a=
"good compiler", but unless decorated with the right command lin=
e options, allows this inevitable crash to compile without the slightest co=
ncern.<br></div></div><div><br></div><div><div style=3D"color:rgb(0,0,0);ba=
ckground-color:rgb(255,255,254);font-size:14px;line-height:21px;white-space=
:pre-wrap"><div><span style=3D"font-family:monospace,monospace;color:rgb(0,=
0,255)">const</span><span style=3D"font-family:monospace,monospace"> </span=
><span style=3D"font-family:monospace,monospace;color:rgb(0,0,255)">char</s=
pan><span style=3D"font-family:monospace,monospace">* foo(</span><span styl=
e=3D"font-family:monospace,monospace;color:rgb(0,0,255)">int</span><span st=
yle=3D"font-family:monospace,monospace"> x)</span><br></div><div><font face=
=3D"monospace, monospace">{</font></div><div><font face=3D"monospace, monos=
pace"> <span style=3D"color:rgb(0,0,255)">if</span> (x =3D=3D <span styl=
e=3D"color:rgb(9,136,90)">0</span>) <span style=3D"color:rgb(0,0,255)">retu=
rn</span> <span style=3D"color:rgb(163,21,21)">"no"</span>;</font=
></div><div><font face=3D"monospace, monospace"> <span style=3D"color:rg=
b(0,0,255)">if</span> (x =3D=3D <span style=3D"color:rgb(9,136,90)">1</span=
>) <span style=3D"color:rgb(0,0,255)">return</span> <span style=3D"color:rg=
b(163,21,21)">"yes"</span>;</font></div><div><font face=3D"monosp=
ace, monospace">}</font></div></div></div></div></blockquote><div><br></div=
></span><div class=3D"m_3645300703562822081prettyprint" style=3D"background=
-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;bo=
rder-width:1px;word-wrap:break-word"><code class=3D"m_3645300703562822081pr=
ettyprint"><div class=3D"m_3645300703562822081subprettyprint"><span style=
=3D"color:#008" class=3D"m_3645300703562822081styled-by-prettify">struct</s=
pan><span style=3D"color:#000" class=3D"m_3645300703562822081styled-by-pret=
tify"> S </span><span style=3D"color:#660" class=3D"m_3645300703562822081st=
yled-by-prettify">{</span><span style=3D"color:#000" class=3D"m_36453007035=
62822081styled-by-prettify"><br>=C2=A0 S</span><span style=3D"color:#660" c=
lass=3D"m_3645300703562822081styled-by-prettify">(</span><span style=3D"col=
or:#008" class=3D"m_3645300703562822081styled-by-prettify">bool</span><span=
style=3D"color:#000" class=3D"m_3645300703562822081styled-by-prettify"> b<=
/span><span style=3D"color:#660" class=3D"m_3645300703562822081styled-by-pr=
ettify">)</span><span style=3D"color:#000" class=3D"m_3645300703562822081st=
yled-by-prettify"> </span><span style=3D"color:#660" class=3D"m_36453007035=
62822081styled-by-prettify">{</span><span style=3D"color:#000" class=3D"m_3=
645300703562822081styled-by-prettify"> puts</span><span style=3D"color:#660=
" class=3D"m_3645300703562822081styled-by-prettify">(</span><span style=3D"=
color:#000" class=3D"m_3645300703562822081styled-by-prettify">foo</span><sp=
an style=3D"color:#660" class=3D"m_3645300703562822081styled-by-prettify">(=
</span><span style=3D"color:#000" class=3D"m_3645300703562822081styled-by-p=
rettify">b</span><span style=3D"color:#660" class=3D"m_3645300703562822081s=
tyled-by-prettify">));</span><span style=3D"color:#000" class=3D"m_36453007=
03562822081styled-by-prettify"> </span><span style=3D"color:#660" class=3D"=
m_3645300703562822081styled-by-prettify">}</span><span style=3D"color:#000"=
class=3D"m_3645300703562822081styled-by-prettify"><br></span><span style=
=3D"color:#008" class=3D"m_3645300703562822081styled-by-prettify">private</=
span><span style=3D"color:#660" class=3D"m_3645300703562822081styled-by-pre=
ttify">:</span><span style=3D"color:#000" class=3D"m_3645300703562822081sty=
led-by-prettify"><br>=C2=A0 </span><span style=3D"color:#008" class=3D"m_36=
45300703562822081styled-by-prettify">const</span><span style=3D"color:#000"=
class=3D"m_3645300703562822081styled-by-prettify"> </span><span style=3D"c=
olor:#008" class=3D"m_3645300703562822081styled-by-prettify">char</span><sp=
an style=3D"color:#660" class=3D"m_3645300703562822081styled-by-prettify">*=
</span><span style=3D"color:#000" class=3D"m_3645300703562822081styled-by-p=
rettify"> foo</span><span style=3D"color:#660" class=3D"m_36453007035628220=
81styled-by-prettify">(</span><span style=3D"color:#008" class=3D"m_3645300=
703562822081styled-by-prettify">int</span><span style=3D"color:#000" class=
=3D"m_3645300703562822081styled-by-prettify"> x</span><span style=3D"color:=
#660" class=3D"m_3645300703562822081styled-by-prettify">)</span><span style=
=3D"color:#000" class=3D"m_3645300703562822081styled-by-prettify"> </span><=
span style=3D"color:#660" class=3D"m_3645300703562822081styled-by-prettify"=
>{</span><span style=3D"color:#000" class=3D"m_3645300703562822081styled-by=
-prettify"> </span><span style=3D"color:#660" class=3D"m_364530070356282208=
1styled-by-prettify">...</span><span style=3D"color:#000" class=3D"m_364530=
0703562822081styled-by-prettify"> </span><span style=3D"color:#660" class=
=3D"m_3645300703562822081styled-by-prettify">}</span><span style=3D"color:#=
000" class=3D"m_3645300703562822081styled-by-prettify"><br></span><span sty=
le=3D"color:#660" class=3D"m_3645300703562822081styled-by-prettify">};</spa=
n></div></code></div><div><br></div><div>Where is the inevitable crash in t=
his code?</div><span class=3D""><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div>Where's the harm in this alternativ=
e?</div><div><br></div><div><div style=3D"color:rgb(0,0,0);font-size:14px;w=
hite-space:pre-wrap"><span style=3D"font-family:monospace,monospace;color:r=
gb(0,0,255)">const</span><span style=3D"font-family:monospace,monospace"> <=
/span><span style=3D"font-family:monospace,monospace;color:rgb(0,0,255)">ch=
ar</span><span style=3D"font-family:monospace,monospace">* foo(</span><span=
style=3D"font-family:monospace,monospace;color:rgb(0,0,255)">int</span><sp=
an style=3D"font-family:monospace,monospace"> x)</span><br></div><div style=
=3D"color:rgb(0,0,0);font-size:14px;white-space:pre-wrap"><font face=3D"mon=
ospace, monospace">{</font></div><div style=3D"color:rgb(0,0,0);font-size:1=
4px;white-space:pre-wrap"><font face=3D"monospace, monospace"> <span sty=
le=3D"color:rgb(0,0,255)">if</span> (x =3D=3D <span style=3D"color:rgb(9,13=
6,90)">0</span>) <span style=3D"color:rgb(0,0,255)">return</span> <span sty=
le=3D"color:rgb(163,21,21)">"no"</span>;</font></div><div style=
=3D"color:rgb(0,0,0);font-size:14px;white-space:pre-wrap"><font face=3D"mon=
ospace, monospace"> <span style=3D"color:rgb(0,0,255)">if</span> (x =3D=
=3D <span style=3D"color:rgb(9,136,90)">1</span>) <span style=3D"color:rgb(=
0,0,255)">return</span> <span style=3D"color:rgb(163,21,21)">"yes"=
;</span>;</font></div><div style=3D"color:rgb(0,0,0);font-size:14px;white-s=
pace:pre-wrap"><font face=3D"monospace, monospace"> assert(!"if you=
got here, you're doomed");</font></div><div style=3D"color:rgb(0,=
0,0);font-size:14px;white-space:pre-wrap"><font face=3D"monospace, monospac=
e"> [[not_reached]]</font></div><div style=3D"color:rgb(0,0,0);font-size=
:14px;white-space:pre-wrap"><font face=3D"monospace, monospace">}</font></d=
iv></div></div></blockquote><div><br></div></span><div>We do not yet have t=
he not_reached attribute. Once we have had not_reached available for a few =
years, we can consider making it compulsory.</div><span class=3D""><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><fon=
t face=3D"monospace, monospace"></font></div><div>In a release build, no ov=
erhead at all. And we've expressed intent succinctly.</div><div><br></d=
iv><div>If we forget to fully express intent, the compiler can tell us. I c=
annot imagine any rational argument why this might be construed as a bad th=
ing.</div></div></blockquote><div><br></div></span><div>As an end goal, thi=
s would be a good thing. As an immediate breaking change, there is no viabl=
e upgrade path.=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div></div><div><br></div></div><div><br><div cla=
ss=3D"gmail_quote"><span class=3D"">On 19 December 2017 at 16:34, Bo Persso=
n <span dir=3D"ltr"><<a rel=3D"nofollow">b...@gmb.dk</a>></span> wrot=
e:<br></span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 2017-12-19 =
15:12, Jan Wilmans wrote:<br>
</span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><span>
On 19 December 2017 at 14:58, Jake Arkinstall <<a rel=3D"nofollow">jake.=
ar...@gmail.com</a> <mailto:<a rel=3D"nofollow">jake.ar...@gmail.com</a>=
>> wrote:<br>
<br>
=C2=A0 =C2=A0 On 19 Dec 2017 13:41, "Nicol Bolas" <<a rel=3D"n=
ofollow">jmck...@gmail.com</a><br></span><span class=3D"">
=C2=A0 =C2=A0 <mailto:<a rel=3D"nofollow">jmck...@gmail.com</a>>> =
wrote:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 But the compiler cannot/prove/ that any particu=
lar statement is<span><br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reachable. Not so long as there is a condition.=
The compiler<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 doesn't know what runtime values you will p=
ass in.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 This is halting-problem levels of hard.<br>
<br>
<br>
=C2=A0 =C2=A0 It needn't be. Simply by adding an abort, throw, or whate=
ver to the<br>
=C2=A0 =C2=A0 very end of each function if there are branches without retur=
ns (in<br>
=C2=A0 =C2=A0 the absence of some code that allows the user to tell the com=
piler<br>
=C2=A0 =C2=A0 to relax). It doesn't affect well formed functions becaus=
e they have<br>
=C2=A0 =C2=A0 already returned by that point. It only actually affects anyt=
hing<br>
=C2=A0 =C2=A0 that reaches the end without returning. As I said in a differ=
ent<br>
=C2=A0 =C2=A0 reply, this probably messes up with some optimisations (obvio=
usly<br>
=C2=A0 =C2=A0 code size, but I'm thinking about speed), so I'm dubi=
ous, but it<br>
=C2=A0 =C2=A0 certainly isn't halting-problem hard if you take into acc=
ount that<br>
=C2=A0 =C2=A0 post-return code does nothing.<br>
<br>
<br>
I agree, the question might be: why was it specified as being UB in the fir=
st place. About the complexity of the problem: the compiler could assume al=
l path are always taking at some point and that could pessimize some optimi=
zations that are currently done. What kind of code is currently out there t=
hat would rely on this?<br>
</span></span></blockquote><span class=3D"">
<br>
It was made UB because we cannot require the compiler to *always* detect th=
e error. See halting-problem above.<br>
<br>
In practice, good compilers will warn you that you might reach the end with=
out returning anything.<br>
<br>
<br>
=C2=A0 =C2=A0 Bo Persson</span><span><span class=3D""><br>
<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></span>
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></span><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/p1bben%24t86%241%40blaine.gmane.org" =
rel=3D"nofollow" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.=
org/d/msgid/std-proposals<wbr>/p1bben%24t86%241%40blaine.<wbr>gmane.org</a>=
..<br>
</span></blockquote></div><br></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/2469097a-ee73-46a9-ac6e-afc28d05236a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/2469=
097a-ee73-46a9-<wbr>ac6e-afc28d05236a%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/CALvx3hbPy2Byyn%3DphSa2QFSkr1x%3D3Kh7=
Re1qfr5dv1%2BjEsWv3A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hbPy2=
Byyn%3DphSa2QFSkr1x%3D3Kh7Re1qfr5dv1%2BjEsWv3A%40mail.gmail.com</a>.<br />
--001a113f6476d2b6570560b3e395--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Tue, 19 Dec 2017 17:29:52 +0100
Raw View
--001a11448e4efe6e930560b3f923
Content-Type: text/plain; charset="UTF-8"
> Right, which I now need to transform hundreds to thousands of lines of
code to use. No.
This is a complete over-exaggeration. You do not have hundreds of thousands
of lines of code in which there is a function with a return type defined,
but some code paths don't return a value. I'll bet you 20 bucks that you
won't find more than 20 in your entire code base.
In any case, the compiler could show you where each of these potential
danger spots were.
Your cheapest, dumbest and ugliest intern could then put the characters
"[[not_reached]]" into their paste buffer, hit F2 followed by ctrl-v 20
times, exit the editor, git commit -am "annotated functions with no_return"
&& git push.
End of problem.
5 minutes.
And what if this idiot intern actually found that one of your functions
were in error? Maybe your game's fan base would see you in a better light
after you fixed the "last but one quest won't complete" bug.
On 19 December 2017 at 17:15, Ren Industries <renindustries@gmail.com>
wrote:
>
> > Performance is absolutely an argument; having narrow contracts on
>> small, inlinable functions makes them very fast and efficient (in many
>> cases, with small switch statements or for loops, they can be compiled down
>> to 2-3 instructions even).
>>
>> I completely agree with you, having written some graphics engines myself.
>> In K&R C with inline assembler, no less.
>>
>> > Forcing them to specify a return statement or open their contract will
>> make them slower,
>>
>> This is nonsense. I have provided a proposal on expressing the intent to
>> not provide a return statement. You would have the same optimisation
>> opportunities that you enjoy today.
>>
>
> Right, which I now need to transform hundreds to thousands of lines of
> code to use. No.
>
>
>>
>> > and with applications like game design, these optimizations are very
>> important.
>>
>> Yes, agree.
>>
>> > I don't know how many leaf functions I have that inline perfectly, but
>> would be hampered in these efforts by any sort of throw logic.
>>
>> No-one is arguing that you have to have any throw logic.
>>
>
> It was mentioned several times in this thread. I don't exactly see how
> else you are going to enforce these constraints at runtime otherwise. It is
> haltingly difficult to do so at compile time, and there is absolutely no
> way I would be behind anything that requires code changes to currently
> working code. And no, if you do not violate the contract, it is NOT BROKEN,
> so by enforcing these things at compile time, you WILL be breaking my code.
>
>
>>
>> > C++ is all about "pay for what you use", not "pay for what someone else
>> thinks you need".
>>
>> Right. I don't use UB. Your game-players have no use for it either. UB in
>> a game means random spawns, crashes, the quest didn't complete and now my
>> 100 hours of gameplay was for nothing, and other events that cause the
>> players to throw their arms up, yell "what is this b*llsh*t?" and give you
>> awful reviews on Steam. I know you don't want that.
>>
>> I'm trying to help you here...
>>
>>
> But you aren't being helpful. You are forcing me to overhaul enormous
> amounts of code to prevent errors I do not experience. I am not using UB: I
> am depending on my contract being narrow to allow inlining and tight
> optimizations, and it's on me to ensure that is safe.
>
> I don't need you to ensure I'm safe.
>
> --
> 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/CAMD6iD_Ycf3a5rueBfoEkqy0azNmz2ts-
> Xi8PaF%3D8K1gQH8ucw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD_Ycf3a5rueBfoEkqy0azNmz2ts-Xi8PaF%3D8K1gQH8ucw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CALvx3hZ2tEU%2Bz6A8q1k2DHtx-hOGmapnJwmr1FUz77kYwZ0ZaA%40mail.gmail.com.
--001a11448e4efe6e930560b3f923
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">Right, which I =
now need to transform hundreds to thousands of lines of code to use. No.</s=
pan><div><span style=3D"font-size:12.8px"><br></span></div><div><span style=
=3D"font-size:12.8px">This is a complete over-exaggeration. You do not have=
hundreds of thousands of lines of code in which there is a function with a=
return type defined, but some code paths don't return a value. I'l=
l bet you 20 bucks that you won't find more than 20 in your entire code=
base.</span></div><div><span style=3D"font-size:12.8px"><br></span></div><=
div><span style=3D"font-size:12.8px">In any case, the compiler could show y=
ou where each of these potential danger spots were.</span></div><div><span =
style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:1=
2.8px">Your cheapest, dumbest and ugliest intern could then put the charact=
ers "[[not_reached]]" into their paste buffer, hit F2 followed by=
ctrl-v 20 times, exit the editor, git commit -am "annotated functions=
with no_return" && git push.<br><br>End of problem.</span></d=
iv><div><span style=3D"font-size:12.8px"><br></span></div><div><span style=
=3D"font-size:12.8px">5 minutes.</span></div><div><span style=3D"font-size:=
12.8px"><br></span></div><div><span style=3D"font-size:12.8px">And what if =
this idiot intern actually found that one of your functions were in error? =
Maybe your game's fan base would see you in a better light after you fi=
xed the "last but one quest won't complete" bug.</span></div>=
<div><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"=
font-size:12.8px"><br></span></div></div><div class=3D"gmail_extra"><br><di=
v class=3D"gmail_quote">On 19 December 2017 at 17:15, Ren Industries <span =
dir=3D"ltr"><<a href=3D"mailto:renindustries@gmail.com" target=3D"_blank=
">renindustries@gmail.com</a>></span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><span class=3D""><br><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><sp=
an>>=C2=A0<span style=3D"font-size:12.8px">Performance is absolutely an =
argument; having narrow contracts on small, inlinable functions makes them =
very fast and efficient (in many cases, with small switch statements or for=
loops, they can be compiled down to 2-3 instructions even).=C2=A0</span><d=
iv><span style=3D"font-size:12.8px"><br></span></div></span><div><span styl=
e=3D"font-size:12.8px">I completely agree with you, having written some gra=
phics engines myself. In K&R C with inline assembler, no less.</span></=
div><span><div><span style=3D"font-size:12.8px"><br></span></div><div><span=
style=3D"font-size:12.8px">> Forcing them to specify a return statement=
or open their contract will make them slower,=C2=A0</span></div><div><span=
style=3D"font-size:12.8px"><br></span></div></span><div><span style=3D"fon=
t-size:12.8px">This is nonsense. I have provided a proposal on expressing t=
he intent to not provide a return statement. You would have the same optimi=
sation opportunities that you enjoy today.</span></div></div></blockquote><=
div><br></div></span><div>Right, which I now need to transform hundreds to =
thousands of lines of code to use. No.</div><span class=3D""><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span><div><span style=
=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px=
">> and with applications like game design, these optimizations are very=
important.=C2=A0</span></div><div><span style=3D"font-size:12.8px"><br></s=
pan></div></span><div><span style=3D"font-size:12.8px">Yes, agree.</span></=
div><span><div><span style=3D"font-size:12.8px"><br></span></div><div><span=
style=3D"font-size:12.8px">> I don't know how many leaf functions I=
have that inline perfectly, but would be hampered in these efforts by any =
sort of throw logic.</span></div><div><span style=3D"font-size:12.8px"><br>=
</span></div></span><div><span style=3D"font-size:12.8px">No-one is arguing=
that you have to have any throw logic.</span></div></div></blockquote><div=
><br></div></span><div>It was mentioned several times in this thread. I don=
't exactly see how else you are going to enforce these constraints at r=
untime otherwise. It is haltingly difficult to do so at compile time, and t=
here is absolutely no way I would be behind anything that requires code cha=
nges to currently working code. And no, if you do not violate the contract,=
it is NOT BROKEN, so by enforcing these things at compile time, you WILL b=
e breaking my code.</div><span class=3D""><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><span><div><span style=3D"font-size:12.8px"=
><br></span><div class=3D"gmail_extra" style=3D"font-size:12.8px"><span sty=
le=3D"font-size:12.8px">> C++ is all about "pay for what you use&qu=
ot;, not "pay for what someone else thinks you need".</span><br><=
/div></div><div class=3D"gmail_extra" style=3D"font-size:12.8px"><span styl=
e=3D"font-size:12.8px"><br></span></div></span><div class=3D"gmail_extra" s=
tyle=3D"font-size:12.8px"><span style=3D"font-size:12.8px">Right. I don'=
;t use UB. Your game-players have no use for it either. UB in a game means =
random spawns, crashes, the quest didn't complete and now my 100 hours =
of gameplay was for nothing, and other events that cause the players to thr=
ow their arms up, yell "what is this b*llsh*t?" and give you awfu=
l reviews on Steam. I know you don't want that.</span></div><div class=
=3D"gmail_extra" style=3D"font-size:12.8px"><span style=3D"font-size:12.8px=
"><br></span></div><div class=3D"gmail_extra" style=3D"font-size:12.8px"><s=
pan style=3D"font-size:12.8px">I'm trying to help you here...</span></d=
iv><div class=3D"gmail_extra" style=3D"font-size:12.8px"><span style=3D"fon=
t-size:12.8px"><br></span></div></div></blockquote><div><br></div></span><d=
iv>But you aren't being helpful. You are forcing me to overhaul enormou=
s amounts of code to prevent errors I do not experience. I am not using UB:=
I am depending on my contract being narrow to allow inlining and tight opt=
imizations, and it's on me to ensure that is safe.</div><div><br></div>=
<div>I don't need you to ensure I'm safe.</div></div></div></div><s=
pan 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/CAMD6iD_Ycf3a5rueBfoEkqy0azNmz2ts-Xi8=
PaF%3D8K1gQH8ucw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/CAMD6iD_<wbr>Ycf3a5rueBfoEkqy0azNmz2ts-<wbr>Xi8PaF%3D8K1gQ=
H8ucw%40mail.<wbr>gmail.com</a>.<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/CALvx3hZ2tEU%2Bz6A8q1k2DHtx-hOGmapnJw=
mr1FUz77kYwZ0ZaA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ2tEU%2B=
z6A8q1k2DHtx-hOGmapnJwmr1FUz77kYwZ0ZaA%40mail.gmail.com</a>.<br />
--001a11448e4efe6e930560b3f923--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Tue, 19 Dec 2017 19:37:08 +0300
Raw View
On 12/19/17 16:42, Richard Hodges wrote:
>=20
>=20
> On Tuesday, 19 December 2017 14:00:07 UTC+1, Andrey Semashev wrote:
>=20
> On 12/19/17 15:54, Richard Hodges wrote:
> >
> > In short, if your function says it returns something, it must retu=
rn
> > something, otherwise compilation error. Anything other outcome is =
a
> > hard-to-track bug in waiting.
> >
> > Thoughts?
>=20
> Sometimes it is difficult to say if the UB actually happens.
>=20
> =C2=A0 =C2=A0int foo(int x)
> =C2=A0 =C2=A0{
> =C2=A0 =C2=A0 =C2=A0switch (x)
> =C2=A0 =C2=A0 =C2=A0{
> =C2=A0 =C2=A0 =C2=A0case 0:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0return 10;
> =C2=A0 =C2=A0 =C2=A0case 1:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0return 20;
> =C2=A0 =C2=A0 =C2=A0}
> =C2=A0 =C2=A0}
>=20
> The compiler cannot tell if the function is ever called with x other
> than 0 or 1. Adding a `default:` section with some fallback code migh=
t
> mean pessimizing the code and `[[unreachable]]`, as any other
> attribute,
> is not required to have any effect (and even if it does, it is still
> UB).
>=20
> The example above is simply a transform with constrained inputs. If you=
=20
> want UB you can code for it with no overhead:
>=20
> =C2=A0 =C2=A0int foo(int x)
> =C2=A0 =C2=A0{
> =C2=A0 =C2=A0 =C2=A0// express preconditions...
> =C2=A0 =C2=A0 =C2=A0assert(x =3D=3D 0 or x =3D=3D 1);
assert is a no-op in release builds.
> =C2=A0 =C2=A0 =C2=A0// transform
> =C2=A0 =C2=A0 =C2=A0switch (x)
> =C2=A0 =C2=A0 =C2=A0{
> =C2=A0 =C2=A0 =C2=A0case 0:=C2=A0x =3D 10;
> =C2=A0 =C2=A0 =C2=A0case 1:=C2=A0x =3D=C2=A020;
> =C2=A0 =C2=A0 =C2=A0}
>=20
> =C2=A0 =C2=A0 =C2=A0// always return something
> =C2=A0 =C2=A0 =C2=A0return x;=C2=A0 // now we're always returning someth=
ing but have=20
> deliberately preserved the UB for the sake of 'performance'
> =C2=A0 =C2=A0}
The above transformation utilises the fact that the return type is the=20
same as `x`, which, of course, is not always the case.
Returning "something" may be not possible (if the returned type cannot=20
be default-constructed) or not reasonable/expensive. It also requires=20
the compiler to generate code that is otherwise not needed, which=20
affects code size and possibly inlinability.
--=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/10981332-a791-aa03-dd22-67cd56716f34%40gmail.com=
..
.
Author: Ren Industries <renindustries@gmail.com>
Date: Tue, 19 Dec 2017 11:40:47 -0500
Raw View
--94eb2c0c43760ed3030560b4211a
Content-Type: text/plain; charset="UTF-8"
> > Right, which I now need to transform hundreds to thousands of lines of
> code to use. No.
>
> This is a complete over-exaggeration. You do not have hundreds of
> thousands of lines of code in which there is a function with a return type
> defined, but some code paths don't return a value. I'll bet you 20 bucks
> that you won't find more than 20 in your entire code base.
>
I found well over 200; I use heavily templated code, these sorts of idioms
occur often and Clang already annoys me complaining about it.
>
> In any case, the compiler could show you where each of these potential
> danger spots were.
>
Sure. But it still doesn't change that those "potential" danger spots are
not "real" danger spots.
>
> Your cheapest, dumbest and ugliest intern could then put the characters
> "[[not_reached]]" into their paste buffer, hit F2 followed by ctrl-v 20
> times, exit the editor, git commit -am "annotated functions with no_return"
> && git push.
>
> End of problem.
>
> 5 minutes.
>
Haha. No. To change this would take me well over an hour, then I'd need to
get permission to merge it, we'd need to run all sorts of tests to prove
there isn't a compiler error, etc etc. Sorry, not all shops are as open to
experimentation as you...for good reason.
>
> And what if this idiot intern actually found that one of your functions
> were in error? Maybe your game's fan base would see you in a better light
> after you fixed the "last but one quest won't complete" bug.
>
>
I'm quite sure they'd prefer a working solution with more enhancements than
time spent adding code that doesn't have any impact on the end result.
Every minute spent on patching code that is already working, and working
perfectly fine, is wasted.
--
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/CAMD6iD_QJcVVgABsMkxZ1B6jaXAT7kynUFJ8DY%2BFnjZQQO-hWA%40mail.gmail.com.
--94eb2c0c43760ed3030560b4211a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">>=C2=A0=
<span style=3D"font-size:12.8px">Right, which I now need to transform hundr=
eds to thousands of lines of code to use. No.</span><div><span style=3D"fon=
t-size:12.8px"><br></span></div></span><div><span style=3D"font-size:12.8px=
">This is a complete over-exaggeration. You do not have hundreds of thousan=
ds of lines of code in which there is a function with a return type defined=
, but some code paths don't return a value. I'll bet you 20 bucks t=
hat you won't find more than 20 in your entire code base.</span></div><=
/div></blockquote><div><br></div><div>I found well over 200; I use heavily =
templated code, these sorts of idioms occur often and Clang already annoys =
me complaining about it.</div><div>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div><span style=3D"font-size:12.8px"><br></span></div>=
<div><span style=3D"font-size:12.8px">In any case, the compiler could show =
you where each of these potential danger spots were.</span></div></div></bl=
ockquote><div><br></div><div>Sure. But it still doesn't change that tho=
se "potential" danger spots are not "real" danger spots=
..</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"fon=
t-size:12.8px">Your cheapest, dumbest and ugliest intern could then put the=
characters "[[not_reached]]" into their paste buffer, hit F2 fol=
lowed by ctrl-v 20 times, exit the editor, git commit -am "annotated f=
unctions with no_return" && git push.<br><br>End of problem.</=
span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><spa=
n style=3D"font-size:12.8px">5 minutes.</span></div></div></blockquote><div=
><br></div><div>Haha. No. To change this would take me well over an hour, t=
hen I'd need to get permission to merge it, we'd need to run all so=
rts of tests to prove there isn't a compiler error, etc etc. Sorry, not=
all shops are as open to experimentation as you...for good reason.</div><d=
iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><span s=
tyle=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12=
..8px">And what if this idiot intern actually found that one of your functio=
ns were in error? Maybe your game's fan base would see you in a better =
light after you fixed the "last but one quest won't complete"=
bug.</span></div><div><span style=3D"font-size:12.8px"><br></span></div></=
div></blockquote><div><br></div><div>I'm quite sure they'd prefer a=
working solution with more enhancements than time spent adding code that d=
oesn't have any impact on the end result.</div><div>Every minute spent =
on patching code that is already working, and working perfectly fine, is wa=
sted.</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/CAMD6iD_QJcVVgABsMkxZ1B6jaXAT7kynUFJ8=
DY%2BFnjZQQO-hWA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD_QJcVVgA=
BsMkxZ1B6jaXAT7kynUFJ8DY%2BFnjZQQO-hWA%40mail.gmail.com</a>.<br />
--94eb2c0c43760ed3030560b4211a--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 19 Dec 2017 08:42:45 -0800 (PST)
Raw View
------=_Part_29681_137791837.1513701765569
Content-Type: multipart/alternative;
boundary="----=_Part_29682_1171070775.1513701765569"
------=_Part_29682_1171070775.1513701765569
Content-Type: text/plain; charset="UTF-8"
On Tuesday, December 19, 2017 at 11:23:43 AM UTC-5, Richard Hodges wrote:
>
> > We do not yet have the not_reached attribute. Once we have had
> not_reached available for a few years, we can consider making it compulsory.
>
> This is the kind of thinking that keeps c++ in the dark ages compared to
> any other high level language.
>
Right, because if you don't do things exactly the way I say they should be
done, then you're in the dark ages.
Please stop making such arguments. They're not helpful towards actually
getting something useful done.
I'll give you one year. You don't need more.
>
That is even less helpful.
>
--
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/330fd349-148c-4c7c-a1af-d46d3e6aa782%40isocpp.org.
------=_Part_29682_1171070775.1513701765569
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, December 19, 2017 at 11:23:43 AM UTC-5=
, Richard Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><div><span style=3D"font-size:12.8px">>=C2=A0</span><span styl=
e=3D"font-size:12.8px">We do not yet have the not_reached attribute. Once w=
e have had not_reached available for a few years, we can consider making it=
compulsory.</span></div><div><span style=3D"font-size:12.8px"><br></span><=
/div><div><span style=3D"font-size:12.8px">This is the kind of thinking tha=
t keeps c++ in the dark ages compared to any other high level language.</sp=
an></div></div></blockquote><div><br></div><div>Right, because if you don&#=
39;t do things exactly the way I say they should be done, then you're i=
n the dark ages.</div><div><br></div><div>Please stop making such arguments=
.. They're not helpful towards actually getting something useful done.</=
div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div><span style=3D"font-size:12.8px">I'll give you one year. You=
don't need more.</span></div></div></blockquote><div><br></div><div>Th=
at is even less helpful.<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">
</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/330fd349-148c-4c7c-a1af-d46d3e6aa782%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/330fd349-148c-4c7c-a1af-d46d3e6aa782=
%40isocpp.org</a>.<br />
------=_Part_29682_1171070775.1513701765569--
------=_Part_29681_137791837.1513701765569--
.
Author: Dilip Ranganathan <misc.usage@gmail.com>
Date: Tue, 19 Dec 2017 12:42:48 -0500
Raw View
--001a113a870adb56140560b4fe27
Content-Type: text/plain; charset="UTF-8"
On Tue, Dec 19, 2017 at 10:02 AM, Richard Hodges <hodges.r@gmail.com> wrote:
>
>> Yes, once I am convinced that it's not going to be pushed back with:
>
> "We can't make the language safer, it might annoy some die-hard UB-lovers",
> "We can't break broken code",
> "We can't make attributes do anything"
>
> You remind me of someone who frequents this chat and who happens to be my
mentor too :-)
If I didn't know any better, I was almost left wondering if he is posting
under an alias!
--
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/CALEPxfsQ4x7mKpuevu2_oqZR83s2WScsyeA2maZ96WypHAmEWg%40mail.gmail.com.
--001a113a870adb56140560b4fe27
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, Dec 19, 2017 at 10:02 AM, Richard Hodges <span dir=3D"ltr"><<a h=
ref=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span =
class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"lt=
r"><br></div></blockquote><div>Yes, once I am convinced that it's not g=
oing to be pushed back with:<br></div></span><div><br></div><div>"We c=
an't make the language safer, it might annoy some die-hard UB-lovers&qu=
ot;,</div><div>"We can't break broken code",</div><div>"=
We can't make attributes do anything"</div><div><br></div></div></=
blockquote><div>You remind me of someone who frequents this chat and who ha=
ppens to be my mentor too :-)</div><div>If I didn't know any better, I =
was almost left wondering if he is posting under an alias!</div><div>=C2=A0=
</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/CALEPxfsQ4x7mKpuevu2_oqZR83s2WScsyeA2=
maZ96WypHAmEWg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALEPxfsQ4x7mKpue=
vu2_oqZR83s2WScsyeA2maZ96WypHAmEWg%40mail.gmail.com</a>.<br />
--001a113a870adb56140560b4fe27--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Tue, 19 Dec 2017 18:43:18 +0100
Raw View
--001a113fbc0899f1600560b5001e
Content-Type: text/plain; charset="UTF-8"
Nicol,
OK, let's reset and focus.
Do we agree that preventing inadvertent UB is a good thing in principle?
On 19 December 2017 at 17:42, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Tuesday, December 19, 2017 at 11:23:43 AM UTC-5, Richard Hodges wrote:
>>
>> > We do not yet have the not_reached attribute. Once we have had
>> not_reached available for a few years, we can consider making it compulsory.
>>
>> This is the kind of thinking that keeps c++ in the dark ages compared to
>> any other high level language.
>>
>
> Right, because if you don't do things exactly the way I say they should be
> done, then you're in the dark ages.
>
> Please stop making such arguments. They're not helpful towards actually
> getting something useful done.
>
> I'll give you one year. You don't need more.
>>
>
> That is even less helpful.
>
>> --
> 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/330fd349-148c-4c7c-
> a1af-d46d3e6aa782%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/330fd349-148c-4c7c-a1af-d46d3e6aa782%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CALvx3hZ93%3DYzYp3ULxzKdzn9h_OMX%2BH-32%2B%2Bu%2B3RSvNtDhU4KA%40mail.gmail.com.
--001a113fbc0899f1600560b5001e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Nicol,<div><br></div><div>OK, let's reset and focus.</=
div><div><br></div><div>Do we agree that preventing inadvertent UB is a goo=
d thing in principle?</div><div><br></div><div><br><div class=3D"gmail_extr=
a"><br><div class=3D"gmail_quote">On 19 December 2017 at 17:42, Nicol Bolas=
<span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com" target=3D"_bl=
ank">jmckesson@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><span class=3D""><br><br>On Tuesday, December 19, 20=
17 at 11:23:43 AM UTC-5, Richard Hodges wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div><span style=3D"font-size:12.8px">>=C2=
=A0</span><span style=3D"font-size:12.8px">We do not yet have the not_reach=
ed attribute. Once we have had not_reached available for a few years, we ca=
n consider making it compulsory.</span></div><div><span style=3D"font-size:=
12.8px"><br></span></div><div><span style=3D"font-size:12.8px">This is the =
kind of thinking that keeps c++ in the dark ages compared to any other high=
level language.</span></div></div></blockquote><div><br></div></span><div>=
Right, because if you don't do things exactly the way I say they should=
be done, then you're in the dark ages.</div><div><br></div><div>Please=
stop making such arguments. They're not helpful towards actually getti=
ng something useful done.</div><span class=3D""><div><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><span style=3D"font-size:=
12.8px">I'll give you one year. You don't need more.</span></div></=
div></blockquote><div><br></div></span><div>That is even less helpful.<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex">
</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/330fd349-148c-4c7c-a1af-d46d3e6aa782%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/330f=
d349-148c-4c7c-<wbr>a1af-d46d3e6aa782%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/CALvx3hZ93%3DYzYp3ULxzKdzn9h_OMX%2BH-=
32%2B%2Bu%2B3RSvNtDhU4KA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3h=
Z93%3DYzYp3ULxzKdzn9h_OMX%2BH-32%2B%2Bu%2B3RSvNtDhU4KA%40mail.gmail.com</a>=
..<br />
--001a113fbc0899f1600560b5001e--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 19 Dec 2017 09:43:36 -0800
Raw View
On ter=C3=A7a-feira, 19 de dezembro de 2017 06:18:45 PST Richard Hodges wro=
te:
> So simply make it so from c++20 that a function shall return or throw. i.=
e.
> programmers shall be honest or their programs shall not compile.
It ALREADY does return or throw.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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/4561860.0QvKHTRbXI%40tjmaciei-mobl1.
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Tue, 19 Dec 2017 18:52:03 +0100
Raw View
--089e08200cdce8e9ed0560b51f86
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
> It ALREADY does return or throw.
I don't think you've been listening.
int foo() {}
neither returns anything (of meaning) nor throws. Neither does it inform
the compiler that the UB is intended. It is never, ever, ever going to be
part of a meaningful program. Any program which calls this function and
uses the return value is doomed. It is a non-program. It has become a noise
generator.
Allowing this is like saying, "we're going to allow landmines under the
living room carpet, because it optimises the case where we would want to
run across the living room not knowing whether we were going to have our
legs blown off."
No-one ever wants that.
So let's prevent home-furnishers from inadvertently leaving landmines under
carpets for the sake of finishing the job 10 seconds early...
On 19 December 2017 at 18:43, Thiago Macieira <thiago@macieira.org> wrote:
> On ter=C3=A7a-feira, 19 de dezembro de 2017 06:18:45 PST Richard Hodges w=
rote:
> > So simply make it so from c++20 that a function shall return or throw.
> i.e.
> > programmers shall be honest or their programs shall not compile.
>
> It ALREADY does return or throw.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
>
> --
> 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/4561860.0QvKHTRbXI%40tjmaciei-mobl1.
>
--=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/CALvx3hb41nRBw7nW4q_y-dXMRhVgFH_WgtJtMTybSPFytaV=
-0A%40mail.gmail.com.
--089e08200cdce8e9ed0560b51f86
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">It ALREADY does=
return or throw.</span><br style=3D"font-size:12.8px"><div><span style=3D"=
font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">I =
don't think you've been listening.</span></div><div><span style=3D"=
font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px"><f=
ont face=3D"monospace, monospace">int foo() {}</font>=C2=A0</span></div><di=
v><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"fon=
t-size:12.8px">neither returns anything (of meaning) nor throws. Neither do=
es it inform the compiler that the UB is intended. It is never, ever, ever =
going to be part of a meaningful program. Any program which calls this func=
tion and uses the return value is doomed. It is a non-program. It has becom=
e a noise generator.</span></div><div><span style=3D"font-size:12.8px"><br>=
</span></div><div><span style=3D"font-size:12.8px">Allowing this is like sa=
ying, "we're going to allow landmines under the living room carpet=
, because it optimises the case where we would want to run across the livin=
g room not knowing whether we were going to have our legs blown off."<=
/span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><sp=
an style=3D"font-size:12.8px">No-one ever wants that.</span></div><div><spa=
n style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size=
:12.8px">So let's prevent home-furnishers from inadvertently leaving la=
ndmines under carpets for the sake of finishing the job 10 seconds early...=
</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><s=
pan style=3D"font-size:12.8px"><br></span></div></div><div class=3D"gmail_e=
xtra"><br><div class=3D"gmail_quote">On 19 December 2017 at 18:43, Thiago M=
acieira <span dir=3D"ltr"><<a href=3D"mailto:thiago@macieira.org" target=
=3D"_blank">thiago@macieira.org</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><span class=3D"">On ter=C3=A7a-feira, 19 de dezembro de 2017 =
06:18:45 PST Richard Hodges wrote:<br>
> So simply make it so from c++20 that a function shall return or throw.=
i.e.<br>
> programmers shall be honest or their programs shall not compile.<br>
<br>
</span>It ALREADY does return or throw.<br>
<br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<span class=3D""><br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/4561860.0QvKHTRbXI%40tjmaciei-=
mobl1" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/<wb=
r>isocpp.org/d/msgid/std-<wbr>proposals/4561860.0QvKHTRbXI%<wbr>40tjmaciei-=
mobl1</a>.<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/CALvx3hb41nRBw7nW4q_y-dXMRhVgFH_WgtJt=
MTybSPFytaV-0A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hb41nRBw7nW=
4q_y-dXMRhVgFH_WgtJtMTybSPFytaV-0A%40mail.gmail.com</a>.<br />
--089e08200cdce8e9ed0560b51f86--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 19 Dec 2017 09:58:42 -0800
Raw View
On ter=C3=A7a-feira, 19 de dezembro de 2017 06:51:38 PST inkwizytoryankes@g=
mail.com=20
wrote:
> Less UB? For some people this is very big quality even bigger than speed
> (this thread and many others show it). This could be even already
> implemented by some sanitizer in GCC or Clang.
Those people can use a macro or their explictily call a termination functio=
n.
We have this in Qt:
#define Q_UNREACHABLE() \
do {\
Q_ASSERT_X(false, "Q_UNREACHABLE()", "Q_UNREACHABLE was reached");\
Q_UNREACHABLE_IMPL();\
} while (false)
In debug code, the assertion may hit. In release mode, the assertion is=20
deleted and you just hit the compiler-specific marker for unreachability.
We also have QT_FORCE_ASSERTS that would keep assertions in release mode, i=
f=20
you want them. And if compilers didn't generate worse code, I'd have made=
=20
Q_ASSERT reduce to Q_ASSUME in no-assertion cases.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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/7459188.JrTDj4A1FR%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 19 Dec 2017 10:05:31 -0800
Raw View
On ter=C3=A7a-feira, 19 de dezembro de 2017 06:57:30 PST Jake Arkinstall wr=
ote:
> I will state this as a question because it's honestly something I would
> love to know: what harm does killing this undefined behaviour do?
It makes the compiler insert unneeded code when it can't prove I have taken=
=20
the necessary steps already.
It's like most of the other UBs. Should the compiler cause a clear terminat=
ion=20
if it detects signer integer overflow? How will it know that the overflow=
=20
isn't impossible? Should the compiler terminate a shift wider than the type=
's=20
width? How will it know I haven't already constrained my input?
On the last one, this happened an hour ago for me:
warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits=
=20
(was 64-bit shift intended?)
No, I wrote exactly the code that I meant. The left side of the shift was 1=
,=20
the right side was already constrained by construction to 0, 1, 2 or 3.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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/1899382.hOWg0Cliai%40tjmaciei-mobl1.
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Tue, 19 Dec 2017 18:06:08 +0000
Raw View
--94eb2c1c1acc43bd940560b55281
Content-Type: text/plain; charset="UTF-8"
I think this entire thread is at odds because of different working
environments. I started out in web development and thus my first line of
thought is "Never trust inputs that haven't been whitelisted, anywhere". I
now work in a different area, but I keep the same philosophy simply to
prevent accidental screwups from myself or others that could cost time,
money, and reputation. In my specific situation, a crash is infinitely
favourable over a paradox of false==true that I didn't see coming because
another developer was doing something stupid. If a developer does something
stupid, I want them to be aware of it, not be under the impression that
everything is fine.
On the other hand, if you're in an environment where everything interacting
with your code is a well-oiled, finely tuned machine, then I can completely
understand why you'd want your code to be able to exploit optimisations
that utilise the existence of undefined behaviour in impossible situations
to make generalisations. As it has been worded above, these pieces of code
have the benefit of a contract with their calling code, and that contract
supersedes the otherwise flexible nature of the underlying types.
If there were a way to keep both sides happy, without disrupting the code
written for either environment, that would be awesome. However, I don't
think there is. Forcing a user to add keywords on either environment would
upset half of the community. The compiler adding handling code at the end
of a function increases code size and could negate some optimisations in
specific situations, and we don't want to have an update to the standard
that ends up slowing down or increasing the binary size of widely used code
- especially as the aim of C++ (in my view) is to create something that's
as fast as (or in some cases faster than) C but without the inconvenience
of actually writing C, and the evolving standards are allowing people to do
this with *increasing, not decreasing* convenience.
The benefit of the status quo is that both situations can coexist so long
as the programmer is competent - and I think we're now in the territory of
debating whether or not this is a reasonable demand. Compilers can have
flags that tell people they're making assumptions, which is useful for one
side of the debate, but those can be turned off for those on the other side
of the debate who have the comfort of *knowing* that nothing can go wrong.
As such, unless an approach is found that allows safety AND speed, I don't
think we will get anywhere. It would be lovely to be able to tell the
compiler "don't worry, I've got you covered, this piece here is only run
from a safe environment. This other piece, though, should trust nothing and
nobody" without adding keywords to existing code. That makes no sense
though. The defines idea is fun, but one has to be careful because of the
way that multiple includes of the same header is handled. It also seems
like a dirty approach to me.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMNCDLL%2Bv6JNSHAgPPRRk%3D_nWJiRoKSHzNkmAN-27N02w%40mail.gmail.com.
--94eb2c1c1acc43bd940560b55281
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div></div><div dir=3D"auto">I think this entire thread i=
s at odds because of different working environments. I started out in web d=
evelopment and thus my first line of thought is "Never trust inputs th=
at haven't been whitelisted, anywhere". I now work in a different =
area, but I keep the same philosophy simply to prevent accidental screwups =
from myself or others that could cost time, money, and reputation. In my sp=
ecific situation, a crash is infinitely favourable over a paradox of false=
=3D=3Dtrue that I didn't see coming because another developer was doing=
something stupid. If a developer does something stupid, I want them to be =
aware of it, not be under the impression that everything is fine.<br></div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">On the other hand, if you'=
;re in an environment where everything interacting with your code is a well=
-oiled, finely tuned machine, then I can completely understand why you'=
d want your code to be able to exploit optimisations that utilise the exist=
ence of undefined behaviour in impossible situations to make generalisation=
s. As it has been worded above, these pieces of code have the benefit of a =
contract with their calling code, and that contract supersedes the otherwis=
e flexible nature of the underlying types.</div><div dir=3D"auto"><br></div=
><div dir=3D"auto">If there were a way to keep both sides happy, without di=
srupting the code written for either environment, that would be awesome. Ho=
wever, I don't think there is. Forcing a user to add keywords on either=
environment would upset half of the community. The compiler adding handlin=
g code at the end of a function increases code size and could negate some o=
ptimisations in specific situations, and we don't want to have an updat=
e to the standard that ends up slowing down or increasing the binary size o=
f widely used code - especially as the aim of C++ (in my view) is to create=
something that's as fast as (or in some cases faster than) C but witho=
ut the inconvenience of actually writing C, and the evolving standards are =
allowing people to do this with <i>increasing, not decreasing</i> convenien=
ce.</div><div dir=3D"auto"><br></div><div dir=3D"auto">The benefit of the s=
tatus quo is that both situations can coexist so long as the programmer is =
competent - and I think we're now in the territory of debating whether =
or not this is a reasonable demand. Compilers can have flags that tell peop=
le they're making assumptions, which is useful for one side of the deba=
te, but those can be turned off for those on the other side of the debate w=
ho have the comfort of <i>knowing</i> that nothing can go wrong.</div><div =
dir=3D"auto"><br></div><div dir=3D"auto">As such, unless an approach is fou=
nd that allows safety AND speed, I don't think we will get anywhere. It=
would be lovely to be able to tell the compiler "don't worry, I&#=
39;ve got you covered, this piece here is only run from a safe environment.=
This other piece, though, should trust nothing and nobody" without ad=
ding keywords to existing code. That makes no sense though. The defines ide=
a is fun, but one has to be careful because of the way that multiple includ=
es of the same header is handled. It also seems like a dirty approach to me=
..</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/CAC%2B0CCMNCDLL%2Bv6JNSHAgPPRRk%3D_nW=
JiRoKSHzNkmAN-27N02w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMN=
CDLL%2Bv6JNSHAgPPRRk%3D_nWJiRoKSHzNkmAN-27N02w%40mail.gmail.com</a>.<br />
--94eb2c1c1acc43bd940560b55281--
.
Author: Ren Industries <renindustries@gmail.com>
Date: Tue, 19 Dec 2017 13:07:56 -0500
Raw View
--f403045c5216bbc81d0560b55891
Content-Type: text/plain; charset="UTF-8"
> > It ALREADY does return or throw.
>
> I don't think you've been listening.
>
> int foo() {}
>
> neither returns anything (of meaning) nor throws. Neither does it inform
> the compiler that the UB is intended. It is never, ever, ever going to be
> part of a meaningful program. Any program which calls this function and
> uses the return value is doomed. It is a non-program. It has become a noise
> generator.
>
> Allowing this is like saying, "we're going to allow landmines under the
> living room carpet, because it optimises the case where we would want to
> run across the living room not knowing whether we were going to have our
> legs blown off."
>
> No-one ever wants that.
>
I want that. I absolutely want it to be faster when I do things properly,
which is the case for less simpler examples with narrower contracts.
If you want to prevent UB by using asserts, exceptions, or specifically
telling the compiler that no path will reach that code, great!
If the compiler wants to warn me, absolutely.
But that doesn't mean I want my narrow contracts widened because you think
I'm doing something wrong.
>
> So let's prevent home-furnishers from inadvertently leaving landmines
> under carpets for the sake of finishing the job 10 seconds early...
>
>
Those landmines increase speed; they were carefully laid there, at a much
greater cost than 10 seconds.
--
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/CAMD6iD9LBkdvM0ybiG6fVa-L1pZ_f8Litp%2BFsk8XgohnLGbNJw%40mail.gmail.com.
--f403045c5216bbc81d0560b55891
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">>=C2=A0=
<span style=3D"font-size:12.8px">It ALREADY does return or throw.</span><br=
style=3D"font-size:12.8px"><div><span style=3D"font-size:12.8px"><br></spa=
n></div></span><div><span style=3D"font-size:12.8px">I don't think you&=
#39;ve been listening.</span></div><div><span style=3D"font-size:12.8px"><b=
r></span></div><div><span style=3D"font-size:12.8px"><font face=3D"monospac=
e, monospace">int foo() {}</font>=C2=A0</span></div><div><span style=3D"fon=
t-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">neith=
er returns anything (of meaning) nor throws. Neither does it inform the com=
piler that the UB is intended. It is never, ever, ever going to be part of =
a meaningful program. Any program which calls this function and uses the re=
turn value is doomed. It is a non-program. It has become a noise generator.=
</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><s=
pan style=3D"font-size:12.8px">Allowing this is like saying, "we'r=
e going to allow landmines under the living room carpet, because it optimis=
es the case where we would want to run across the living room not knowing w=
hether we were going to have our legs blown off."</span></div><div><sp=
an style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-siz=
e:12.8px">No-one ever wants that.</span></div></div></blockquote><div><br><=
/div><div>I want that. I absolutely want it to be faster when I do things p=
roperly, which is the case for less simpler examples with narrower contract=
s.</div><div>If you want to prevent UB by using asserts, exceptions, or spe=
cifically telling the compiler that no path will reach that code, great!</d=
iv><div>If the compiler wants to warn me, absolutely.</div><div><br></div><=
div>But that doesn't mean I want my narrow contracts widened because yo=
u think I'm doing something wrong.</div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div><span style=3D"font-size:12.8px"><br=
></span></div><div><span style=3D"font-size:12.8px">So let's prevent ho=
me-furnishers from inadvertently leaving landmines under carpets for the sa=
ke of finishing the job 10 seconds early...</span></div><div><br></div></di=
v></blockquote><div><br></div><div>Those landmines increase speed; they wer=
e carefully laid there, at a much greater cost than 10 seconds.=C2=A0</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/CAMD6iD9LBkdvM0ybiG6fVa-L1pZ_f8Litp%2=
BFsk8XgohnLGbNJw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD9LBkdvM0=
ybiG6fVa-L1pZ_f8Litp%2BFsk8XgohnLGbNJw%40mail.gmail.com</a>.<br />
--f403045c5216bbc81d0560b55891--
.
Author: Justin Bassett <jbassett271@gmail.com>
Date: Tue, 19 Dec 2017 10:09:54 -0800
Raw View
--001a114a8014c797a30560b55f4c
Content-Type: text/plain; charset="UTF-8"
I do not think it's a good idea to have a breaking change like this.
That said, is there a way we can introduce breaking changes? Most ideas for
such changes have some value if we disregard the fact that they break
existing code.
Suppose we released a tool with the change, which scans the codebase and
makes the changes automatically. Macros make this difficult, but let's just
suppose it was possible. If all now-broken code was updated to the
equivalent alternative after the breaking change, can we justify making a
breaking change? What if we clustered several breaking changes together?
I'm not talking about a tool like the Python 2 to 3 converter, which
doesn't always work, as there isn't always an equivalent. I'm talking about
only allowing changes for which there always is an equivalent.
I do already see a big problem with this: libraries. I don't know how to
solve it.
On Dec 19, 2017 8:42 AM, "Nicol Bolas" <jmckesson@gmail.com> wrote:
>
> On Tue, Dec 19, 2017 at 10:02 AM, Richard Hodges <hodges.r@gmail.com>
> wrote:
>
>>
>>> Yes, once I am convinced that it's not going to be pushed back with:
>>
>> "We can't make the language safer, it might annoy some die-hard
>> UB-lovers",
>> "We can't break broken code",
>> "We can't make attributes do anything"
>>
>> You remind me of someone who frequents this chat and who happens to be my
> mentor too :-)
> If I didn't know any better, I was almost left wondering if he is posting
> under an alias!
>
>
> --
> 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/CALEPxfsQ4x7mKpuevu2_
> oqZR83s2WScsyeA2maZ96WypHAmEWg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALEPxfsQ4x7mKpuevu2_oqZR83s2WScsyeA2maZ96WypHAmEWg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAPuuy5e8RP_t%3Dceev7R%3DLZMpjZzMqkNwcc-RqjV7mpuFTUKQ9w%40mail.gmail.com.
--001a114a8014c797a30560b55f4c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">I do not think it's a good idea to have a breaking ch=
ange like this.<div dir=3D"auto"><br></div><div dir=3D"auto">That said, is =
there a way we can introduce breaking changes? Most ideas for such changes =
have some value if we disregard the fact that they break existing code.</di=
v><div dir=3D"auto"><br></div><div dir=3D"auto">Suppose we released a tool =
with the change, which scans the codebase and makes the changes automatical=
ly. Macros make this difficult, but let's just suppose it was possible.=
If all now-broken code was updated to the equivalent alternative after the=
breaking change, can we justify making a breaking change? What if we clust=
ered several breaking changes together? I'm not talking about a tool li=
ke the Python 2 to 3 converter, which doesn't always work, as there isn=
't always an equivalent. I'm talking about only allowing changes fo=
r which there always is an equivalent.</div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">I do already see a big problem with this: libraries. I don&#=
39;t know how to solve it.</div><div dir=3D"auto"><br></div><div dir=3D"aut=
o"><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=
">On Dec 19, 2017 8:42 AM, "Nicol Bolas" <<a href=3D"mailto:jm=
ckesson@gmail.com">jmckesson@gmail.com</a>> wrote:<br type=3D"attributio=
n"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extr=
a"><br><div class=3D"gmail_quote">On Tue, Dec 19, 2017 at 10:02 AM, Richard=
Hodges <span dir=3D"ltr"><<a href=3D"mailto:hodges.r@gmail.com" target=
=3D"_blank">hodges.r@gmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><span><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"ltr"><br></div></blockquote><div>Yes, once I am con=
vinced that it's not going to be pushed back with:<br></div></span><div=
><br></div><div>"We can't make the language safer, it might annoy =
some die-hard UB-lovers",</div><div>"We can't break broken co=
de",</div><div>"We can't make attributes do anything"</d=
iv><div><br></div></div></blockquote><div>You remind me of someone who freq=
uents this chat and who happens to be my mentor too :-)</div><div>If I didn=
't know any better, I was almost left wondering if he is posting under =
an alias!</div><div>=C2=A0</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" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALEPxfsQ4x7mKpuevu2_oqZR83s2WScsyeA2=
maZ96WypHAmEWg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-=
<wbr>proposals/<wbr>CALEPxfsQ4x7mKpuevu2_<wbr>oqZR83s2WScsyeA2maZ96WypHAmEW=
g<wbr>%40mail.gmail.com</a>.<br>
</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/CAPuuy5e8RP_t%3Dceev7R%3DLZMpjZzMqkNw=
cc-RqjV7mpuFTUKQ9w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPuuy5e8RP_t=
%3Dceev7R%3DLZMpjZzMqkNwcc-RqjV7mpuFTUKQ9w%40mail.gmail.com</a>.<br />
--001a114a8014c797a30560b55f4c--
.
Author: inkwizytoryankes@gmail.com
Date: Tue, 19 Dec 2017 10:30:16 -0800 (PST)
Raw View
------=_Part_28_422496990.1513708216211
Content-Type: multipart/alternative;
boundary="----=_Part_29_1875477216.1513708216211"
------=_Part_29_1875477216.1513708216211
Content-Type: text/plain; charset="UTF-8"
On Tuesday, December 19, 2017 at 4:52:21 PM UTC+1, Richard Hodges wrote:
>
> > That means that if one single header included by one single TU in my
> program is broken by your change, I am unable to upgrade. Worse, it means
> that if anyone who might use any of my library code is unable to upgrade,
> then I cannot use any C++20 features.
>
> This is a (the only) valid concern I have seen expressed.
>
> If the atmosphere were slightly more "let's make things better" and less
> "let's keep things rubbish", I'd be tempted to think of it as nudging the
> general idea of preventing UB forward while providing a way to interact
> with legacy headers.
>
> Being a positive person, I hereby choose to see your valid concern as a
> driver for innovation.
>
> Here's one idea, just off the top of my head:
>
> extern "UBAllowed" {
> #include <nasty_old_ub_filled_header.hpp>
> }
>
> Here's another
>
> #pragma turn_a_blind_eye_to_ub(true)
> #include <nasty_old_ub_filled_header.hpp>
> #pragma turn_a_blind_eye_to_ub(true)
>
> Of course we all know that the hardest problem in computer science is
> naming things. I'll open the floor to better names, but shall we all choose
> to agree on the general principle that anything we can do to help
> programmers not shoot themselves in their extremities is a good thing?
>
>
>
Why not optin? And why you not ask your compiler writer to add this option
it for you? Why force something on other if they do not want this?
--
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/96aaac82-8dc5-4fd1-a6fb-824d91a22c3a%40isocpp.org.
------=_Part_29_1875477216.1513708216211
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, December 19, 2017 at 4:52:21 PM UTC+1,=
Richard Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">That means that if one =
single header included by one single TU in my program is broken by your cha=
nge, I am unable to upgrade. Worse, it means that if anyone who might use a=
ny of my library code is unable to upgrade, then I cannot use any C++20 fea=
tures.</span><div><span style=3D"font-size:12.8px"><br></span></div><div><s=
pan style=3D"font-size:12.8px">This is a (the only) valid concern I have se=
en expressed.</span></div><div><br></div><div>If the atmosphere were slight=
ly more "let's make things better" and less "let's k=
eep things rubbish", I'd be tempted to think of it as nudging the =
general idea of preventing UB forward while providing a way to interact wit=
h legacy headers.</div><div><br></div><div>Being a positive person, I hereb=
y choose to see your valid concern as a driver for innovation.</div><div><b=
r></div><div>Here's one idea, just off the top of my head:</div><div><b=
r></div><div><font face=3D"monospace, monospace">extern "UBAllowed&quo=
t; {</font></div><div><font face=3D"monospace, monospace">=C2=A0 #include &=
lt;nasty_old_ub_filled_header.<wbr>hpp></font></div><div><font face=3D"m=
onospace, monospace">}</font></div><div><br></div><div>Here's another</=
div><div><br></div><div><div><font face=3D"monospace, monospace">#pragma tu=
rn_a_blind_eye_to_ub(true)</font></div></div><div><div><font face=3D"monosp=
ace, monospace">=C2=A0 #include <nasty_old_ub_filled_header.<wbr>hpp>=
</font></div><div><font face=3D"monospace, monospace">#pragma turn_a_blind_=
eye_to_ub(true)</font></div></div><div><br></div><div>Of course we all know=
that the hardest problem in computer science is naming things. I'll op=
en the floor to better names, but shall we all choose to agree on the gener=
al principle that anything we can do to help programmers not shoot themselv=
es in their extremities is a good thing?</div><div><br></div></div><div><br=
></div></blockquote><div>=C2=A0</div><div>Why not optin? And why you not as=
k your compiler writer to add this option it for you? Why force something o=
n other if they do not want this?<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/96aaac82-8dc5-4fd1-a6fb-824d91a22c3a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/96aaac82-8dc5-4fd1-a6fb-824d91a22c3a=
%40isocpp.org</a>.<br />
------=_Part_29_1875477216.1513708216211--
------=_Part_28_422496990.1513708216211--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Tue, 19 Dec 2017 19:59:55 +0100
Raw View
--94eb2c05b4ba9a07a50560b61279
Content-Type: text/plain; charset="UTF-8"
> Why not optin?
For the same reason that the trigger switch for a fighter-jet's guns has a
guard over it. You can't forget to do the safe thing. You have to
consciously choose to do the expert thing (fire the guns, omit a return
statement, do a reinterpret_cast and so on).
At the moment, the fact that you can forget to return a value, and have to
consciously remember to do what is the right thing in the majority of
cases, is a language defect. Pure and simple.
I'm not looking to take away your (my) ability to do dangerous and cool
things. I'm merely suggesting that the right way round is that the normally
correct thing is the default, and the dangerous fighter-jock thing requires
lifting the trigger cap.
Just so everyone is sure that you really did mean to fire up the gatling
gun while still in the hangar...
On 19 December 2017 at 19:30, <inkwizytoryankes@gmail.com> wrote:
>
>
> On Tuesday, December 19, 2017 at 4:52:21 PM UTC+1, Richard Hodges wrote:
>>
>> > That means that if one single header included by one single TU in my
>> program is broken by your change, I am unable to upgrade. Worse, it means
>> that if anyone who might use any of my library code is unable to upgrade,
>> then I cannot use any C++20 features.
>>
>> This is a (the only) valid concern I have seen expressed.
>>
>> If the atmosphere were slightly more "let's make things better" and less
>> "let's keep things rubbish", I'd be tempted to think of it as nudging the
>> general idea of preventing UB forward while providing a way to interact
>> with legacy headers.
>>
>> Being a positive person, I hereby choose to see your valid concern as a
>> driver for innovation.
>>
>> Here's one idea, just off the top of my head:
>>
>> extern "UBAllowed" {
>> #include <nasty_old_ub_filled_header.hpp>
>> }
>>
>> Here's another
>>
>> #pragma turn_a_blind_eye_to_ub(true)
>> #include <nasty_old_ub_filled_header.hpp>
>> #pragma turn_a_blind_eye_to_ub(true)
>>
>> Of course we all know that the hardest problem in computer science is
>> naming things. I'll open the floor to better names, but shall we all choose
>> to agree on the general principle that anything we can do to help
>> programmers not shoot themselves in their extremities is a good thing?
>>
>>
>>
> Why not optin? And why you not ask your compiler writer to add this option
> it for you? Why force something on other if they do not want this?
>
> --
> 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/96aaac82-8dc5-4fd1-
> a6fb-824d91a22c3a%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/96aaac82-8dc5-4fd1-a6fb-824d91a22c3a%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CALvx3hYy7NYjbHfkjxiFk9Q6OWL2nPcpbdXAVMmWZYkYfKf%3DdA%40mail.gmail.com.
--94eb2c05b4ba9a07a50560b61279
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">Why not optin?<=
/span><div><span style=3D"font-size:12.8px"><br></span></div><div><span sty=
le=3D"font-size:12.8px">For the same reason that the trigger switch for a f=
ighter-jet's guns has a guard over it. You can't forget to do the s=
afe thing. You have to consciously=C2=A0choose to do the expert thing (fire=
the guns, omit a return statement, do a reinterpret_cast and so on).</span=
></div><div><span style=3D"font-size:12.8px"><br></span></div><div><span st=
yle=3D"font-size:12.8px">At the moment, the fact that you can forget to ret=
urn a value, and have to consciously=C2=A0remember to do what is the right =
thing in the majority of cases, is a language defect. Pure and simple.</spa=
n></div><div><span style=3D"font-size:12.8px"><br></span></div><div><span s=
tyle=3D"font-size:12.8px">I'm not looking to take away your (my) abilit=
y to do dangerous and cool things. I'm merely suggesting that the right=
way round is that the normally correct thing is the default, and the dange=
rous fighter-jock thing requires lifting the trigger cap.</span></div><div>=
<span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-=
size:12.8px">Just so everyone is sure that you really did mean to fire up t=
he gatling gun while still in the hangar...</span></div><div><span style=3D=
"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px"><=
br></span></div><div><span style=3D"font-size:12.8px"><br></span></div></di=
v><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 19 December =
2017 at 19:30, <span dir=3D"ltr"><<a href=3D"mailto:inkwizytoryankes@gm=
ail.com" target=3D"_blank">inkwizytoryankes@gmail.com</a>></span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><br><b=
r>On Tuesday, December 19, 2017 at 4:52:21 PM UTC+1, Richard Hodges wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">>=C2=A0<span sty=
le=3D"font-size:12.8px">That means that if one single header included by on=
e single TU in my program is broken by your change, I am unable to upgrade.=
Worse, it means that if anyone who might use any of my library code is una=
ble to upgrade, then I cannot use any C++20 features.</span><div><span styl=
e=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8p=
x">This is a (the only) valid concern I have seen expressed.</span></div><d=
iv><br></div><div>If the atmosphere were slightly more "let's make=
things better" and less "let's keep things rubbish", I&=
#39;d be tempted to think of it as nudging the general idea of preventing U=
B forward while providing a way to interact with legacy headers.</div><div>=
<br></div><div>Being a positive person, I hereby choose to see your valid c=
oncern as a driver for innovation.</div><div><br></div><div>Here's one =
idea, just off the top of my head:</div><div><br></div><div><font face=3D"m=
onospace, monospace">extern "UBAllowed" {</font></div><div><font =
face=3D"monospace, monospace">=C2=A0 #include <nasty_old_ub_filled_heade=
r.hp<wbr>p></font></div><div><font face=3D"monospace, monospace">}</font=
></div><div><br></div><div>Here's another</div><div><br></div><div><div=
><font face=3D"monospace, monospace">#pragma turn_a_blind_eye_to_ub(true)</=
font></div></div><div><div><font face=3D"monospace, monospace">=C2=A0 #incl=
ude <nasty_old_ub_filled_header.hp<wbr>p></font></div><div><font face=
=3D"monospace, monospace">#pragma turn_a_blind_eye_to_ub(true)</font></div>=
</div><div><br></div><div>Of course we all know that the hardest problem in=
computer science is naming things. I'll open the floor to better names=
, but shall we all choose to agree on the general principle that anything w=
e can do to help programmers not shoot themselves in their extremities is a=
good thing?</div><div><br></div></div><div><br></div></blockquote><div>=C2=
=A0</div></span><div>Why not optin? And why you not ask your compiler write=
r to add this option it for you? Why force something on other if they do no=
t want this?<br></div></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/96aaac82-8dc5-4fd1-a6fb-824d91a22c3a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/96aa=
ac82-8dc5-4fd1-<wbr>a6fb-824d91a22c3a%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/CALvx3hYy7NYjbHfkjxiFk9Q6OWL2nPcpbdXA=
VMmWZYkYfKf%3DdA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hYy7NYjbH=
fkjxiFk9Q6OWL2nPcpbdXAVMmWZYkYfKf%3DdA%40mail.gmail.com</a>.<br />
--94eb2c05b4ba9a07a50560b61279--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 19 Dec 2017 11:05:32 -0800
Raw View
On ter=C3=A7a-feira, 19 de dezembro de 2017 09:52:03 PST Richard Hodges wro=
te:
> > It ALREADY does return or throw.
>=20
> I don't think you've been listening.
I was.
> int foo() {}
>=20
> neither returns anything (of meaning) nor throws. Neither does it inform
> the compiler that the UB is intended. It is never, ever, ever going to be
> part of a meaningful program. Any program which calls this function and
> uses the return value is doomed. It is a non-program. It has become a noi=
se
> generator.
Who says I am going to *call* this function? I might never call it, only us=
e=20
its address for some marker. So it's entirely possible that even this funct=
ion=20
returns in exactly all the cases where it needs to return.
More importantly, I was thinking of cases like:
const char *foo(int x)
{
switch (x) {
case 0:
return "Hello";
case 1:
return "World";
}
}
If foo() is only ever called with 0 or 1, then this function does return or=
=20
throw in all cases. The compiler unlikely to be able to prove otherwise. I =
do=20
not need to add a return or throw or abort() at the end because that's dead=
=20
code.
If this were my code, I'd add [[unreachable]] or some other compiler-specif=
ic=20
no-code marker at the end. But not something that could generate code.
> Allowing this is like saying, "we're going to allow landmines under the
> living room carpet, because it optimises the case where we would want to
> run across the living room not knowing whether we were going to have our
> legs blown off."
No, but it is like saying "we're going to allow landmines there where no on=
e=20
is ever going to be anyway". If you change your code, you may have a proble=
m.=20
But until then, it may be safe.
> No-one ever wants that.
>=20
> So let's prevent home-furnishers from inadvertently leaving landmines und=
er
> carpets for the sake of finishing the job 10 seconds early...
Disagreed. More apt analogy:
Let's allow painters not to paint behind furniture and mirrors because no o=
ne=20
is ever going to see anyway. If you move your furniture, then you may have =
to=20
apply some paint job.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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/6130888.rSlXyRg4JF%40tjmaciei-mobl1.
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Tue, 19 Dec 2017 19:25:31 +0000
Raw View
--001a11492a422ab3710560b66ed2
Content-Type: text/plain; charset="UTF-8"
On 19 Dec 2017 19:05, "Thiago Macieira" <thiago@macieira.org> wrote:
More apt analogy:
Let's allow painters not to paint behind furniture and mirrors because no
one
is ever going to see anyway. If you move your furniture, then you may have
to
apply some paint job.
That's a good analogy. The difference for me is that painters are expensive
so I hope they do the job properly. That you aren't going to move your
furniture is an assumption - a contract that you decided on at one point.
Then you find that the contract wasn't suitable at a later date, and are
forced to either call the painters in for a second time or decide not to
move your furniture after all. Both have costs involved.
But again, the difference with me is also that I don't make such decisions
and prepare for the furniture to be moved around in the future. But that's
what I do with my house, and it's not my concern what other people do with
theirs.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMtQNwpdAuj9Mjhep3WPoTFiD9W32bOxtkt84RLi16-6w%40mail.gmail.com.
--001a11492a422ab3710560b66ed2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><br><div class=3D"gmail_extra" dir=3D"auto"><br><div clas=
s=3D"gmail_quote">On 19 Dec 2017 19:05, "Thiago Macieira" <<a =
href=3D"mailto:thiago@macieira.org">thiago@macieira.org</a>> wrote:<br t=
ype=3D"attribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div class=3D"quoted-text">Mor=
e apt analogy:<br></div>
<br>
Let's allow painters not to paint behind furniture and mirrors because =
no one<br>
is ever going to see anyway. If you move your furniture, then you may have =
to<br>
apply some paint job.</blockquote></div></div><div dir=3D"auto"><br></div><=
div dir=3D"auto">That's a good analogy. The difference for me is that p=
ainters are expensive so I hope they do the job properly. That you aren'=
;t going to move your furniture is an assumption - a contract that you deci=
ded on at one point. Then you find that the contract wasn't suitable at=
a later date, and are forced to either call the painters in for a second t=
ime or decide not to move your furniture after all. Both have costs involve=
d.</div><div dir=3D"auto"><br></div><div dir=3D"auto">But again, the differ=
ence with me is also that I don't make such decisions and prepare for t=
he furniture to be moved around in the future. But that's what I do wit=
h my house, and it's not my concern what other people do with theirs.</=
div><div class=3D"gmail_extra" dir=3D"auto"></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMtQNwpdAuj9Mjhep3WPoTFiD9W32=
bOxtkt84RLi16-6w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMtQNwp=
dAuj9Mjhep3WPoTFiD9W32bOxtkt84RLi16-6w%40mail.gmail.com</a>.<br />
--001a11492a422ab3710560b66ed2--
.
Author: inkwizytoryankes@gmail.com
Date: Tue, 19 Dec 2017 11:32:54 -0800 (PST)
Raw View
------=_Part_8027_1655326132.1513711974317
Content-Type: multipart/alternative;
boundary="----=_Part_8028_1945617747.1513711974317"
------=_Part_8028_1945617747.1513711974317
Content-Type: text/plain; charset="UTF-8"
On Tuesday, December 19, 2017 at 7:59:58 PM UTC+1, Richard Hodges wrote:
>
> > Why not optin?
>
> For the same reason that the trigger switch for a fighter-jet's guns has a
> guard over it. You can't forget to do the safe thing. You have to
> consciously choose to do the expert thing (fire the guns, omit a return
> statement, do a reinterpret_cast and so on).
>
>
And my knife in kitchen do not have any safeguards...
> At the moment, the fact that you can forget to return a value, and have to
> consciously remember to do what is the right thing in the majority of
> cases, is a language defect. Pure and simple.
>
> I'm not looking to take away your (my) ability to do dangerous and cool
> things. I'm merely suggesting that the right way round is that the normally
> correct thing is the default, and the dangerous fighter-jock thing requires
> lifting the trigger cap.
>
> Just so everyone is sure that you really did mean to fire up the gatling
> gun while still in the hangar...
>
>
>
And only few agree with you, if someone need more safe code they can use
correct compiler switches to do so. Standard do not need to be changed, UB
means that anything can happens, calling abort fall into this too.
--
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/d725d697-3f82-470b-926b-9d291a77d9fa%40isocpp.org.
------=_Part_8028_1945617747.1513711974317
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, December 19, 2017 at 7:59:58 PM UTC+1,=
Richard Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">Why not optin?</span><d=
iv><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"fo=
nt-size:12.8px">For the same reason that the trigger switch for a fighter-j=
et's guns has a guard over it. You can't forget to do the safe thin=
g. You have to consciously=C2=A0choose to do the expert thing (fire the gun=
s, omit a return statement, do a reinterpret_cast and so on).</span></div><=
div><span style=3D"font-size:12.8px"><br></span></div></div></blockquote><d=
iv><br></div><div>And my knife in <span id=3D"result_box" class=3D"short_te=
xt" lang=3D"en"><span class=3D"">kitchen do not have any safeguards...<br><=
/span></span></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div><span style=3D"font-size:12.8px"></span></div><=
div><span style=3D"font-size:12.8px">At the moment, the fact that you can f=
orget to return a value, and have to consciously=C2=A0remember to do what i=
s the right thing in the majority of cases, is a language defect. Pure and =
simple.</span></div><div><span style=3D"font-size:12.8px"><br></span></div>=
<div><span style=3D"font-size:12.8px">I'm not looking to take away your=
(my) ability to do dangerous and cool things. I'm merely suggesting th=
at the right way round is that the normally correct thing is the default, a=
nd the dangerous fighter-jock thing requires lifting the trigger cap.</span=
></div><div><span style=3D"font-size:12.8px"><br></span></div><div><span st=
yle=3D"font-size:12.8px">Just so everyone is sure that you really did mean =
to fire up the gatling gun while still in the hangar...</span></div><div><s=
pan style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-si=
ze:12.8px"><br></span></div></div></blockquote><div><br></div><div>And only=
few agree with you, if someone need more safe code they can use correct co=
mpiler switches to do so. Standard do not need to be changed, UB means that=
anything can happens, calling abort fall into this too.<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/d725d697-3f82-470b-926b-9d291a77d9fa%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d725d697-3f82-470b-926b-9d291a77d9fa=
%40isocpp.org</a>.<br />
------=_Part_8028_1945617747.1513711974317--
------=_Part_8027_1655326132.1513711974317--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 19 Dec 2017 11:38:45 -0800
Raw View
On ter=C3=A7a-feira, 19 de dezembro de 2017 10:09:54 PST Justin Bassett wro=
te:
> That said, is there a way we can introduce breaking changes? Most ideas f=
or
> such changes have some value if we disregard the fact that they break
> existing code.
>=20
> Suppose we released a tool with the change, which scans the codebase and
> makes the changes automatically. Macros make this difficult, but let's ju=
st
> suppose it was possible. If all now-broken code was updated to the
> equivalent alternative after the breaking change, can we justify making a
> breaking change? What if we clustered several breaking changes together?
Sorry to be sarcastic, but you're basically saying "if we ignore or solve a=
ll=20
the problems, then there are no problems".
We can't ignore that there's a language, with a defined syntax, and billion=
s=20
of lines of code that would need to be scanned and updated.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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/2039804.K0WUg3pRiR%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 19 Dec 2017 11:56:42 -0800
Raw View
On ter=C3=A7a-feira, 19 de dezembro de 2017 11:25:31 PST Jake Arkinstall wr=
ote:
> That's a good analogy. The difference for me is that painters are expensi=
ve
> so I hope they do the job properly. That you aren't going to move your
> furniture is an assumption - a contract that you decided on at one point.
> Then you find that the contract wasn't suitable at a later date, and are
> forced to either call the painters in for a second time or decide not to
> move your furniture after all. Both have costs involved.
That's also a good extension. Finding bugs in code is expensive, so you sho=
uld=20
require in code review that an unreachable marker be added to the end of th=
e=20
function and you should insist in compilers that have such a marker. An=20
assertion may make sense too.
But the there'ss a difference between good coding practices and requirement=
by=20
the standard.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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/4161060.PZLmZ66CQQ%40tjmaciei-mobl1.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 19 Dec 2017 12:21:42 -0800 (PST)
Raw View
------=_Part_31403_1506331550.1513714903035
Content-Type: multipart/alternative;
boundary="----=_Part_31404_995133658.1513714903035"
------=_Part_31404_995133658.1513714903035
Content-Type: text/plain; charset="UTF-8"
On Tuesday, December 19, 2017 at 1:09:58 PM UTC-5, Justin Bassett wrote:
>
> I do not think it's a good idea to have a breaking change like this.
>
> That said, is there a way we can introduce breaking changes? Most ideas
> for such changes have some value if we disregard the fact that they break
> existing code.
>
> Suppose we released a tool with the change, which scans the codebase and
> makes the changes automatically. Macros make this difficult, but let's just
> suppose it was possible. If all now-broken code was updated to the
> equivalent alternative after the breaking change, can we justify making a
> breaking change? What if we clustered several breaking changes together?
> I'm not talking about a tool like the Python 2 to 3 converter, which
> doesn't always work, as there isn't always an equivalent. I'm talking about
> only allowing changes for which there always is an equivalent.
>
> I do already see a big problem with this: libraries. I don't know how to
> solve it.
>
The problem's not just that.
Pretty much every tool for parsing and "correcting" C++ to some new
standard runs afoul of macros. So long as there are big macro-libraries
that generate lots of C++ boilerplate, we cannot successfully automate even
the most basic of corrections.
If it weren't for those things, we could do it.
But that doesn't mean we shouldn't have an [[unreachable]] attribute. We
just shouldn't enforce it.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ea833b2-db69-408d-bee4-eb1ba3e425c9%40isocpp.org.
------=_Part_31404_995133658.1513714903035
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, December 19, 2017 at 1:09:58 PM UTC-5,=
Justin Bassett wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"auto">I do not think it's a good idea to have a breaking change lik=
e this.<div dir=3D"auto"><br></div><div dir=3D"auto">That said, is there a =
way we can introduce breaking changes? Most ideas for such changes have som=
e value if we disregard the fact that they break existing code.</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">Suppose we released a tool with the=
change, which scans the codebase and makes the changes automatically. Macr=
os make this difficult, but let's just suppose it was possible. If all =
now-broken code was updated to the equivalent alternative after the breakin=
g change, can we justify making a breaking change? What if we clustered sev=
eral breaking changes together? I'm not talking about a tool like the P=
ython 2 to 3 converter, which doesn't always work, as there isn't a=
lways an equivalent. I'm talking about only allowing changes for which =
there always is an equivalent.</div><div dir=3D"auto"><br></div><div dir=3D=
"auto">I do already see a big problem with this: libraries. I don't kno=
w how to solve it.</div></div></blockquote><div><br></div><div>The problem&=
#39;s not just that.</div><div><br></div><div>Pretty much every tool for pa=
rsing and "correcting" C++ to some new standard runs afoul of mac=
ros. So long as there are big macro-libraries that generate lots of C++ boi=
lerplate, we cannot successfully automate even the most basic of correction=
s.</div><div><br></div><div>If it weren't for those things, we could do=
it.</div><div><br></div><div>But that doesn't mean we shouldn't ha=
ve an [[unreachable]] attribute. We just shouldn't enforce it.</div></d=
iv>
<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/9ea833b2-db69-408d-bee4-eb1ba3e425c9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9ea833b2-db69-408d-bee4-eb1ba3e425c9=
%40isocpp.org</a>.<br />
------=_Part_31404_995133658.1513714903035--
------=_Part_31403_1506331550.1513714903035--
.
Author: Ricardo Fabiano de Andrade <ricardofabianodeandrade@gmail.com>
Date: Tue, 19 Dec 2017 15:02:39 -0600
Raw View
--f403045e714298a0740560b7c908
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I don't think you understood Richard's suggestion...
On Tue, Dec 19, 2017 at 12:05 PM, Thiago Macieira <thiago@macieira.org>
wrote:
> On ter=C3=A7a-feira, 19 de dezembro de 2017 06:57:30 PST Jake Arkinstall =
wrote:
> > I will state this as a question because it's honestly something I would
> > love to know: what harm does killing this undefined behaviour do?
>
> It makes the compiler insert unneeded code when it can't prove I have tak=
en
> the necessary steps already.
>
>
No, no code is added. The idea is:
- A function which currently misses a return or throw statement is no
longer UB, it's a compiler error
- Unless a new attribute is used to state the intention to leave the
function as is.
(I am not debating here how the detection of what missing return/throw is
made or what other statements could used instead, i.e. assert or which is
the new attribute)
Did I get it right Richard?
> It's like most of the other UBs. Should the compiler cause a clear
> termination
> if it detects signer integer overflow? How will it know that the overflow
> isn't impossible? Should the compiler terminate a shift wider than the
> type's
> width? How will it know I haven't already constrained my input?
>
> On the last one, this happened an hour ago for me:
>
> warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bi=
ts
> (was 64-bit shift intended?)
>
> No, I wrote exactly the code that I meant. The left side of the shift was
> 1,
> the right side was already constrained by construction to 0, 1, 2 or 3.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
>
> --
> 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/1899382.hOWg0Cliai%40tjmaciei-mobl1.
>
--=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/CA%2BfGSbN1yMJ88pfUsyZVxbLNsneVgnxKWNm5Akv3Jpv3g=
ooOWw%40mail.gmail.com.
--f403045e714298a0740560b7c908
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I don't think you understood Richard's suggestion.=
...<br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Dec=
19, 2017 at 12:05 PM, Thiago Macieira <span dir=3D"ltr"><<a href=3D"mai=
lto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>></spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On ter=C3=A7=
a-feira, 19 de dezembro de 2017 06:57:30 PST Jake Arkinstall wrote:<br>
> I will state this as a question because it's honestly something I =
would<br>
> love to know: what harm does killing this undefined behaviour do?<br>
<br>
It makes the compiler insert unneeded code when it can't prove I have t=
aken<br>
the necessary steps already.<br>
<br></blockquote><div><br></div><div>No, no code is added. The idea is:</di=
v><div>- A function which currently misses a return or throw statement is n=
o longer UB, it's a compiler error<br></div><div>- Unless a new attribu=
te is used to state the intention to leave the function as is.</div><div><b=
r></div><div>(I am not debating here how the detection of what missing retu=
rn/throw is made or what other statements could used instead, i.e. assert o=
r which is the new attribute)<br></div><div><br></div><div>Did I get it rig=
ht Richard?</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">
It's like most of the other UBs. Should the compiler cause a clear term=
ination<br>
if it detects signer integer overflow? How will it know that the overflow<b=
r>
isn't impossible? Should the compiler terminate a shift wider than the =
type's<br>
width? How will it know I haven't already constrained my input?<br>
<br>
On the last one, this happened an hour ago for me:<br>
<br>
warning C4334: '<<': result of 32-bit shift implicitly conver=
ted to 64 bits<br>
(was 64-bit shift intended?)<br>
<br>
No, I wrote exactly the code that I meant. The left side of the shift was 1=
,<br>
the right side was already constrained by construction to 0, 1, 2 or 3.<br>
<span class=3D"gmail-HOEnZb"><font color=3D"#888888"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>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/1899382.hOWg0Cliai%40tjmaciei-mobl1" =
rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/<wbr>isocp=
p.org/d/msgid/std-<wbr>proposals/1899382.hOWg0Cliai%<wbr>40tjmaciei-mobl1</=
a>.<br>
</font></span></blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CA%2BfGSbN1yMJ88pfUsyZVxbLNsneVgnxKWN=
m5Akv3Jpv3gooOWw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbN1yMJ8=
8pfUsyZVxbLNsneVgnxKWNm5Akv3Jpv3gooOWw%40mail.gmail.com</a>.<br />
--f403045e714298a0740560b7c908--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 19 Dec 2017 13:24:37 -0800 (PST)
Raw View
------=_Part_30943_2097173316.1513718677859
Content-Type: multipart/alternative;
boundary="----=_Part_30944_2065553598.1513718677860"
------=_Part_30944_2065553598.1513718677860
Content-Type: text/plain; charset="UTF-8"
On Tuesday, December 19, 2017 at 12:52:06 PM UTC-5, Richard Hodges wrote:
>
> > It ALREADY does return or throw.
>
> I don't think you've been listening.
>
> int foo() {}
>
> neither returns anything (of meaning) nor throws. Neither does it inform
> the compiler that the UB is intended. It is never, ever, ever going to be
> part of a meaningful program. Any program which calls this function and
> uses the return value is doomed. It is a non-program. It has become a noise
> generator.
>
> Allowing this is like saying, "we're going to allow landmines under the
> living room carpet, because it optimises the case where we would want to
> run across the living room not knowing whether we were going to have our
> legs blown off."
>
How is that any different from:
int *ptr = nullptr;
*ptr = 5;
That's guaranteed to provoke UB. But the compiler is not* required* to give
an error if it can certainly determine that a pointer is NULL.
C and C++ does not save you from yourself.
--
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/bec5a887-bd53-44b5-af95-045162568c1d%40isocpp.org.
------=_Part_30944_2065553598.1513718677860
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, December 19, 2017 at 12:52:06 PM UTC-5=
, Richard Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">It ALREADY does return=
or throw.</span><br style=3D"font-size:12.8px"><div><span style=3D"font-si=
ze:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">I don'=
;t think you've been listening.</span></div><div><span style=3D"font-si=
ze:12.8px"><br></span></div><div><span style=3D"font-size:12.8px"><font fac=
e=3D"monospace, monospace">int foo() {}</font>=C2=A0</span></div><div><span=
style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:=
12.8px">neither returns anything (of meaning) nor throws. Neither does it i=
nform the compiler that the UB is intended. It is never, ever, ever going t=
o be part of a meaningful program. Any program which calls this function an=
d uses the return value is doomed. It is a non-program. It has become a noi=
se generator.</span></div><div><span style=3D"font-size:12.8px"><br></span>=
</div><div><span style=3D"font-size:12.8px">Allowing this is like saying, &=
quot;we're going to allow landmines under the living room carpet, becau=
se it optimises the case where we would want to run across the living room =
not knowing whether we were going to have our legs blown off."</span><=
/div></div></blockquote><div><br></div><div>How is that any different from:=
</div><div><br></div><div class=3D"prettyprint" style=3D"border: 1px solid =
rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 250, =
250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span clas=
s=3D"styled-by-prettify" style=3D"color: #008;">int</span><span class=3D"st=
yled-by-prettify" style=3D"color: #000;"> </span><span class=3D"styled-by-p=
rettify" style=3D"color: #660;">*</span><span class=3D"styled-by-prettify" =
style=3D"color: #000;">ptr </span><span class=3D"styled-by-prettify" style=
=3D"color: #660;">=3D</span><span class=3D"styled-by-prettify" style=3D"col=
or: #000;"> </span><span class=3D"styled-by-prettify" style=3D"color: #008;=
">nullptr</span><span class=3D"styled-by-prettify" style=3D"color: #660;">;=
</span><span class=3D"styled-by-prettify" style=3D"color: #000;"><br></span=
><span class=3D"styled-by-prettify" style=3D"color: #660;">*</span><span cl=
ass=3D"styled-by-prettify" style=3D"color: #000;">ptr </span><span class=3D=
"styled-by-prettify" style=3D"color: #660;">=3D</span><span class=3D"styled=
-by-prettify" style=3D"color: #000;"> </span><span class=3D"styled-by-prett=
ify" style=3D"color: #066;">5</span><span class=3D"styled-by-prettify" styl=
e=3D"color: #660;">;</span></div></code></div><div><br></div><div>That'=
s guaranteed to provoke UB. But the compiler is not<i> required</i> to give=
an error if it can certainly determine that a pointer is NULL.=C2=A0</div>=
<div><br></div><div>C and C++ does not save you from yourself.</div><div><b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
</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/bec5a887-bd53-44b5-af95-045162568c1d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bec5a887-bd53-44b5-af95-045162568c1d=
%40isocpp.org</a>.<br />
------=_Part_30944_2065553598.1513718677860--
------=_Part_30943_2097173316.1513718677859--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 19 Dec 2017 13:47:33 -0800 (PST)
Raw View
------=_Part_31577_573979559.1513720053843
Content-Type: multipart/alternative;
boundary="----=_Part_31578_1013678513.1513720053843"
------=_Part_31578_1013678513.1513720053843
Content-Type: text/plain; charset="UTF-8"
On Tuesday, December 19, 2017 at 12:43:21 PM UTC-5, Richard Hodges wrote:
>
> Nicol,
>
> OK, let's reset and focus.
>
> Do we agree that preventing inadvertent UB is a good thing in principle?
>
If you want to have a principles war, my highest principle when it comes to
any language feature is to *Do No Harm*. And breaking people's code,
however much you personally consider it to already be broken, is Doing Harm.
So it doesn't matter if I agree with that principle or not; there are
higher principles that you cannot simply ignore.
[[unreachable]] alone is good enough. It allows the user to explicitly
communicate when a "missing" return statement is intended. There's no need
to involve the compiler in this matter.
>
--
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/c7dc5405-a381-4477-a237-c61c161534d3%40isocpp.org.
------=_Part_31578_1013678513.1513720053843
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, December 19, 2017 at 12:43:21 PM UTC-5, Richar=
d Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
">Nicol,<div><br></div><div>OK, let's reset and focus.</div><div><br></=
div><div>Do we agree that preventing inadvertent UB is a good thing in prin=
ciple?</div></div></blockquote><div><br></div><div>If you want to have a pr=
inciples war, my highest principle when it comes to any language feature is=
to <u>Do No Harm</u>. And breaking people's code, however much you per=
sonally consider it to already be broken, is Doing Harm.</div><div><br></di=
v><div>So it doesn't matter if I agree with that principle or not; ther=
e are higher principles that you cannot simply ignore.</div><div><br></div>=
<div>[[unreachable]] alone is good enough. It allows the user to explicitly=
communicate when a "missing" return statement is intended. There=
's no need to involve the compiler in this matter.<br></div><blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">
</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/c7dc5405-a381-4477-a237-c61c161534d3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c7dc5405-a381-4477-a237-c61c161534d3=
%40isocpp.org</a>.<br />
------=_Part_31578_1013678513.1513720053843--
------=_Part_31577_573979559.1513720053843--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 19 Dec 2017 13:47:50 -0800 (PST)
Raw View
------=_Part_31364_419848518.1513720070734
Content-Type: multipart/alternative;
boundary="----=_Part_31365_255083765.1513720070735"
------=_Part_31365_255083765.1513720070735
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tuesday, December 19, 2017 at 4:02:44 PM UTC-5, Ricardo Andrade wrote:
>
> I don't think you understood Richard's suggestion...
>
> On Tue, Dec 19, 2017 at 12:05 PM, Thiago Macieira <thi...@macieira.org=20
> <javascript:>> wrote:
>
>> On ter=C3=A7a-feira, 19 de dezembro de 2017 06:57:30 PST Jake Arkinstall=
wrote:
>> > I will state this as a question because it's honestly something I woul=
d
>> > love to know: what harm does killing this undefined behaviour do?
>>
>> It makes the compiler insert unneeded code when it can't prove I have=20
>> taken
>> the necessary steps already.
>>
>>
> No, no code is added. The idea is:
> - A function which currently misses a return or throw statement is no=20
> longer UB, it's a compiler error
>
That wasn't the idea that Thiago was responding to. The idea that Marcin=20
suggested=20
<https://groups.google.com/a/isocpp.org/d/msg/std-proposals/Uu2QViiWh4k/0lS=
Ah3VhAgAJ>=20
was merely to make falling off the end of a function well-defined behavior:=
=20
terminate execution. His point being that it makes it easier to find out=20
why something went wrong if you get a crash in the function where it=20
actually went wrong. Thiago's counter was that it's inserting code where=20
code doesn't strictly need to be inserted.
>
--=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/998e0c0d-5e8e-4583-8aae-ac23652d918d%40isocpp.or=
g.
------=_Part_31365_255083765.1513720070735
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, December 19, 2017 at 4:02:44 PM UTC-5,=
Ricardo Andrade wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr">I don't think you understood Richard's suggestion...<br><=
div><br><div class=3D"gmail_quote">On Tue, Dec 19, 2017 at 12:05 PM, Thiago=
Macieira <span dir=3D"ltr"><<a onmousedown=3D"this.href=3D'javascri=
pt:';return true;" onclick=3D"this.href=3D'javascript:';return =
true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscat=
ed-mailto=3D"MU3mKdCkBQAJ">thi...@macieira.org</a>></span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex">On ter=C3=A7a-feira, 19 de d=
ezembro de 2017 06:57:30 PST Jake Arkinstall wrote:<br>
> I will state this as a question because it's honestly something I =
would<br>
> love to know: what harm does killing this undefined behaviour do?<br>
<br>
It makes the compiler insert unneeded code when it can't prove I have t=
aken<br>
the necessary steps already.<br>
<br></blockquote><div><br></div><div>No, no code is added. The idea is:</di=
v><div>- A function which currently misses a return or throw statement is n=
o longer UB, it's a compiler error<br></div></div></div></div></blockqu=
ote><div><br></div><div>That wasn't the idea that Thiago was responding=
to. <a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/=
Uu2QViiWh4k/0lSAh3VhAgAJ">The idea that Marcin suggested</a> was merely to =
make falling off the end of a function well-defined behavior: terminate exe=
cution. His point being that it makes it easier to find out why something w=
ent wrong if you get a crash in the function where it actually went wrong. =
Thiago's counter was that it's inserting code where code doesn'=
t strictly need to be inserted.<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;">
</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/998e0c0d-5e8e-4583-8aae-ac23652d918d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/998e0c0d-5e8e-4583-8aae-ac23652d918d=
%40isocpp.org</a>.<br />
------=_Part_31365_255083765.1513720070735--
------=_Part_31364_419848518.1513720070734--
.
Author: Justin Bassett <jbassett271@gmail.com>
Date: Tue, 19 Dec 2017 13:55:11 -0800
Raw View
--001a114c5c9e7309db0560b8853a
Content-Type: text/plain; charset="UTF-8"
>
>
> Sorry to be sarcastic, but you're basically saying "if we ignore or solve
> all
> the problems, then there are no problems".
>
>
Yeah that's close to what I'm saying. If we can figure out what is bad
about breaking changes and address them, how is that not a good thing? It
could be valuable to be able to make breaking changes in the future, even
if this is not one of them.
> We can't ignore that there's a language, with a defined syntax, and
> billions
> of lines of code that would need to be scanned and updated.
>
That's very true. It's not cheap to scan through millions/billions of lines
of code and update where needed. Even if such a tool existed, I don't think
it would be a good idea to require use of the tool more often than rarely.
But is it really so expensive that we cannot afford to do it even once?
--
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/CAPuuy5cAPcu1%3DYCs1RDfE%3DJSpG5wkrgskevc%3DhuL%3DXw80-uk%3Dg%40mail.gmail.com.
--001a114c5c9e7309db0560b8853a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><span class=3D""><br>
</span>Sorry to be sarcastic, but you're basically saying "if we i=
gnore or solve all<br>
the problems, then there are no problems".<br>
<br></blockquote><div>=C2=A0</div><div>Yeah that's close to what I'=
m saying. If we can figure out what is bad about breaking changes and addre=
ss them, how is that not a good thing? It could be valuable to be able to m=
ake breaking changes in the future, even if this is not one of them.</div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">
We can't ignore that there's a language, with a defined syntax, and=
billions<br>
of lines of code that would need to be scanned and updated.<br></blockquote=
><div><br></div><div>That's very true. It's not cheap to scan throu=
gh millions/billions of lines of code and update where needed. Even if such=
a tool existed, I don't think it would be a good idea to require use o=
f the tool more often than rarely. But is it really so expensive that we ca=
nnot afford to do it even once?</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/CAPuuy5cAPcu1%3DYCs1RDfE%3DJSpG5wkrgs=
kevc%3DhuL%3DXw80-uk%3Dg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPuuy5=
cAPcu1%3DYCs1RDfE%3DJSpG5wkrgskevc%3DhuL%3DXw80-uk%3Dg%40mail.gmail.com</a>=
..<br />
--001a114c5c9e7309db0560b8853a--
.
Author: Justin Bassett <jbassett271@gmail.com>
Date: Tue, 19 Dec 2017 13:55:40 -0800
Raw View
--f40304360c68332c370560b887ee
Content-Type: text/plain; charset="UTF-8"
>
>
> Pretty much every tool for parsing and "correcting" C++ to some new
> standard runs afoul of macros. So long as there are big macro-libraries
> that generate lots of C++ boilerplate, we cannot successfully automate even
> the most basic of corrections.
>
>
At some point, is it worth trying to solve it? In C++11, UDLs were added,
which was a breaking change, such as with the format macro constants. But
the benefits were considered good enough that they outweighed the breaking
of existing code, which could be fixed by adding a space. So what if this
said tool gives up when it finds macros and points them out to the user,
saying, "I can't handle these macros automatically, you need to do some
manual editing." Are macros really used so much for generating entire
functions that this case will come up frequently?
--
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/CAPuuy5dU4gUQtvFYZ2fzHHeRR9Md7e011xiy8Yt_cFL2m2xyWA%40mail.gmail.com.
--f40304360c68332c370560b887ee
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>Pretty much=
every tool for parsing and "correcting" C++ to some new standard=
runs afoul of macros. So long as there are big macro-libraries that genera=
te lots of C++ boilerplate, we cannot successfully automate even the most b=
asic of corrections.</div><div><br></div></div></blockquote><div><br></div>=
<div>At some point, is it worth trying to solve it? In C++11, UDLs were add=
ed, which was a breaking change, such as with the format macro constants. B=
ut the benefits were considered good enough that they outweighed the breaki=
ng of existing code, which could be fixed by adding a space. So what if thi=
s said tool gives up when it finds macros and points them out to the user, =
saying, "I can't handle these macros automatically, you need to do=
some manual editing." Are macros really used so much for generating e=
ntire functions that this case will come up frequently?</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/CAPuuy5dU4gUQtvFYZ2fzHHeRR9Md7e011xiy=
8Yt_cFL2m2xyWA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPuuy5dU4gUQtvFY=
Z2fzHHeRR9Md7e011xiy8Yt_cFL2m2xyWA%40mail.gmail.com</a>.<br />
--f40304360c68332c370560b887ee--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 19 Dec 2017 14:51:45 -0800
Raw View
On ter=C3=A7a-feira, 19 de dezembro de 2017 13:02:39 PST Ricardo Fabiano de=
Andrade=20
wrote:
> On Tue, Dec 19, 2017 at 12:05 PM, Thiago Macieira <thiago@macieira.org>
> wrote:
> > On ter=C3=A7a-feira, 19 de dezembro de 2017 06:57:30 PST Jake Arkinstal=
l wrote:
> > > I will state this as a question because it's honestly something I wou=
ld
> > > love to know: what harm does killing this undefined behaviour do?
> >=20
> > It makes the compiler insert unneeded code when it can't prove I have
> > taken
> > the necessary steps already.
>=20
> No, no code is added. The idea is:
> - A function which currently misses a return or throw statement is no
> longer UB, it's a compiler error
So the perfectly valid function I have is no longer valid. I would need to=
=20
modify it and insert something there to make it valid again.
> - Unless a new attribute is used to state the intention to leave the
> function as is.
As discussed, an attribute will not be accepted by the committee to allow=
=20
changing an otherwise-invalid program back to valid. So the attribute alone=
=20
won't help me. I'd need to do:
[[unreachable]];
return dummy;
Which in turn means I have to ensure there is a suitably dummy value to ins=
ert=20
in that statement. And since a compiler may not yet implement the=20
[[unreachable]] attribute, it would mean the compiler is back again at=20
generating code I don't need.
I want to point out that the above is exactly what I do today and what I=20
insist in code reviews from contributors, but that's a *choice* I have. I k=
now=20
which compilers do not have the suitable unreachability marker and will=20
produce code and which users will be penalised.
See for yourself:
https://godbolt.org/g/wZavUH
https://godbolt.org/g/9soXLj
ICC supports both __assume(0) and __builtin_unreachable(), but its dead cod=
e=20
eliminator isn't as good as the other three's.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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/34405323.kbXR0CtUYz%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 19 Dec 2017 14:54:47 -0800
Raw View
On ter=C3=A7a-feira, 19 de dezembro de 2017 13:55:11 PST Justin Bassett wro=
te:
> But is it really so expensive that we cannot afford to do it even once?
Given the experience from Python 2 and 3, Qt 3, 4 and 5, yes.
You can provide the best tool and people will still target the old version=
=20
because they afford to run it, for any reason.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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/6821083.aV8Rit7lne%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 19 Dec 2017 15:02:48 -0800
Raw View
On ter=C3=A7a-feira, 19 de dezembro de 2017 13:55:40 PST Justin Bassett wro=
te:
> At some point, is it worth trying to solve it? In C++11, UDLs were added,
> which was a breaking change, such as with the format macro constants. But
> the benefits were considered good enough that they outweighed the breakin=
g
> of existing code, which could be fixed by adding a space. So what if this
> said tool gives up when it finds macros and points them out to the user,
> saying, "I can't handle these macros automatically, you need to do some
> manual editing." Are macros really used so much for generating entire
> functions that this case will come up frequently?
It's a matter of benefit vs cost, not just of writing the tool, but that of=
=20
running it in existing, stable codebases. How big is the cost of manually=
=20
correcting what the tool won't catch?
Yes, there have been prior breaking changes, like auto and string=20
concatenation with macros. Those were weighed against the cost and found to=
be=20
worth it. Moreover, those also had backwards-compatible solutions: auto sim=
ply=20
had to be deleted from wherever it was used, a space needed to be added=20
between as string and a macro that was #defined to a string.
The cost of the solution for forgetting a return is greater. It happens far=
=20
more often than auto and it has no backwards-compatible 100% solution. We'd=
=20
need to (per current committee guidelines) introduce a new keyword or=20
construct, wait some 10 years so that compatibility will rise to 99%, then=
=20
make it mandatory.
And that's only for this specific change. You actually proposed a massive=
=20
language-breaking flag day. That will never happen to C++.
It will never happen because the other side of that break would be a fork o=
f=20
the language: C++ would continue to exist and a new language would be born.=
=20
Q.v. Python2 vs Python3 or XHTML 1.1 vs HTML5.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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/4617520.syT2OyPe6L%40tjmaciei-mobl1.
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Wed, 20 Dec 2017 00:18:38 +0100
Raw View
--001a1143e71ee2f1b20560b9affe
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Ricardo wrote:
> No, no code is added. The idea is:
> - A function which currently misses a return or throw statement is no
longer UB, it's a compiler error
> - Unless a new attribute is used to state the intention to leave the
function as is.
> (I am not debating here how the detection of what missing return/throw is
made or what other statements could used instead, i.e. assert or which is
the new attribute)
> Did I get it right Richard?
Right.
On 20 December 2017 at 00:02, Thiago Macieira <thiago@macieira.org> wrote:
> On ter=C3=A7a-feira, 19 de dezembro de 2017 13:55:40 PST Justin Bassett w=
rote:
> > At some point, is it worth trying to solve it? In C++11, UDLs were adde=
d,
> > which was a breaking change, such as with the format macro constants. B=
ut
> > the benefits were considered good enough that they outweighed the
> breaking
> > of existing code, which could be fixed by adding a space. So what if th=
is
> > said tool gives up when it finds macros and points them out to the user=
,
> > saying, "I can't handle these macros automatically, you need to do some
> > manual editing." Are macros really used so much for generating entire
> > functions that this case will come up frequently?
>
> It's a matter of benefit vs cost, not just of writing the tool, but that =
of
> running it in existing, stable codebases. How big is the cost of manually
> correcting what the tool won't catch?
>
> Yes, there have been prior breaking changes, like auto and string
> concatenation with macros. Those were weighed against the cost and found
> to be
> worth it. Moreover, those also had backwards-compatible solutions: auto
> simply
> had to be deleted from wherever it was used, a space needed to be added
> between as string and a macro that was #defined to a string.
>
> The cost of the solution for forgetting a return is greater. It happens f=
ar
> more often than auto and it has no backwards-compatible 100% solution. We=
'd
> need to (per current committee guidelines) introduce a new keyword or
> construct, wait some 10 years so that compatibility will rise to 99%, the=
n
> make it mandatory.
>
> And that's only for this specific change. You actually proposed a massive
> language-breaking flag day. That will never happen to C++.
>
> It will never happen because the other side of that break would be a fork
> of
> the language: C++ would continue to exist and a new language would be bor=
n.
> Q.v. Python2 vs Python3 or XHTML 1.1 vs HTML5.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
>
> --
> 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/4617520.syT2OyPe6L%40tjmaciei-mobl1.
>
--=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/CALvx3hZRw6N2BZFc_dgKfuuXj_Y4CkqcjqDCZuXtExswhqD=
wUw%40mail.gmail.com.
--001a1143e71ee2f1b20560b9affe
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Ricardo wrote:<br><br><div>> No, no code is added. The =
idea is:</div><div>> - A function which currently misses a return or thr=
ow statement is no longer UB, it's a compiler error<br></div><div>> =
- Unless a new attribute is used to state the intention to leave the functi=
on as is.</div><div><br></div><div>> (I
am not debating here how the detection of what missing return/throw is=20
made or what other statements could used instead, i.e. assert or which=20
is the new attribute)<br></div><div><br></div><div>> Did I get it right =
Richard?</div><div><br></div><div>Right.</div><div><br></div></div><div cla=
ss=3D"gmail_extra"><br><div class=3D"gmail_quote">On 20 December 2017 at 00=
:02, Thiago Macieira <span dir=3D"ltr"><<a href=3D"mailto:thiago@macieir=
a.org" target=3D"_blank">thiago@macieira.org</a>></span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><span class=3D"">On ter=C3=A7a-feira, 19 de dezem=
bro de 2017 13:55:40 PST Justin Bassett wrote:<br>
> At some point, is it worth trying to solve it? In C++11, UDLs were add=
ed,<br>
> which was a breaking change, such as with the format macro constants. =
But<br>
> the benefits were considered good enough that they outweighed the brea=
king<br>
> of existing code, which could be fixed by adding a space. So what if t=
his<br>
> said tool gives up when it finds macros and points them out to the use=
r,<br>
> saying, "I can't handle these macros automatically, you need =
to do some<br>
> manual editing." Are macros really used so much for generating en=
tire<br>
> functions that this case will come up frequently?<br>
<br>
</span>It's a matter of benefit vs cost, not just of writing the tool, =
but that of<br>
running it in existing, stable codebases. How big is the cost of manually<b=
r>
correcting what the tool won't catch?<br>
<br>
Yes, there have been prior breaking changes, like auto and string<br>
concatenation with macros. Those were weighed against the cost and found to=
be<br>
worth it. Moreover, those also had backwards-compatible solutions: auto sim=
ply<br>
had to be deleted from wherever it was used, a space needed to be added<br>
between as string and a macro that was #defined to a string.<br>
<br>
The cost of the solution for forgetting a return is greater. It happens far=
<br>
more often than auto and it has no backwards-compatible 100% solution. We&#=
39;d<br>
need to (per current committee guidelines) introduce a new keyword or<br>
construct, wait some 10 years so that compatibility will rise to 99%, then<=
br>
make it mandatory.<br>
<br>
And that's only for this specific change. You actually proposed a massi=
ve<br>
language-breaking flag day. That will never happen to C++.<br>
<br>
It will never happen because the other side of that break would be a fork o=
f<br>
the language: C++ would continue to exist and a new language would be born.=
<br>
Q.v. Python2 vs Python3 or XHTML 1.1 vs HTML5.<br>
<span class=3D""><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
</span><span class=3D"">--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/4617520.syT2OyPe6L%40tjmaciei-=
mobl1" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/<wb=
r>isocpp.org/d/msgid/std-<wbr>proposals/4617520.syT2OyPe6L%<wbr>40tjmaciei-=
mobl1</a>.<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/CALvx3hZRw6N2BZFc_dgKfuuXj_Y4CkqcjqDC=
ZuXtExswhqDwUw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZRw6N2BZFc=
_dgKfuuXj_Y4CkqcjqDCZuXtExswhqDwUw%40mail.gmail.com</a>.<br />
--001a1143e71ee2f1b20560b9affe--
.
Author: Myriachan <myriachan@gmail.com>
Date: Tue, 19 Dec 2017 18:35:07 -0800 (PST)
Raw View
------=_Part_921_1479529162.1513737307414
Content-Type: multipart/alternative;
boundary="----=_Part_922_1974978042.1513737307414"
------=_Part_922_1974978042.1513737307414
Content-Type: text/plain; charset="UTF-8"
On Tuesday, December 19, 2017 at 2:51:49 PM UTC-8, Thiago Macieira wrote:
>
> As discussed, an attribute will not be accepted by the committee to allow
> changing an otherwise-invalid program back to valid. So the attribute
> alone
> won't help me. I'd need to do:
>
> [[unreachable]];
> return dummy;
>
> Which in turn means I have to ensure there is a suitably dummy value to
> insert
> in that statement. And since a compiler may not yet implement the
> [[unreachable]] attribute, it would mean the compiler is back again at
> generating code I don't need.
>
> I want to point out that the above is exactly what I do today and what I
> insist in code reviews from contributors, but that's a *choice* I have. I
> know
> which compilers do not have the suitable unreachability marker and will
> produce code and which users will be penalised.
>
> See for yourself:
>
> https://godbolt.org/g/wZavUH
> https://godbolt.org/g/9soXLj
>
> ICC supports both __assume(0) and __builtin_unreachable(), but its dead
> code
> eliminator isn't as good as the other three's.
>
>
In Toronto, for my unreachable proposal, the consensus of EWG was that
instead of [[unreachable]], it should be a function called
std::unreachable(). I'll submit an updated proposal for the Jacksonville
meeting.
[[noreturn]] void unreachable();
[[noreturn]] void unreachable(const char *);
Melissa
--
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/7dac8d2e-b643-4458-8f44-e24cf68e66c9%40isocpp.org.
------=_Part_922_1974978042.1513737307414
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, December 19, 2017 at 2:51:49 PM UTC-8, Thiago =
Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">As discussed, a=
n attribute will not be accepted by the committee to allow=20
<br>changing an otherwise-invalid program back to valid. So the attribute a=
lone=20
<br>won't help me. I'd need to do:
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[[unreachable]];
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0return dummy;
<br>
<br>Which in turn means I have to ensure there is a suitably dummy value to=
insert=20
<br>in that statement. And since a compiler may not yet implement the=20
<br>[[unreachable]] attribute, it would mean the compiler is back again at=
=20
<br>generating code I don't need.
<br>
<br>I want to point out that the above is exactly what I do today and what =
I=20
<br>insist in code reviews from contributors, but that's a *choice* I h=
ave. I know=20
<br>which compilers do not have the suitable unreachability marker and will=
=20
<br>produce code and which users will be penalised.
<br>
<br>See for yourself:
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<a href=3D"https://godb=
olt.org/g/wZavUH" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgodbolt.org%2Fg%2Fw=
ZavUH\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHBbno3sJu4YgA1MZLB6uo8ZYhl9g&=
#39;;return true;" onclick=3D"this.href=3D'https://www.google.com/url?q=
\x3dhttps%3A%2F%2Fgodbolt.org%2Fg%2FwZavUH\x26sa\x3dD\x26sntz\x3d1\x26usg\x=
3dAFQjCNHBbno3sJu4YgA1MZLB6uo8ZYhl9g';return true;">https://godbolt.org=
/g/<wbr>wZavUH</a>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<a href=3D"https://godb=
olt.org/g/9soXLj" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgodbolt.org%2Fg%2F9=
soXLj\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFJIK0gjgC9jANnHXmX1AIWhRlEFQ&=
#39;;return true;" onclick=3D"this.href=3D'https://www.google.com/url?q=
\x3dhttps%3A%2F%2Fgodbolt.org%2Fg%2F9soXLj\x26sa\x3dD\x26sntz\x3d1\x26usg\x=
3dAFQjCNFJIK0gjgC9jANnHXmX1AIWhRlEFQ';return true;">https://godbolt.org=
/g/<wbr>9soXLj</a>
<br>
<br>ICC supports both __assume(0) and __builtin_unreachable(), but its dead=
code=20
<br>eliminator isn't as good as the other three's.
<br>
<br></blockquote><div><br></div><div>In Toronto, for my unreachable proposa=
l, the consensus of EWG was that instead of [[unreachable]], it should be a=
function called std::unreachable().=C2=A0 I'll submit an updated propo=
sal for the Jacksonville meeting.</div><div><br></div><div>[[noreturn]] voi=
d unreachable();</div><div>[[noreturn]] void unreachable(const char *);</di=
v><div></div><br><div>Melissa<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/7dac8d2e-b643-4458-8f44-e24cf68e66c9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7dac8d2e-b643-4458-8f44-e24cf68e66c9=
%40isocpp.org</a>.<br />
------=_Part_922_1974978042.1513737307414--
------=_Part_921_1479529162.1513737307414--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Tue, 19 Dec 2017 22:48:09 -0800 (PST)
Raw View
------=_Part_1500_1167058759.1513752489569
Content-Type: multipart/alternative;
boundary="----=_Part_1501_537655222.1513752489570"
------=_Part_1501_537655222.1513752489570
Content-Type: text/plain; charset="UTF-8"
> In Toronto, for my unreachable proposal, the consensus of EWG was that
instead of [[unreachable]], it should be a function called
std::unreachable(). I'll submit an updated proposal for the Jacksonville
meeting.
Wonderful. This looks like progress.
Revisiting our examples deliberate non-returning functions again, it seems
to me that all the arguments for allowing a function to return something on
an unexecuted path are based on a false premise.
The argument goes, "by having some code paths do UB I can get faster code".
In the example of:
const char* foo(int x) {
if (x == 0) return "no";
if (x == 1) return "yes";
}
gcc actually produces this:
foo(int):
test edi, edi
mov eax, OFFSET FLAT:.LC0
je .L1
mov eax, OFFSET FLAT:.LC1
..L1:
rep ret
So it has effectively re-written the function thus:
const char* foo(int x) {
if (x == 0) return "no";
return "yes";
}
The irony here is that if I actually write that (i.e. express intent
explicitly and actually code in the U of B) the same compiler, with the
same command line settings gives me this:
foo(int):
test edi, edi
mov edx, OFFSET FLAT:.LC1
mov eax, OFFSET FLAT:.LC0
cmovne rax, rdx
ret
Which is better code.
Explain to me again how developers get better performance by leaving UB
paths in template leaf functions? This argument is just nonsense.
The actual fact of the matter is that UB *prevents* optimisations. The ISO
c++ committee would do the community a great service by preventing it
wherever possible.
In the case of a non-taken return path, it is always possible to express
the algorithm correctly. There is no need for c++ to allow this sloppy
approach.
On Wednesday, 20 December 2017 03:35:07 UTC+1, Myriachan wrote:
>
> On Tuesday, December 19, 2017 at 2:51:49 PM UTC-8, Thiago Macieira wrote:
>>
>> As discussed, an attribute will not be accepted by the committee to allow
>> changing an otherwise-invalid program back to valid. So the attribute
>> alone
>> won't help me. I'd need to do:
>>
>> [[unreachable]];
>> return dummy;
>>
>> Which in turn means I have to ensure there is a suitably dummy value to
>> insert
>> in that statement. And since a compiler may not yet implement the
>> [[unreachable]] attribute, it would mean the compiler is back again at
>> generating code I don't need.
>>
>> I want to point out that the above is exactly what I do today and what I
>> insist in code reviews from contributors, but that's a *choice* I have. I
>> know
>> which compilers do not have the suitable unreachability marker and will
>> produce code and which users will be penalised.
>>
>> See for yourself:
>>
>> https://godbolt.org/g/wZavUH
>> https://godbolt.org/g/9soXLj
>>
>> ICC supports both __assume(0) and __builtin_unreachable(), but its dead
>> code
>> eliminator isn't as good as the other three's.
>>
>>
> In Toronto, for my unreachable proposal, the consensus of EWG was that
> instead of [[unreachable]], it should be a function called
> std::unreachable(). I'll submit an updated proposal for the Jacksonville
> meeting.
>
> [[noreturn]] void unreachable();
> [[noreturn]] void unreachable(const char *);
>
> Melissa
>
--
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/46aa7abb-185e-4f20-9211-e7a443b78d77%40isocpp.org.
------=_Part_1501_537655222.1513752489570
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">> In Toronto, for my unreachable proposal, the consensu=
s of EWG was that instead of [[unreachable]], it should be a function calle=
d std::unreachable().=C2=A0 I'll submit an updated proposal for the Jac=
ksonville meeting.<div><br></div><div>Wonderful. This looks like progress.<=
/div><div><br></div><div>Revisiting our examples deliberate non-returning f=
unctions again, it seems to me that all the arguments for allowing a functi=
on to return something on an unexecuted path are based on a false premise.<=
/div><div><br></div><div>The argument goes, "by having some code paths=
do UB I can get faster code".</div><div><br></div><div>In the example=
of:</div><div><font face=3D"courier new, monospace"><br></font></div><div>=
<div style=3D"color: rgb(0, 0, 0); background-color: rgb(255, 255, 254); fo=
nt-size: 14px; line-height: 21px; white-space: pre;"><div style=3D""><font =
face=3D"courier new, monospace"><span style=3D"color: #0000ff;">const</span=
> <span style=3D"color: #0000ff;">char</span>* foo(<span style=3D"color: #0=
000ff;">int</span> x) { </font></div><div style=3D""><font face=3D"courier =
new, monospace"> <span style=3D"color: #0000ff;">if</span> (x =3D=3D <sp=
an style=3D"color: #09885a;">0</span>) <span style=3D"color: #0000ff;">retu=
rn</span> <span style=3D"color: #a31515;">"no"</span>;</font></di=
v><div style=3D""><font face=3D"courier new, monospace"> <span style=3D"=
color: #0000ff;">if</span> (x =3D=3D <span style=3D"color: #09885a;">1</spa=
n>) <span style=3D"color: #0000ff;">return</span> <span style=3D"color: #a3=
1515;">"yes"</span>;</font></div><div style=3D""><font face=3D"co=
urier new, monospace">}</font></div><br></div><div style=3D"color: rgb(0, 0=
, 0); background-color: rgb(255, 255, 254); font-size: 14px; line-height: 2=
1px; white-space: pre;">gcc actually produces this:</div><div style=3D"colo=
r: rgb(0, 0, 0); background-color: rgb(255, 255, 254); font-size: 14px; lin=
e-height: 21px; white-space: pre;"><br></div><div style=3D"color: rgb(0, 0,=
0); background-color: rgb(255, 255, 254); font-size: 14px; line-height: 21=
px; white-space: pre;"><div style=3D"line-height: 21px;"><div style=3D""><s=
pan style=3D"color: rgb(0, 128, 128);"><font face=3D"courier new, monospace=
">foo(int):</font></span></div><div style=3D""><font face=3D"courier new, m=
onospace"> <span style=3D"color: #0000ff;">test</span> <span styl=
e=3D"color: #4864aa;">edi</span>, <span style=3D"color: #4864aa;">edi</span=
></font></div><div style=3D""><font face=3D"courier new, monospace"> =
<span style=3D"color: #0000ff;">mov</span> <span style=3D"color: #4864=
aa;">eax</span>, <span style=3D"color: #008080;">OFFSET</span> <span style=
=3D"color: #008080;">FLAT</span>:<span style=3D"color: #008080;">.LC0</span=
></font></div><div style=3D""><font face=3D"courier new, monospace"> =
<span style=3D"color: #0000ff;">je</span> <span style=3D"color: #0080=
80;">.L1</span></font></div><div style=3D""><font face=3D"courier new, mono=
space"> <span style=3D"color: #0000ff;">mov</span> <span style=
=3D"color: #4864aa;">eax</span>, <span style=3D"color: #008080;">OFFSET</sp=
an> <span style=3D"color: #008080;">FLAT</span>:<span style=3D"color: #0080=
80;">.LC1</span></font></div><div style=3D""><span style=3D"color: #008080;=
"><font face=3D"courier new, monospace">.L1:</font></span></div><div style=
=3D""><font face=3D"courier new, monospace"> <span style=3D"color: #=
0000ff;">rep</span> <span style=3D"color: #008080;">ret</span></font></div>=
<div style=3D"font-family: "Fira Mono";"><span style=3D"color: #0=
08080;"><br></span></div></div></div><div>So it has effectively re-written =
the function thus:</div><div><br></div><div><div style=3D"color: rgb(0, 0, =
0); background-color: rgb(255, 255, 254); font-size: 14px; line-height: 21p=
x; white-space: pre;"><div style=3D""><font face=3D"courier new, monospace"=
><span style=3D"color: rgb(0, 0, 255);">const</span> <span style=3D"color: =
rgb(0, 0, 255);">char</span>* foo(<span style=3D"color: rgb(0, 0, 255);">in=
t</span> x) { </font></div><div style=3D""><font face=3D"courier new, monos=
pace"> <span style=3D"color: #0000ff;">if</span> (x =3D=3D <span style=
=3D"color: #09885a;">0</span>) <span style=3D"color: #0000ff;">return</span=
> <span style=3D"color: #a31515;">"no"</span>;</font></div><div s=
tyle=3D""><font face=3D"courier new, monospace"> <span style=3D"color: #=
0000ff;">return</span> <span style=3D"color: #a31515;">"yes"</spa=
n>;</font></div><div style=3D""><font face=3D"courier new, monospace">}</fo=
nt></div><br></div></div><div>The irony here is that if I actually write th=
at (i.e. express intent explicitly and actually code in the U of B) the sam=
e compiler, with the same command line settings gives me this:</div><div><b=
r></div><div><div style=3D"color: rgb(0, 0, 0); background-color: rgb(255, =
255, 254); font-size: 14px; line-height: 21px; white-space: pre;"><div styl=
e=3D""><span style=3D"color: rgb(0, 128, 128);"><font face=3D"courier new, =
monospace">foo(int):</font></span></div><div style=3D""><font face=3D"couri=
er new, monospace"> <span style=3D"color: #0000ff;">test</span> <=
span style=3D"color: #4864aa;">edi</span>, <span style=3D"color: #4864aa;">=
edi</span></font></div><div style=3D""><font face=3D"courier new, monospace=
"> <span style=3D"color: #0000ff;">mov</span> <span style=3D"col=
or: #4864aa;">edx</span>, <span style=3D"color: #008080;">OFFSET</span> <sp=
an style=3D"color: #008080;">FLAT</span>:<span style=3D"color: #008080;">.L=
C1</span></font></div><div style=3D""><font face=3D"courier new, monospace"=
> <span style=3D"color: #0000ff;">mov</span> <span style=3D"colo=
r: #4864aa;">eax</span>, <span style=3D"color: #008080;">OFFSET</span> <spa=
n style=3D"color: #008080;">FLAT</span>:<span style=3D"color: #008080;">.LC=
0</span></font></div><div style=3D""><font face=3D"courier new, monospace">=
<span style=3D"color: #0000ff;">cmovne</span> <span style=3D"color=
: #4864aa;">rax</span>, <span style=3D"color: #4864aa;">rdx</span></font></=
div><div style=3D""><font face=3D"courier new, monospace"> <span sty=
le=3D"color: #0000ff;">ret</span></font></div></div></div><br>Which is bett=
er code.</div><div><br></div><div>Explain to me again how developers get be=
tter performance by leaving UB paths in template leaf functions? This argum=
ent is just nonsense.</div><div><br></div><div>The actual fact of the matte=
r is that UB *prevents* optimisations. The ISO c++ committee would do the c=
ommunity a great service by preventing it wherever possible.</div><div><br>=
</div><div>In the case of a non-taken return path, it is always possible to=
express the algorithm correctly. There is no need for c++ to allow this sl=
oppy approach.</div><div><br></div><div><br></div><div>On Wednesday, 20 Dec=
ember 2017 03:35:07 UTC+1, Myriachan wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr">On Tuesday, December 19, 2017 at 2:51:49 PM =
UTC-8, Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">As dis=
cussed, an attribute will not be accepted by the committee to allow=20
<br>changing an otherwise-invalid program back to valid. So the attribute a=
lone=20
<br>won't help me. I'd need to do:
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[[unreachable]];
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0return dummy;
<br>
<br>Which in turn means I have to ensure there is a suitably dummy value to=
insert=20
<br>in that statement. And since a compiler may not yet implement the=20
<br>[[unreachable]] attribute, it would mean the compiler is back again at=
=20
<br>generating code I don't need.
<br>
<br>I want to point out that the above is exactly what I do today and what =
I=20
<br>insist in code reviews from contributors, but that's a *choice* I h=
ave. I know=20
<br>which compilers do not have the suitable unreachability marker and will=
=20
<br>produce code and which users will be penalised.
<br>
<br>See for yourself:
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<a href=3D"https://godb=
olt.org/g/wZavUH" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.hr=
ef=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgodbolt.org%2Fg%2Fw=
ZavUH\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHBbno3sJu4YgA1MZLB6uo8ZYhl9g&=
#39;;return true;" onclick=3D"this.href=3D'https://www.google.com/url?q=
\x3dhttps%3A%2F%2Fgodbolt.org%2Fg%2FwZavUH\x26sa\x3dD\x26sntz\x3d1\x26usg\x=
3dAFQjCNHBbno3sJu4YgA1MZLB6uo8ZYhl9g';return true;">https://godbolt.org=
/g/<wbr>wZavUH</a>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<a href=3D"https://godb=
olt.org/g/9soXLj" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.hr=
ef=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgodbolt.org%2Fg%2F9=
soXLj\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFJIK0gjgC9jANnHXmX1AIWhRlEFQ&=
#39;;return true;" onclick=3D"this.href=3D'https://www.google.com/url?q=
\x3dhttps%3A%2F%2Fgodbolt.org%2Fg%2F9soXLj\x26sa\x3dD\x26sntz\x3d1\x26usg\x=
3dAFQjCNFJIK0gjgC9jANnHXmX1AIWhRlEFQ';return true;">https://godbolt.org=
/g/<wbr>9soXLj</a>
<br>
<br>ICC supports both __assume(0) and __builtin_unreachable(), but its dead=
code=20
<br>eliminator isn't as good as the other three's.
<br>
<br></blockquote><div><br></div><div>In Toronto, for my unreachable proposa=
l, the consensus of EWG was that instead of [[unreachable]], it should be a=
function called std::unreachable().=C2=A0 I'll submit an updated propo=
sal for the Jacksonville meeting.</div><div><br></div><div>[[noreturn]] voi=
d unreachable();</div><div>[[noreturn]] void unreachable(const char *);</di=
v><div></div><br><div>Melissa<br></div></div></blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/46aa7abb-185e-4f20-9211-e7a443b78d77%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/46aa7abb-185e-4f20-9211-e7a443b78d77=
%40isocpp.org</a>.<br />
------=_Part_1501_537655222.1513752489570--
------=_Part_1500_1167058759.1513752489569--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 20 Dec 2017 00:16:27 -0800
Raw View
On ter=C3=A7a-feira, 19 de dezembro de 2017 22:48:09 PST Richard Hodges wro=
te:
> Revisiting our examples deliberate non-returning functions again, it seem=
s
> to me that all the arguments for allowing a function to return something =
on
> an unexecuted path are based on a false premise.
>=20
> The argument goes, "by having some code paths do UB I can get faster code=
".
That's not the argument. The argument is "by not having some code paths, I =
get=20
faster and/or smaller code".
> In the example of:
>=20
> const char* foo(int x) {
> if (x =3D=3D 0) return "no";
> if (x =3D=3D 1) return "yes";
> }
That was not the example. It was using a switch. So let me change it on you=
to=20
make it more specific:
enum Values { E1, E2 };
const char *foo(Values v)
{
switch (v) {
case E1:
return "no";
case E2:
return "yes";
}
}
There's a distinct advantage in using a switch and not having a default:=20
label: the compiler can warn me if I forgot any of the enumerations. So if =
a=20
later version of my code does add E3, I can get a compiler warning.
So now do your thing. Tell me how to write better code without losing that=
=20
warning.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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/17204456.OZKWC7E4z5%40tjmaciei-mobl1.
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Wed, 20 Dec 2017 11:53:47 +0100
Raw View
--f403045c4866e7c3de0560c36551
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thiago rather sullenly said:
> That was not the example. It was using a switch. So let me change it on
you to
> make it more specific:
> enum Values { E1, E2 };
> const char *foo(Values v)
> {
> switch (v) {
> case E1:
> return "no";
> case E2:
> return "yes";
> }
>}
> There's a distinct advantage in using a switch and not having a default:
> label: the compiler can warn me if I forgot any of the enumerations. So
if a
>later version of my code does add E3, I can get a compiler warning.
Sure, so now let's refactor the function into the same logic with no UB:
enum Values { E1, E2 };
const char *foo(Values v)
{
const char* result =3D "no";
switch (v) {
case E1: break;
case E2: result =3D "yes"; break;
}
return result;
}
And then let's look at gcc's output using the same compiler switches as
before:
foo(Values):
cmp edi, 1
mov edx, OFFSET FLAT:.LC0
mov eax, OFFSET FLAT:.LC1
cmovne rax, rdx
ret
Oh look! No UB, compiler warnings for unhandled cases and... perfect code.
Please feel free to offer more non-examples. "Richard's UB-Removal Service"
is at your disposal.
There is absolutely no reason to allow a return path that does not return a
value. The fact that c++ does is not a design decision. It's merely an
ancient artefact of K&R C. It is an error to allow it in the language.
On 20 December 2017 at 09:16, Thiago Macieira <thiago@macieira.org> wrote:
> On ter=C3=A7a-feira, 19 de dezembro de 2017 22:48:09 PST Richard Hodges w=
rote:
> > Revisiting our examples deliberate non-returning functions again, it
> seems
> > to me that all the arguments for allowing a function to return somethin=
g
> on
> > an unexecuted path are based on a false premise.
> >
> > The argument goes, "by having some code paths do UB I can get faster
> code".
>
> That's not the argument. The argument is "by not having some code paths, =
I
> get
> faster and/or smaller code".
>
> > In the example of:
> >
> > const char* foo(int x) {
> > if (x =3D=3D 0) return "no";
> > if (x =3D=3D 1) return "yes";
> > }
>
> That was not the example. It was using a switch. So let me change it on
> you to
> make it more specific:
>
> enum Values { E1, E2 };
>
> const char *foo(Values v)
> {
> switch (v) {
> case E1:
> return "no";
> case E2:
> return "yes";
> }
> }
>
> There's a distinct advantage in using a switch and not having a default:
> label: the compiler can warn me if I forgot any of the enumerations. So i=
f
> a
> later version of my code does add E3, I can get a compiler warning.
>
> So now do your thing. Tell me how to write better code without losing tha=
t
> warning.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
>
> --
> 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/17204456.OZKWC7E4z5%40tjmaciei-mobl1.
>
--=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/CALvx3hafVPg7YDvOHRt6uHbSpnh7X%2BjXy35wWjQWba2KZ=
KGPrw%40mail.gmail.com.
--f403045c4866e7c3de0560c36551
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thiago rather sullenly said:<div><br></div><div>> That =
was not the example. It was using a switch. So let me change it on you to<b=
r>> make it more specific:<br><br>> enum Values { E1, E2 };<br><br>&g=
t; const char *foo(Values v)<br>> {<br>>=C2=A0 =C2=A0 switch (v) {<br=
>>=C2=A0 =C2=A0 =C2=A0case E1:<br>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return=
"no";<br>>=C2=A0 =C2=A0 case E2:<br>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 return "yes";<br>>=C2=A0 =C2=A0 }<br>>}<br><br>> =
There's a distinct advantage in using a switch and not having a default=
:<br>> label: the compiler can warn me if I forgot any of the enumeratio=
ns. So if a<br>>later version of my code does add E3, I can get a compil=
er warning.<br><div><br></div><div>Sure, so now let's refactor the func=
tion into the same logic with no UB:</div><div><br></div><div><div style=3D=
"color:rgb(0,0,0);background-color:rgb(255,255,254);font-size:14px;line-hei=
ght:21px;white-space:pre"><div><font face=3D"monospace, monospace"><span st=
yle=3D"color:rgb(0,0,255)">enum</span> Values { E1, E2 };</font></div><font=
face=3D"monospace, monospace"><br></font></div></div><div><div style=3D"co=
lor:rgb(0,0,0);background-color:rgb(255,255,254);font-size:14px;line-height=
:21px;white-space:pre"><div><font face=3D"monospace, monospace"><span style=
=3D"color:rgb(0,0,255)">const</span> <span style=3D"color:rgb(0,0,255)">cha=
r</span> *foo(Values v)</font></div><div><font face=3D"monospace, monospace=
">{</font></div><div><font face=3D"monospace, monospace"> <span style=3D=
"color:rgb(0,0,255)">const</span> <span style=3D"color:rgb(0,0,255)">char</=
span>* result =3D <span style=3D"color:rgb(163,21,21)">"no"</span=
>;</font></div><div><font face=3D"monospace, monospace"> <span style=3D"=
color:rgb(0,0,255)">switch</span> (v) {</font></div><div><font face=3D"mono=
space, monospace"> <span style=3D"color:rgb(0,0,255)">case</span> E1: <s=
pan style=3D"color:rgb(0,0,255)">break</span>;</font></div><div><font face=
=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">case</span=
> E2: result =3D <span style=3D"color:rgb(163,21,21)">"yes"</span=
>; <span style=3D"color:rgb(0,0,255)">break</span>;</font></div><div><font =
face=3D"monospace, monospace"> }</font></div><div><font face=3D"monospac=
e, monospace"> <span style=3D"color:rgb(0,0,255)">return</span> result;<=
/font></div><div><font face=3D"monospace, monospace">}</font></div><font fa=
ce=3D"Fira Mono">And then let's look at gcc's output using the same=
compiler switches as before:</font></div></div><div style=3D"color:rgb(0,0=
,0);background-color:rgb(255,255,254);font-size:14px;line-height:21px;white=
-space:pre"><font face=3D"Fira Mono"><br></font></div><div style=3D"color:r=
gb(0,0,0);background-color:rgb(255,255,254);font-size:14px;line-height:21px=
;white-space:pre"><div style=3D"line-height:21px"><div style=3D""><span sty=
le=3D"color:rgb(0,128,128)"><font face=3D"monospace, monospace">foo(Values)=
:</font></span></div><div style=3D""><font face=3D"monospace, monospace"> =
<span style=3D"color:rgb(0,0,255)">cmp</span> <span style=3D"colo=
r:rgb(72,100,170)">edi</span>, <span style=3D"color:rgb(9,136,90)">1</span>=
</font></div><div style=3D""><font face=3D"monospace, monospace"> <s=
pan style=3D"color:rgb(0,0,255)">mov</span> <span style=3D"color:rgb(72=
,100,170)">edx</span>, <span style=3D"color:rgb(0,128,128)">OFFSET</span> <=
span style=3D"color:rgb(0,128,128)">FLAT</span>:<span style=3D"color:rgb(0,=
128,128)">.LC0</span></font></div><div style=3D""><font face=3D"monospace, =
monospace"> <span style=3D"color:rgb(0,0,255)">mov</span> <span =
style=3D"color:rgb(72,100,170)">eax</span>, <span style=3D"color:rgb(0,128,=
128)">OFFSET</span> <span style=3D"color:rgb(0,128,128)">FLAT</span>:<span =
style=3D"color:rgb(0,128,128)">.LC1</span></font></div><div style=3D""><fon=
t face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">=
cmovne</span> <span style=3D"color:rgb(72,100,170)">rax</span>, <span styl=
e=3D"color:rgb(72,100,170)">rdx</span></font></div><div style=3D""><font fa=
ce=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">ret<=
/span></font></div></div></div><div style=3D"color:rgb(0,0,0);background-co=
lor:rgb(255,255,254);font-family:"Fira Mono";font-size:14px;line-=
height:21px;white-space:pre"><br></div><div style=3D"color:rgb(0,0,0);backg=
round-color:rgb(255,255,254);font-family:"Fira Mono";font-size:14=
px;line-height:21px;white-space:pre">Oh look! No UB, compiler warnings for =
unhandled cases and... perfect code.</div><div style=3D"color:rgb(0,0,0);ba=
ckground-color:rgb(255,255,254);font-family:"Fira Mono";font-size=
:14px;line-height:21px;white-space:pre"><br></div><div style=3D"color:rgb(0=
,0,0);background-color:rgb(255,255,254);font-family:"Fira Mono";f=
ont-size:14px;line-height:21px;white-space:pre">Please feel free to offer m=
ore non-examples. "Richard's UB-Removal Service" is at your d=
isposal.</div><div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,2=
54);font-family:"Fira Mono";font-size:14px;line-height:21px;white=
-space:pre"><br></div><div style=3D"color:rgb(0,0,0);background-color:rgb(2=
55,255,254);font-family:"Fira Mono";font-size:14px;line-height:21=
px;white-space:pre">There is absolutely no reason to allow a return path th=
at does not return a value. The fact that c++ does is not a design decision=
.. It's merely an ancient artefact of K&R C. It is an error to allow=
it in the language.</div><div style=3D"color:rgb(0,0,0);background-color:r=
gb(255,255,254);font-family:"Fira Mono";font-size:14px;line-heigh=
t:21px;white-space:pre"><br></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On 20 December 2017 at 09:16, Thiago Macieira <span dir=3D=
"ltr"><<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@m=
acieira.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><span class=3D"gmail-">On ter=C3=A7a-feira, 19 de dezembro de 2=
017 22:48:09 PST Richard Hodges wrote:<br>
> Revisiting our examples deliberate non-returning functions again, it s=
eems<br>
> to me that all the arguments for allowing a function to return somethi=
ng on<br>
> an unexecuted path are based on a false premise.<br>
><br>
> The argument goes, "by having some code paths do UB I can get fas=
ter code".<br>
<br>
</span>That's not the argument. The argument is "by not having som=
e code paths, I get<br>
faster and/or smaller code".<br>
<span class=3D"gmail-"><br>
> In the example of:<br>
><br>
> const char* foo(int x) {<br>
> if (x =3D=3D 0) return "no";<br>
> if (x =3D=3D 1) return "yes";<br>
> }<br>
<br>
</span>That was not the example. It was using a switch. So let me change it=
on you to<br>
make it more specific:<br>
<br>
enum Values { E1, E2 };<br>
<br>
const char *foo(Values v)<br>
{<br>
=C2=A0 =C2=A0 switch (v) {<br>
=C2=A0 =C2=A0 case E1:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return "no";<br>
=C2=A0 =C2=A0 case E2:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return "yes";<br>
=C2=A0 =C2=A0 }<br>
}<br>
<br>
There's a distinct advantage in using a switch and not having a default=
:<br>
label: the compiler can warn me if I forgot any of the enumerations. So if =
a<br>
later version of my code does add E3, I can get a compiler warning.<br>
<br>
So now do your thing. Tell me how to write better code without losing that<=
br>
warning.<br>
<span class=3D"gmail-"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
</span><span class=3D"gmail-">--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/17204456.OZKWC7E4z5%40tjmaciei=
-mobl1" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/<w=
br>isocpp.org/d/msgid/std-<wbr>proposals/17204456.OZKWC7E4z5%<wbr>40tjmacie=
i-mobl1</a>.<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/CALvx3hafVPg7YDvOHRt6uHbSpnh7X%2BjXy3=
5wWjQWba2KZKGPrw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hafVPg7YD=
vOHRt6uHbSpnh7X%2BjXy35wWjQWba2KZKGPrw%40mail.gmail.com</a>.<br />
--f403045c4866e7c3de0560c36551--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 20 Dec 2017 12:08:13 +0000
Raw View
--f403045e6d8e1675700560c4706b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wed, Dec 20, 2017 at 10:53 AM, Richard Hodges <hodges.r@gmail.com> wrote=
:
> Thiago rather sullenly said:
>
> > That was not the example. It was using a switch. So let me change it on
> you to
> > make it more specific:
>
> > enum Values { E1, E2 };
>
> > const char *foo(Values v)
> > {
> > switch (v) {
> > case E1:
> > return "no";
> > case E2:
> > return "yes";
> > }
> >}
>
> > There's a distinct advantage in using a switch and not having a default=
:
> > label: the compiler can warn me if I forgot any of the enumerations. So
> if a
> >later version of my code does add E3, I can get a compiler warning.
>
> Sure, so now let's refactor the function into the same logic with no UB:
>
> enum Values { E1, E2 };
>
> const char *foo(Values v)
> {
> const char* result =3D "no";
> switch (v) {
> case E1: break;
> case E2: result =3D "yes"; break;
> }
> return result;
> }
>
I recognise that style is to some extent a matter of taste, but I would not
accept that code change.
Before: functional, SSA, symmetric, branching control flow.
After: imperative, mutating, asymmetric, braided control flow.
There is also the issue that your version leaves open the question of
whether non-enumerated values are permissible. This has the potential to
turn into a wide contract, impeding maintainability.
And what do you do if the return type has expensive assignment, is
non-assignable or immovable? Or if it is non-default constructible and its
ctors depend on the argument - a factory, say?
And then let's look at gcc's output using the same compiler switches as
> before:
>
> foo(Values):
> cmp edi, 1
> mov edx, OFFSET FLAT:.LC0
> mov eax, OFFSET FLAT:.LC1
> cmovne rax, rdx
> ret
>
> Oh look! No UB, compiler warnings for unhandled cases and... perfect code=
..
>
> Please feel free to offer more non-examples. "Richard's UB-Removal
> Service" is at your disposal.
>
> There is absolutely no reason to allow a return path that does not return
> a value. The fact that c++ does is not a design decision. It's merely an
> ancient artefact of K&R C. It is an error to allow it in the language.
>
>
> On 20 December 2017 at 09:16, Thiago Macieira <thiago@macieira.org> wrote=
:
>
>> On ter=C3=A7a-feira, 19 de dezembro de 2017 22:48:09 PST Richard Hodges =
wrote:
>> > Revisiting our examples deliberate non-returning functions again, it
>> seems
>> > to me that all the arguments for allowing a function to return
>> something on
>> > an unexecuted path are based on a false premise.
>> >
>> > The argument goes, "by having some code paths do UB I can get faster
>> code".
>>
>> That's not the argument. The argument is "by not having some code paths,
>> I get
>> faster and/or smaller code".
>>
>> > In the example of:
>> >
>> > const char* foo(int x) {
>> > if (x =3D=3D 0) return "no";
>> > if (x =3D=3D 1) return "yes";
>> > }
>>
>> That was not the example. It was using a switch. So let me change it on
>> you to
>> make it more specific:
>>
>> enum Values { E1, E2 };
>>
>> const char *foo(Values v)
>> {
>> switch (v) {
>> case E1:
>> return "no";
>> case E2:
>> return "yes";
>> }
>> }
>>
>> There's a distinct advantage in using a switch and not having a default:
>> label: the compiler can warn me if I forgot any of the enumerations. So
>> if a
>> later version of my code does add E3, I can get a compiler warning.
>>
>> So now do your thing. Tell me how to write better code without losing th=
at
>> warning.
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> Software Architect - Intel Open Source Technology Center
>>
>> --
>> 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-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/is
>> ocpp.org/d/msgid/std-proposals/17204456.OZKWC7E4z5%40tjmaciei-mobl1.
>>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CALvx3hafVPg7YDvOHRt6uHbSpnh7X
> %2BjXy35wWjQWba2KZKGPrw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hafVP=
g7YDvOHRt6uHbSpnh7X%2BjXy35wWjQWba2KZKGPrw%40mail.gmail.com?utm_medium=3Dem=
ail&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/CAJnLdOaTTe%3DDhd2qSzZUxRH5DgmdkGsWS5BA0VKUyv6rM=
ODTDg%40mail.gmail.com.
--f403045e6d8e1675700560c4706b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Dec 20, 2017 at 10:53 AM, Richard Hodges <span dir=3D"ltr"><<a href=
=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a>>=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Thiago ra=
ther sullenly said:<div><br></div><div><span class=3D"">> That was not t=
he example. It was using a switch. So let me change it on you to<br>> ma=
ke it more specific:<br><br>> enum Values { E1, E2 };<br><br>> const =
char *foo(Values v)<br>> {<br>>=C2=A0 =C2=A0 switch (v) {<br>>=C2=
=A0 =C2=A0 =C2=A0case E1:<br>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return "n=
o";<br>>=C2=A0 =C2=A0 case E2:<br>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 r=
eturn "yes";<br>>=C2=A0 =C2=A0 }<br>>}<br><br>> There=
9;s a distinct advantage in using a switch and not having a default:<br>>=
; label: the compiler can warn me if I forgot any of the enumerations. So i=
f a<br>>later version of my code does add E3, I can get a compiler warni=
ng.<br><div><br></div></span><div>Sure, so now let's refactor the funct=
ion into the same logic with no UB:</div><div><br></div><div><div style=3D"=
color:rgb(0,0,0);background-color:rgb(255,255,254);font-size:14px;line-heig=
ht:21px;white-space:pre-wrap"><div><font face=3D"monospace, monospace"><spa=
n style=3D"color:rgb(0,0,255)">enum</span> Values { E1, E2 };</font></div><=
font face=3D"monospace, monospace"><br></font></div></div><div><div style=
=3D"color:rgb(0,0,0);background-color:rgb(255,255,254);font-size:14px;line-=
height:21px;white-space:pre-wrap"><div><font face=3D"monospace, monospace">=
<span style=3D"color:rgb(0,0,255)">const</span> <span style=3D"color:rgb(0,=
0,255)">char</span> *foo(Values v)</font></div><div><font face=3D"monospace=
, monospace">{</font></div><div><font face=3D"monospace, monospace"> <sp=
an style=3D"color:rgb(0,0,255)">const</span> <span style=3D"color:rgb(0,0,2=
55)">char</span>* result =3D <span style=3D"color:rgb(163,21,21)">"no&=
quot;</span>;</font></div><div><font face=3D"monospace, monospace"> <spa=
n style=3D"color:rgb(0,0,255)">switch</span> (v) {</font></div><div><font f=
ace=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">case</s=
pan> E1: <span style=3D"color:rgb(0,0,255)">break</span>;</font></div><div>=
<font face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">=
case</span> E2: result =3D <span style=3D"color:rgb(163,21,21)">"yes&q=
uot;</span>; <span style=3D"color:rgb(0,0,255)">break</span>;</font></div><=
div><font face=3D"monospace, monospace"> }</font></div><div><font face=
=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">return</sp=
an> result;</font></div><div><font face=3D"monospace, monospace">}</font></=
div></div></div></div></div></blockquote><div><br></div><div>I recognise th=
at style is to some extent a matter of taste, but I would not accept that c=
ode change.</div><div><br></div><div>Before: functional, SSA, symmetric, br=
anching control flow.</div><div>After: imperative, mutating, asymmetric, br=
aided control flow.</div><div><br></div><div>There is also the issue that y=
our version leaves open the question of whether non-enumerated values are p=
ermissible. This has the potential to turn into a wide contract, impeding m=
aintainability.</div><div><br></div><div>And what do you do if the return t=
ype has expensive assignment, is non-assignable or immovable? Or if it is n=
on-default constructible and its ctors depend on the argument - a factory, =
say?</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv><div><div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,254);fo=
nt-size:14px;line-height:21px;white-space:pre-wrap"><font face=3D"Fira Mono=
">And then let's look at gcc's output using the same compiler switc=
hes as before:</font></div></div><div style=3D"color:rgb(0,0,0);background-=
color:rgb(255,255,254);font-size:14px;line-height:21px;white-space:pre-wrap=
"><font face=3D"Fira Mono"><br></font></div><div style=3D"color:rgb(0,0,0);=
background-color:rgb(255,255,254);font-size:14px;line-height:21px;white-spa=
ce:pre-wrap"><div style=3D"line-height:21px"><div><span style=3D"color:rgb(=
0,128,128)"><font face=3D"monospace, monospace">foo(Values):</font></span><=
/div><div><font face=3D"monospace, monospace"> <span style=3D"color:=
rgb(0,0,255)">cmp</span> <span style=3D"color:rgb(72,100,170)">edi</spa=
n>, <span style=3D"color:rgb(9,136,90)">1</span></font></div><div><font fac=
e=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">mov</=
span> <span style=3D"color:rgb(72,100,170)">edx</span>, <span style=3D"=
color:rgb(0,128,128)">OFFSET</span> <span style=3D"color:rgb(0,128,128)">FL=
AT</span>:<span style=3D"color:rgb(0,128,128)">.LC0</span></font></div><spa=
n class=3D""><div><font face=3D"monospace, monospace"> <span style=
=3D"color:rgb(0,0,255)">mov</span> <span style=3D"color:rgb(72,100,170)=
">eax</span>, <span style=3D"color:rgb(0,128,128)">OFFSET</span> <span styl=
e=3D"color:rgb(0,128,128)">FLAT</span>:<span style=3D"color:rgb(0,128,128)"=
>.LC1</span></font></div></span><div><font face=3D"monospace, monospace"> =
<span style=3D"color:rgb(0,0,255)">cmovne</span> <span style=3D"colo=
r:rgb(72,100,170)">rax</span>, <span style=3D"color:rgb(72,100,170)">rdx</s=
pan></font></div><div><font face=3D"monospace, monospace"> <span sty=
le=3D"color:rgb(0,0,255)">ret</span></font></div></div></div><div style=3D"=
color:rgb(0,0,0);background-color:rgb(255,255,254);font-family:"Fira M=
ono";font-size:14px;line-height:21px;white-space:pre-wrap"><br></div><=
div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,254);font-family=
:"Fira Mono";font-size:14px;line-height:21px;white-space:pre-wrap=
">Oh look! No UB, compiler warnings for unhandled cases and... perfect code=
..</div><div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,254);fon=
t-family:"Fira Mono";font-size:14px;line-height:21px;white-space:=
pre-wrap"><br></div><div style=3D"color:rgb(0,0,0);background-color:rgb(255=
,255,254);font-family:"Fira Mono";font-size:14px;line-height:21px=
;white-space:pre-wrap">Please feel free to offer more non-examples. "R=
ichard's UB-Removal Service" is at your disposal.</div><div style=
=3D"color:rgb(0,0,0);background-color:rgb(255,255,254);font-family:"Fi=
ra Mono";font-size:14px;line-height:21px;white-space:pre-wrap"><br></d=
iv><div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,254);font-fa=
mily:"Fira Mono";font-size:14px;line-height:21px;white-space:pre-=
wrap">There is absolutely no reason to allow a return path that does not re=
turn a value. The fact that c++ does is not a design decision. It's mer=
ely an ancient artefact of K&R C. It is an error to allow it in the lan=
guage.</div><div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,254=
);font-family:"Fira Mono";font-size:14px;line-height:21px;white-s=
pace:pre-wrap"><br></div><div class=3D"gmail_extra"><br><div class=3D"gmail=
_quote"><div><div class=3D"h5">On 20 December 2017 at 09:16, Thiago Macieir=
a <span dir=3D"ltr"><<a href=3D"mailto:thiago@macieira.org" target=3D"_b=
lank">thiago@macieira.org</a>></span> wrote:<br></div></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div><div class=3D"h5"><span class=3D=
"m_7374135999389710844gmail-">On ter=C3=A7a-feira, 19 de dezembro de 2017 2=
2:48:09 PST Richard Hodges wrote:<br>
> Revisiting our examples deliberate non-returning functions again, it s=
eems<br>
> to me that all the arguments for allowing a function to return somethi=
ng on<br>
> an unexecuted path are based on a false premise.<br>
><br>
> The argument goes, "by having some code paths do UB I can get fas=
ter code".<br>
<br>
</span>That's not the argument. The argument is "by not having som=
e code paths, I get<br>
faster and/or smaller code".<br>
<span class=3D"m_7374135999389710844gmail-"><br>
> In the example of:<br>
><br>
> const char* foo(int x) {<br>
> if (x =3D=3D 0) return "no";<br>
> if (x =3D=3D 1) return "yes";<br>
> }<br>
<br>
</span>That was not the example. It was using a switch. So let me change it=
on you to<br>
make it more specific:<br>
<br>
enum Values { E1, E2 };<br>
<br>
const char *foo(Values v)<br>
{<br>
=C2=A0 =C2=A0 switch (v) {<br>
=C2=A0 =C2=A0 case E1:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return "no";<br>
=C2=A0 =C2=A0 case E2:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return "yes";<br>
=C2=A0 =C2=A0 }<br>
}<br>
<br>
There's a distinct advantage in using a switch and not having a default=
:<br>
label: the compiler can warn me if I forgot any of the enumerations. So if =
a<br>
later version of my code does add E3, I can get a compiler warning.<br>
<br>
So now do your thing. Tell me how to write better code without losing that<=
br>
warning.<br>
<span class=3D"m_7374135999389710844gmail-"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
</span></div></div><span class=3D"m_7374135999389710844gmail-">--<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<span class=3D""><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></span><span class=3D"">To view this discussion on the web visit <a =
href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/172044=
56.OZKWC7E4z5%40tjmaciei-mobl1" rel=3D"noreferrer" target=3D"_blank">https:=
//groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/17204456.O=
ZKWC7E4z5%40tjmacie<wbr>i-mobl1</a>.<br>
</span></blockquote></div><br></div></div></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/U=
u2QViiWh4k/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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/CALvx3hafVPg7YDvOHRt6uHbSpnh7X%2BjXy3=
5wWjQWba2KZKGPrw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/<wbr>CALvx3hafVPg7YDvOHRt6uHbSpnh7X<wbr>%2BjXy35wWjQWba2KZ=
KGPrw%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAJnLdOaTTe%3DDhd2qSzZUxRH5DgmdkGsWS5=
BA0VKUyv6rMODTDg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOaTTe%3DD=
hd2qSzZUxRH5DgmdkGsWS5BA0VKUyv6rMODTDg%40mail.gmail.com</a>.<br />
--f403045e6d8e1675700560c4706b--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Wed, 20 Dec 2017 13:31:34 +0100
Raw View
--001a114aad789d0a2c0560c4c3be
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
> After: imperative, mutating, asymmetric, braided control flow.
You're nitpicking. The author of the UB foo argued that UB was necessary
for performance. It's not. It hinders performance. You know full well that
you can express the intent of the contact to a human reader at zero cost
with an assert and/or contract documentation, like this:
template<class T, class...LegalValues>
bool is_one_of(T&& v, LegalValues&&...lv)
{
return ((v =3D=3D lv) or ...);
}
enum Values { E1, E2 };
/// @param v is a member of the enum Values
/// @pre v shall be either E1 or E2
/// @note this function reserves the right to return any legal c string
/// should the precondition, above be not met.
const char *foo(Values v)
{
assert(is_one_of(v, E1, E2));
const char* result =3D "no";
switch (v) {
case E1: break;
case E2: result =3D "yes"; break;
}
return result;
}
compiling with gcc -std=3Dc++17 -O2 -DNDEBUG
foo(Values):
cmp edi, 1
mov edx, OFFSET FLAT:.LC0
mov eax, OFFSET FLAT:.LC1
cmovne rax, rdx
ret
As before. Zero ambiguity here. Plus a deliberate expression of contract,
intent and consequences. Callers can pay their money and take their choice.
At least now what they get is not compiler/platform/SDK dependent. It's
well-defined and 100% efficient.
> There is also the issue that your version leaves open the question of
whether non-enumerated values are permissible. This has the potential to
turn into a wide contract, impeding maintainability.
What? No, this version is simply expressing the behaviour that you got
accidentally, deliberately. Plus it has warnings about unhandled cases. The
behaviour is exactly the same as the UB version (at least on gcc) but now
it's quicker and has no UB.
> And what do you do if the return type has expensive assignment, is
non-assignable or immovable? Or if it is non-default constructible and its
ctors depend on the argument - a factory, say?
Post an example and allow "Richy's UB Removal Service" to show you how to
write efficient code without UB. Better yet, try it yourself. You'll be
amazed at what you're capable of.
On 20 December 2017 at 13:08, 'Edward Catmur' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:
> On Wed, Dec 20, 2017 at 10:53 AM, Richard Hodges <hodges.r@gmail.com>
> wrote:
>
>> Thiago rather sullenly said:
>>
>> > That was not the example. It was using a switch. So let me change it o=
n
>> you to
>> > make it more specific:
>>
>> > enum Values { E1, E2 };
>>
>> > const char *foo(Values v)
>> > {
>> > switch (v) {
>> > case E1:
>> > return "no";
>> > case E2:
>> > return "yes";
>> > }
>> >}
>>
>> > There's a distinct advantage in using a switch and not having a defaul=
t:
>> > label: the compiler can warn me if I forgot any of the enumerations. S=
o
>> if a
>> >later version of my code does add E3, I can get a compiler warning.
>>
>> Sure, so now let's refactor the function into the same logic with no UB:
>>
>> enum Values { E1, E2 };
>>
>> const char *foo(Values v)
>> {
>> const char* result =3D "no";
>> switch (v) {
>> case E1: break;
>> case E2: result =3D "yes"; break;
>> }
>> return result;
>> }
>>
>
> I recognise that style is to some extent a matter of taste, but I would
> not accept that code change.
>
> Before: functional, SSA, symmetric, branching control flow.
> After: imperative, mutating, asymmetric, braided control flow.
>
> There is also the issue that your version leaves open the question of
> whether non-enumerated values are permissible. This has the potential to
> turn into a wide contract, impeding maintainability.
>
> And what do you do if the return type has expensive assignment, is
> non-assignable or immovable? Or if it is non-default constructible and it=
s
> ctors depend on the argument - a factory, say?
>
> And then let's look at gcc's output using the same compiler switches as
>> before:
>>
>> foo(Values):
>> cmp edi, 1
>> mov edx, OFFSET FLAT:.LC0
>> mov eax, OFFSET FLAT:.LC1
>> cmovne rax, rdx
>> ret
>>
>> Oh look! No UB, compiler warnings for unhandled cases and... perfect cod=
e.
>>
>> Please feel free to offer more non-examples. "Richard's UB-Removal
>> Service" is at your disposal.
>>
>> There is absolutely no reason to allow a return path that does not retur=
n
>> a value. The fact that c++ does is not a design decision. It's merely an
>> ancient artefact of K&R C. It is an error to allow it in the language.
>>
>>
>> On 20 December 2017 at 09:16, Thiago Macieira <thiago@macieira.org>
>> wrote:
>>
>>> On ter=C3=A7a-feira, 19 de dezembro de 2017 22:48:09 PST Richard Hodges=
wrote:
>>> > Revisiting our examples deliberate non-returning functions again, it
>>> seems
>>> > to me that all the arguments for allowing a function to return
>>> something on
>>> > an unexecuted path are based on a false premise.
>>> >
>>> > The argument goes, "by having some code paths do UB I can get faster
>>> code".
>>>
>>> That's not the argument. The argument is "by not having some code paths=
,
>>> I get
>>> faster and/or smaller code".
>>>
>>> > In the example of:
>>> >
>>> > const char* foo(int x) {
>>> > if (x =3D=3D 0) return "no";
>>> > if (x =3D=3D 1) return "yes";
>>> > }
>>>
>>> That was not the example. It was using a switch. So let me change it on
>>> you to
>>> make it more specific:
>>>
>>> enum Values { E1, E2 };
>>>
>>> const char *foo(Values v)
>>> {
>>> switch (v) {
>>> case E1:
>>> return "no";
>>> case E2:
>>> return "yes";
>>> }
>>> }
>>>
>>> There's a distinct advantage in using a switch and not having a default=
:
>>> label: the compiler can warn me if I forgot any of the enumerations. So
>>> if a
>>> later version of my code does add E3, I can get a compiler warning.
>>>
>>> So now do your thing. Tell me how to write better code without losing
>>> that
>>> warning.
>>>
>>> --
>>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>> Software Architect - Intel Open Source Technology Center
>>>
>>> --
>>> 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/is
>>> ocpp.org/d/msgid/std-proposals/17204456.OZKWC7E4z5%40tjmaciei-mobl1.
>>>
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit https://groups.google.com/a/is
>> ocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/is
>> ocpp.org/d/msgid/std-proposals/CALvx3hafVPg7YDvOHRt6uHbSpnh7
>> X%2BjXy35wWjQWba2KZKGPrw%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hafV=
Pg7YDvOHRt6uHbSpnh7X%2BjXy35wWjQWba2KZKGPrw%40mail.gmail.com?utm_medium=3De=
mail&utm_source=3Dfooter>
>> .
>>
>
> --
> 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/CAJnLdOaTTe%
> 3DDhd2qSzZUxRH5DgmdkGsWS5BA0VKUyv6rMODTDg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOaTTe=
%3DDhd2qSzZUxRH5DgmdkGsWS5BA0VKUyv6rMODTDg%40mail.gmail.com?utm_medium=3Dem=
ail&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/CALvx3ha4tYUn9v0_X_PLVGCt_k0OJahJAroAhUe0EkEA5H%=
2B2sw%40mail.gmail.com.
--001a114aad789d0a2c0560c4c3be
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">After: imperati=
ve, mutating, asymmetric, braided control flow.</span><div><span style=3D"f=
ont-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">You=
're nitpicking. The author of the UB foo argued that UB was necessary f=
or performance. It's not. It hinders performance. You know full well th=
at you can express the intent of the contact to a human reader at zero cost=
with an assert and/or contract documentation, like this:</span></div><div>=
<span style=3D"font-size:12.8px"><br></span></div><div><div style=3D"backgr=
ound-color:rgb(255,255,254);line-height:21px"><div style=3D"color:rgb(0,0,0=
);font-size:14px;white-space:pre"><font face=3D"monospace, monospace"><span=
style=3D"color:rgb(0,0,255)">template</span><<span style=3D"color:rgb(0=
,0,255)">class</span> T, <span style=3D"color:rgb(0,0,255)">class</span>...=
LegalValues></font></div><div style=3D"color:rgb(0,0,0);font-size:14px;w=
hite-space:pre"><font face=3D"monospace, monospace"><span style=3D"color:rg=
b(0,0,255)">bool</span> is_one_of(T&& v, LegalValues&&...lv=
)</font></div><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre=
"><font face=3D"monospace, monospace">{</font></div><div style=3D"color:rgb=
(0,0,0);font-size:14px;white-space:pre"><font face=3D"monospace, monospace"=
> <span style=3D"color:rgb(0,0,255)">return</span> ((v =3D=3D lv) <span =
style=3D"color:rgb(0,0,255)">or</span> ...);</font></div><div style=3D"colo=
r:rgb(0,0,0);font-size:14px;white-space:pre"><font face=3D"monospace, monos=
pace">}</font></div><font face=3D"monospace, monospace" style=3D"color:rgb(=
0,0,0);font-size:14px;white-space:pre"><br></font><div style=3D"color:rgb(0=
,0,0);font-size:14px;white-space:pre"><font face=3D"monospace, monospace"><=
span style=3D"color:rgb(0,0,255)">enum</span> Values { E1, E2 };</font></di=
v><font face=3D"monospace, monospace" style=3D"color:rgb(0,0,0);font-size:1=
4px;white-space:pre"><br></font><div style=3D"color:rgb(0,0,0);font-size:14=
px;white-space:pre"><span style=3D"color:rgb(0,128,0)"><font face=3D"monosp=
ace, monospace">/// @param v is a member of the enum Values</font></span></=
div><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><span st=
yle=3D"color:rgb(0,128,0)"><font face=3D"monospace, monospace">/// @pre v s=
hall be either E1 or E2</font></span></div><div style=3D"color:rgb(0,0,0);f=
ont-size:14px;white-space:pre"><span style=3D"color:rgb(0,128,0)"><font fac=
e=3D"monospace, monospace">/// @note this function reserves the right to re=
turn any legal c string</font></span></div><div style=3D"color:rgb(0,0,0);f=
ont-size:14px;white-space:pre"><span style=3D"color:rgb(0,128,0)"><font fac=
e=3D"monospace, monospace">/// should the precondition, above be not =
met.</font></span></div><div style=3D"color:rgb(0,0,0);font-size:14px;white=
-space:pre"><font face=3D"monospace, monospace"><span style=3D"color:rgb(0,=
0,255)">const</span> <span style=3D"color:rgb(0,0,255)">char</span> *foo(Va=
lues v)</font></div><div style=3D"color:rgb(0,0,0);font-size:14px;white-spa=
ce:pre"><font face=3D"monospace, monospace">{</font></div><div style=3D"col=
or:rgb(0,0,0);font-size:14px;white-space:pre"><font face=3D"monospace, mono=
space"> assert(is_one_of(v, E1, E2));</font></div><font face=3D"monospac=
e, monospace" style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><br=
></font><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><fon=
t face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">cons=
t</span> <span style=3D"color:rgb(0,0,255)">char</span>* result =3D <span s=
tyle=3D"color:rgb(163,21,21)">"no"</span>;</font></div><div style=
=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><font face=3D"monospac=
e, monospace"> <span style=3D"color:rgb(0,0,255)">switch</span> (v) {</f=
ont></div><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><f=
ont face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">ca=
se</span> E1: <span style=3D"color:rgb(0,0,255)">break</span>;</font></div>=
<div style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><font face=
=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">case</span=
> E2: result =3D <span style=3D"color:rgb(163,21,21)">"yes"</span=
>; <span style=3D"color:rgb(0,0,255)">break</span>;</font></div><div style=
=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><font face=3D"monospac=
e, monospace"> }</font></div><div style=3D"color:rgb(0,0,0);font-size:14=
px;white-space:pre"><font face=3D"monospace, monospace"> <span style=3D"=
color:rgb(0,0,255)">return</span> result;</font></div><div style=3D"color:r=
gb(0,0,0);font-size:14px;white-space:pre"><font face=3D"monospace, monospac=
e">}</font></div><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:=
pre"><font face=3D"monospace, monospace"><br></font></div><div><font face=
=3D"monospace, monospace" style=3D"color:rgb(0,0,0);font-size:14px;white-sp=
ace:pre">compiling with gcc </font><font color=3D"#000000" face=3D"monospac=
e, monospace"><span style=3D"font-size:14px;white-space:pre">-std=3Dc++17 -=
O2 -DNDEBUG</span></font></div><div><div style=3D"color:rgb(0,0,0);font-siz=
e:14px;line-height:21px;white-space:pre"><div style=3D""><span style=3D"col=
or:rgb(0,128,128)"><font face=3D"monospace, monospace">foo(Values):</font><=
/span></div><div style=3D""><font face=3D"monospace, monospace"> <sp=
an style=3D"color:rgb(0,0,255)">cmp</span> <span style=3D"color:rgb(72,=
100,170)">edi</span>, <span style=3D"color:rgb(9,136,90)">1</span></font></=
div><div style=3D""><font face=3D"monospace, monospace"> <span style=
=3D"color:rgb(0,0,255)">mov</span> <span style=3D"color:rgb(72,100,170)=
">edx</span>, <span style=3D"color:rgb(0,128,128)">OFFSET</span> <span styl=
e=3D"color:rgb(0,128,128)">FLAT</span>:<span style=3D"color:rgb(0,128,128)"=
>.LC0</span></font></div><div style=3D""><font face=3D"monospace, monospace=
"> <span style=3D"color:rgb(0,0,255)">mov</span> <span style=3D"=
color:rgb(72,100,170)">eax</span>, <span style=3D"color:rgb(0,128,128)">OFF=
SET</span> <span style=3D"color:rgb(0,128,128)">FLAT</span>:<span style=3D"=
color:rgb(0,128,128)">.LC1</span></font></div><div style=3D""><font face=3D=
"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">cmovne</s=
pan> <span style=3D"color:rgb(72,100,170)">rax</span>, <span style=3D"colo=
r:rgb(72,100,170)">rdx</span></font></div><div style=3D""><font face=3D"mon=
ospace, monospace"> <span style=3D"color:rgb(0,0,255)">ret</span></f=
ont></div><div style=3D"font-family:"Fira Mono"">As before. Zero =
ambiguity here. Plus a deliberate expression of contract, intent and conseq=
uences. Callers can pay their money and take their choice. At least now wha=
t they get is not compiler/platform/SDK dependent. It's well-defined an=
d 100% efficient.</div><div style=3D"font-family:"Fira Mono""><br=
></div></div></div></div></div><div><span style=3D"font-size:12.8px">>=
=C2=A0</span><span style=3D"font-size:12.8px">There is also the issue that =
your version leaves open the question of whether non-enumerated values are =
permissible. This has the potential to turn into a wide contract, impeding =
maintainability.</span></div><div><span style=3D"font-size:12.8px"><br></sp=
an></div><div>What? No, this version is simply expressing the behaviour tha=
t you got accidentally, deliberately. Plus it has warnings about unhandled =
cases. The behaviour is exactly the same as the UB version (at least on gcc=
) but now it's quicker and has no UB.</div><div><br></div><div>>=C2=
=A0<span style=3D"font-size:12.8px">And what do you do if the return type h=
as expensive assignment, is non-assignable or immovable? Or if it is non-de=
fault constructible and its ctors depend on the argument - a factory, say?<=
/span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><sp=
an style=3D"font-size:12.8px">Post an example and allow "Richy's U=
B Removal Service" to show you how to write efficient code without UB.=
Better yet, try it yourself. You'll be amazed at what you're capab=
le of.</span></div><div><span style=3D"font-size:12.8px"><br></span></div><=
div><br></div><div><span style=3D"font-size:12.8px"><br></span></div><div><=
span style=3D"font-size:12.8px"><br></span></div><div><br></div></div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 20 December 2017 at=
13:08, 'Edward Catmur' via ISO C++ Standard - Future Proposals <sp=
an dir=3D"ltr"><<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_b=
lank">std-proposals@isocpp.org</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><span class=3D"">On Wed, Dec 20, 2017 at 10:53 AM, Richard Hodges=
<span dir=3D"ltr"><<a href=3D"mailto:hodges.r@gmail.com" target=3D"_bla=
nk">hodges.r@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr">Thiago rather sullenly said:<div><br></div><div><span>=
> That was not the example. It was using a switch. So let me change it o=
n you to<br>> make it more specific:<br><br>> enum Values { E1, E2 };=
<br><br>> const char *foo(Values v)<br>> {<br>>=C2=A0 =C2=A0 switc=
h (v) {<br>>=C2=A0 =C2=A0 =C2=A0case E1:<br>>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 return "no";<br>>=C2=A0 =C2=A0 case E2:<br>>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 return "yes";<br>>=C2=A0 =C2=A0 }<br>>}<b=
r><br>> There's a distinct advantage in using a switch and not havin=
g a default:<br>> label: the compiler can warn me if I forgot any of the=
enumerations. So if a<br>>later version of my code does add E3, I can g=
et a compiler warning.<br><div><br></div></span><div>Sure, so now let's=
refactor the function into the same logic with no UB:</div><div><br></div>=
<div><div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,254);font-=
size:14px;line-height:21px;white-space:pre-wrap"><div><font face=3D"monospa=
ce, monospace"><span style=3D"color:rgb(0,0,255)">enum</span> Values { E1, =
E2 };</font></div><font face=3D"monospace, monospace"><br></font></div></di=
v><div><div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,254);fon=
t-size:14px;line-height:21px;white-space:pre-wrap"><div><font face=3D"monos=
pace, monospace"><span style=3D"color:rgb(0,0,255)">const</span> <span styl=
e=3D"color:rgb(0,0,255)">char</span> *foo(Values v)</font></div><div><font =
face=3D"monospace, monospace">{</font></div><div><font face=3D"monospace, m=
onospace"> <span style=3D"color:rgb(0,0,255)">const</span> <span style=
=3D"color:rgb(0,0,255)">char</span>* result =3D <span style=3D"color:rgb(16=
3,21,21)">"no"</span>;</font></div><div><font face=3D"monospace, =
monospace"> <span style=3D"color:rgb(0,0,255)">switch</span> (v) {</font=
></div><div><font face=3D"monospace, monospace"> <span style=3D"color:rg=
b(0,0,255)">case</span> E1: <span style=3D"color:rgb(0,0,255)">break</span>=
;</font></div><div><font face=3D"monospace, monospace"> <span style=3D"c=
olor:rgb(0,0,255)">case</span> E2: result =3D <span style=3D"color:rgb(163,=
21,21)">"yes"</span>; <span style=3D"color:rgb(0,0,255)">break</s=
pan>;</font></div><div><font face=3D"monospace, monospace"> }</font></di=
v><div><font face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0=
,255)">return</span> result;</font></div><div><font face=3D"monospace, mono=
space">}</font></div></div></div></div></div></blockquote><div><br></div></=
span><div>I recognise that style is to some extent a matter of taste, but I=
would not accept that code change.</div><div><br></div><div>Before: functi=
onal, SSA, symmetric, branching control flow.</div><div>After: imperative, =
mutating, asymmetric, braided control flow.</div><div><br></div><div>There =
is also the issue that your version leaves open the question of whether non=
-enumerated values are permissible. This has the potential to turn into a w=
ide contract, impeding maintainability.</div><div><br></div><div>And what d=
o you do if the return type has expensive assignment, is non-assignable or =
immovable? Or if it is non-default constructible and its ctors depend on th=
e argument - a factory, say?</div><div><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div><div class=3D"h5"><div dir=3D"ltr"><div><div><div style=3D"color:=
rgb(0,0,0);background-color:rgb(255,255,254);font-size:14px;line-height:21p=
x;white-space:pre-wrap"><font face=3D"Fira Mono">And then let's look at=
gcc's output using the same compiler switches as before:</font></div><=
/div><div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,254);font-=
size:14px;line-height:21px;white-space:pre-wrap"><font face=3D"Fira Mono"><=
br></font></div><div style=3D"color:rgb(0,0,0);background-color:rgb(255,255=
,254);font-size:14px;line-height:21px;white-space:pre-wrap"><div style=3D"l=
ine-height:21px"><div><span style=3D"color:rgb(0,128,128)"><font face=3D"mo=
nospace, monospace">foo(Values):</font></span></div><div><font face=3D"mono=
space, monospace"> <span style=3D"color:rgb(0,0,255)">cmp</span> =
<span style=3D"color:rgb(72,100,170)">edi</span>, <span style=3D"color:rgb=
(9,136,90)">1</span></font></div><div><font face=3D"monospace, monospace"> =
<span style=3D"color:rgb(0,0,255)">mov</span> <span style=3D"col=
or:rgb(72,100,170)">edx</span>, <span style=3D"color:rgb(0,128,128)">OFFSET=
</span> <span style=3D"color:rgb(0,128,128)">FLAT</span>:<span style=3D"col=
or:rgb(0,128,128)">.LC0</span></font></div><span><div><font face=3D"monospa=
ce, monospace"> <span style=3D"color:rgb(0,0,255)">mov</span> <s=
pan style=3D"color:rgb(72,100,170)">eax</span>, <span style=3D"color:rgb(0,=
128,128)">OFFSET</span> <span style=3D"color:rgb(0,128,128)">FLAT</span>:<s=
pan style=3D"color:rgb(0,128,128)">.LC1</span></font></div></span><div><fon=
t face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">=
cmovne</span> <span style=3D"color:rgb(72,100,170)">rax</span>, <span styl=
e=3D"color:rgb(72,100,170)">rdx</span></font></div><div><font face=3D"monos=
pace, monospace"> <span style=3D"color:rgb(0,0,255)">ret</span></fon=
t></div></div></div><div style=3D"color:rgb(0,0,0);background-color:rgb(255=
,255,254);font-family:"Fira Mono";font-size:14px;line-height:21px=
;white-space:pre-wrap"><br></div><div style=3D"color:rgb(0,0,0);background-=
color:rgb(255,255,254);font-family:"Fira Mono";font-size:14px;lin=
e-height:21px;white-space:pre-wrap">Oh look! No UB, compiler warnings for u=
nhandled cases and... perfect code.</div><div style=3D"color:rgb(0,0,0);bac=
kground-color:rgb(255,255,254);font-family:"Fira Mono";font-size:=
14px;line-height:21px;white-space:pre-wrap"><br></div><div style=3D"color:r=
gb(0,0,0);background-color:rgb(255,255,254);font-family:"Fira Mono&quo=
t;;font-size:14px;line-height:21px;white-space:pre-wrap">Please feel free t=
o offer more non-examples. "Richard's UB-Removal Service" is =
at your disposal.</div><div style=3D"color:rgb(0,0,0);background-color:rgb(=
255,255,254);font-family:"Fira Mono";font-size:14px;line-height:2=
1px;white-space:pre-wrap"><br></div><div style=3D"color:rgb(0,0,0);backgrou=
nd-color:rgb(255,255,254);font-family:"Fira Mono";font-size:14px;=
line-height:21px;white-space:pre-wrap">There is absolutely no reason to all=
ow a return path that does not return a value. The fact that c++ does is no=
t a design decision. It's merely an ancient artefact of K&R C. It i=
s an error to allow it in the language.</div><div style=3D"color:rgb(0,0,0)=
;background-color:rgb(255,255,254);font-family:"Fira Mono";font-s=
ize:14px;line-height:21px;white-space:pre-wrap"><br></div><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote"><div><div class=3D"m_8418329263813=
003623h5">On 20 December 2017 at 09:16, Thiago Macieira <span dir=3D"ltr">&=
lt;<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira=
..org</a>></span> wrote:<br></div></div><blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><div><div class=3D"m_8418329263813003623h5"><span class=3D=
"m_8418329263813003623m_7374135999389710844gmail-">On ter=C3=A7a-feira, 19 =
de dezembro de 2017 22:48:09 PST Richard Hodges wrote:<br>
> Revisiting our examples deliberate non-returning functions again, it s=
eems<br>
> to me that all the arguments for allowing a function to return somethi=
ng on<br>
> an unexecuted path are based on a false premise.<br>
><br>
> The argument goes, "by having some code paths do UB I can get fas=
ter code".<br>
<br>
</span>That's not the argument. The argument is "by not having som=
e code paths, I get<br>
faster and/or smaller code".<br>
<span class=3D"m_8418329263813003623m_7374135999389710844gmail-"><br>
> In the example of:<br>
><br>
> const char* foo(int x) {<br>
> if (x =3D=3D 0) return "no";<br>
> if (x =3D=3D 1) return "yes";<br>
> }<br>
<br>
</span>That was not the example. It was using a switch. So let me change it=
on you to<br>
make it more specific:<br>
<br>
enum Values { E1, E2 };<br>
<br>
const char *foo(Values v)<br>
{<br>
=C2=A0 =C2=A0 switch (v) {<br>
=C2=A0 =C2=A0 case E1:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return "no";<br>
=C2=A0 =C2=A0 case E2:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return "yes";<br>
=C2=A0 =C2=A0 }<br>
}<br>
<br>
There's a distinct advantage in using a switch and not having a default=
:<br>
label: the compiler can warn me if I forgot any of the enumerations. So if =
a<br>
later version of my code does add E3, I can get a compiler warning.<br>
<br>
So now do your thing. Tell me how to write better code without losing that<=
br>
warning.<br>
<span class=3D"m_8418329263813003623m_7374135999389710844gmail-"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
</span></div></div><span class=3D"m_8418329263813003623m_737413599938971084=
4gmail-">--<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<span><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></span><span>To view this discussion on the web visit <a href=3D"htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/17204456.OZKWC7E4=
z5%40tjmaciei-mobl1" rel=3D"noreferrer" target=3D"_blank">https://groups.go=
ogle.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/17204456.OZKWC7E4z5%4=
0tjmacie<wbr>i-mobl1</a>.<br>
</span></blockquote></div><br></div></div></div></div></div><span>
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/is<wbr>ocpp.org/d/topic/std-proposals<wbr>/U=
u2QViiWh4k/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isoc<wbr>pp.org</a>.<span class=3D""><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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hafVPg7YDvOHRt6uHbSpnh7X%2BjXy3=
5wWjQWba2KZKGPrw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/st=
d-proposals<wbr>/CALvx3hafVPg7YDvOHRt6uHbSpnh7<wbr>X%2BjXy35wWjQWba2KZKGPrw=
%40mai<wbr>l.gmail.com</a>.<br>
</blockquote></div><br></div></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/CAJnLdOaTTe%3DDhd2qSzZUxRH5DgmdkGsWS5=
BA0VKUyv6rMODTDg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/CAJnLdOaTTe%<wbr>3DDhd2qSzZUxRH5DgmdkGsWS5BA0VK<wbr>Uyv6rM=
ODTDg%40mail.gmail.com</a>.<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/CALvx3ha4tYUn9v0_X_PLVGCt_k0OJahJAroA=
hUe0EkEA5H%2B2sw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3ha4tYUn9v=
0_X_PLVGCt_k0OJahJAroAhUe0EkEA5H%2B2sw%40mail.gmail.com</a>.<br />
--001a114aad789d0a2c0560c4c3be--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Wed, 20 Dec 2017 13:40:05 +0100
Raw View
--001a113f647619c99b0560c4e2ce
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
We can even do this, and the function is still 100% efficient:
const char *foo(Values v)
{
assert(is_one_of(v, E1, E2));
const char* bad_contract_result =3D "yes";
switch (v) {
case E1: return "no";
case E2: return "yes";
}
return bad_contract_result;
}
results in:
foo(Values):
test edi, edi
mov edx, OFFSET FLAT:.LC1
mov eax, OFFSET FLAT:.LC0
cmovne rax, rdx
ret
Still no UB, consequences explicitly spelled out, compiler warnings on
missed cases, symmetric code.
Optimisers are interested in observable outcomes. UB defeats optimisers.
On 20 December 2017 at 13:31, Richard Hodges <hodges.r@gmail.com> wrote:
> > After: imperative, mutating, asymmetric, braided control flow.
>
> You're nitpicking. The author of the UB foo argued that UB was necessary
> for performance. It's not. It hinders performance. You know full well tha=
t
> you can express the intent of the contact to a human reader at zero cost
> with an assert and/or contract documentation, like this:
>
> template<class T, class...LegalValues>
> bool is_one_of(T&& v, LegalValues&&...lv)
> {
> return ((v =3D=3D lv) or ...);
> }
>
> enum Values { E1, E2 };
>
> /// @param v is a member of the enum Values
> /// @pre v shall be either E1 or E2
> /// @note this function reserves the right to return any legal c string
> /// should the precondition, above be not met.
> const char *foo(Values v)
> {
> assert(is_one_of(v, E1, E2));
>
> const char* result =3D "no";
> switch (v) {
> case E1: break;
> case E2: result =3D "yes"; break;
> }
> return result;
> }
>
> compiling with gcc -std=3Dc++17 -O2 -DNDEBUG
> foo(Values):
> cmp edi, 1
> mov edx, OFFSET FLAT:.LC0
> mov eax, OFFSET FLAT:.LC1
> cmovne rax, rdx
> ret
> As before. Zero ambiguity here. Plus a deliberate expression of contract,
> intent and consequences. Callers can pay their money and take their choic=
e.
> At least now what they get is not compiler/platform/SDK dependent. It's
> well-defined and 100% efficient.
>
> > There is also the issue that your version leaves open the question of
> whether non-enumerated values are permissible. This has the potential to
> turn into a wide contract, impeding maintainability.
>
> What? No, this version is simply expressing the behaviour that you got
> accidentally, deliberately. Plus it has warnings about unhandled cases. T=
he
> behaviour is exactly the same as the UB version (at least on gcc) but now
> it's quicker and has no UB.
>
> > And what do you do if the return type has expensive assignment, is
> non-assignable or immovable? Or if it is non-default constructible and it=
s
> ctors depend on the argument - a factory, say?
>
> Post an example and allow "Richy's UB Removal Service" to show you how to
> write efficient code without UB. Better yet, try it yourself. You'll be
> amazed at what you're capable of.
>
>
>
>
>
>
> On 20 December 2017 at 13:08, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>> On Wed, Dec 20, 2017 at 10:53 AM, Richard Hodges <hodges.r@gmail.com>
>> wrote:
>>
>>> Thiago rather sullenly said:
>>>
>>> > That was not the example. It was using a switch. So let me change it
>>> on you to
>>> > make it more specific:
>>>
>>> > enum Values { E1, E2 };
>>>
>>> > const char *foo(Values v)
>>> > {
>>> > switch (v) {
>>> > case E1:
>>> > return "no";
>>> > case E2:
>>> > return "yes";
>>> > }
>>> >}
>>>
>>> > There's a distinct advantage in using a switch and not having a
>>> default:
>>> > label: the compiler can warn me if I forgot any of the enumerations.
>>> So if a
>>> >later version of my code does add E3, I can get a compiler warning.
>>>
>>> Sure, so now let's refactor the function into the same logic with no UB=
:
>>>
>>> enum Values { E1, E2 };
>>>
>>> const char *foo(Values v)
>>> {
>>> const char* result =3D "no";
>>> switch (v) {
>>> case E1: break;
>>> case E2: result =3D "yes"; break;
>>> }
>>> return result;
>>> }
>>>
>>
>> I recognise that style is to some extent a matter of taste, but I would
>> not accept that code change.
>>
>> Before: functional, SSA, symmetric, branching control flow.
>> After: imperative, mutating, asymmetric, braided control flow.
>>
>> There is also the issue that your version leaves open the question of
>> whether non-enumerated values are permissible. This has the potential to
>> turn into a wide contract, impeding maintainability.
>>
>> And what do you do if the return type has expensive assignment, is
>> non-assignable or immovable? Or if it is non-default constructible and i=
ts
>> ctors depend on the argument - a factory, say?
>>
>> And then let's look at gcc's output using the same compiler switches as
>>> before:
>>>
>>> foo(Values):
>>> cmp edi, 1
>>> mov edx, OFFSET FLAT:.LC0
>>> mov eax, OFFSET FLAT:.LC1
>>> cmovne rax, rdx
>>> ret
>>>
>>> Oh look! No UB, compiler warnings for unhandled cases and... perfect
>>> code.
>>>
>>> Please feel free to offer more non-examples. "Richard's UB-Removal
>>> Service" is at your disposal.
>>>
>>> There is absolutely no reason to allow a return path that does not
>>> return a value. The fact that c++ does is not a design decision. It's
>>> merely an ancient artefact of K&R C. It is an error to allow it in the
>>> language.
>>>
>>>
>>> On 20 December 2017 at 09:16, Thiago Macieira <thiago@macieira.org>
>>> wrote:
>>>
>>>> On ter=C3=A7a-feira, 19 de dezembro de 2017 22:48:09 PST Richard Hodge=
s
>>>> wrote:
>>>> > Revisiting our examples deliberate non-returning functions again, it
>>>> seems
>>>> > to me that all the arguments for allowing a function to return
>>>> something on
>>>> > an unexecuted path are based on a false premise.
>>>> >
>>>> > The argument goes, "by having some code paths do UB I can get faster
>>>> code".
>>>>
>>>> That's not the argument. The argument is "by not having some code
>>>> paths, I get
>>>> faster and/or smaller code".
>>>>
>>>> > In the example of:
>>>> >
>>>> > const char* foo(int x) {
>>>> > if (x =3D=3D 0) return "no";
>>>> > if (x =3D=3D 1) return "yes";
>>>> > }
>>>>
>>>> That was not the example. It was using a switch. So let me change it o=
n
>>>> you to
>>>> make it more specific:
>>>>
>>>> enum Values { E1, E2 };
>>>>
>>>> const char *foo(Values v)
>>>> {
>>>> switch (v) {
>>>> case E1:
>>>> return "no";
>>>> case E2:
>>>> return "yes";
>>>> }
>>>> }
>>>>
>>>> There's a distinct advantage in using a switch and not having a defaul=
t:
>>>> label: the compiler can warn me if I forgot any of the enumerations. S=
o
>>>> if a
>>>> later version of my code does add E3, I can get a compiler warning.
>>>>
>>>> So now do your thing. Tell me how to write better code without losing
>>>> that
>>>> warning.
>>>>
>>>> --
>>>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>>> Software Architect - Intel Open Source Technology Center
>>>>
>>>> --
>>>> 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/i=
s
>>>> ocpp.org/d/msgid/std-proposals/17204456.OZKWC7E4z5%40tjmaciei-mobl1.
>>>>
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this topic, visit https://groups.google.com/a/is
>>> ocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
>>> To unsubscribe from this group and all its topics, 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/is
>>> ocpp.org/d/msgid/std-proposals/CALvx3hafVPg7YDvOHRt6uHbSpnh7
>>> X%2BjXy35wWjQWba2KZKGPrw%40mail.gmail.com
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3haf=
VPg7YDvOHRt6uHbSpnh7X%2BjXy35wWjQWba2KZKGPrw%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
>>> .
>>>
>>
>> --
>> 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-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/is
>> ocpp.org/d/msgid/std-proposals/CAJnLdOaTTe%3DDhd2qSzZUxRH5Dg
>> mdkGsWS5BA0VKUyv6rMODTDg%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOaTT=
e%3DDhd2qSzZUxRH5DgmdkGsWS5BA0VKUyv6rMODTDg%40mail.gmail.com?utm_medium=3De=
mail&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/CALvx3hb8xdEwYGpefvi2oiJm-wDwGADzBvuZ23%2B7%2BMJ=
jaimbJg%40mail.gmail.com.
--001a113f647619c99b0560c4e2ce
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><br></div>We can even do this, and the function is st=
ill 100% efficient:<div><br></div><div><div style=3D"color:rgb(0,0,0);backg=
round-color:rgb(255,255,254);font-size:14px;line-height:21px;white-space:pr=
e"><div><font face=3D"monospace, monospace"><span style=3D"color:rgb(0,0,25=
5)">const</span> <span style=3D"color:rgb(0,0,255)">char</span> *foo(Values=
v)</font></div><div><font face=3D"monospace, monospace">{</font></div><div=
><font face=3D"monospace, monospace"> assert(is_one_of(v, E1, E2));</fon=
t></div><font face=3D"monospace, monospace"><br></font><div><font face=3D"m=
onospace, monospace"> <span style=3D"color:rgb(0,0,255)">const</span> <s=
pan style=3D"color:rgb(0,0,255)">char</span>* bad_contract_result =3D <span=
style=3D"color:rgb(163,21,21)">"yes"</span>;</font></div><div><f=
ont face=3D"monospace, monospace"> </font></div><div><font face=3D"monos=
pace, monospace"> <span style=3D"color:rgb(0,0,255)">switch</span> (v) {=
</font></div><div><font face=3D"monospace, monospace"> <span style=3D"co=
lor:rgb(0,0,255)">case</span> E1: <span style=3D"color:rgb(0,0,255)">return=
</span> <span style=3D"color:rgb(163,21,21)">"no"</span>;</font><=
/div><div><font face=3D"monospace, monospace"> <span style=3D"color:rgb(=
0,0,255)">case</span> E2: <span style=3D"color:rgb(0,0,255)">return</span> =
<span style=3D"color:rgb(163,21,21)">"yes"</span>;</font></div><d=
iv><font face=3D"monospace, monospace"> }</font></div><font face=3D"mono=
space, monospace"><br></font><div><font face=3D"monospace, monospace"> <=
span style=3D"color:rgb(0,0,255)">return</span> bad_contract_result;</font>=
</div><div><font face=3D"monospace, monospace">}</font></div><br></div></di=
v><div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,254);font-fam=
ily:"Fira Mono";font-size:14px;line-height:21px;white-space:pre">=
results in:</div><div style=3D"color:rgb(0,0,0);background-color:rgb(255,25=
5,254);font-family:"Fira Mono";font-size:14px;line-height:21px;wh=
ite-space:pre"><br></div><div style=3D"color:rgb(0,0,0);background-color:rg=
b(255,255,254);font-size:14px;line-height:21px;white-space:pre"><div style=
=3D"line-height:21px"><div style=3D""><span style=3D"color:rgb(0,128,128)">=
<font face=3D"monospace, monospace">foo(Values):</font></span></div><div st=
yle=3D""><font face=3D"monospace, monospace"> <span style=3D"color:r=
gb(0,0,255)">test</span> <span style=3D"color:rgb(72,100,170)">edi</span=
>, <span style=3D"color:rgb(72,100,170)">edi</span></font></div><div style=
=3D""><font face=3D"monospace, monospace"> <span style=3D"color:rgb(=
0,0,255)">mov</span> <span style=3D"color:rgb(72,100,170)">edx</span>, =
<span style=3D"color:rgb(0,128,128)">OFFSET</span> <span style=3D"color:rgb=
(0,128,128)">FLAT</span>:<span style=3D"color:rgb(0,128,128)">.LC1</span></=
font></div><div style=3D""><font face=3D"monospace, monospace"> <spa=
n style=3D"color:rgb(0,0,255)">mov</span> <span style=3D"color:rgb(72,1=
00,170)">eax</span>, <span style=3D"color:rgb(0,128,128)">OFFSET</span> <sp=
an style=3D"color:rgb(0,128,128)">FLAT</span>:<span style=3D"color:rgb(0,12=
8,128)">.LC0</span></font></div><div style=3D""><font face=3D"monospace, mo=
nospace"> <span style=3D"color:rgb(0,0,255)">cmovne</span> <span st=
yle=3D"color:rgb(72,100,170)">rax</span>, <span style=3D"color:rgb(72,100,1=
70)">rdx</span></font></div><div style=3D""><font face=3D"monospace, monosp=
ace"> <span style=3D"color:rgb(0,0,255)">ret</span></font></div></di=
v></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Sti=
ll no UB, consequences explicitly spelled out, compiler warnings on missed =
cases, symmetric code.=C2=A0</div><div class=3D"gmail_extra"><br></div><div=
class=3D"gmail_extra">Optimisers are interested in observable outcomes. UB=
defeats optimisers.=C2=A0</div><div class=3D"gmail_extra"><br></div><div c=
lass=3D"gmail_extra"><br><div class=3D"gmail_quote">On 20 December 2017 at =
13:31, Richard Hodges <span dir=3D"ltr"><<a href=3D"mailto:hodges.r@gmai=
l.com" target=3D"_blank">hodges.r@gmail.com</a>></span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">>=C2=A0<span =
style=3D"font-size:12.8px">After: imperative, mutating, asymmetric, braided=
control flow.</span><div><span style=3D"font-size:12.8px"><br></span></div=
></span><div><span style=3D"font-size:12.8px">You're nitpicking. The au=
thor of the UB foo argued that UB was necessary for performance. It's n=
ot. It hinders performance. You know full well that you can express the int=
ent of the contact to a human reader at zero cost with an assert and/or con=
tract documentation, like this:</span></div><div><span style=3D"font-size:1=
2.8px"><br></span></div><div><div style=3D"background-color:rgb(255,255,254=
);line-height:21px"><div style=3D"color:rgb(0,0,0);font-size:14px;white-spa=
ce:pre-wrap"><font face=3D"monospace, monospace"><span style=3D"color:rgb(0=
,0,255)">template</span><<span style=3D"color:rgb(0,0,255)">class</span>=
T, <span style=3D"color:rgb(0,0,255)">class</span>...LegalValues></font=
></div><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre-wrap">=
<font face=3D"monospace, monospace"><span style=3D"color:rgb(0,0,255)">bool=
</span> is_one_of(T&& v, LegalValues&&...lv)</font></div><d=
iv style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre-wrap"><font fac=
e=3D"monospace, monospace">{</font></div><div style=3D"color:rgb(0,0,0);fon=
t-size:14px;white-space:pre-wrap"><font face=3D"monospace, monospace"> <=
span style=3D"color:rgb(0,0,255)">return</span> ((v =3D=3D lv) <span style=
=3D"color:rgb(0,0,255)">or</span> ...);</font></div><div style=3D"color:rgb=
(0,0,0);font-size:14px;white-space:pre-wrap"><font face=3D"monospace, monos=
pace">}</font></div><font face=3D"monospace, monospace" style=3D"color:rgb(=
0,0,0);font-size:14px;white-space:pre-wrap"><br></font><div style=3D"color:=
rgb(0,0,0);font-size:14px;white-space:pre-wrap"><font face=3D"monospace, mo=
nospace"><span style=3D"color:rgb(0,0,255)">enum</span> Values { E1, E2 };<=
/font></div><font face=3D"monospace, monospace" style=3D"color:rgb(0,0,0);f=
ont-size:14px;white-space:pre-wrap"><br></font><div style=3D"color:rgb(0,0,=
0);font-size:14px;white-space:pre-wrap"><span style=3D"color:rgb(0,128,0)">=
<font face=3D"monospace, monospace">/// @param v is a member of the enum Va=
lues</font></span></div><div style=3D"color:rgb(0,0,0);font-size:14px;white=
-space:pre-wrap"><span style=3D"color:rgb(0,128,0)"><font face=3D"monospace=
, monospace">/// @pre v shall be either E1 or E2</font></span></div><div st=
yle=3D"color:rgb(0,0,0);font-size:14px;white-space:pre-wrap"><span style=3D=
"color:rgb(0,128,0)"><font face=3D"monospace, monospace">/// @note this fun=
ction reserves the right to return any legal c string</font></span></div><d=
iv style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre-wrap"><span sty=
le=3D"color:rgb(0,128,0)"><font face=3D"monospace, monospace">/// sho=
uld the precondition, above be not met.</font></span></div><div style=3D"co=
lor:rgb(0,0,0);font-size:14px;white-space:pre-wrap"><font face=3D"monospace=
, monospace"><span style=3D"color:rgb(0,0,255)">const</span> <span style=3D=
"color:rgb(0,0,255)">char</span> *foo(Values v)</font></div><div style=3D"c=
olor:rgb(0,0,0);font-size:14px;white-space:pre-wrap"><font face=3D"monospac=
e, monospace">{</font></div><div style=3D"color:rgb(0,0,0);font-size:14px;w=
hite-space:pre-wrap"><font face=3D"monospace, monospace"> assert(is_one_=
of(v, E1, E2));</font></div><span class=3D""><font face=3D"monospace, monos=
pace" style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre-wrap"><br></=
font><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre-wrap"><f=
ont face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">co=
nst</span> <span style=3D"color:rgb(0,0,255)">char</span>* result =3D <span=
style=3D"color:rgb(163,21,21)">"no"</span>;</font></div><div sty=
le=3D"color:rgb(0,0,0);font-size:14px;white-space:pre-wrap"><font face=3D"m=
onospace, monospace"> <span style=3D"color:rgb(0,0,255)">switch</span> (=
v) {</font></div><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:=
pre-wrap"><font face=3D"monospace, monospace"> <span style=3D"color:rgb(=
0,0,255)">case</span> E1: <span style=3D"color:rgb(0,0,255)">break</span>;<=
/font></div><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre-w=
rap"><font face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,2=
55)">case</span> E2: result =3D <span style=3D"color:rgb(163,21,21)">"=
yes"</span>; <span style=3D"color:rgb(0,0,255)">break</span>;</font></=
div><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre-wrap"><fo=
nt face=3D"monospace, monospace"> }</font></div><div style=3D"color:rgb(=
0,0,0);font-size:14px;white-space:pre-wrap"><font face=3D"monospace, monosp=
ace"> <span style=3D"color:rgb(0,0,255)">return</span> result;</font></d=
iv><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre-wrap"><fon=
t face=3D"monospace, monospace">}</font></div><div style=3D"color:rgb(0,0,0=
);font-size:14px;white-space:pre-wrap"><font face=3D"monospace, monospace">=
<br></font></div></span><div><font face=3D"monospace, monospace" style=3D"c=
olor:rgb(0,0,0);font-size:14px;white-space:pre-wrap">compiling with gcc </f=
ont><font color=3D"#000000" face=3D"monospace, monospace"><span style=3D"fo=
nt-size:14px;white-space:pre-wrap">-std=3Dc++17 -O2 -DNDEBUG</span></font><=
/div><div><div style=3D"color:rgb(0,0,0);font-size:14px;line-height:21px;wh=
ite-space:pre-wrap"><span class=3D""><div><span style=3D"color:rgb(0,128,12=
8)"><font face=3D"monospace, monospace">foo(Values):</font></span></div><di=
v><font face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,=
255)">cmp</span> <span style=3D"color:rgb(72,100,170)">edi</span>, <spa=
n style=3D"color:rgb(9,136,90)">1</span></font></div><div><font face=3D"mon=
ospace, monospace"> <span style=3D"color:rgb(0,0,255)">mov</span> =
<span style=3D"color:rgb(72,100,170)">edx</span>, <span style=3D"color:rg=
b(0,128,128)">OFFSET</span> <span style=3D"color:rgb(0,128,128)">FLAT</span=
>:<span style=3D"color:rgb(0,128,128)">.LC0</span></font></div><div><font f=
ace=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">mov=
</span> <span style=3D"color:rgb(72,100,170)">eax</span>, <span style=
=3D"color:rgb(0,128,128)">OFFSET</span> <span style=3D"color:rgb(0,128,128)=
">FLAT</span>:<span style=3D"color:rgb(0,128,128)">.LC1</span></font></div>=
<div><font face=3D"monospace, monospace"> <span style=3D"color:rgb(0=
,0,255)">cmovne</span> <span style=3D"color:rgb(72,100,170)">rax</span>, <=
span style=3D"color:rgb(72,100,170)">rdx</span></font></div><div><font face=
=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">ret</s=
pan></font></div></span><div style=3D"font-family:"Fira Mono"">As=
before. Zero ambiguity here. Plus a deliberate expression of contract, int=
ent and consequences. Callers can pay their money and take their choice. At=
least now what they get is not compiler/platform/SDK dependent. It's w=
ell-defined and 100% efficient.</div><div style=3D"font-family:"Fira M=
ono""><br></div></div></div></div></div><span class=3D""><div><span st=
yle=3D"font-size:12.8px">>=C2=A0</span><span style=3D"font-size:12.8px">=
There is also the issue that your version leaves open the question of wheth=
er non-enumerated values are permissible. This has the potential to turn in=
to a wide contract, impeding maintainability.</span></div><div><span style=
=3D"font-size:12.8px"><br></span></div></span><div>What? No, this version i=
s simply expressing the behaviour that you got accidentally, deliberately. =
Plus it has warnings about unhandled cases. The behaviour is exactly the sa=
me as the UB version (at least on gcc) but now it's quicker and has no =
UB.</div><span class=3D""><div><br></div><div>>=C2=A0<span style=3D"font=
-size:12.8px">And what do you do if the return type has expensive assignmen=
t, is non-assignable or immovable? Or if it is non-default constructible an=
d its ctors depend on the argument - a factory, say?</span></div><div><span=
style=3D"font-size:12.8px"><br></span></div></span><div><span style=3D"fon=
t-size:12.8px">Post an example and allow "Richy's UB Removal Servi=
ce" to show you how to write efficient code without UB. Better yet, tr=
y it yourself. You'll be amazed at what you're capable of.</span></=
div><div><span style=3D"font-size:12.8px"><br></span></div><div><br></div><=
div><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"f=
ont-size:12.8px"><br></span></div><div><br></div></div><div class=3D"HOEnZb=
"><div class=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quot=
e">On 20 December 2017 at 13:08, 'Edward Catmur' via ISO C++ Standa=
rd - Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals=
@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_e=
xtra"><div class=3D"gmail_quote"><span>On Wed, Dec 20, 2017 at 10:53 AM, Ri=
chard Hodges <span dir=3D"ltr"><<a href=3D"mailto:hodges.r@gmail.com" ta=
rget=3D"_blank">hodges.r@gmail.com</a>></span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr">Thiago rather sullenly said:<div><br></div=
><div><span>> That was not the example. It was using a switch. So let me=
change it on you to<br>> make it more specific:<br><br>> enum Values=
{ E1, E2 };<br><br>> const char *foo(Values v)<br>> {<br>>=C2=A0 =
=C2=A0 switch (v) {<br>>=C2=A0 =C2=A0 =C2=A0case E1:<br>>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 return "no";<br>>=C2=A0 =C2=A0 case E2:<br>&=
gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 return "yes";<br>>=C2=A0 =C2=A0=
}<br>>}<br><br>> There's a distinct advantage in using a switch =
and not having a default:<br>> label: the compiler can warn me if I forg=
ot any of the enumerations. So if a<br>>later version of my code does ad=
d E3, I can get a compiler warning.<br><div><br></div></span><div>Sure, so =
now let's refactor the function into the same logic with no UB:</div><d=
iv><br></div><div><div style=3D"color:rgb(0,0,0);background-color:rgb(255,2=
55,254);font-size:14px;line-height:21px;white-space:pre-wrap"><div><font fa=
ce=3D"monospace, monospace"><span style=3D"color:rgb(0,0,255)">enum</span> =
Values { E1, E2 };</font></div><font face=3D"monospace, monospace"><br></fo=
nt></div></div><div><div style=3D"color:rgb(0,0,0);background-color:rgb(255=
,255,254);font-size:14px;line-height:21px;white-space:pre-wrap"><div><font =
face=3D"monospace, monospace"><span style=3D"color:rgb(0,0,255)">const</spa=
n> <span style=3D"color:rgb(0,0,255)">char</span> *foo(Values v)</font></di=
v><div><font face=3D"monospace, monospace">{</font></div><div><font face=3D=
"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">const</span> =
<span style=3D"color:rgb(0,0,255)">char</span>* result =3D <span style=3D"c=
olor:rgb(163,21,21)">"no"</span>;</font></div><div><font face=3D"=
monospace, monospace"> <span style=3D"color:rgb(0,0,255)">switch</span> =
(v) {</font></div><div><font face=3D"monospace, monospace"> <span style=
=3D"color:rgb(0,0,255)">case</span> E1: <span style=3D"color:rgb(0,0,255)">=
break</span>;</font></div><div><font face=3D"monospace, monospace"> <spa=
n style=3D"color:rgb(0,0,255)">case</span> E2: result =3D <span style=3D"co=
lor:rgb(163,21,21)">"yes"</span>; <span style=3D"color:rgb(0,0,25=
5)">break</span>;</font></div><div><font face=3D"monospace, monospace"> =
}</font></div><div><font face=3D"monospace, monospace"> <span style=3D"c=
olor:rgb(0,0,255)">return</span> result;</font></div><div><font face=3D"mon=
ospace, monospace">}</font></div></div></div></div></div></blockquote><div>=
<br></div></span><div>I recognise that style is to some extent a matter of =
taste, but I would not accept that code change.</div><div><br></div><div>Be=
fore: functional, SSA, symmetric, branching control flow.</div><div>After: =
imperative, mutating, asymmetric, braided control flow.</div><div><br></div=
><div>There is also the issue that your version leaves open the question of=
whether non-enumerated values are permissible. This has the potential to t=
urn into a wide contract, impeding maintainability.</div><div><br></div><di=
v>And what do you do if the return type has expensive assignment, is non-as=
signable or immovable? Or if it is non-default constructible and its ctors =
depend on the argument - a factory, say?</div><div><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div><div class=3D"m_-8942373410016678614h5"><div dir=3D"l=
tr"><div><div><div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,2=
54);font-size:14px;line-height:21px;white-space:pre-wrap"><font face=3D"Fir=
a Mono">And then let's look at gcc's output using the same compiler=
switches as before:</font></div></div><div style=3D"color:rgb(0,0,0);backg=
round-color:rgb(255,255,254);font-size:14px;line-height:21px;white-space:pr=
e-wrap"><font face=3D"Fira Mono"><br></font></div><div style=3D"color:rgb(0=
,0,0);background-color:rgb(255,255,254);font-size:14px;line-height:21px;whi=
te-space:pre-wrap"><div style=3D"line-height:21px"><div><span style=3D"colo=
r:rgb(0,128,128)"><font face=3D"monospace, monospace">foo(Values):</font></=
span></div><div><font face=3D"monospace, monospace"> <span style=3D"=
color:rgb(0,0,255)">cmp</span> <span style=3D"color:rgb(72,100,170)">ed=
i</span>, <span style=3D"color:rgb(9,136,90)">1</span></font></div><div><fo=
nt face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)"=
>mov</span> <span style=3D"color:rgb(72,100,170)">edx</span>, <span sty=
le=3D"color:rgb(0,128,128)">OFFSET</span> <span style=3D"color:rgb(0,128,12=
8)">FLAT</span>:<span style=3D"color:rgb(0,128,128)">.LC0</span></font></di=
v><span><div><font face=3D"monospace, monospace"> <span style=3D"col=
or:rgb(0,0,255)">mov</span> <span style=3D"color:rgb(72,100,170)">eax</=
span>, <span style=3D"color:rgb(0,128,128)">OFFSET</span> <span style=3D"co=
lor:rgb(0,128,128)">FLAT</span>:<span style=3D"color:rgb(0,128,128)">.LC1</=
span></font></div></span><div><font face=3D"monospace, monospace"> <=
span style=3D"color:rgb(0,0,255)">cmovne</span> <span style=3D"color:rgb(7=
2,100,170)">rax</span>, <span style=3D"color:rgb(72,100,170)">rdx</span></f=
ont></div><div><font face=3D"monospace, monospace"> <span style=3D"c=
olor:rgb(0,0,255)">ret</span></font></div></div></div><div style=3D"color:r=
gb(0,0,0);background-color:rgb(255,255,254);font-family:"Fira Mono&quo=
t;;font-size:14px;line-height:21px;white-space:pre-wrap"><br></div><div sty=
le=3D"color:rgb(0,0,0);background-color:rgb(255,255,254);font-family:"=
Fira Mono";font-size:14px;line-height:21px;white-space:pre-wrap">Oh lo=
ok! No UB, compiler warnings for unhandled cases and... perfect code.</div>=
<div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,254);font-famil=
y:"Fira Mono";font-size:14px;line-height:21px;white-space:pre-wra=
p"><br></div><div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,25=
4);font-family:"Fira Mono";font-size:14px;line-height:21px;white-=
space:pre-wrap">Please feel free to offer more non-examples. "Richard&=
#39;s UB-Removal Service" is at your disposal.</div><div style=3D"colo=
r:rgb(0,0,0);background-color:rgb(255,255,254);font-family:"Fira Mono&=
quot;;font-size:14px;line-height:21px;white-space:pre-wrap"><br></div><div =
style=3D"color:rgb(0,0,0);background-color:rgb(255,255,254);font-family:&qu=
ot;Fira Mono";font-size:14px;line-height:21px;white-space:pre-wrap">Th=
ere is absolutely no reason to allow a return path that does not return a v=
alue. The fact that c++ does is not a design decision. It's merely an a=
ncient artefact of K&R C. It is an error to allow it in the language.</=
div><div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,254);font-f=
amily:"Fira Mono";font-size:14px;line-height:21px;white-space:pre=
-wrap"><br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
<div><div class=3D"m_-8942373410016678614m_8418329263813003623h5">On 20 Dec=
ember 2017 at 09:16, Thiago Macieira <span dir=3D"ltr"><<a href=3D"mailt=
o:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>></span>=
wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv><div class=3D"m_-8942373410016678614m_8418329263813003623h5"><span class=
=3D"m_-8942373410016678614m_8418329263813003623m_7374135999389710844gmail-"=
>On ter=C3=A7a-feira, 19 de dezembro de 2017 22:48:09 PST Richard Hodges wr=
ote:<br>
> Revisiting our examples deliberate non-returning functions again, it s=
eems<br>
> to me that all the arguments for allowing a function to return somethi=
ng on<br>
> an unexecuted path are based on a false premise.<br>
><br>
> The argument goes, "by having some code paths do UB I can get fas=
ter code".<br>
<br>
</span>That's not the argument. The argument is "by not having som=
e code paths, I get<br>
faster and/or smaller code".<br>
<span class=3D"m_-8942373410016678614m_8418329263813003623m_737413599938971=
0844gmail-"><br>
> In the example of:<br>
><br>
> const char* foo(int x) {<br>
> if (x =3D=3D 0) return "no";<br>
> if (x =3D=3D 1) return "yes";<br>
> }<br>
<br>
</span>That was not the example. It was using a switch. So let me change it=
on you to<br>
make it more specific:<br>
<br>
enum Values { E1, E2 };<br>
<br>
const char *foo(Values v)<br>
{<br>
=C2=A0 =C2=A0 switch (v) {<br>
=C2=A0 =C2=A0 case E1:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return "no";<br>
=C2=A0 =C2=A0 case E2:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return "yes";<br>
=C2=A0 =C2=A0 }<br>
}<br>
<br>
There's a distinct advantage in using a switch and not having a default=
:<br>
label: the compiler can warn me if I forgot any of the enumerations. So if =
a<br>
later version of my code does add E3, I can get a compiler warning.<br>
<br>
So now do your thing. Tell me how to write better code without losing that<=
br>
warning.<br>
<span class=3D"m_-8942373410016678614m_8418329263813003623m_737413599938971=
0844gmail-"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
</span></div></div><span class=3D"m_-8942373410016678614m_84183292638130036=
23m_7374135999389710844gmail-">--<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<span><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></span><span>To view this discussion on the web visit <a href=3D"htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/17204456.OZKWC7E4=
z5%40tjmaciei-mobl1" rel=3D"noreferrer" target=3D"_blank">https://groups.go=
ogle.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/17204456.OZKWC7E4z5%4=
0tjmacie<wbr>i-mobl1</a>.<br>
</span></blockquote></div><br></div></div></div></div></div><span>
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/is<wbr>ocpp.org/d/topic/std-proposals<wbr>/U=
u2QViiWh4k/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isoc<wbr>pp.org</a>.<span><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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hafVPg7YDvOHRt6uHbSpnh7X%2BjXy3=
5wWjQWba2KZKGPrw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/st=
d-proposals<wbr>/CALvx3hafVPg7YDvOHRt6uHbSpnh7<wbr>X%2BjXy35wWjQWba2KZKGPrw=
%40mai<wbr>l.gmail.com</a>.<br>
</blockquote></div><br></div></div><span>
<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@isoc<wbr>pp.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/CAJnLdOaTTe%3DDhd2qSzZUxRH5DgmdkGsWS5=
BA0VKUyv6rMODTDg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/st=
d-proposals<wbr>/CAJnLdOaTTe%3DDhd2qSzZUxRH5Dg<wbr>mdkGsWS5BA0VKUyv6rMODTDg=
%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CALvx3hb8xdEwYGpefvi2oiJm-wDwGADzBvuZ=
23%2B7%2BMJjaimbJg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hb8xdEw=
YGpefvi2oiJm-wDwGADzBvuZ23%2B7%2BMJjaimbJg%40mail.gmail.com</a>.<br />
--001a113f647619c99b0560c4e2ce--
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Wed, 20 Dec 2017 12:57:49 +0000
Raw View
--001a11495e187ef0b20560c52166
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Out of interest, what is this behaviour like with some converging loop?
E.g. a polynomial solver with some tolerance.
The reason I'm asking is that the UB CHANGES at different optimisation
levels, so if that has no net effect then what's the point of it?
With trivial examples it's very easy for an optimisation process to
simplify things into a more concise format, specifically because it's a
small and common pattern (sometimes surprisingly well. Clang even turns a
sum of unsigned i from i =3D 1 to N into the gauss summation N(N+1)/2,
eradicating the loop entirely). When the loop isn't unrollable, and the
result isn't something that a compiler could look and say "it's easier to
just do X instead of a loop", then I think the result could differ. On the
other hand, WITH undefined behaviour, such a trivial loop can actually be
simplified in the knowledge that a bad input deserves a bad output. A
classic example, though of a different UB, is that (i*2)/2 is usually
replaced with i, even when i is more than half of the upper limit.
I think a good idea would be for people to post loops they are concerned
about and see what this change would do, performance-wise.
On 20 Dec 2017 12:40, "Richard Hodges" <hodges.r@gmail.com> wrote:
>
> We can even do this, and the function is still 100% efficient:
>
> const char *foo(Values v)
> {
> assert(is_one_of(v, E1, E2));
>
> const char* bad_contract_result =3D "yes";
> switch (v) {
> case E1: return "no";
> case E2: return "yes";
> }
>
> return bad_contract_result;
> }
>
> results in:
>
> foo(Values):
> test edi, edi
> mov edx, OFFSET FLAT:.LC1
> mov eax, OFFSET FLAT:.LC0
> cmovne rax, rdx
> ret
>
> Still no UB, consequences explicitly spelled out, compiler warnings on
> missed cases, symmetric code.
>
> Optimisers are interested in observable outcomes. UB defeats optimisers.
>
>
> On 20 December 2017 at 13:31, Richard Hodges <hodges.r@gmail.com> wrote:
>
>> > After: imperative, mutating, asymmetric, braided control flow.
>>
>> You're nitpicking. The author of the UB foo argued that UB was necessary
>> for performance. It's not. It hinders performance. You know full well th=
at
>> you can express the intent of the contact to a human reader at zero cost
>> with an assert and/or contract documentation, like this:
>>
>> template<class T, class...LegalValues>
>> bool is_one_of(T&& v, LegalValues&&...lv)
>> {
>> return ((v =3D=3D lv) or ...);
>> }
>>
>> enum Values { E1, E2 };
>>
>> /// @param v is a member of the enum Values
>> /// @pre v shall be either E1 or E2
>> /// @note this function reserves the right to return any legal c string
>> /// should the precondition, above be not met.
>> const char *foo(Values v)
>> {
>> assert(is_one_of(v, E1, E2));
>>
>> const char* result =3D "no";
>> switch (v) {
>> case E1: break;
>> case E2: result =3D "yes"; break;
>> }
>> return result;
>> }
>>
>> compiling with gcc -std=3Dc++17 -O2 -DNDEBUG
>> foo(Values):
>> cmp edi, 1
>> mov edx, OFFSET FLAT:.LC0
>> mov eax, OFFSET FLAT:.LC1
>> cmovne rax, rdx
>> ret
>> As before. Zero ambiguity here. Plus a deliberate expression of contract=
,
>> intent and consequences. Callers can pay their money and take their choi=
ce.
>> At least now what they get is not compiler/platform/SDK dependent. It's
>> well-defined and 100% efficient.
>>
>> > There is also the issue that your version leaves open the question of
>> whether non-enumerated values are permissible. This has the potential to
>> turn into a wide contract, impeding maintainability.
>>
>> What? No, this version is simply expressing the behaviour that you got
>> accidentally, deliberately. Plus it has warnings about unhandled cases. =
The
>> behaviour is exactly the same as the UB version (at least on gcc) but no=
w
>> it's quicker and has no UB.
>>
>> > And what do you do if the return type has expensive assignment, is
>> non-assignable or immovable? Or if it is non-default constructible and i=
ts
>> ctors depend on the argument - a factory, say?
>>
>> Post an example and allow "Richy's UB Removal Service" to show you how t=
o
>> write efficient code without UB. Better yet, try it yourself. You'll be
>> amazed at what you're capable of.
>>
>>
>>
>>
>>
>>
>> On 20 December 2017 at 13:08, 'Edward Catmur' via ISO C++ Standard -
>> Future Proposals <std-proposals@isocpp.org> wrote:
>>
>>> On Wed, Dec 20, 2017 at 10:53 AM, Richard Hodges <hodges.r@gmail.com>
>>> wrote:
>>>
>>>> Thiago rather sullenly said:
>>>>
>>>> > That was not the example. It was using a switch. So let me change it
>>>> on you to
>>>> > make it more specific:
>>>>
>>>> > enum Values { E1, E2 };
>>>>
>>>> > const char *foo(Values v)
>>>> > {
>>>> > switch (v) {
>>>> > case E1:
>>>> > return "no";
>>>> > case E2:
>>>> > return "yes";
>>>> > }
>>>> >}
>>>>
>>>> > There's a distinct advantage in using a switch and not having a
>>>> default:
>>>> > label: the compiler can warn me if I forgot any of the enumerations.
>>>> So if a
>>>> >later version of my code does add E3, I can get a compiler warning.
>>>>
>>>> Sure, so now let's refactor the function into the same logic with no U=
B:
>>>>
>>>> enum Values { E1, E2 };
>>>>
>>>> const char *foo(Values v)
>>>> {
>>>> const char* result =3D "no";
>>>> switch (v) {
>>>> case E1: break;
>>>> case E2: result =3D "yes"; break;
>>>> }
>>>> return result;
>>>> }
>>>>
>>>
>>> I recognise that style is to some extent a matter of taste, but I would
>>> not accept that code change.
>>>
>>> Before: functional, SSA, symmetric, branching control flow.
>>> After: imperative, mutating, asymmetric, braided control flow.
>>>
>>> There is also the issue that your version leaves open the question of
>>> whether non-enumerated values are permissible. This has the potential t=
o
>>> turn into a wide contract, impeding maintainability.
>>>
>>> And what do you do if the return type has expensive assignment, is
>>> non-assignable or immovable? Or if it is non-default constructible and =
its
>>> ctors depend on the argument - a factory, say?
>>>
>>> And then let's look at gcc's output using the same compiler switches as
>>>> before:
>>>>
>>>> foo(Values):
>>>> cmp edi, 1
>>>> mov edx, OFFSET FLAT:.LC0
>>>> mov eax, OFFSET FLAT:.LC1
>>>> cmovne rax, rdx
>>>> ret
>>>>
>>>> Oh look! No UB, compiler warnings for unhandled cases and... perfect
>>>> code.
>>>>
>>>> Please feel free to offer more non-examples. "Richard's UB-Removal
>>>> Service" is at your disposal.
>>>>
>>>> There is absolutely no reason to allow a return path that does not
>>>> return a value. The fact that c++ does is not a design decision. It's
>>>> merely an ancient artefact of K&R C. It is an error to allow it in the
>>>> language.
>>>>
>>>>
>>>> On 20 December 2017 at 09:16, Thiago Macieira <thiago@macieira.org>
>>>> wrote:
>>>>
>>>>> On ter=C3=A7a-feira, 19 de dezembro de 2017 22:48:09 PST Richard Hodg=
es
>>>>> wrote:
>>>>> > Revisiting our examples deliberate non-returning functions again, i=
t
>>>>> seems
>>>>> > to me that all the arguments for allowing a function to return
>>>>> something on
>>>>> > an unexecuted path are based on a false premise.
>>>>> >
>>>>> > The argument goes, "by having some code paths do UB I can get faste=
r
>>>>> code".
>>>>>
>>>>> That's not the argument. The argument is "by not having some code
>>>>> paths, I get
>>>>> faster and/or smaller code".
>>>>>
>>>>> > In the example of:
>>>>> >
>>>>> > const char* foo(int x) {
>>>>> > if (x =3D=3D 0) return "no";
>>>>> > if (x =3D=3D 1) return "yes";
>>>>> > }
>>>>>
>>>>> That was not the example. It was using a switch. So let me change it
>>>>> on you to
>>>>> make it more specific:
>>>>>
>>>>> enum Values { E1, E2 };
>>>>>
>>>>> const char *foo(Values v)
>>>>> {
>>>>> switch (v) {
>>>>> case E1:
>>>>> return "no";
>>>>> case E2:
>>>>> return "yes";
>>>>> }
>>>>> }
>>>>>
>>>>> There's a distinct advantage in using a switch and not having a
>>>>> default:
>>>>> label: the compiler can warn me if I forgot any of the enumerations.
>>>>> So if a
>>>>> later version of my code does add E3, I can get a compiler warning.
>>>>>
>>>>> So now do your thing. Tell me how to write better code without losing
>>>>> that
>>>>> warning.
>>>>>
>>>>> --
>>>>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>>>> Software Architect - Intel Open Source Technology Center
>>>>>
>>>>> --
>>>>> 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, sen=
d
>>>>> 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
>>>>> /17204456.OZKWC7E4z5%40tjmaciei-mobl1.
>>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to a topic in the
>>>> Google Groups "ISO C++ Standard - Future Proposals" group.
>>>> To unsubscribe from this topic, visit https://groups.google.com/a/is
>>>> ocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
>>>> To unsubscribe from this group and all its topics, 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/i=
s
>>>> ocpp.org/d/msgid/std-proposals/CALvx3hafVPg7YDvOHRt6uHbSpnh7
>>>> X%2BjXy35wWjQWba2KZKGPrw%40mail.gmail.com
>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3ha=
fVPg7YDvOHRt6uHbSpnh7X%2BjXy35wWjQWba2KZKGPrw%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
>>>> .
>>>>
>>>
>>> --
>>> 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/is
>>> ocpp.org/d/msgid/std-proposals/CAJnLdOaTTe%3DDhd2qSzZUxRH5Dg
>>> mdkGsWS5BA0VKUyv6rMODTDg%40mail.gmail.com
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOaT=
Te%3DDhd2qSzZUxRH5DgmdkGsWS5BA0VKUyv6rMODTDg%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
>>> .
>>>
>>
>>
> --
> 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/CALvx3hb8xdEwYGpefvi2oiJm-
> wDwGADzBvuZ23%2B7%2BMJjaimbJg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hb8xd=
EwYGpefvi2oiJm-wDwGADzBvuZ23%2B7%2BMJjaimbJg%40mail.gmail.com?utm_medium=3D=
email&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/CAC%2B0CCORk%3DVb1yhQ7VnnuwyHAVF49pTrRLZix9MromZ=
RSh97cg%40mail.gmail.com.
--001a11495e187ef0b20560c52166
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">Out of interest, what is this behaviour like with some co=
nverging loop? E.g. a polynomial solver with some tolerance.<div dir=3D"aut=
o"><br></div><div dir=3D"auto">The reason I'm asking is that the UB CHA=
NGES at different optimisation levels, so if that has no net effect then wh=
at's the point of it?</div><div dir=3D"auto"><br></div><div dir=3D"auto=
">With trivial examples it's very easy for an optimisation process to s=
implify things into a more concise format, specifically because it's a =
small and common pattern (sometimes surprisingly well. Clang even turns a s=
um of unsigned i from i =3D 1 to N into the gauss summation N(N+1)/2, eradi=
cating the loop entirely). When the loop isn't unrollable, and the resu=
lt isn't something that a compiler could look and say "it's ea=
sier to just do X instead of a loop", then I think the result could di=
ffer. On the other hand, WITH undefined behaviour, such a trivial loop can =
actually be simplified in the knowledge that a bad input deserves a bad out=
put. A classic example, though of a different UB, is that (i*2)/2 is usuall=
y replaced with i, even when i is more than half of the upper limit.</div><=
div dir=3D"auto"><br></div><div dir=3D"auto">I think a good idea would be f=
or people to post loops they are concerned about and see what this change w=
ould do, performance-wise.</div></div><div class=3D"gmail_extra"><br><div c=
lass=3D"gmail_quote">On 20 Dec 2017 12:40, "Richard Hodges" <<=
a href=3D"mailto:hodges.r@gmail.com">hodges.r@gmail.com</a>> wrote:<br t=
ype=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><b=
r></div>We can even do this, and the function is still 100% efficient:<div>=
<br></div><div><div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,=
254);font-size:14px;line-height:21px;white-space:pre-wrap"><div><font face=
=3D"monospace, monospace"><span style=3D"color:rgb(0,0,255)">const</span> <=
span style=3D"color:rgb(0,0,255)">char</span> *foo(Values v)</font></div><d=
iv><font face=3D"monospace, monospace">{</font></div><div><font face=3D"mon=
ospace, monospace"> assert(is_one_of(v, E1, E2));</font></div><font face=
=3D"monospace, monospace"><br></font><div><font face=3D"monospace, monospac=
e"> <span style=3D"color:rgb(0,0,255)">const</span> <span style=3D"color=
:rgb(0,0,255)">char</span>* bad_contract_result =3D <span style=3D"color:rg=
b(163,21,21)">"yes"</span>;</font></div><div><font face=3D"monosp=
ace, monospace"> </font></div><div><font face=3D"monospace, monospace"> =
<span style=3D"color:rgb(0,0,255)">switch</span> (v) {</font></div><div>=
<font face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">=
case</span> E1: <span style=3D"color:rgb(0,0,255)">return</span> <span styl=
e=3D"color:rgb(163,21,21)">"no"</span>;</font></div><div><font fa=
ce=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">case</sp=
an> E2: <span style=3D"color:rgb(0,0,255)">return</span> <span style=3D"col=
or:rgb(163,21,21)">"yes"</span>;</font></div><div><font face=3D"m=
onospace, monospace"> }</font></div><font face=3D"monospace, monospace">=
<br></font><div><font face=3D"monospace, monospace"> <span style=3D"colo=
r:rgb(0,0,255)">return</span> bad_contract_result;</font></div><div><font f=
ace=3D"monospace, monospace">}</font></div><br></div></div><div style=3D"co=
lor:rgb(0,0,0);background-color:rgb(255,255,254);font-family:"Fira Mon=
o";font-size:14px;line-height:21px;white-space:pre-wrap">results in:</=
div><div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,254);font-f=
amily:"Fira Mono";font-size:14px;line-height:21px;white-space:pre=
-wrap"><br></div><div style=3D"color:rgb(0,0,0);background-color:rgb(255,25=
5,254);font-size:14px;line-height:21px;white-space:pre-wrap"><div style=3D"=
line-height:21px"><div><span style=3D"color:rgb(0,128,128)"><font face=3D"m=
onospace, monospace">foo(Values):</font></span></div><div><font face=3D"mon=
ospace, monospace"> <span style=3D"color:rgb(0,0,255)">test</span> =
<span style=3D"color:rgb(72,100,170)">edi</span>, <span style=3D"color:rg=
b(72,100,170)">edi</span></font></div><div><font face=3D"monospace, monospa=
ce"> <span style=3D"color:rgb(0,0,255)">mov</span> <span style=
=3D"color:rgb(72,100,170)">edx</span>, <span style=3D"color:rgb(0,128,128)"=
>OFFSET</span> <span style=3D"color:rgb(0,128,128)">FLAT</span>:<span style=
=3D"color:rgb(0,128,128)">.LC1</span></font></div><div><font face=3D"monosp=
ace, monospace"> <span style=3D"color:rgb(0,0,255)">mov</span> <=
span style=3D"color:rgb(72,100,170)">eax</span>, <span style=3D"color:rgb(0=
,128,128)">OFFSET</span> <span style=3D"color:rgb(0,128,128)">FLAT</span>:<=
span style=3D"color:rgb(0,128,128)">.LC0</span></font></div><div><font face=
=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">cmovne=
</span> <span style=3D"color:rgb(72,100,170)">rax</span>, <span style=3D"c=
olor:rgb(72,100,170)">rdx</span></font></div><div><font face=3D"monospace, =
monospace"> <span style=3D"color:rgb(0,0,255)">ret</span></font></di=
v></div></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extr=
a">Still no UB, consequences explicitly spelled out, compiler warnings on m=
issed cases, symmetric code.=C2=A0</div><div class=3D"gmail_extra"><br></di=
v><div class=3D"gmail_extra">Optimisers are interested in observable outcom=
es. UB defeats optimisers.=C2=A0</div><div class=3D"gmail_extra"><br></div>=
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 20 December 20=
17 at 13:31, Richard Hodges <span dir=3D"ltr"><<a href=3D"mailto:hodges.=
r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a>></span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span>>=C2=A0<span style=
=3D"font-size:12.8px">After: imperative, mutating, asymmetric, braided cont=
rol flow.</span><div><span style=3D"font-size:12.8px"><br></span></div></sp=
an><div><span style=3D"font-size:12.8px">You're nitpicking. The author =
of the UB foo argued that UB was necessary for performance. It's not. I=
t hinders performance. You know full well that you can express the intent o=
f the contact to a human reader at zero cost with an assert and/or contract=
documentation, like this:</span></div><div><span style=3D"font-size:12.8px=
"><br></span></div><div><div style=3D"background-color:rgb(255,255,254);lin=
e-height:21px"><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:pr=
e-wrap"><font face=3D"monospace, monospace"><span style=3D"color:rgb(0,0,25=
5)">template</span><<span style=3D"color:rgb(0,0,255)">class</span> T, <=
span style=3D"color:rgb(0,0,255)">class</span>...LegalValues></font></di=
v><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre-wrap"><font=
face=3D"monospace, monospace"><span style=3D"color:rgb(0,0,255)">bool</spa=
n> is_one_of(T&& v, LegalValues&&...lv)</font></div><div st=
yle=3D"color:rgb(0,0,0);font-size:14px;white-space:pre-wrap"><font face=3D"=
monospace, monospace">{</font></div><div style=3D"color:rgb(0,0,0);font-siz=
e:14px;white-space:pre-wrap"><font face=3D"monospace, monospace"> <span =
style=3D"color:rgb(0,0,255)">return</span> ((v =3D=3D lv) <span style=3D"co=
lor:rgb(0,0,255)">or</span> ...);</font></div><div style=3D"color:rgb(0,0,0=
);font-size:14px;white-space:pre-wrap"><font face=3D"monospace, monospace">=
}</font></div><font face=3D"monospace, monospace" style=3D"color:rgb(0,0,0)=
;font-size:14px;white-space:pre-wrap"><br></font><div style=3D"color:rgb(0,=
0,0);font-size:14px;white-space:pre-wrap"><font face=3D"monospace, monospac=
e"><span style=3D"color:rgb(0,0,255)">enum</span> Values { E1, E2 };</font>=
</div><font face=3D"monospace, monospace" style=3D"color:rgb(0,0,0);font-si=
ze:14px;white-space:pre-wrap"><br></font><div style=3D"color:rgb(0,0,0);fon=
t-size:14px;white-space:pre-wrap"><span style=3D"color:rgb(0,128,0)"><font =
face=3D"monospace, monospace">/// @param v is a member of the enum Values</=
font></span></div><div style=3D"color:rgb(0,0,0);font-size:14px;white-space=
:pre-wrap"><span style=3D"color:rgb(0,128,0)"><font face=3D"monospace, mono=
space">/// @pre v shall be either E1 or E2</font></span></div><div style=3D=
"color:rgb(0,0,0);font-size:14px;white-space:pre-wrap"><span style=3D"color=
:rgb(0,128,0)"><font face=3D"monospace, monospace">/// @note this function =
reserves the right to return any legal c string</font></span></div><div sty=
le=3D"color:rgb(0,0,0);font-size:14px;white-space:pre-wrap"><span style=3D"=
color:rgb(0,128,0)"><font face=3D"monospace, monospace">/// should th=
e precondition, above be not met.</font></span></div><div style=3D"color:rg=
b(0,0,0);font-size:14px;white-space:pre-wrap"><font face=3D"monospace, mono=
space"><span style=3D"color:rgb(0,0,255)">const</span> <span style=3D"color=
:rgb(0,0,255)">char</span> *foo(Values v)</font></div><div style=3D"color:r=
gb(0,0,0);font-size:14px;white-space:pre-wrap"><font face=3D"monospace, mon=
ospace">{</font></div><div style=3D"color:rgb(0,0,0);font-size:14px;white-s=
pace:pre-wrap"><font face=3D"monospace, monospace"> assert(is_one_of(v, =
E1, E2));</font></div><span><font face=3D"monospace, monospace" style=3D"co=
lor:rgb(0,0,0);font-size:14px;white-space:pre-wrap"><br></font><div style=
=3D"color:rgb(0,0,0);font-size:14px;white-space:pre-wrap"><font face=3D"mon=
ospace, monospace"> <span style=3D"color:rgb(0,0,255)">const</span> <spa=
n style=3D"color:rgb(0,0,255)">char</span>* result =3D <span style=3D"color=
:rgb(163,21,21)">"no"</span>;</font></div><div style=3D"color:rgb=
(0,0,0);font-size:14px;white-space:pre-wrap"><font face=3D"monospace, monos=
pace"> <span style=3D"color:rgb(0,0,255)">switch</span> (v) {</font></di=
v><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre-wrap"><font=
face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">case<=
/span> E1: <span style=3D"color:rgb(0,0,255)">break</span>;</font></div><di=
v style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre-wrap"><font face=
=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">case</span=
> E2: result =3D <span style=3D"color:rgb(163,21,21)">"yes"</span=
>; <span style=3D"color:rgb(0,0,255)">break</span>;</font></div><div style=
=3D"color:rgb(0,0,0);font-size:14px;white-space:pre-wrap"><font face=3D"mon=
ospace, monospace"> }</font></div><div style=3D"color:rgb(0,0,0);font-si=
ze:14px;white-space:pre-wrap"><font face=3D"monospace, monospace"> <span=
style=3D"color:rgb(0,0,255)">return</span> result;</font></div><div style=
=3D"color:rgb(0,0,0);font-size:14px;white-space:pre-wrap"><font face=3D"mon=
ospace, monospace">}</font></div><div style=3D"color:rgb(0,0,0);font-size:1=
4px;white-space:pre-wrap"><font face=3D"monospace, monospace"><br></font></=
div></span><div><font face=3D"monospace, monospace" style=3D"color:rgb(0,0,=
0);font-size:14px;white-space:pre-wrap">compiling with gcc </font><font col=
or=3D"#000000" face=3D"monospace, monospace"><span style=3D"font-size:14px;=
white-space:pre-wrap">-std=3Dc++17 -O2 -DNDEBUG</span></font></div><div><di=
v style=3D"color:rgb(0,0,0);font-size:14px;line-height:21px;white-space:pre=
-wrap"><span><div><span style=3D"color:rgb(0,128,128)"><font face=3D"monosp=
ace, monospace">foo(Values):</font></span></div><div><font face=3D"monospac=
e, monospace"> <span style=3D"color:rgb(0,0,255)">cmp</span> <sp=
an style=3D"color:rgb(72,100,170)">edi</span>, <span style=3D"color:rgb(9,1=
36,90)">1</span></font></div><div><font face=3D"monospace, monospace"> =
<span style=3D"color:rgb(0,0,255)">mov</span> <span style=3D"color:r=
gb(72,100,170)">edx</span>, <span style=3D"color:rgb(0,128,128)">OFFSET</sp=
an> <span style=3D"color:rgb(0,128,128)">FLAT</span>:<span style=3D"color:r=
gb(0,128,128)">.LC0</span></font></div><div><font face=3D"monospace, monosp=
ace"> <span style=3D"color:rgb(0,0,255)">mov</span> <span style=
=3D"color:rgb(72,100,170)">eax</span>, <span style=3D"color:rgb(0,128,128)"=
>OFFSET</span> <span style=3D"color:rgb(0,128,128)">FLAT</span>:<span style=
=3D"color:rgb(0,128,128)">.LC1</span></font></div><div><font face=3D"monosp=
ace, monospace"> <span style=3D"color:rgb(0,0,255)">cmovne</span> <=
span style=3D"color:rgb(72,100,170)">rax</span>, <span style=3D"color:rgb(7=
2,100,170)">rdx</span></font></div><div><font face=3D"monospace, monospace"=
> <span style=3D"color:rgb(0,0,255)">ret</span></font></div></span><=
div style=3D"font-family:"Fira Mono"">As before. Zero ambiguity h=
ere. Plus a deliberate expression of contract, intent and consequences. Cal=
lers can pay their money and take their choice. At least now what they get =
is not compiler/platform/SDK dependent. It's well-defined and 100% effi=
cient.</div><div style=3D"font-family:"Fira Mono""><br></div></di=
v></div></div></div><span><div><span style=3D"font-size:12.8px">>=C2=A0<=
/span><span style=3D"font-size:12.8px">There is also the issue that your ve=
rsion leaves open the question of whether non-enumerated values are permiss=
ible. This has the potential to turn into a wide contract, impeding maintai=
nability.</span></div><div><span style=3D"font-size:12.8px"><br></span></di=
v></span><div>What? No, this version is simply expressing the behaviour tha=
t you got accidentally, deliberately. Plus it has warnings about unhandled =
cases. The behaviour is exactly the same as the UB version (at least on gcc=
) but now it's quicker and has no UB.</div><span><div><br></div><div>&g=
t;=C2=A0<span style=3D"font-size:12.8px">And what do you do if the return t=
ype has expensive assignment, is non-assignable or immovable? Or if it is n=
on-default constructible and its ctors depend on the argument - a factory, =
say?</span></div><div><span style=3D"font-size:12.8px"><br></span></div></s=
pan><div><span style=3D"font-size:12.8px">Post an example and allow "R=
ichy's UB Removal Service" to show you how to write efficient code=
without UB. Better yet, try it yourself. You'll be amazed at what you&=
#39;re capable of.</span></div><div><span style=3D"font-size:12.8px"><br></=
span></div><div><br></div><div><span style=3D"font-size:12.8px"><br></span>=
</div><div><span style=3D"font-size:12.8px"><br></span></div><div><br></div=
></div><div class=3D"m_-5056915537697166450HOEnZb"><div class=3D"m_-5056915=
537697166450h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">O=
n 20 December 2017 at 13:08, 'Edward Catmur' via ISO C++ Standard -=
Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@iso=
cpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra=
"><div class=3D"gmail_quote"><span>On Wed, Dec 20, 2017 at 10:53 AM, Richar=
d Hodges <span dir=3D"ltr"><<a href=3D"mailto:hodges.r@gmail.com" target=
=3D"_blank">hodges.r@gmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">Thiago rather sullenly said:<div><br></div><=
div><span>> That was not the example. It was using a switch. So let me c=
hange it on you to<br>> make it more specific:<br><br>> enum Values {=
E1, E2 };<br><br>> const char *foo(Values v)<br>> {<br>>=C2=A0 =
=C2=A0 switch (v) {<br>>=C2=A0 =C2=A0 =C2=A0case E1:<br>>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 return "no";<br>>=C2=A0 =C2=A0 case E2:<br>&=
gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 return "yes";<br>>=C2=A0 =C2=A0=
}<br>>}<br><br>> There's a distinct advantage in using a switch =
and not having a default:<br>> label: the compiler can warn me if I forg=
ot any of the enumerations. So if a<br>>later version of my code does ad=
d E3, I can get a compiler warning.<br><div><br></div></span><div>Sure, so =
now let's refactor the function into the same logic with no UB:</div><d=
iv><br></div><div><div style=3D"color:rgb(0,0,0);background-color:rgb(255,2=
55,254);font-size:14px;line-height:21px;white-space:pre-wrap"><div><font fa=
ce=3D"monospace, monospace"><span style=3D"color:rgb(0,0,255)">enum</span> =
Values { E1, E2 };</font></div><font face=3D"monospace, monospace"><br></fo=
nt></div></div><div><div style=3D"color:rgb(0,0,0);background-color:rgb(255=
,255,254);font-size:14px;line-height:21px;white-space:pre-wrap"><div><font =
face=3D"monospace, monospace"><span style=3D"color:rgb(0,0,255)">const</spa=
n> <span style=3D"color:rgb(0,0,255)">char</span> *foo(Values v)</font></di=
v><div><font face=3D"monospace, monospace">{</font></div><div><font face=3D=
"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">const</span> =
<span style=3D"color:rgb(0,0,255)">char</span>* result =3D <span style=3D"c=
olor:rgb(163,21,21)">"no"</span>;</font></div><div><font face=3D"=
monospace, monospace"> <span style=3D"color:rgb(0,0,255)">switch</span> =
(v) {</font></div><div><font face=3D"monospace, monospace"> <span style=
=3D"color:rgb(0,0,255)">case</span> E1: <span style=3D"color:rgb(0,0,255)">=
break</span>;</font></div><div><font face=3D"monospace, monospace"> <spa=
n style=3D"color:rgb(0,0,255)">case</span> E2: result =3D <span style=3D"co=
lor:rgb(163,21,21)">"yes"</span>; <span style=3D"color:rgb(0,0,25=
5)">break</span>;</font></div><div><font face=3D"monospace, monospace"> =
}</font></div><div><font face=3D"monospace, monospace"> <span style=3D"c=
olor:rgb(0,0,255)">return</span> result;</font></div><div><font face=3D"mon=
ospace, monospace">}</font></div></div></div></div></div></blockquote><div>=
<br></div></span><div>I recognise that style is to some extent a matter of =
taste, but I would not accept that code change.</div><div><br></div><div>Be=
fore: functional, SSA, symmetric, branching control flow.</div><div>After: =
imperative, mutating, asymmetric, braided control flow.</div><div><br></div=
><div>There is also the issue that your version leaves open the question of=
whether non-enumerated values are permissible. This has the potential to t=
urn into a wide contract, impeding maintainability.</div><div><br></div><di=
v>And what do you do if the return type has expensive assignment, is non-as=
signable or immovable? Or if it is non-default constructible and its ctors =
depend on the argument - a factory, say?</div><div><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div><div class=3D"m_-5056915537697166450m_-89423734100166=
78614h5"><div dir=3D"ltr"><div><div><div style=3D"color:rgb(0,0,0);backgrou=
nd-color:rgb(255,255,254);font-size:14px;line-height:21px;white-space:pre-w=
rap"><font face=3D"Fira Mono">And then let's look at gcc's output u=
sing the same compiler switches as before:</font></div></div><div style=3D"=
color:rgb(0,0,0);background-color:rgb(255,255,254);font-size:14px;line-heig=
ht:21px;white-space:pre-wrap"><font face=3D"Fira Mono"><br></font></div><di=
v style=3D"color:rgb(0,0,0);background-color:rgb(255,255,254);font-size:14p=
x;line-height:21px;white-space:pre-wrap"><div style=3D"line-height:21px"><d=
iv><span style=3D"color:rgb(0,128,128)"><font face=3D"monospace, monospace"=
>foo(Values):</font></span></div><div><font face=3D"monospace, monospace"> =
<span style=3D"color:rgb(0,0,255)">cmp</span> <span style=3D"col=
or:rgb(72,100,170)">edi</span>, <span style=3D"color:rgb(9,136,90)">1</span=
></font></div><div><font face=3D"monospace, monospace"> <span style=
=3D"color:rgb(0,0,255)">mov</span> <span style=3D"color:rgb(72,100,170)=
">edx</span>, <span style=3D"color:rgb(0,128,128)">OFFSET</span> <span styl=
e=3D"color:rgb(0,128,128)">FLAT</span>:<span style=3D"color:rgb(0,128,128)"=
>.LC0</span></font></div><span><div><font face=3D"monospace, monospace"> =
<span style=3D"color:rgb(0,0,255)">mov</span> <span style=3D"color=
:rgb(72,100,170)">eax</span>, <span style=3D"color:rgb(0,128,128)">OFFSET</=
span> <span style=3D"color:rgb(0,128,128)">FLAT</span>:<span style=3D"color=
:rgb(0,128,128)">.LC1</span></font></div></span><div><font face=3D"monospac=
e, monospace"> <span style=3D"color:rgb(0,0,255)">cmovne</span> <sp=
an style=3D"color:rgb(72,100,170)">rax</span>, <span style=3D"color:rgb(72,=
100,170)">rdx</span></font></div><div><font face=3D"monospace, monospace"> =
<span style=3D"color:rgb(0,0,255)">ret</span></font></div></div></di=
v><div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,254);font-fam=
ily:"Fira Mono";font-size:14px;line-height:21px;white-space:pre-w=
rap"><br></div><div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,=
254);font-family:"Fira Mono";font-size:14px;line-height:21px;whit=
e-space:pre-wrap">Oh look! No UB, compiler warnings for unhandled cases and=
.... perfect code.</div><div style=3D"color:rgb(0,0,0);background-color:rgb(=
255,255,254);font-family:"Fira Mono";font-size:14px;line-height:2=
1px;white-space:pre-wrap"><br></div><div style=3D"color:rgb(0,0,0);backgrou=
nd-color:rgb(255,255,254);font-family:"Fira Mono";font-size:14px;=
line-height:21px;white-space:pre-wrap">Please feel free to offer more non-e=
xamples. "Richard's UB-Removal Service" is at your disposal.<=
/div><div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,254);font-=
family:"Fira Mono";font-size:14px;line-height:21px;white-space:pr=
e-wrap"><br></div><div style=3D"color:rgb(0,0,0);background-color:rgb(255,2=
55,254);font-family:"Fira Mono";font-size:14px;line-height:21px;w=
hite-space:pre-wrap">There is absolutely no reason to allow a return path t=
hat does not return a value. The fact that c++ does is not a design decisio=
n. It's merely an ancient artefact of K&R C. It is an error to allo=
w it in the language.</div><div style=3D"color:rgb(0,0,0);background-color:=
rgb(255,255,254);font-family:"Fira Mono";font-size:14px;line-heig=
ht:21px;white-space:pre-wrap"><br></div><div class=3D"gmail_extra"><br><div=
class=3D"gmail_quote"><div><div class=3D"m_-5056915537697166450m_-89423734=
10016678614m_8418329263813003623h5">On 20 December 2017 at 09:16, Thiago Ma=
cieira <span dir=3D"ltr"><<a href=3D"mailto:thiago@macieira.org" target=
=3D"_blank">thiago@macieira.org</a>></span> wrote:<br></div></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div><div class=3D"m_-505691553=
7697166450m_-8942373410016678614m_8418329263813003623h5"><span class=3D"m_-=
5056915537697166450m_-8942373410016678614m_8418329263813003623m_73741359993=
89710844gmail-">On ter=C3=A7a-feira, 19 de dezembro de 2017 22:48:09 PST Ri=
chard Hodges wrote:<br>
> Revisiting our examples deliberate non-returning functions again, it s=
eems<br>
> to me that all the arguments for allowing a function to return somethi=
ng on<br>
> an unexecuted path are based on a false premise.<br>
><br>
> The argument goes, "by having some code paths do UB I can get fas=
ter code".<br>
<br>
</span>That's not the argument. The argument is "by not having som=
e code paths, I get<br>
faster and/or smaller code".<br>
<span class=3D"m_-5056915537697166450m_-8942373410016678614m_84183292638130=
03623m_7374135999389710844gmail-"><br>
> In the example of:<br>
><br>
> const char* foo(int x) {<br>
> if (x =3D=3D 0) return "no";<br>
> if (x =3D=3D 1) return "yes";<br>
> }<br>
<br>
</span>That was not the example. It was using a switch. So let me change it=
on you to<br>
make it more specific:<br>
<br>
enum Values { E1, E2 };<br>
<br>
const char *foo(Values v)<br>
{<br>
=C2=A0 =C2=A0 switch (v) {<br>
=C2=A0 =C2=A0 case E1:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return "no";<br>
=C2=A0 =C2=A0 case E2:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return "yes";<br>
=C2=A0 =C2=A0 }<br>
}<br>
<br>
There's a distinct advantage in using a switch and not having a default=
:<br>
label: the compiler can warn me if I forgot any of the enumerations. So if =
a<br>
later version of my code does add E3, I can get a compiler warning.<br>
<br>
So now do your thing. Tell me how to write better code without losing that<=
br>
warning.<br>
<span class=3D"m_-5056915537697166450m_-8942373410016678614m_84183292638130=
03623m_7374135999389710844gmail-"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
</span></div></div><span class=3D"m_-5056915537697166450m_-8942373410016678=
614m_8418329263813003623m_7374135999389710844gmail-">--<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<span><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></span><span>To view this discussion on the web visit <a href=3D"htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/17204456.OZKWC7E4=
z5%40tjmaciei-mobl1" rel=3D"noreferrer" target=3D"_blank">https://groups.go=
ogle.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/17204456.OZKWC7E4z5%4=
0tjmacie<wbr>i-mobl1</a>.<br>
</span></blockquote></div><br></div></div></div></div></div><span>
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/is<wbr>ocpp.org/d/topic/std-proposals<wbr>/U=
u2QViiWh4k/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isoc<wbr>pp.org</a>.<span><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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hafVPg7YDvOHRt6uHbSpnh7X%2BjXy3=
5wWjQWba2KZKGPrw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/st=
d-proposals<wbr>/CALvx3hafVPg7YDvOHRt6uHbSpnh7<wbr>X%2BjXy35wWjQWba2KZKGPrw=
%40mai<wbr>l.gmail.com</a>.<br>
</blockquote></div><br></div></div><span>
<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@isoc<wbr>pp.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/CAJnLdOaTTe%3DDhd2qSzZUxRH5DgmdkGsWS5=
BA0VKUyv6rMODTDg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/st=
d-proposals<wbr>/CAJnLdOaTTe%3DDhd2qSzZUxRH5Dg<wbr>mdkGsWS5BA0VKUyv6rMODTDg=
%40mai<wbr>l.gmail.com</a>.<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hb8xdEwYGpefvi2oiJm-wDwGADzBvuZ=
23%2B7%2BMJjaimbJg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/=
std-<wbr>proposals/<wbr>CALvx3hb8xdEwYGpefvi2oiJm-<wbr>wDwGADzBvuZ23%2B7%2B=
MJjaimbJg%<wbr>40mail.gmail.com</a>.<br>
</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/CAC%2B0CCORk%3DVb1yhQ7VnnuwyHAVF49pTr=
RLZix9MromZRSh97cg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCORk%=
3DVb1yhQ7VnnuwyHAVF49pTrRLZix9MromZRSh97cg%40mail.gmail.com</a>.<br />
--001a11495e187ef0b20560c52166--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 20 Dec 2017 06:58:31 -0800 (PST)
Raw View
------=_Part_2677_1755894714.1513781911538
Content-Type: multipart/alternative;
boundary="----=_Part_2678_953964167.1513781911538"
------=_Part_2678_953964167.1513781911538
Content-Type: text/plain; charset="UTF-8"
On Wednesday, December 20, 2017 at 7:57:53 AM UTC-5, Jake Arkinstall wrote:
>
> I think a good idea would be for people to post loops they are concerned
> about and see what this change would do, performance-wise.
>
I don't agree. That gives too much weight to the "let's make this change"
argument. See, the burden of proof is on those* proposing* the change to
show that it* won't* affect performance or whatever.
>
--
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/c664246c-bfa9-4712-8317-81a59b0775e7%40isocpp.org.
------=_Part_2678_953964167.1513781911538
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, December 20, 2017 at 7:57:53 AM UTC-5, Jake =
Arkinstall wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"a=
uto"><div dir=3D"auto">I think a good idea would be for people to post loop=
s they are concerned about and see what this change would do, performance-w=
ise.</div></div></blockquote><div><br></div><div>I don't agree. That gi=
ves too much weight to the "let's make this change" argument.=
See, the burden of proof is on those<i> proposing</i> the change to show t=
hat it<i> won't</i> affect performance or whatever.<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div><div class=3D"gmail_quote"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">
</blockquote></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/c664246c-bfa9-4712-8317-81a59b0775e7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c664246c-bfa9-4712-8317-81a59b0775e7=
%40isocpp.org</a>.<br />
------=_Part_2678_953964167.1513781911538--
------=_Part_2677_1755894714.1513781911538--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 20 Dec 2017 07:12:19 -0800 (PST)
Raw View
------=_Part_2854_1429143575.1513782740066
Content-Type: multipart/alternative;
boundary="----=_Part_2855_2098122133.1513782740066"
------=_Part_2855_2098122133.1513782740066
Content-Type: text/plain; charset="UTF-8"
On Wednesday, December 20, 2017 at 7:31:37 AM UTC-5, Richard Hodges wrote:
>
> > After: imperative, mutating, asymmetric, braided control flow.
>
> You're nitpicking. The author of the UB foo argued that UB was necessary
> for performance. It's not.
>
So you've in favor of writing ugly code just to avoid the performance
penalty for your idea? I have a hard time finding that to be convincing.
People don't add variables unless they need them, and this code doesn't
*need* them. Everything here is static and based on literals, so there's no
reason to have a variable. Not unless you're pedantic about some UB that
will never happen.
That code should fail a code review for being needlessly complicated.
It hinders performance. You know full well that you can express the intent
> of the contact to a human reader at zero cost with an assert and/or
> contract documentation,
>
So long as the number of enumerators doesn't exceed the compiler limits on
the number of function or template arguments. `switch` statements either
have no such limits or have a lot higher limits.
Not to mention this requires manually entering the enumerators an
additional time. DRY is a thing for a reason.
It's better to just let compilers *do their jobs*. They've been looking out
for missing enumerators on `switch` conditions for over a decade; why
should we start hard-coding that into our programs?
--
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/07ff3dff-9b90-425e-98ff-ec435ba12ca2%40isocpp.org.
------=_Part_2855_2098122133.1513782740066
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, December 20, 2017 at 7:31:37 AM UTC-5, Richa=
rd Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">>=C2=A0<span style=3D"font-size:12.8px">After: imperative, mutating, =
asymmetric, braided control flow.</span><div><span style=3D"font-size:12.8p=
x"><br></span></div><div><span style=3D"font-size:12.8px">You're nitpic=
king. The author of the UB foo argued that UB was necessary for performance=
.. It's not.</span></div></div></blockquote><div><br></div><div>So you&#=
39;ve in favor of writing ugly code just to avoid the performance penalty f=
or your idea? I have a hard time finding that to be convincing.</div><div><=
br></div><div>People don't add variables unless they need them, and thi=
s code doesn't <i>need</i> them. Everything here is static and based on=
literals, so there's no reason to have a variable. Not unless you'=
re pedantic about some UB that will never happen.</div><div><br></div><div>=
That code should fail a code review for being needlessly complicated.</div>=
<div><i><br></i></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><span style=3D"font-size:12.8px">It hinders performance. You =
know full well that you can express the intent of the contact to a human re=
ader at zero cost with an assert and/or contract documentation,</span></div=
></div></blockquote><div><br></div><div>So long as the number of enumerator=
s doesn't exceed the compiler limits on the number of function or templ=
ate arguments. `switch` statements either have no such limits or have a lot=
higher limits.</div><div><br></div><div>Not to mention this requires manua=
lly entering the enumerators an additional time. DRY is a thing for a reaso=
n.</div><div><i><br></i></div><div>It's better to just let compilers <i=
>do their jobs</i>. They've been looking out for missing enumerators on=
`switch` conditions for over a decade; why should we start hard-coding tha=
t into our programs?</div><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;">
</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/07ff3dff-9b90-425e-98ff-ec435ba12ca2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/07ff3dff-9b90-425e-98ff-ec435ba12ca2=
%40isocpp.org</a>.<br />
------=_Part_2855_2098122133.1513782740066--
------=_Part_2854_1429143575.1513782740066--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Wed, 20 Dec 2017 16:32:12 +0100
Raw View
--001a113fbc089b4f700560c749c9
Content-Type: text/plain; charset="UTF-8"
> So you've in favor of writing ugly code just to avoid the performance
penalty for your idea?
Any retort that begins with the word, "so" is bound to be needlessly
confrontational. Are you really here in the interests of the language?
Please think carefully before answering.
Please kindly see the second implementation.
Also please ponder carefully the fact that the versions of this function
with no UB produce better code than when the compiler is faced with UB.
If you can find me a function that produces better code when UB is invoked
around the return value, I'm all eyes and ears. Until then, the performance
argument fails at the first test.
I have shown you facts.
Refute with facts, or please kindly stop and think.
On 20 December 2017 at 16:12, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, December 20, 2017 at 7:31:37 AM UTC-5, Richard Hodges wrote:
>>
>> > After: imperative, mutating, asymmetric, braided control flow.
>>
>> You're nitpicking. The author of the UB foo argued that UB was necessary
>> for performance. It's not.
>>
>
> So you've in favor of writing ugly code just to avoid the performance
> penalty for your idea? I have a hard time finding that to be convincing.
>
> People don't add variables unless they need them, and this code doesn't
> *need* them. Everything here is static and based on literals, so there's
> no reason to have a variable. Not unless you're pedantic about some UB that
> will never happen.
>
> That code should fail a code review for being needlessly complicated.
>
> It hinders performance. You know full well that you can express the intent
>> of the contact to a human reader at zero cost with an assert and/or
>> contract documentation,
>>
>
> So long as the number of enumerators doesn't exceed the compiler limits on
> the number of function or template arguments. `switch` statements either
> have no such limits or have a lot higher limits.
>
> Not to mention this requires manually entering the enumerators an
> additional time. DRY is a thing for a reason.
>
> It's better to just let compilers *do their jobs*. They've been looking
> out for missing enumerators on `switch` conditions for over a decade; why
> should we start hard-coding that into our programs?
>
> --
> 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/07ff3dff-9b90-425e-
> 98ff-ec435ba12ca2%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/07ff3dff-9b90-425e-98ff-ec435ba12ca2%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CALvx3hYmZ43uKf_HYOMnK-uFaeDwR8DaGoq1UjsUB3OtA9gwdQ%40mail.gmail.com.
--001a113fbc089b4f700560c749c9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">So you've i=
n favor of writing ugly code just to avoid the performance penalty for your=
idea?</span><div><span style=3D"font-size:12.8px"><br></span></div><div><s=
pan style=3D"font-size:12.8px">Any retort that begins with the word, "=
so" is bound to be needlessly confrontational. Are you really here in =
the interests of the language? Please think carefully before answering.</sp=
an></div><div><span style=3D"font-size:12.8px"><br></span></div><div><span =
style=3D"font-size:12.8px">Please kindly see the second implementation.</sp=
an></div><div><span style=3D"font-size:12.8px"><br></span></div><div><span =
style=3D"font-size:12.8px">Also please ponder carefully the fact that the v=
ersions of this function with no UB produce better code than when the compi=
ler is faced with UB.</span></div><div><span style=3D"font-size:12.8px"><br=
></span></div><div><span style=3D"font-size:12.8px">If you can find me a fu=
nction that produces better code when UB is invoked around the return value=
, I'm all eyes and ears. Until then, the performance argument fails at =
the first test.=C2=A0</span></div><div><span style=3D"font-size:12.8px"><br=
></span></div><div><span style=3D"font-size:12.8px">I have shown you facts.=
</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><s=
pan style=3D"font-size:12.8px">Refute with facts, or please kindly stop and=
think.</span></div><div><span style=3D"font-size:12.8px"><br></span></div>=
<div><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"=
font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px"><b=
r></span></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 20 December 2017 at 16:12, Nicol Bolas <span dir=3D"ltr"><<a href=
=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span c=
lass=3D"">On Wednesday, December 20, 2017 at 7:31:37 AM UTC-5, Richard Hodg=
es wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">>=C2=
=A0<span style=3D"font-size:12.8px">After: imperative, mutating, asymmetric=
, braided control flow.</span><div><span style=3D"font-size:12.8px"><br></s=
pan></div><div><span style=3D"font-size:12.8px">You're nitpicking. The =
author of the UB foo argued that UB was necessary for performance. It's=
not.</span></div></div></blockquote><div><br></div></span><div>So you'=
ve in favor of writing ugly code just to avoid the performance penalty for =
your idea? I have a hard time finding that to be convincing.</div><div><br>=
</div><div>People don't add variables unless they need them, and this c=
ode doesn't <i>need</i> them. Everything here is static and based on li=
terals, so there's no reason to have a variable. Not unless you're =
pedantic about some UB that will never happen.</div><div><br></div><div>Tha=
t code should fail a code review for being needlessly complicated.</div><sp=
an class=3D""><div><i><br></i></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div><span style=3D"font-size:12.8px">It hinders performa=
nce. You know full well that you can express the intent of the contact to a=
human reader at zero cost with an assert and/or contract documentation,</s=
pan></div></div></blockquote><div><br></div></span><div>So long as the numb=
er of enumerators doesn't exceed the compiler limits on the number of f=
unction or template arguments. `switch` statements either have no such limi=
ts or have a lot higher limits.</div><div><br></div><div>Not to mention thi=
s requires manually entering the enumerators an additional time. DRY is a t=
hing for a reason.</div><div><i><br></i></div><div>It's better to just =
let compilers <i>do their jobs</i>. They've been looking out for missin=
g enumerators on `switch` conditions for over a decade; why should we start=
hard-coding that into our programs?</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex">
</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/07ff3dff-9b90-425e-98ff-ec435ba12ca2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/07ff=
3dff-9b90-425e-<wbr>98ff-ec435ba12ca2%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/CALvx3hYmZ43uKf_HYOMnK-uFaeDwR8DaGoq1=
UjsUB3OtA9gwdQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hYmZ43uKf_H=
YOMnK-uFaeDwR8DaGoq1UjsUB3OtA9gwdQ%40mail.gmail.com</a>.<br />
--001a113fbc089b4f700560c749c9--
.
Author: Dilip Ranganathan <misc.usage@gmail.com>
Date: Wed, 20 Dec 2017 10:50:10 -0500
Raw View
--94eb2c05e7c0df1b020560c789d9
Content-Type: text/plain; charset="UTF-8"
On Wed, Dec 20, 2017 at 10:12 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, December 20, 2017 at 7:31:37 AM UTC-5, Richard Hodges wrote:
>>
>> > After: imperative, mutating, asymmetric, braided control flow.
>>
>> You're nitpicking. The author of the UB foo argued that UB was necessary
>> for performance. It's not.
>>
>
> So you've in favor of writing ugly code just to avoid the performance
> penalty for your idea? I have a hard time finding that to be convincing.
>
But _where_ is this penalty? Richard's re-write of every example posted
thus far seems to
produce better code than when the compiler is faced with UB.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALEPxfsKRgRcNCeaxVU6uic6%3DaXA_NvbC%2B3sDboKMcov%2BfGquw%40mail.gmail.com.
--94eb2c05e7c0df1b020560c789d9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Wed, Dec 20, 2017 at 10:12 AM, Nicol Bolas <span dir=3D"ltr"><<a href=
=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span c=
lass=3D"">On Wednesday, December 20, 2017 at 7:31:37 AM UTC-5, Richard Hodg=
es wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">>=C2=
=A0<span style=3D"font-size:12.8px">After: imperative, mutating, asymmetric=
, braided control flow.</span><div><span style=3D"font-size:12.8px"><br></s=
pan></div><div><span style=3D"font-size:12.8px">You're nitpicking. The =
author of the UB foo argued that UB was necessary for performance. It's=
not.</span></div></div></blockquote><div><br></div></span><div>So you'=
ve in favor of writing ugly code just to avoid the performance penalty for =
your idea? I have a hard time finding that to be convincing.</div></div></b=
lockquote><div><br></div><div>But _where_ is this penalty? Richard's re=
-write of every example posted thus far seems to</div><div>produce better c=
ode than when the compiler is faced with UB.</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/CALEPxfsKRgRcNCeaxVU6uic6%3DaXA_NvbC%=
2B3sDboKMcov%2BfGquw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALEPxfsKRg=
RcNCeaxVU6uic6%3DaXA_NvbC%2B3sDboKMcov%2BfGquw%40mail.gmail.com</a>.<br />
--94eb2c05e7c0df1b020560c789d9--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 20 Dec 2017 17:55:14 +0200
Raw View
On 20 December 2017 at 16:58, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, December 20, 2017 at 7:57:53 AM UTC-5, Jake Arkinstall wrote:
>>
>> I think a good idea would be for people to post loops they are concerned
>> about and see what this change would do, performance-wise.
>
>
> I don't agree. That gives too much weight to the "let's make this change"
> argument. See, the burden of proof is on those proposing the change to show
> that it won't affect performance or whatever.
This exercise is pointless. Here's an excerpt from a discussion
between two committee members in Albuquerque:
VV: We could go towards a direction of making the lack of return
ill-formed. Compilers already diagnose it, by default.
CC: But how do you know you call the function?
VV: I don't. That runs into the Halting Problem. This would therefore
cause unnecessary churn in valid code. Consider
the idea withdrawn. Let's kill it if it comes up in the form of a proposal.
CC: Agreed.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZ3_BKrqR2tuxWWDc%2B8K%2By3F0La%3Dv60gN-hD77jamn4wQ%40mail.gmail.com.
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Wed, 20 Dec 2017 16:59:42 +0100
Raw View
--f403045c4866f526410560c7abe5
Content-Type: text/plain; charset="UTF-8"
> This exercise is pointless. Here's an excerpt from a discussion
> between two committee members in Albuquerque:
It is not pointless. It simply means that these two people need to be
sidelined or convinced in the interests of the common good. They are
humans, not gods or emperors. They hold no more power than we the community
choose to give them.
That process begins with an irrefutable argument. Thus far, attempts to
refute my argument have come to nothing.
I am still waiting for code that compiles better when UB is involved guys.
I can wait all day if you want...
Bring it, please.
On 20 December 2017 at 16:55, Ville Voutilainen <ville.voutilainen@gmail.com
> wrote:
> On 20 December 2017 at 16:58, Nicol Bolas <jmckesson@gmail.com> wrote:
> > On Wednesday, December 20, 2017 at 7:57:53 AM UTC-5, Jake Arkinstall
> wrote:
> >>
> >> I think a good idea would be for people to post loops they are concerned
> >> about and see what this change would do, performance-wise.
> >
> >
> > I don't agree. That gives too much weight to the "let's make this change"
> > argument. See, the burden of proof is on those proposing the change to
> show
> > that it won't affect performance or whatever.
>
> This exercise is pointless. Here's an excerpt from a discussion
> between two committee members in Albuquerque:
>
> VV: We could go towards a direction of making the lack of return
> ill-formed. Compilers already diagnose it, by default.
> CC: But how do you know you call the function?
> VV: I don't. That runs into the Halting Problem. This would therefore
> cause unnecessary churn in valid code. Consider
> the idea withdrawn. Let's kill it if it comes up in the form of a proposal.
> CC: Agreed.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAFk2RUZ3_BKrqR2tuxWWDc%2B8K%2By3F0La%
> 3Dv60gN-hD77jamn4wQ%40mail.gmail.com.
>
--
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/CALvx3haodAcjtQdQc4tYjNapOi71YpUGR6DJ3LD1goLdBRAkLw%40mail.gmail.com.
--f403045c4866f526410560c7abe5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">This exercise i=
s pointless. Here's an excerpt from a discussion</span><br style=3D"fon=
t-size:12.8px"><span style=3D"font-size:12.8px">> between two committee =
members in Albuquerque:</span><div><span style=3D"font-size:12.8px"><br></s=
pan></div><div><span style=3D"font-size:12.8px">It is not pointless. It sim=
ply means that these two people need to be sidelined or convinced in the in=
terests of the common good. They are humans, not gods or emperors. They hol=
d no more power than we the community choose to give them.</span></div><div=
><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font=
-size:12.8px">That process begins with an irrefutable argument. Thus far, a=
ttempts to refute my argument have come to nothing.</span></div><div><span =
style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:1=
2.8px">I am still waiting for code that compiles better when UB is involved=
guys. I can wait all day if you want...</span></div><div><span style=3D"fo=
nt-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">Brin=
g it, please.</span></div><div><span style=3D"font-size:12.8px"><br></span>=
</div><div><span style=3D"font-size:12.8px"><br></span></div></div><div cla=
ss=3D"gmail_extra"><br><div class=3D"gmail_quote">On 20 December 2017 at 16=
:55, Ville Voutilainen <span dir=3D"ltr"><<a href=3D"mailto:ville.voutil=
ainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.com</a>></spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 20 December=
2017 at 16:58, Nicol Bolas <<a href=3D"mailto:jmckesson@gmail.com">jmck=
esson@gmail.com</a>> wrote:<br>
> On Wednesday, December 20, 2017 at 7:57:53 AM UTC-5, Jake Arkinstall w=
rote:<br>
>><br>
>> I think a good idea would be for people to post loops they are con=
cerned<br>
>> about and see what this change would do, performance-wise.<br>
><br>
><br>
> I don't agree. That gives too much weight to the "let's m=
ake this change"<br>
> argument. See, the burden of proof is on those proposing the change to=
show<br>
> that it won't affect performance or whatever.<br>
<br>
</span>This exercise is pointless. Here's an excerpt from a discussion<=
br>
between two committee members in Albuquerque:<br>
<br>
VV: We could go towards a direction of making the lack of return<br>
ill-formed. Compilers already diagnose it, by default.<br>
CC: But how do you know you call the function?<br>
VV: I don't. That runs into the Halting Problem. This would therefore<b=
r>
cause unnecessary churn in valid code. Consider<br>
the idea withdrawn. Let's kill it if it comes up in the form of a propo=
sal.<br>
CC: Agreed.<br>
<span class=3D""><br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZ3_BKrqR2tuxWWDc%2B8K%2=
By3F0La%3Dv60gN-hD77jamn4wQ%40mail.gmail.com" rel=3D"noreferrer" target=3D"=
_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>propos=
als/CAFk2RUZ3_<wbr>BKrqR2tuxWWDc%2B8K%2By3F0La%<wbr>3Dv60gN-hD77jamn4wQ%40m=
ail.<wbr>gmail.com</a>.<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/CALvx3haodAcjtQdQc4tYjNapOi71YpUGR6DJ=
3LD1goLdBRAkLw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3haodAcjtQdQ=
c4tYjNapOi71YpUGR6DJ3LD1goLdBRAkLw%40mail.gmail.com</a>.<br />
--f403045c4866f526410560c7abe5--
.
Author: j c <james.a.cooper@gmail.com>
Date: Wed, 20 Dec 2017 16:00:36 +0000
Raw View
--94eb2c082698308a870560c7af8d
Content-Type: text/plain; charset="UTF-8"
Why would not knowing if you call the function or not matter? What if the
function is part of a shared library?
On Wed, Dec 20, 2017 at 3:55 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 20 December 2017 at 16:58, Nicol Bolas <jmckesson@gmail.com> wrote:
> > On Wednesday, December 20, 2017 at 7:57:53 AM UTC-5, Jake Arkinstall
> wrote:
> >>
> >> I think a good idea would be for people to post loops they are concerned
> >> about and see what this change would do, performance-wise.
> >
> >
> > I don't agree. That gives too much weight to the "let's make this change"
> > argument. See, the burden of proof is on those proposing the change to
> show
> > that it won't affect performance or whatever.
>
> This exercise is pointless. Here's an excerpt from a discussion
> between two committee members in Albuquerque:
>
> VV: We could go towards a direction of making the lack of return
> ill-formed. Compilers already diagnose it, by default.
> CC: But how do you know you call the function?
> VV: I don't. That runs into the Halting Problem. This would therefore
> cause unnecessary churn in valid code. Consider
> the idea withdrawn. Let's kill it if it comes up in the form of a proposal.
> CC: Agreed.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAFk2RUZ3_BKrqR2tuxWWDc%2B8K%2By3F0La%
> 3Dv60gN-hD77jamn4wQ%40mail.gmail.com.
>
--
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/CAFQaeCDYx%3DTQp-vtF4%3Drh7KSf3wf9a94K%3DiR1RNy8uK-imn7RQ%40mail.gmail.com.
--94eb2c082698308a870560c7af8d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Why would not knowing if you call the function or not matt=
er? What if the function is part of a shared library?<br></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Dec 20, 2017 at 3:5=
5 PM, Ville Voutilainen <span dir=3D"ltr"><<a href=3D"mailto:ville.vouti=
lainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.com</a>></sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 20 Decembe=
r 2017 at 16:58, Nicol Bolas <<a href=3D"mailto:jmckesson@gmail.com">jmc=
kesson@gmail.com</a>> wrote:<br>
> On Wednesday, December 20, 2017 at 7:57:53 AM UTC-5, Jake Arkinstall w=
rote:<br>
>><br>
>> I think a good idea would be for people to post loops they are con=
cerned<br>
>> about and see what this change would do, performance-wise.<br>
><br>
><br>
> I don't agree. That gives too much weight to the "let's m=
ake this change"<br>
> argument. See, the burden of proof is on those proposing the change to=
show<br>
> that it won't affect performance or whatever.<br>
<br>
</span>This exercise is pointless. Here's an excerpt from a discussion<=
br>
between two committee members in Albuquerque:<br>
<br>
VV: We could go towards a direction of making the lack of return<br>
ill-formed. Compilers already diagnose it, by default.<br>
CC: But how do you know you call the function?<br>
VV: I don't. That runs into the Halting Problem. This would therefore<b=
r>
cause unnecessary churn in valid code. Consider<br>
the idea withdrawn. Let's kill it if it comes up in the form of a propo=
sal.<br>
CC: Agreed.<br>
<span class=3D""><br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZ3_BKrqR2tuxWWDc%2B8K%2=
By3F0La%3Dv60gN-hD77jamn4wQ%40mail.gmail.com" rel=3D"noreferrer" target=3D"=
_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>propos=
als/CAFk2RUZ3_<wbr>BKrqR2tuxWWDc%2B8K%2By3F0La%<wbr>3Dv60gN-hD77jamn4wQ%40m=
ail.<wbr>gmail.com</a>.<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/CAFQaeCDYx%3DTQp-vtF4%3Drh7KSf3wf9a94=
K%3DiR1RNy8uK-imn7RQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFQaeCDYx%=
3DTQp-vtF4%3Drh7KSf3wf9a94K%3DiR1RNy8uK-imn7RQ%40mail.gmail.com</a>.<br />
--94eb2c082698308a870560c7af8d--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 20 Dec 2017 18:06:27 +0200
Raw View
On 20 December 2017 at 18:00, j c <james.a.cooper@gmail.com> wrote:
> Why would not knowing if you call the function or not matter? What if the
> function is part of a shared library?
The problem is diagnosing return-less functions that are never used.
That's a false positive. If there
are false positives, the diagnostic should be a warning that you can
turn on or off, not a language rule.
--
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/CAFk2RUYYBVycPPwBqTkkDq8c_7KwbT5gOkR9LqzC%3Dr0Lwmnw3Q%40mail.gmail.com.
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 20 Dec 2017 16:06:35 +0000
Raw View
--001a1147c1389afff10560c7c41f
Content-Type: text/plain; charset="UTF-8"
On Wed, Dec 20, 2017 at 3:32 PM, Richard Hodges <hodges.r@gmail.com> wrote:
> > So you've in favor of writing ugly code just to avoid the performance
> penalty for your idea?
>
> Any retort that begins with the word, "so" is bound to be needlessly
> confrontational. Are you really here in the interests of the language?
> Please think carefully before answering.
>
> Please kindly see the second implementation.
>
> Also please ponder carefully the fact that the versions of this function
> with no UB produce better code than when the compiler is faced with UB.
>
I have been unable to reproduce this. Could you please post the versions
and flags of the compilers that you saw exhibit this issue? godbolt.org
links would be great if possible.
If you can find me a function that produces better code when UB is invoked
> around the return value, I'm all eyes and ears. Until then, the performance
> argument fails at the first test.
>
This is a pointless task, because you are reserving yourself the right to
contort the function to reproduce the actual behavior selected by the
compiler; you can do this by decompiling the generated code to
non-idiomatic C++. The question is which version of the function is more
readable and maintainable.
I have shown you facts.
>
> Refute with facts, or please kindly stop and think.
>
>
>
>
>
> On 20 December 2017 at 16:12, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>> On Wednesday, December 20, 2017 at 7:31:37 AM UTC-5, Richard Hodges wrote:
>>>
>>> > After: imperative, mutating, asymmetric, braided control flow.
>>>
>>> You're nitpicking. The author of the UB foo argued that UB was necessary
>>> for performance. It's not.
>>>
>>
>> So you've in favor of writing ugly code just to avoid the performance
>> penalty for your idea? I have a hard time finding that to be convincing.
>>
>> People don't add variables unless they need them, and this code doesn't
>> *need* them. Everything here is static and based on literals, so there's
>> no reason to have a variable. Not unless you're pedantic about some UB that
>> will never happen.
>>
>> That code should fail a code review for being needlessly complicated.
>>
>> It hinders performance. You know full well that you can express the
>>> intent of the contact to a human reader at zero cost with an assert and/or
>>> contract documentation,
>>>
>>
>> So long as the number of enumerators doesn't exceed the compiler limits
>> on the number of function or template arguments. `switch` statements either
>> have no such limits or have a lot higher limits.
>>
>> Not to mention this requires manually entering the enumerators an
>> additional time. DRY is a thing for a reason.
>>
>> It's better to just let compilers *do their jobs*. They've been looking
>> out for missing enumerators on `switch` conditions for over a decade; why
>> should we start hard-coding that into our programs?
>>
>> --
>> 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/is
>> ocpp.org/d/msgid/std-proposals/07ff3dff-9b90-425e-98ff-
>> ec435ba12ca2%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/07ff3dff-9b90-425e-98ff-ec435ba12ca2%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CALvx3hYmZ43uKf_HYOMnK-
> uFaeDwR8DaGoq1UjsUB3OtA9gwdQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hYmZ43uKf_HYOMnK-uFaeDwR8DaGoq1UjsUB3OtA9gwdQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAJnLdOY6NjGmhBeT2KBTxTMqGgm143i-BnvTzVGxNgmsH%2BGeLw%40mail.gmail.com.
--001a1147c1389afff10560c7c41f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Dec 20, 2017 at 3:32 PM, Richard Hodges <span dir=3D"ltr"><<a href=
=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a>>=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span cla=
ss=3D"">>=C2=A0<span style=3D"font-size:12.8px">So you've in favor o=
f writing ugly code just to avoid the performance penalty for your idea?</s=
pan><div><span style=3D"font-size:12.8px"><br></span></div></span><div><spa=
n style=3D"font-size:12.8px">Any retort that begins with the word, "so=
" is bound to be needlessly confrontational. Are you really here in th=
e interests of the language? Please think carefully before answering.</span=
></div><div><span style=3D"font-size:12.8px"><br></span></div><div><span st=
yle=3D"font-size:12.8px">Please kindly see the second implementation.</span=
></div><div><span style=3D"font-size:12.8px"><br></span></div><div><span st=
yle=3D"font-size:12.8px">Also please ponder carefully the fact that the ver=
sions of this function with no UB produce better code than when the compile=
r is faced with UB.</span></div></div></blockquote><div><br></div><div>I ha=
ve been unable to reproduce this. Could you please post the versions and fl=
ags of the compilers that you saw exhibit this issue? <a href=3D"http://god=
bolt.org">godbolt.org</a> links would be great if possible.=C2=A0</div><div=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><span style=
=3D"font-size:12.8px"></span></div><div><span style=3D"font-size:12.8px">If=
you can find me a function that produces better code when UB is invoked ar=
ound the return value, I'm all eyes and ears. Until then, the performan=
ce argument fails at the first test.=C2=A0</span></div></div></blockquote><=
div><br></div><div>This is a pointless task, because you are reserving your=
self the right to contort the function to reproduce the actual behavior sel=
ected by the compiler; you can do this by decompiling the generated code to=
non-idiomatic C++. The question is which version of the function is more r=
eadable and maintainable.</div><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div><span style=3D"font-size:12.8px"></span></div><div>=
<span style=3D"font-size:12.8px">I have shown you facts.</span></div><div><=
span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-s=
ize:12.8px">Refute with facts, or please kindly stop and think.</span></div=
><div><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D=
"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px"><=
br></span></div><div><span style=3D"font-size:12.8px"><br></span></div></di=
v><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span class=3D"=
">On 20 December 2017 at 16:12, Nicol Bolas <span dir=3D"ltr"><<a href=
=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&g=
t;</span> wrote:<br></span><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">=
<div dir=3D"ltr"><span>On Wednesday, December 20, 2017 at 7:31:37 AM UTC-5,=
Richard Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr">>=C2=A0<span style=3D"font-size:12.8px">After: imperative, mutating,=
asymmetric, braided control flow.</span><div><span style=3D"font-size:12.8=
px"><br></span></div><div><span style=3D"font-size:12.8px">You're nitpi=
cking. The author of the UB foo argued that UB was necessary for performanc=
e. It's not.</span></div></div></blockquote><div><br></div></span><div>=
So you've in favor of writing ugly code just to avoid the performance p=
enalty for your idea? I have a hard time finding that to be convincing.</di=
v><div><br></div><div>People don't add variables unless they need them,=
and this code doesn't <i>need</i> them. Everything here is static and =
based on literals, so there's no reason to have a variable. Not unless =
you're pedantic about some UB that will never happen.</div><div><br></d=
iv><div>That code should fail a code review for being needlessly complicate=
d.</div><span><div><i><br></i></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div><span style=3D"font-size:12.8px">It hinders performa=
nce. You know full well that you can express the intent of the contact to a=
human reader at zero cost with an assert and/or contract documentation,</s=
pan></div></div></blockquote><div><br></div></span><div>So long as the numb=
er of enumerators doesn't exceed the compiler limits on the number of f=
unction or template arguments. `switch` statements either have no such limi=
ts or have a lot higher limits.</div><div><br></div><div>Not to mention thi=
s requires manually entering the enumerators an additional time. DRY is a t=
hing for a reason.</div><div><i><br></i></div><div>It's better to just =
let compilers <i>do their jobs</i>. They've been looking out for missin=
g enumerators on `switch` conditions for over a decade; why should we start=
hard-coding that into our programs?</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex">
</blockquote></div></span><span>
<p></p>
-- <br><span class=3D"">
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></span>
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@isoc<wbr>pp.org</a>.<span class=3D""><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></span><spa=
n 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/07ff3dff-9b90-425e-98ff-ec435ba12ca2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/07ff=
3dff-9b90-425e-98ff-<wbr>ec435ba12ca2%40isocpp.org</a>.<br>
</span></blockquote></div><br></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/U=
u2QViiWh4k/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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/CALvx3hYmZ43uKf_HYOMnK-uFaeDwR8DaGoq1=
UjsUB3OtA9gwdQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-=
<wbr>proposals/CALvx3hYmZ43uKf_<wbr>HYOMnK-<wbr>uFaeDwR8DaGoq1UjsUB3OtA9gwd=
Q%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAJnLdOY6NjGmhBeT2KBTxTMqGgm143i-BnvT=
zVGxNgmsH%2BGeLw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOY6NjGmhB=
eT2KBTxTMqGgm143i-BnvTzVGxNgmsH%2BGeLw%40mail.gmail.com</a>.<br />
--001a1147c1389afff10560c7c41f--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Wed, 20 Dec 2017 17:06:51 +0100
Raw View
--089e08200cdc85c5950560c7c596
Content-Type: text/plain; charset="UTF-8"
I will go further and dissect this conversation in Albuquerque:
"VV: We could go towards a direction of making the lack of return ill-formed.
Compilers already diagnose it, by default."
This is a reasonable statement, but made with all the conviction of a wet
paper bag.
"CC: But how do you know you call the function?"
An idiotic response. The correctness of code does not depend on whether it
is called.
"VV: I don't. That runs into the Halting Problem. This would therefore cause
unnecessary churn in valid code. Consider the idea withdrawn. Let's kill it
if it comes up in the form of a proposal."
This is meaningless drivel. An attempt to sound educated by quoting some
buzzwords. The last sentence borders on conspiracy to deliberately do harm
and subvert the process of positive change.
"CC: Agreed."
Translation: "phew! I don't have to tax my brain to figure out how to move
this forward. Lets get some drinks in the bar!"
On 20 December 2017 at 17:00, j c <james.a.cooper@gmail.com> wrote:
> Why would not knowing if you call the function or not matter? What if the
> function is part of a shared library?
>
> On Wed, Dec 20, 2017 at 3:55 PM, Ville Voutilainen <
> ville.voutilainen@gmail.com> wrote:
>
>> On 20 December 2017 at 16:58, Nicol Bolas <jmckesson@gmail.com> wrote:
>> > On Wednesday, December 20, 2017 at 7:57:53 AM UTC-5, Jake Arkinstall
>> wrote:
>> >>
>> >> I think a good idea would be for people to post loops they are
>> concerned
>> >> about and see what this change would do, performance-wise.
>> >
>> >
>> > I don't agree. That gives too much weight to the "let's make this
>> change"
>> > argument. See, the burden of proof is on those proposing the change to
>> show
>> > that it won't affect performance or whatever.
>>
>> This exercise is pointless. Here's an excerpt from a discussion
>> between two committee members in Albuquerque:
>>
>> VV: We could go towards a direction of making the lack of return
>> ill-formed. Compilers already diagnose it, by default.
>> CC: But how do you know you call the function?
>> VV: I don't. That runs into the Halting Problem. This would therefore
>> cause unnecessary churn in valid code. Consider
>> the idea withdrawn. Let's kill it if it comes up in the form of a
>> proposal.
>> CC: Agreed.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/is
>> ocpp.org/d/msgid/std-proposals/CAFk2RUZ3_BKrqR2tuxWWDc%2B8K%
>> 2By3F0La%3Dv60gN-hD77jamn4wQ%40mail.gmail.com.
>>
>
> --
> 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/CAFQaeCDYx%3DTQp-vtF4%3Drh7KSf3wf9a94K%
> 3DiR1RNy8uK-imn7RQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFQaeCDYx%3DTQp-vtF4%3Drh7KSf3wf9a94K%3DiR1RNy8uK-imn7RQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CALvx3hb9YYgxHD_2-gY%2BJCQUTPaRGwUTt8jAvw8VyqPAKtBB%3Dw%40mail.gmail.com.
--089e08200cdc85c5950560c7c596
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I will go further and dissect this conversation in Albuque=
rque:<div><br></div><div><span style=3D"font-size:12.8px">"VV: We coul=
d go towards a direction of making the lack of return=C2=A0</span><span sty=
le=3D"font-size:12.8px">ill-formed. Compilers already diagnose it, by defau=
lt."</span></div><div><br></div><div>This is a reasonable statement, b=
ut made with all the conviction of a wet paper bag.=C2=A0</div><div><br sty=
le=3D"font-size:12.8px"><span style=3D"font-size:12.8px">"CC: But how =
do you know you call the function?"</span></div><div><br></div><div>An=
idiotic response. The correctness of code does not depend on whether it is=
called.</div><div><br></div><div><span style=3D"font-size:12.8px">"VV=
: I don't. That runs into the Halting Problem. This would therefore=C2=
=A0</span><span style=3D"font-size:12.8px">cause unnecessary churn in valid=
code. Consider=C2=A0</span><span style=3D"font-size:12.8px">the idea withd=
rawn. Let's kill it if it comes up in the form of a proposal."</sp=
an></div><div><br></div><div>This is meaningless drivel. An attempt to soun=
d educated by quoting some buzzwords. The last sentence borders on conspira=
cy to deliberately do harm and subvert the process of positive change.</div=
><div><br></div><div><span style=3D"font-size:12.8px">"CC: Agreed.&quo=
t;</span><br></div><div><span style=3D"font-size:12.8px"><br></span></div><=
div><span style=3D"font-size:12.8px">Translation: "phew! I don't h=
ave to tax my brain to figure out how to move this forward. Lets get some d=
rinks in the bar!"</span></div><div><span style=3D"font-size:12.8px"><=
br></span></div><div><span style=3D"font-size:12.8px"><br></span></div><div=
><span style=3D"font-size:12.8px"><br></span></div></div><div class=3D"gmai=
l_extra"><br><div class=3D"gmail_quote">On 20 December 2017 at 17:00, j c <=
span dir=3D"ltr"><<a href=3D"mailto:james.a.cooper@gmail.com" target=3D"=
_blank">james.a.cooper@gmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">Why would not knowing if you call the functi=
on or not matter? What if the function is part of a shared library?<br></di=
v><div><div class=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail=
_quote">On Wed, Dec 20, 2017 at 3:55 PM, Ville Voutilainen <span dir=3D"ltr=
"><<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">vill=
e.voutilainen@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><span>On 20 December 2017 at 16:58, Nicol Bolas <<a href=3D"mailto:=
jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>> wrote:<b=
r>
> On Wednesday, December 20, 2017 at 7:57:53 AM UTC-5, Jake Arkinstall w=
rote:<br>
>><br>
>> I think a good idea would be for people to post loops they are con=
cerned<br>
>> about and see what this change would do, performance-wise.<br>
><br>
><br>
> I don't agree. That gives too much weight to the "let's m=
ake this change"<br>
> argument. See, the burden of proof is on those proposing the change to=
show<br>
> that it won't affect performance or whatever.<br>
<br>
</span>This exercise is pointless. Here's an excerpt from a discussion<=
br>
between two committee members in Albuquerque:<br>
<br>
VV: We could go towards a direction of making the lack of return<br>
ill-formed. Compilers already diagnose it, by default.<br>
CC: But how do you know you call the function?<br>
VV: I don't. That runs into the Halting Problem. This would therefore<b=
r>
cause unnecessary churn in valid code. Consider<br>
the idea withdrawn. Let's kill it if it comes up in the form of a propo=
sal.<br>
CC: Agreed.<br>
<span><br>
--<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.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.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZ3_BKrqR2tuxWWDc%2B8K%2=
By3F0La%3Dv60gN-hD77jamn4wQ%40mail.gmail.com" rel=3D"noreferrer" target=3D"=
_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<w=
br>/CAFk2RUZ3_BKrqR2tuxWWDc%2B8K%<wbr>2By3F0La%3Dv60gN-hD77jamn4wQ%<wbr>40m=
ail.gmail.com</a>.<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" 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></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFQaeCDYx%3DTQp-vtF4%3Drh7KSf3wf9a94=
K%3DiR1RNy8uK-imn7RQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgi=
d/std-<wbr>proposals/CAFQaeCDYx%3DTQp-<wbr>vtF4%3Drh7KSf3wf9a94K%<wbr>3DiR1=
RNy8uK-imn7RQ%40mail.<wbr>gmail.com</a>.<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/CALvx3hb9YYgxHD_2-gY%2BJCQUTPaRGwUTt8=
jAvw8VyqPAKtBB%3Dw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hb9YYgx=
HD_2-gY%2BJCQUTPaRGwUTt8jAvw8VyqPAKtBB%3Dw%40mail.gmail.com</a>.<br />
--089e08200cdc85c5950560c7c596--
.
Author: Ren Industries <renindustries@gmail.com>
Date: Wed, 20 Dec 2017 11:07:13 -0500
Raw View
--f403043974e8dcbb7b0560c7c69d
Content-Type: text/plain; charset="UTF-8"
> > This exercise is pointless. Here's an excerpt from a discussion
> > between two committee members in Albuquerque:
>
> It is not pointless. It simply means that these two people need to be
> sidelined or convinced in the interests of the common good. They are
> humans, not gods or emperors. They hold no more power than we the community
> choose to give them.
>
Wrong. C++ isn't defined by the "community", it's defined by a systematic
standardization process, which involves...committee members.
>
> That process begins with an irrefutable argument. Thus far, attempts to
> refute my argument have come to nothing.
>
No it doesn't. The process begins with *you*, the person who wants
this, *providing
a compelling argument.*
We are not here to convince you; you are here to convince us.
>
> I am still waiting for code that compiles better when UB is involved guys.
> I can wait all day if you want...
>
UB is the instantiation of the lack of a return value; you wish to get rid
of that POSSIBLE UB, where as I maintain that ANY code changes required to
support this are ungainly and a bad idea. *You* need to prove that the
required code change, which would break not insubstantial amounts of code,
is worth that effort and will *not* impact code.
You have not done so. You've provided a statement that a particular
compiler on a particular system MAY generate better code in a specific
instance. This does not an exhaustive case make, nor is it compelling,
especially given the most important impact of a change like this will be
with regards to inlinability.
And I've been unable to replicate your results on Clang or MSVC.
>
> Bring it, please.
>
You prove that this change is worth while and won't impact currently
working code, please.
--
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/CAMD6iD-U6hQGp-sAPNqL%3DQPjVEx-sOWfxhMhrAaOE63oA_tSWQ%40mail.gmail.com.
--f403043974e8dcbb7b0560c7c69d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">>=C2=A0=
<span style=3D"font-size:12.8px">This exercise is pointless. Here's an =
excerpt from a discussion</span><br style=3D"font-size:12.8px"><span style=
=3D"font-size:12.8px">> between two committee members in Albuquerque:</s=
pan><div><span style=3D"font-size:12.8px"><br></span></div></span><div><spa=
n style=3D"font-size:12.8px">It is not pointless. It simply means that thes=
e two people need to be sidelined or convinced in the interests of the comm=
on good. They are humans, not gods or emperors. They hold no more power tha=
n we the community choose to give them.</span></div></div></blockquote><div=
><br></div><div>Wrong. C++ isn't defined by the "community", =
it's defined by a systematic standardization process, which involves...=
committee members.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div><span style=3D"font-size:12.8px"><br></span></div><div><=
span style=3D"font-size:12.8px">That process begins with an irrefutable arg=
ument. Thus far, attempts to refute my argument have come to nothing.</span=
></div></div></blockquote><div><br></div><div>No it doesn't. The proces=
s begins with <i>you</i>, the person who wants this, <i>providing a compell=
ing argument.</i></div><div>We are not here to convince you; you are here t=
o convince us.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div><span style=3D"font-size:12.8px"><br></span></div><div><span=
style=3D"font-size:12.8px">I am still waiting for code that compiles bette=
r when UB is involved guys. I can wait all day if you want...</span></div><=
/div></blockquote><div><br></div><div>UB is the instantiation of the lack o=
f a return value; you wish to get rid of that POSSIBLE UB, where as I maint=
ain that ANY code changes required to support this are ungainly and a bad i=
dea. <i>You</i>=C2=A0need to prove that the required code change, which wou=
ld break not insubstantial amounts of code, is worth that effort and will <=
i>not</i>=C2=A0impact code.</div><div><br></div><div>You have not done so. =
You've provided a statement that a particular compiler on a particular =
system MAY generate better code in a specific instance. This does not an ex=
haustive case make, nor is it compelling, especially given the most importa=
nt impact of a change like this will be with regards to inlinability.=C2=A0=
</div><div><br></div><div>And I've been unable to replicate your result=
s on Clang or MSVC.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div><span style=3D"font-size:12.8px"><br></span></div><div>=
<span style=3D"font-size:12.8px">Bring it, please.</span></div></div></bloc=
kquote><div><br></div><div>You prove that this change is worth while and wo=
n't impact currently working code, please.=C2=A0</div><div>=C2=A0</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/CAMD6iD-U6hQGp-sAPNqL%3DQPjVEx-sOWfxh=
MhrAaOE63oA_tSWQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD-U6hQGp-=
sAPNqL%3DQPjVEx-sOWfxhMhrAaOE63oA_tSWQ%40mail.gmail.com</a>.<br />
--f403043974e8dcbb7b0560c7c69d--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 20 Dec 2017 18:08:05 +0200
Raw View
On 20 December 2017 at 17:59, Richard Hodges <hodges.r@gmail.com> wrote:
>> This exercise is pointless. Here's an excerpt from a discussion
>> between two committee members in Albuquerque:
>
> It is not pointless. It simply means that these two people need to be
> sidelined or convinced in the interests of the common good. They are humans,
> not gods or emperors. They hold no more power than we the community choose
> to give them.
How much power those two people hold is not the community's decision.
> That process begins with an irrefutable argument. Thus far, attempts to
> refute my argument have come to nothing.
> I am still waiting for code that compiles better when UB is involved guys. I
> can wait all day if you want...
> Bring it, please.
Whether there's some code generation improvement is secondary to the
problem of diagnosing
valid code with false positives.
--
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/CAFk2RUYMsLgNGue7cDR-vY_tv1hcCBybcN%3DLBpPKKZGNy91EXQ%40mail.gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 20 Dec 2017 08:08:49 -0800 (PST)
Raw View
------=_Part_2905_1076205327.1513786129381
Content-Type: multipart/alternative;
boundary="----=_Part_2906_1540010976.1513786129381"
------=_Part_2906_1540010976.1513786129381
Content-Type: text/plain; charset="UTF-8"
On Wednesday, December 20, 2017 at 10:59:45 AM UTC-5, Richard Hodges wrote:
>
> > This exercise is pointless. Here's an excerpt from a discussion
> > between two committee members in Albuquerque:
>
> It is not pointless. It simply means that these two people need to be
> sidelined or convinced in the interests of the common good.
>
Please stop declaring that your ideas are absolutely part of the "common
good". Different people have different ideas about what that means, and
your ideas are not inherently more "good" than others.
> They are humans, not gods or emperors. They hold no more power than we the
> community choose to give them.
>
First, where is this "the community"? I don't see mobs of C++ programmers
rallying to say, "yes, absolutely, the most important problem of my day is
around missing return statements! We need to fix this broken C++ thing!"
While some C++ programmers probably agree with you, this is very much* not*
a priority thing for them. There is far more interest in significant
features like modules, concepts, ranges, operator<=>, etc than in
relatively trivial matters like this.
So you no more speak for "the community" than any other one person.
Second, unless you actually go to committee meetings and put forward your
argument there, then committee members* do* hold more power than you do.
The only "sidelining" you could possibly do to them from outside of the
committee involves forking the language.
Good luck with that.
That process begins with an irrefutable argument. Thus far, attempts to
> refute my argument have come to nothing.
>
Only because you consider breaking other people's code to be an acceptable
starting point. Fortunately, the committee does not agree.
I am still waiting for code that compiles better when UB is involved guys.
>
I don't believe that's this is necessary when deciding whether to move
forward on this idea.
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/15a59ccf-c076-408f-8b3c-5b5938a3bb54%40isocpp.org.
------=_Part_2906_1540010976.1513786129381
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, December 20, 2017 at 10:59:45 AM UTC=
-5, Richard Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">This exercise is poi=
ntless. Here's an excerpt from a discussion</span><br style=3D"font-siz=
e:12.8px"><span style=3D"font-size:12.8px">> between two committee membe=
rs in Albuquerque:</span><div><span style=3D"font-size:12.8px"><br></span><=
/div><div><span style=3D"font-size:12.8px">It is not pointless. It simply m=
eans that these two people need to be sidelined or convinced in the interes=
ts of the common good.</span></div></div></blockquote><div><br></div><div>P=
lease stop declaring that your ideas are absolutely part of the "commo=
n good". Different people have different ideas about what that means, =
and your ideas are not inherently more "good" than others.</div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div><span style=3D"font-size:12.8px">They are humans, not gods or emper=
ors. They hold no more power than we the community choose to give them.</sp=
an></div></div></blockquote><div><br></div><div>First, where is this "=
the community"? I don't see mobs of C++ programmers rallying to sa=
y, "yes, absolutely, the most important problem of my day is around mi=
ssing return statements! We need to fix this broken C++ thing!"</div><=
div><br></div><div>While some C++ programmers probably agree with you, this=
is very much<i> not</i> a priority thing for them. There is far more inter=
est in significant features like modules, concepts, ranges, operator<=3D=
>, etc than in relatively trivial matters like this.</div><div><br></div=
><div>So you no more speak for "the community" than any other one=
person.</div><div><br></div><div>Second, unless you actually go to committ=
ee meetings and put forward your argument there, then committee members<i> =
do</i> hold more power than you do. The only "sidelining" you cou=
ld possibly do to them from outside of the committee involves forking the l=
anguage.</div><div><br></div><div>Good luck with that.</div><div><i><br></i=
></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><=
span style=3D"font-size:12.8px">That process begins with an irrefutable arg=
ument. Thus far, attempts to refute my argument have come to nothing.</span=
></div></div></blockquote><div><br></div><div>Only because you consider bre=
aking other people's code to be an acceptable starting point. Fortunate=
ly, the committee does not agree.</div><div><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr"><div><span style=3D"font-size:12.8=
px">I am still waiting for code that compiles better when UB is involved gu=
ys.</span></div></div></blockquote><div><br></div><div>I don't believe =
that's this is necessary when deciding whether to move forward on this =
idea.<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
</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/15a59ccf-c076-408f-8b3c-5b5938a3bb54%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/15a59ccf-c076-408f-8b3c-5b5938a3bb54=
%40isocpp.org</a>.<br />
------=_Part_2906_1540010976.1513786129381--
------=_Part_2905_1076205327.1513786129381--
.
Author: Dilip Ranganathan <misc.usage@gmail.com>
Date: Wed, 20 Dec 2017 11:11:29 -0500
Raw View
--94eb2c1921e6214d6a0560c7d6c2
Content-Type: text/plain; charset="UTF-8"
> And I've been unable to replicate your results on Clang or MSVC.
>
https://godbolt.org/g/fjpVuU
MSVC does exactly what Richard posted above. You need to use either /Oxs or
/Oxt.
Former optimizes on size, the latter favors space.
--
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/CALEPxft_gscKVAwkfWTj9JY%2BWGj7Cgth3qTkALa%3DLGrkR5aing%40mail.gmail.com.
--94eb2c1921e6214d6a0560c7d6c2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><div>And I've been unable=
to replicate your results on Clang or MSVC.</div></div></div></div></block=
quote><div><br></div><div><a href=3D"https://godbolt.org/g/fjpVuU">https://=
godbolt.org/g/fjpVuU</a></div><div><br></div><div>MSVC does exactly what Ri=
chard posted above. You need to use either /Oxs or /Oxt.<br>Former optimize=
s on size, the latter favors space.</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/CALEPxft_gscKVAwkfWTj9JY%2BWGj7Cgth3q=
TkALa%3DLGrkR5aing%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALEPxft_gscK=
VAwkfWTj9JY%2BWGj7Cgth3qTkALa%3DLGrkR5aing%40mail.gmail.com</a>.<br />
--94eb2c1921e6214d6a0560c7d6c2--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Wed, 20 Dec 2017 17:12:55 +0100
Raw View
--001a114aad7840e42e0560c7db25
Content-Type: text/plain; charset="UTF-8"
In response to Edward's request for a godbolt link:
https://godbolt.org/g/UFL6pN
On 20 December 2017 at 17:06, 'Edward Catmur' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:
> On Wed, Dec 20, 2017 at 3:32 PM, Richard Hodges <hodges.r@gmail.com>
> wrote:
>
>> > So you've in favor of writing ugly code just to avoid the performance
>> penalty for your idea?
>>
>> Any retort that begins with the word, "so" is bound to be needlessly
>> confrontational. Are you really here in the interests of the language?
>> Please think carefully before answering.
>>
>> Please kindly see the second implementation.
>>
>> Also please ponder carefully the fact that the versions of this function
>> with no UB produce better code than when the compiler is faced with UB.
>>
>
> I have been unable to reproduce this. Could you please post the versions
> and flags of the compilers that you saw exhibit this issue? godbolt.org
> links would be great if possible.
>
> If you can find me a function that produces better code when UB is invoked
>> around the return value, I'm all eyes and ears. Until then, the performance
>> argument fails at the first test.
>>
>
> This is a pointless task, because you are reserving yourself the right to
> contort the function to reproduce the actual behavior selected by the
> compiler; you can do this by decompiling the generated code to
> non-idiomatic C++. The question is which version of the function is more
> readable and maintainable.
>
> I have shown you facts.
>>
>> Refute with facts, or please kindly stop and think.
>>
>>
>>
>>
>>
>> On 20 December 2017 at 16:12, Nicol Bolas <jmckesson@gmail.com> wrote:
>>
>>> On Wednesday, December 20, 2017 at 7:31:37 AM UTC-5, Richard Hodges
>>> wrote:
>>>>
>>>> > After: imperative, mutating, asymmetric, braided control flow.
>>>>
>>>> You're nitpicking. The author of the UB foo argued that UB was
>>>> necessary for performance. It's not.
>>>>
>>>
>>> So you've in favor of writing ugly code just to avoid the performance
>>> penalty for your idea? I have a hard time finding that to be convincing.
>>>
>>> People don't add variables unless they need them, and this code doesn't
>>> *need* them. Everything here is static and based on literals, so
>>> there's no reason to have a variable. Not unless you're pedantic about some
>>> UB that will never happen.
>>>
>>> That code should fail a code review for being needlessly complicated.
>>>
>>> It hinders performance. You know full well that you can express the
>>>> intent of the contact to a human reader at zero cost with an assert and/or
>>>> contract documentation,
>>>>
>>>
>>> So long as the number of enumerators doesn't exceed the compiler limits
>>> on the number of function or template arguments. `switch` statements either
>>> have no such limits or have a lot higher limits.
>>>
>>> Not to mention this requires manually entering the enumerators an
>>> additional time. DRY is a thing for a reason.
>>>
>>> It's better to just let compilers *do their jobs*. They've been looking
>>> out for missing enumerators on `switch` conditions for over a decade; why
>>> should we start hard-coding that into our programs?
>>>
>>> --
>>> 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/is
>>> ocpp.org/d/msgid/std-proposals/07ff3dff-9b90-425e-98ff-ec435
>>> ba12ca2%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/07ff3dff-9b90-425e-98ff-ec435ba12ca2%40isocpp.org?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit https://groups.google.com/a/is
>> ocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/is
>> ocpp.org/d/msgid/std-proposals/CALvx3hYmZ43uKf_HYOMnK-uFaeDw
>> R8DaGoq1UjsUB3OtA9gwdQ%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hYmZ43uKf_HYOMnK-uFaeDwR8DaGoq1UjsUB3OtA9gwdQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
> --
> 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/CAJnLdOY6NjGmhBeT2KBTxTMqGgm14
> 3i-BnvTzVGxNgmsH%2BGeLw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOY6NjGmhBeT2KBTxTMqGgm143i-BnvTzVGxNgmsH%2BGeLw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CALvx3hb1KcvHZQQvrqOJ%3DGj-f3btYNXRBcQ%3DX%3D0Ooqk%2BnyWHNg%40mail.gmail.com.
--001a114aad7840e42e0560c7db25
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>In response to Edward's request for a godbolt lin=
k:</div><div><br></div><div><br></div><a href=3D"https://godbolt.org/g/UFL6=
pN">https://godbolt.org/g/UFL6pN</a><br><div><br></div></div><div class=3D"=
gmail_extra"><br><div class=3D"gmail_quote">On 20 December 2017 at 17:06, &=
#39;Edward Catmur' via ISO C++ Standard - Future Proposals <span dir=3D=
"ltr"><<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std=
-proposals@isocpp.org</a>></span> wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><=
span class=3D"">On Wed, Dec 20, 2017 at 3:32 PM, Richard Hodges <span dir=
=3D"ltr"><<a href=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hodges=
..r@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><span>>=C2=A0<span style=3D"font-size:12.8px">So you've i=
n favor of writing ugly code just to avoid the performance penalty for your=
idea?</span><div><span style=3D"font-size:12.8px"><br></span></div></span>=
<div><span style=3D"font-size:12.8px">Any retort that begins with the word,=
"so" is bound to be needlessly confrontational. Are you really h=
ere in the interests of the language? Please think carefully before answeri=
ng.</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div=
><span style=3D"font-size:12.8px">Please kindly see the second implementati=
on.</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div=
><span style=3D"font-size:12.8px">Also please ponder carefully the fact tha=
t the versions of this function with no UB produce better code than when th=
e compiler is faced with UB.</span></div></div></blockquote><div><br></div>=
</span><div>I have been unable to reproduce this. Could you please post the=
versions and flags of the compilers that you saw exhibit this issue? <a hr=
ef=3D"http://godbolt.org" target=3D"_blank">godbolt.org</a> links would be =
great if possible.=C2=A0</div><span class=3D""><div><br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div><span style=3D"font-size:12.8px"></=
span></div><div><span style=3D"font-size:12.8px">If you can find me a funct=
ion that produces better code when UB is invoked around the return value, I=
'm all eyes and ears. Until then, the performance argument fails at the=
first test.=C2=A0</span></div></div></blockquote><div><br></div></span><di=
v>This is a pointless task, because you are reserving yourself the right to=
contort the function to reproduce the actual behavior selected by the comp=
iler; you can do this by decompiling the generated code to non-idiomatic C+=
+. The question is which version of the function is more readable and maint=
ainable.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"=
"><div dir=3D"ltr"><div><span style=3D"font-size:12.8px"></span></div><div>=
<span style=3D"font-size:12.8px">I have shown you facts.</span></div><div><=
span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-s=
ize:12.8px">Refute with facts, or please kindly stop and think.</span></div=
><div><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D=
"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px"><=
br></span></div><div><span style=3D"font-size:12.8px"><br></span></div></di=
v><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span>On 20 Dec=
ember 2017 at 16:12, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:jm=
ckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></span> wro=
te:<br></span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><span><div dir=3D"ltr"><span>O=
n Wednesday, December 20, 2017 at 7:31:37 AM UTC-5, Richard Hodges wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">>=C2=A0<span styl=
e=3D"font-size:12.8px">After: imperative, mutating, asymmetric, braided con=
trol flow.</span><div><span style=3D"font-size:12.8px"><br></span></div><di=
v><span style=3D"font-size:12.8px">You're nitpicking. The author of the=
UB foo argued that UB was necessary for performance. It's not.</span><=
/div></div></blockquote><div><br></div></span><div>So you've in favor o=
f writing ugly code just to avoid the performance penalty for your idea? I =
have a hard time finding that to be convincing.</div><div><br></div><div>Pe=
ople don't add variables unless they need them, and this code doesn'=
;t <i>need</i> them. Everything here is static and based on literals, so th=
ere's no reason to have a variable. Not unless you're pedantic abou=
t some UB that will never happen.</div><div><br></div><div>That code should=
fail a code review for being needlessly complicated.</div><span><div><i><b=
r></i></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><=
span style=3D"font-size:12.8px">It hinders performance. You know full well =
that you can express the intent of the contact to a human reader at zero co=
st with an assert and/or contract documentation,</span></div></div></blockq=
uote><div><br></div></span><div>So long as the number of enumerators doesn&=
#39;t exceed the compiler limits on the number of function or template argu=
ments. `switch` statements either have no such limits or have a lot higher =
limits.</div><div><br></div><div>Not to mention this requires manually ente=
ring the enumerators an additional time. DRY is a thing for a reason.</div>=
<div><i><br></i></div><div>It's better to just let compilers <i>do thei=
r jobs</i>. They've been looking out for missing enumerators on `switch=
` conditions for over a decade; why should we start hard-coding that into o=
ur programs?</div><div><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></span><span>
<p></p>
-- <br><span>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></span>
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@isoc<wbr>pp.org</a>.<span><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></span><spa=
n>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/07ff3dff-9b90-425e-98ff-ec435ba12ca2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/07ff=
3dff-9b90-425e-98ff-ec435<wbr>ba12ca2%40isocpp.org</a>.<br>
</span></blockquote></div><br></div></span><span>
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/is<wbr>ocpp.org/d/topic/std-proposals<wbr>/U=
u2QViiWh4k/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isoc<wbr>pp.org</a>.<span class=3D""><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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hYmZ43uKf_HYOMnK-uFaeDwR8DaGoq1=
UjsUB3OtA9gwdQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-=
proposals<wbr>/CALvx3hYmZ43uKf_HYOMnK-uFaeDw<wbr>R8DaGoq1UjsUB3OtA9gwdQ%40m=
ail.<wbr>gmail.com</a>.<br>
</blockquote></div><br></div></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/CAJnLdOY6NjGmhBeT2KBTxTMqGgm143i-BnvT=
zVGxNgmsH%2BGeLw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/<wbr>CAJnLdOY6NjGmhBeT2KBTxTMqGgm14<wbr>3i-BnvTzVGxNgmsH%2=
BGeLw%<wbr>40mail.gmail.com</a>.<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/CALvx3hb1KcvHZQQvrqOJ%3DGj-f3btYNXRBc=
Q%3DX%3D0Ooqk%2BnyWHNg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hb1=
KcvHZQQvrqOJ%3DGj-f3btYNXRBcQ%3DX%3D0Ooqk%2BnyWHNg%40mail.gmail.com</a>.<br=
/>
--001a114aad7840e42e0560c7db25--
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Wed, 20 Dec 2017 16:17:01 +0000
Raw View
--001a11492a42e857c00560c7e932
Content-Type: text/plain; charset="UTF-8"
On 20 Dec 2017 15:55, "Ville Voutilainen" <ville.voutilainen@gmail.com>
wrote:
VV: We could go towards a direction of making the lack of return
ill-formed. Compilers already diagnose it, by default.
CC: But how do you know you call the function?
VV: I don't. That runs into the Halting Problem. This would therefore
cause unnecessary churn in valid code. Consider
the idea withdrawn. Let's kill it if it comes up in the form of a proposal.
CC: Agreed.
Wow. Was there someone at the meeting holding up a sign saying "[citation
needed]" when the halting problem was brought up? Adding something at the
end of functions that have a non-returning branch (whether accessible or
not) is hardly solving the halting problem or causing churn. It never gets
run, assuming the function behaved beforehand.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMyMzkkrp9L%3DjZxv5i82%3Dj9Pxcu13r5_cnow16uvxjbRQ%40mail.gmail.com.
--001a11492a42e857c00560c7e932
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On 20 Dec 2017 15:55, "Ville Voutilainen" <<a href=
=3D"mailto:ville.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>>=
wrote:<br type=3D"attribution"><blockquote class=3D"quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"quot=
ed-text">VV: We could go towards a direction of making the lack of return</=
div>
ill-formed. Compilers already diagnose it, by default.<br>
CC: But how do you know you call the function?<br>
VV: I don't. That runs into the Halting Problem. This would therefore<b=
r>
cause unnecessary churn in valid code. Consider<br>
the idea withdrawn. Let's kill it if it comes up in the form of a propo=
sal.<br>
CC: Agreed.<br></blockquote></div></div></div><div dir=3D"auto"><br></div><=
div dir=3D"auto">Wow. Was there someone at the meeting holding up a sign sa=
ying "[citation needed]" when the halting problem was brought up?=
Adding something at the end of functions that have a non-returning branch =
(whether accessible or not) is hardly solving the halting problem or causin=
g churn. It never gets run, assuming the function behaved beforehand.</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/CAC%2B0CCMyMzkkrp9L%3DjZxv5i82%3Dj9Px=
cu13r5_cnow16uvxjbRQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMy=
Mzkkrp9L%3DjZxv5i82%3Dj9Pxcu13r5_cnow16uvxjbRQ%40mail.gmail.com</a>.<br />
--001a11492a42e857c00560c7e932--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 20 Dec 2017 18:36:06 +0200
Raw View
On 20 December 2017 at 18:17, Jake Arkinstall <jake.arkinstall@gmail.com> wrote:
>
>
> On 20 Dec 2017 15:55, "Ville Voutilainen" <ville.voutilainen@gmail.com>
> wrote:
>
> VV: We could go towards a direction of making the lack of return
> ill-formed. Compilers already diagnose it, by default.
> CC: But how do you know you call the function?
> VV: I don't. That runs into the Halting Problem. This would therefore
> cause unnecessary churn in valid code. Consider
> the idea withdrawn. Let's kill it if it comes up in the form of a proposal.
> CC: Agreed.
>
>
> Wow. Was there someone at the meeting holding up a sign saying "[citation
> needed]" when the halting problem was brought up? Adding something at the
> end of functions that have a non-returning branch (whether accessible or
> not) is hardly solving the halting problem or causing churn. It never gets
> run, assuming the function behaved beforehand.
The churn comes from functions that don't have a return or an
annotation that that is intended,
and the halting problem issue is that a compiler doesn't know which of
those functions are used
and which ones unused. Which leads to false positives. Were this a
from-scratch matter, we might
well decide to diagnose the lack of return, but since it's not, and
there's existing valid code
and breakage thereof to consider, trying to mandate a diagnostic for a
missing return is fighting
an uphill battle.
You are all more than welcome to continue to misunderstand that or
claim that such considerations
are brought up by idiots, but if you choose to do so, I honestly
wonder why this thread exists, considering
that there seems to be a strong effort by the supposed proponents of
the idea to convince everybody
else that they don't really want this idea to succeed.
--
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/CAFk2RUaxu_thbrRbqxL-nuvZkQnVvKP1rfE_XB%2B342AcLUcrag%40mail.gmail.com.
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Wed, 20 Dec 2017 18:02:27 +0100
Raw View
--001a113fbc086b7f410560c88ce8
Content-Type: text/plain; charset="UTF-8"
> The churn comes from functions that don't have a return or an annotation
that that is intended,
We have already seen that these "intended no return" functions result in
worse code. This is precisely because the compiler cannot deduce intent. In
every other conversation about UB, there would be unanimous agreement that
UB is to be avoided.
For some unfathomable reason, on this issue, some wish to defy the evidence
before them and continue to demand the right to write UB functions without
a diagnostic - to the detriment of the vast majority who simply want
functions to do defined things.
How do I know that the majority want functions to do defined things?
Because the universally accepted process for writing and testing code is to
write tests. What do tests do? They verify the claims of the function's
author. What do UB functions do? They refuse to make any claims. Is that
testable? No. Is it useful? Quad erat demonstrandum, no.
> and the halting problem issue is that a compiler doesn't know which of those
functions are used and which ones unused
Totally irrelevant. The compiler doesn't know or care about the colour of
my socks either. Code either has defined behaviour, or it's a useless
liability.
> Which leads to false positives.
All UB is a positively an error. The correct (and performant) thing to do
is fix it.
> but since it's not, and there's existing valid code and breakage thereof
to consider
Do you remember when we moved from K&R function declarations to ANSI
function declarations? I do. Everyone coped just fine. No-one demanded the
right to continue to write
func(x,y)
double x;
int y;
{
if (x > 0)
return y;
}
**this** is the origin on the UB on non-specified returns. Almost
everything else got fixed. This got forgotten.
> trying to mandate a diagnostic for a missing return is fighting an uphill
battle.
One of my engineers, an experienced guy with 20 years writing c++, spent
the first half of today diagnosing something that turned out to be a result
of exactly this. Forgetting to return the shared_ptr he had created. In a
function he had written 30 minutes prior. The crash occurred in thread 3,
nowhere near the offending code that was executed in thread 1.
Half a day. Over something the compiler could, no, *should* have told him
on the first compile.
This happens a lot, all over the world, every day. The combined loss of
productivity easily outweighs the minor inconvenience of fixing a few
lazily-written, demonstrably suboptimal, leaf functions.
You and the current committee stance on this, are wrong. It is a problem.
Not all developers are as vociferous as me, so why don't you ask the others
whether they'd prefer to have this? Ask, not tell.
On 20 December 2017 at 17:36, Ville Voutilainen <ville.voutilainen@gmail.com
> wrote:
> On 20 December 2017 at 18:17, Jake Arkinstall <jake.arkinstall@gmail.com>
> wrote:
> >
> >
> > On 20 Dec 2017 15:55, "Ville Voutilainen" <ville.voutilainen@gmail.com>
> > wrote:
> >
> > VV: We could go towards a direction of making the lack of return
> > ill-formed. Compilers already diagnose it, by default.
> > CC: But how do you know you call the function?
> > VV: I don't. That runs into the Halting Problem. This would therefore
> > cause unnecessary churn in valid code. Consider
> > the idea withdrawn. Let's kill it if it comes up in the form of a
> proposal.
> > CC: Agreed.
> >
> >
> > Wow. Was there someone at the meeting holding up a sign saying "[citation
> > needed]" when the halting problem was brought up? Adding something at the
> > end of functions that have a non-returning branch (whether accessible or
> > not) is hardly solving the halting problem or causing churn. It never
> gets
> > run, assuming the function behaved beforehand.
>
> The churn comes from functions that don't have a return or an
> annotation that that is intended,
> and the halting problem issue is that a compiler doesn't know which of
> those functions are used
> and which ones unused. Which leads to false positives. Were this a
> from-scratch matter, we might
> well decide to diagnose the lack of return, but since it's not, and
> there's existing valid code
> and breakage thereof to consider, trying to mandate a diagnostic for a
> missing return is fighting
> an uphill battle.
>
> You are all more than welcome to continue to misunderstand that or
> claim that such considerations
> are brought up by idiots, but if you choose to do so, I honestly
> wonder why this thread exists, considering
> that there seems to be a strong effort by the supposed proponents of
> the idea to convince everybody
> else that they don't really want this idea to succeed.
>
> --
> 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/CAFk2RUaxu_thbrRbqxL-nuvZkQnVvKP1rfE_XB%
> 2B342AcLUcrag%40mail.gmail.com.
>
--
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/CALvx3haEDQgDKne-9UtVWY7jGkhbgoXB6HZT0vQSFAiW13NJmg%40mail.gmail.com.
--001a113fbc086b7f410560c88ce8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">The churn comes=
from functions that don't have a return or an=C2=A0</span><span style=
=3D"font-size:12.8px">annotation that that is intended,</span><div><span st=
yle=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.=
8px">We have already seen that these "intended no return" functio=
ns result in worse code. This is precisely because the compiler cannot dedu=
ce intent. In every other conversation about UB, there would be unanimous a=
greement that UB is to be avoided.</span></div><div><span style=3D"font-siz=
e:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">For some u=
nfathomable reason, on this issue, some wish to defy the evidence before th=
em and continue to demand the right to write UB functions without a diagnos=
tic - to the detriment of the vast majority who simply want functions to do=
defined things.</span></div><div><span style=3D"font-size:12.8px"><br></sp=
an></div><div><span style=3D"font-size:12.8px">How do I know that the major=
ity want functions to do defined things? Because the universally accepted p=
rocess for writing and testing code is to write tests. What do tests do? Th=
ey verify the claims of the function's author. What do UB functions do?=
They refuse to make any claims. Is that testable? No. Is it useful? Quad e=
rat demonstrandum, no.</span></div><div><span style=3D"font-size:12.8px"><b=
r></span></div><div><span style=3D"font-size:12.8px">>=C2=A0</span><span=
style=3D"font-size:12.8px">and the halting problem issue is that a compile=
r doesn't know which of=C2=A0</span><span style=3D"font-size:12.8px">th=
ose functions are used=C2=A0</span><span style=3D"font-size:12.8px">and whi=
ch ones unused</span></div><div><span style=3D"font-size:12.8px"><br></span=
></div><div><span style=3D"font-size:12.8px">Totally irrelevant. The compil=
er doesn't know or care about the colour of my socks either. Code eithe=
r has defined behaviour, or it's a useless liability.</span></div><div>=
<span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-=
size:12.8px">>=C2=A0</span><span style=3D"font-size:12.8px">Which leads =
to false positives.</span></div><div><span style=3D"font-size:12.8px"><br><=
/span></div><div><span style=3D"font-size:12.8px">All UB is a positively an=
error. The correct (and performant) thing to do is fix it.</span></div><di=
v><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"fon=
t-size:12.8px">>=C2=A0</span><span style=3D"font-size:12.8px">but since =
it's not, and=C2=A0</span><span style=3D"font-size:12.8px">there's =
existing valid code=C2=A0</span><span style=3D"font-size:12.8px">and breaka=
ge thereof to consider</span></div><div><span style=3D"font-size:12.8px"><b=
r></span></div><div><span style=3D"font-size:12.8px">Do you remember when w=
e moved from K&R function declarations to ANSI function declarations? I=
do. Everyone coped just fine. No-one demanded the right to continue to wri=
te</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div>=
<span style=3D"font-size:12.8px"><font face=3D"monospace, monospace">func(x=
,y)</font></span></div><div><span style=3D"font-size:12.8px"><font face=3D"=
monospace, monospace">double x;</font></span></div><div><span style=3D"font=
-size:12.8px"><font face=3D"monospace, monospace">int y;</font></span></div=
><div><span style=3D"font-size:12.8px"><font face=3D"monospace, monospace">=
{</font></span></div><div><span style=3D"font-size:12.8px"><font face=3D"mo=
nospace, monospace">=C2=A0 if (x > 0)</font></span></div><div><span styl=
e=3D"font-size:12.8px"><font face=3D"monospace, monospace">=C2=A0 =C2=A0 re=
turn y;</font></span></div><div><span style=3D"font-size:12.8px"><font face=
=3D"monospace, monospace">}</font></span></div><div><span style=3D"font-siz=
e:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">**this** i=
s the origin on the UB on non-specified returns. Almost everything else got=
fixed. This got forgotten.</span></div><div><span style=3D"font-size:12.8p=
x"><br></span></div><div><span style=3D"font-size:12.8px"><br></span></div>=
<div><span style=3D"font-size:12.8px">>=C2=A0</span><span style=3D"font-=
size:12.8px">trying to mandate a diagnostic for a=C2=A0</span><span style=
=3D"font-size:12.8px">missing return is fighting=C2=A0</span><span style=3D=
"font-size:12.8px">an uphill battle.</span></div><div><span style=3D"font-s=
ize:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">One of m=
y engineers, an experienced guy with 20 years writing c++, spent the first =
half of today diagnosing something that turned out to be a result of exactl=
y this. Forgetting to return the shared_ptr he had created. In a function h=
e had written 30 minutes prior. The crash occurred in thread 3, nowhere nea=
r the offending code that was executed in thread 1.</span></div><div><span =
style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:1=
2.8px">Half a day. Over something the compiler could, no, *should* have tol=
d him on the first compile.</span></div><div><span style=3D"font-size:12.8p=
x"><br></span></div><div><span style=3D"font-size:12.8px">This happens a lo=
t, all over the world, every day. The combined loss of productivity easily =
outweighs the minor inconvenience of fixing a few lazily-written, demonstra=
bly suboptimal, leaf functions.</span></div><div><span style=3D"font-size:1=
2.8px"><br></span></div><div><span style=3D"font-size:12.8px">You and the c=
urrent committee stance on this, are wrong. It is a problem. Not all develo=
pers are as vociferous as me, so why don't you ask the others whether t=
hey'd prefer to have this? Ask, not tell.</span></div><div><span style=
=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px=
"><br></span></div><div><br></div></div><div class=3D"gmail_extra"><br><div=
class=3D"gmail_quote">On 20 December 2017 at 17:36, Ville Voutilainen <spa=
n dir=3D"ltr"><<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"=
_blank">ville.voutilainen@gmail.com</a>></span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><span class=3D"">On 20 December 2017 at 18:17, Jake Arkins=
tall <<a href=3D"mailto:jake.arkinstall@gmail.com">jake.arkinstall@gmail=
..com</a>> wrote:<br>
><br>
><br>
> On 20 Dec 2017 15:55, "Ville Voutilainen" <<a href=3D"mai=
lto:ville.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>><br>
> wrote:<br>
><br>
> VV: We could go towards a direction of making the lack of return<br>
> ill-formed. Compilers already diagnose it, by default.<br>
> CC: But how do you know you call the function?<br>
> VV: I don't. That runs into the Halting Problem. This would theref=
ore<br>
> cause unnecessary churn in valid code. Consider<br>
> the idea withdrawn. Let's kill it if it comes up in the form of a =
proposal.<br>
> CC: Agreed.<br>
><br>
><br>
> Wow. Was there someone at the meeting holding up a sign saying "[=
citation<br>
> needed]" when the halting problem was brought up? Adding somethin=
g at the<br>
> end of functions that have a non-returning branch (whether accessible =
or<br>
> not) is hardly solving the halting problem or causing churn. It never =
gets<br>
> run, assuming the function behaved beforehand.<br>
<br>
</span>The churn comes from functions that don't have a return or an<br=
>
annotation that that is intended,<br>
and the halting problem issue is that a compiler doesn't know which of<=
br>
those functions are used<br>
and which ones unused. Which leads to false positives. Were this a<br>
from-scratch matter, we might<br>
well decide to diagnose the lack of return, but since it's not, and<br>
there's existing valid code<br>
and breakage thereof to consider, trying to mandate a diagnostic for a<br>
missing return is fighting<br>
an uphill battle.<br>
<br>
You are all more than welcome to continue to misunderstand that or<br>
claim that such considerations<br>
are brought up by idiots, but if you choose to do so, I honestly<br>
wonder why this thread exists, considering<br>
that there seems to be a strong effort by the supposed proponents of<br>
the idea to convince everybody<br>
else that they don't really want this idea to succeed.<br>
<span class=3D""><br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUaxu_thbrRbqxL-nuvZkQnVv=
KP1rfE_XB%2B342AcLUcrag%40mail.gmail.com" rel=3D"noreferrer" target=3D"_bla=
nk">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/=
CAFk2RUaxu_<wbr>thbrRbqxL-nuvZkQnVvKP1rfE_XB%<wbr>2B342AcLUcrag%40mail.gmai=
l.com</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/CALvx3haEDQgDKne-9UtVWY7jGkhbgoXB6HZT=
0vQSFAiW13NJmg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3haEDQgDKne-=
9UtVWY7jGkhbgoXB6HZT0vQSFAiW13NJmg%40mail.gmail.com</a>.<br />
--001a113fbc086b7f410560c88ce8--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 20 Dec 2017 09:13:17 -0800
Raw View
On quarta-feira, 20 de dezembro de 2017 07:59:42 PST Richard Hodges wrote:
> I am still waiting for code that compiles better when UB is involved guys.
Do we need to bring the discussion on signed integer overflow and shifting
again? I thought I was quite clear that the code was faster in both cases.
More importantly, UB is *not* involved. That's the entire point. UB can only
happen if the function is misused in the first place. If that happens, the
result you get is nonsense, regardless of whether that was caused by you or by
the compiler.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/1806941.Rp44EGdGQP%40tjmaciei-mobl1.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 20 Dec 2017 19:17:23 +0200
Raw View
On 20 December 2017 at 19:02, Richard Hodges <hodges.r@gmail.com> wrote:
> One of my engineers, an experienced guy with 20 years writing c++, spent the
> first half of today diagnosing something that turned out to be a result of
> exactly this. Forgetting to return the shared_ptr he had created. In a
> function he had written 30 minutes prior. The crash occurred in thread 3,
> nowhere near the offending code that was executed in thread 1.
>
> Half a day. Over something the compiler could, no, *should* have told him on
> the first compile.
You're saying your compiler can't tell you that?
> You and the current committee stance on this, are wrong. It is a problem.
> Not all developers are as vociferous as me, so why don't you ask the others
> whether they'd prefer to have this? Ask, not tell.
Feel free to convince us otherwise. Thus far you've failed.
--
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/CAFk2RUaG6Wj6%2B1g46a03NDNtGP3yHqH18%2B%2BB2OJSNLTgPi3uEQ%40mail.gmail.com.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 20 Dec 2017 09:17:37 -0800
Raw View
On quarta-feira, 20 de dezembro de 2017 08:06:51 PST Richard Hodges wrote:
> "CC: But how do you know you call the function?"
>
> An idiotic response. The correctness of code does not depend on whether it
> is called.
Of course it does! I don't know what definition of "correct" you're using,
there...
By "correct", I understand that the program runs as defined by the language
rules, given all possible external inputs. Since the function is never called,
the fact that it does not return or returns garbage simply cannot affect the
program's running. Therefore, by this definition, this program will run
correctly.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/2268816.GXjlaZc0m5%40tjmaciei-mobl1.
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Wed, 20 Dec 2017 18:17:42 +0100
Raw View
--94eb2c05b4bae5dec90560c8c2e0
Content-Type: text/plain; charset="UTF-8"
> Do we need to bring the discussion on signed integer overflow and
shifting again?
No, what we're going to do is keep the thread on topic. The topic is around
allowing a function that advertises that it returns a value to not return a
value.
Show me a function that performs better when there is a control path that
does not return a value that does not produce code at least as good when
written so that all control paths return a value.
On 20 December 2017 at 18:13, Thiago Macieira <thiago@macieira.org> wrote:
> On quarta-feira, 20 de dezembro de 2017 07:59:42 PST Richard Hodges wrote:
> > I am still waiting for code that compiles better when UB is involved
> guys.
>
> Do we need to bring the discussion on signed integer overflow and shifting
> again? I thought I was quite clear that the code was faster in both cases.
>
> More importantly, UB is *not* involved. That's the entire point. UB can
> only
> happen if the function is misused in the first place. If that happens, the
> result you get is nonsense, regardless of whether that was caused by you
> or by
> the compiler.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
>
> --
> 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/1806941.Rp44EGdGQP%40tjmaciei-mobl1.
>
--
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/CALvx3haKrE99_paHqaLwVbi%2BDD5XvP-P6SZuci2cyBwbKru0dw%40mail.gmail.com.
--94eb2c05b4bae5dec90560c8c2e0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">Do we need to b=
ring the discussion on signed integer overflow and shifting=C2=A0</span><sp=
an style=3D"font-size:12.8px">again?=C2=A0</span><div><span style=3D"font-s=
ize:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">No, what=
we're going to do is keep the thread on topic. The topic is around all=
owing a function that advertises that it returns a value to not return a va=
lue.</span></div><div><span style=3D"font-size:12.8px"><br></span></div><di=
v><span style=3D"font-size:12.8px">Show me a function that performs better =
when there is a control path that does not return a value that does not pro=
duce code at least as good when written so that all control paths return a =
value.</span></div><div><span style=3D"font-size:12.8px"><br></span></div><=
/div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 20 Decemb=
er 2017 at 18:13, Thiago Macieira <span dir=3D"ltr"><<a href=3D"mailto:t=
hiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>></span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On quarta-feira, 20=
de dezembro de 2017 07:59:42 PST Richard Hodges wrote:<br>
> I am still waiting for code that compiles better when UB is involved g=
uys.<br>
<br>
</span>Do we need to bring the discussion on signed integer overflow and sh=
ifting<br>
again? I thought I was quite clear that the code was faster in both cases.<=
br>
<br>
More importantly, UB is *not* involved. That's the entire point. UB can=
only<br>
happen if the function is misused in the first place. If that happens, the<=
br>
result you get is nonsense, regardless of whether that was caused by you or=
by<br>
the compiler.<br>
<span class=3D""><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
</span><span class=3D"">--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/1806941.Rp44EGdGQP%40tjmaciei-=
mobl1" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/<wb=
r>isocpp.org/d/msgid/std-<wbr>proposals/1806941.Rp44EGdGQP%<wbr>40tjmaciei-=
mobl1</a>.<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/CALvx3haKrE99_paHqaLwVbi%2BDD5XvP-P6S=
Zuci2cyBwbKru0dw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3haKrE99_p=
aHqaLwVbi%2BDD5XvP-P6SZuci2cyBwbKru0dw%40mail.gmail.com</a>.<br />
--94eb2c05b4bae5dec90560c8c2e0--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Wed, 20 Dec 2017 18:21:33 +0100
Raw View
--001a114034b8a676ee0560c8d07d
Content-Type: text/plain; charset="UTF-8"
> Since the function is never called, the fact that it does not return or
returns garbage simply cannot affect the program's running. Therefore, by
this definition, this program will run correctly.
A function that is never called either,
* has no place in the program in the first place. Just delete it, or
* may be called in some later modification to the program, so it had better
be correct, by the strictest definition of the term.
This is another straw-man.
On 20 December 2017 at 18:17, Richard Hodges <hodges.r@gmail.com> wrote:
> > Do we need to bring the discussion on signed integer overflow and
> shifting again?
>
> No, what we're going to do is keep the thread on topic. The topic is
> around allowing a function that advertises that it returns a value to not
> return a value.
>
> Show me a function that performs better when there is a control path that
> does not return a value that does not produce code at least as good when
> written so that all control paths return a value.
>
>
> On 20 December 2017 at 18:13, Thiago Macieira <thiago@macieira.org> wrote:
>
>> On quarta-feira, 20 de dezembro de 2017 07:59:42 PST Richard Hodges wrote:
>> > I am still waiting for code that compiles better when UB is involved
>> guys.
>>
>> Do we need to bring the discussion on signed integer overflow and shifting
>> again? I thought I was quite clear that the code was faster in both cases.
>>
>> More importantly, UB is *not* involved. That's the entire point. UB can
>> only
>> happen if the function is misused in the first place. If that happens, the
>> result you get is nonsense, regardless of whether that was caused by you
>> or by
>> the compiler.
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> Software Architect - Intel Open Source Technology Center
>>
>> --
>> 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/is
>> ocpp.org/d/msgid/std-proposals/1806941.Rp44EGdGQP%40tjmaciei-mobl1.
>>
>
>
--
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/CALvx3hawKVGSk7XR1EU9uF59OJuPKAvv9YPMtWt5p_Eo9zio7Q%40mail.gmail.com.
--001a114034b8a676ee0560c8d07d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span style=3D"font-size:12.8px">> Since the function i=
s never called,=C2=A0</span><span style=3D"font-size:12.8px">the fact that =
it does not return or returns garbage simply cannot affect the=C2=A0</span>=
<span style=3D"font-size:12.8px">program's running. Therefore, by this =
definition, this program will run=C2=A0</span><span style=3D"font-size:12.8=
px">correctly.</span><br><div><span style=3D"font-size:12.8px"><br></span><=
/div><div><span style=3D"font-size:12.8px">A function that is never called =
either,</span></div><div><span style=3D"font-size:12.8px"><br></span></div>=
<div><span style=3D"font-size:12.8px">* has no place in the program in the =
first place. Just delete it, or</span></div><div><span style=3D"font-size:1=
2.8px"><br></span></div><div><span style=3D"font-size:12.8px">* may be call=
ed in some later modification to the program, so it had better be correct, =
by the strictest definition of the term.</span></div><div><span style=3D"fo=
nt-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">This=
is another straw-man.</span></div><div><span style=3D"font-size:12.8px"><b=
r></span></div><div><span style=3D"font-size:12.8px"><br></span></div><div>=
<span style=3D"font-size:12.8px"><br></span></div></div><div class=3D"gmail=
_extra"><br><div class=3D"gmail_quote">On 20 December 2017 at 18:17, Richar=
d Hodges <span dir=3D"ltr"><<a href=3D"mailto:hodges.r@gmail.com" target=
=3D"_blank">hodges.r@gmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">D=
o we need to bring the discussion on signed integer overflow and shifting=
=C2=A0</span><span style=3D"font-size:12.8px">again?=C2=A0</span><div><span=
style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:=
12.8px">No, what we're going to do is keep the thread on topic. The top=
ic is around allowing a function that advertises that it returns a value to=
not return a value.</span></div><div><span style=3D"font-size:12.8px"><br>=
</span></div><div><span style=3D"font-size:12.8px">Show me a function that =
performs better when there is a control path that does not return a value t=
hat does not produce code at least as good when written so that all control=
paths return a value.</span></div><div><span style=3D"font-size:12.8px"><b=
r></span></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 20 December 2017 at 18:13, Thiago Macieira <span dir=3D"ltr"><<a =
href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</=
a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On quarta-feir=
a, 20 de dezembro de 2017 07:59:42 PST Richard Hodges wrote:<br>
> I am still waiting for code that compiles better when UB is involved g=
uys.<br>
<br>
</span>Do we need to bring the discussion on signed integer overflow and sh=
ifting<br>
again? I thought I was quite clear that the code was faster in both cases.<=
br>
<br>
More importantly, UB is *not* involved. That's the entire point. UB can=
only<br>
happen if the function is misused in the first place. If that happens, the<=
br>
result you get is nonsense, regardless of whether that was caused by you or=
by<br>
the compiler.<span class=3D""><br>
<span><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
</span><span>--<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.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></span>To view this discussion on the web visit <a href=3D"https://g=
roups.google.com/a/isocpp.org/d/msgid/std-proposals/1806941.Rp44EGdGQP%40tj=
maciei-mobl1" rel=3D"noreferrer" target=3D"_blank">https://groups.google.co=
m/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/1806941.Rp44EGdGQP%40tjmacie=
i<wbr>-mobl1</a>.<br>
</blockquote></div><br></div>
</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/CALvx3hawKVGSk7XR1EU9uF59OJuPKAvv9YPM=
tWt5p_Eo9zio7Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hawKVGSk7XR=
1EU9uF59OJuPKAvv9YPMtWt5p_Eo9zio7Q%40mail.gmail.com</a>.<br />
--001a114034b8a676ee0560c8d07d--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 20 Dec 2017 17:50:05 +0000
Raw View
--089e0821370cc5c2ce0560c9363a
Content-Type: text/plain; charset="UTF-8"
On 20 Dec 2017 16:12, "Richard Hodges" <hodges.r@gmail.com> wrote:
In response to Edward's request for a godbolt link:
https://godbolt.org/g/UFL6pN
That's fixed in trunk.
On 20 December 2017 at 17:06, 'Edward Catmur' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:
> On Wed, Dec 20, 2017 at 3:32 PM, Richard Hodges <hodges.r@gmail.com>
> wrote:
>
>> > So you've in favor of writing ugly code just to avoid the performance
>> penalty for your idea?
>>
>> Any retort that begins with the word, "so" is bound to be needlessly
>> confrontational. Are you really here in the interests of the language?
>> Please think carefully before answering.
>>
>> Please kindly see the second implementation.
>>
>> Also please ponder carefully the fact that the versions of this function
>> with no UB produce better code than when the compiler is faced with UB.
>>
>
> I have been unable to reproduce this. Could you please post the versions
> and flags of the compilers that you saw exhibit this issue? godbolt.org
> links would be great if possible.
>
> If you can find me a function that produces better code when UB is invoked
>> around the return value, I'm all eyes and ears. Until then, the performance
>> argument fails at the first test.
>>
>
> This is a pointless task, because you are reserving yourself the right to
> contort the function to reproduce the actual behavior selected by the
> compiler; you can do this by decompiling the generated code to
> non-idiomatic C++. The question is which version of the function is more
> readable and maintainable.
>
> I have shown you facts.
>>
>> Refute with facts, or please kindly stop and think.
>>
>>
>>
>>
>>
>> On 20 December 2017 at 16:12, Nicol Bolas <jmckesson@gmail.com> wrote:
>>
>>> On Wednesday, December 20, 2017 at 7:31:37 AM UTC-5, Richard Hodges
>>> wrote:
>>>>
>>>> > After: imperative, mutating, asymmetric, braided control flow.
>>>>
>>>> You're nitpicking. The author of the UB foo argued that UB was
>>>> necessary for performance. It's not.
>>>>
>>>
>>> So you've in favor of writing ugly code just to avoid the performance
>>> penalty for your idea? I have a hard time finding that to be convincing.
>>>
>>> People don't add variables unless they need them, and this code doesn't
>>> *need* them. Everything here is static and based on literals, so
>>> there's no reason to have a variable. Not unless you're pedantic about some
>>> UB that will never happen.
>>>
>>> That code should fail a code review for being needlessly complicated.
>>>
>>> It hinders performance. You know full well that you can express the
>>>> intent of the contact to a human reader at zero cost with an assert and/or
>>>> contract documentation,
>>>>
>>>
>>> So long as the number of enumerators doesn't exceed the compiler limits
>>> on the number of function or template arguments. `switch` statements either
>>> have no such limits or have a lot higher limits.
>>>
>>> Not to mention this requires manually entering the enumerators an
>>> additional time. DRY is a thing for a reason.
>>>
>>> It's better to just let compilers *do their jobs*. They've been looking
>>> out for missing enumerators on `switch` conditions for over a decade; why
>>> should we start hard-coding that into our programs?
>>>
>>> --
>>> 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/is
>>> ocpp.org/d/msgid/std-proposals/07ff3dff-9b90-425e-98ff-ec435
>>> ba12ca2%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/07ff3dff-9b90-425e-98ff-ec435ba12ca2%40isocpp.org?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit https://groups.google.com/a/is
>> ocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/is
>> ocpp.org/d/msgid/std-proposals/CALvx3hYmZ43uKf_HYOMnK-uFaeDw
>> R8DaGoq1UjsUB3OtA9gwdQ%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hYmZ43uKf_HYOMnK-uFaeDwR8DaGoq1UjsUB3OtA9gwdQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
> --
> 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/is
> ocpp.org/d/msgid/std-proposals/CAJnLdOY6NjGmhBeT2KBTxTMqGgm1
> 43i-BnvTzVGxNgmsH%2BGeLw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOY6NjGmhBeT2KBTxTMqGgm143i-BnvTzVGxNgmsH%2BGeLw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to a topic in the
Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/
isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
To unsubscribe from this group and all its topics, 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/CALvx3hb1KcvHZQQvrqOJ%3DGj-
f3btYNXRBcQ%3DX%3D0Ooqk%2BnyWHNg%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hb1KcvHZQQvrqOJ%3DGj-f3btYNXRBcQ%3DX%3D0Ooqk%2BnyWHNg%40mail.gmail.com?utm_medium=email&utm_source=footer>
..
--
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/CAJnLdOZojGkf5Mh3EKPfmwh8tr9Dep1Di-nq62hFxGsM4aFiog%40mail.gmail.com.
--089e0821370cc5c2ce0560c9363a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On 20 Dec 2017 16:12, "Richard Hodges" <<a href=3D"m=
ailto:hodges.r@gmail.com">hodges.r@gmail.com</a>> wrote:<br type=3D"attr=
ibution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>In response to Edwa=
rd's request for a godbolt link:</div><div><br></div><div><br></div><a =
href=3D"https://godbolt.org/g/UFL6pN" target=3D"_blank">https://godbolt.org=
/g/UFL6pN</a><br><div></div></div></blockquote></div></div></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">That's fixed in trunk.=C2=A0</div=
><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_extra"><=
div class=3D"gmail_quote"><blockquote class=3D"quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><b=
r></div></div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div cl=
ass=3D"elided-text">On 20 December 2017 at 17:06, 'Edward Catmur' v=
ia ISO C++ Standard - Future Proposals <span dir=3D"ltr"><<a href=3D"mai=
lto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a=
>></span> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"e=
lided-text"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail=
_quote"><span>On Wed, Dec 20, 2017 at 3:32 PM, Richard Hodges <span dir=3D"=
ltr"><<a href=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@g=
mail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><span>>=C2=A0<span style=3D"font-size:12.8px">So you've in =
favor of writing ugly code just to avoid the performance penalty for your i=
dea?</span><div><span style=3D"font-size:12.8px"><br></span></div></span><d=
iv><span style=3D"font-size:12.8px">Any retort that begins with the word, &=
quot;so" is bound to be needlessly confrontational. Are you really her=
e in the interests of the language? Please think carefully before answering=
..</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><=
span style=3D"font-size:12.8px">Please kindly see the second implementation=
..</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><=
span style=3D"font-size:12.8px">Also please ponder carefully the fact that =
the versions of this function with no UB produce better code than when the =
compiler is faced with UB.</span></div></div></blockquote><div><br></div></=
span><div>I have been unable to reproduce this. Could you please post the v=
ersions and flags of the compilers that you saw exhibit this issue? <a href=
=3D"http://godbolt.org" target=3D"_blank">godbolt.org</a> links would be gr=
eat if possible.=C2=A0</div><span><div><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div><span style=3D"font-size:12.8px"></span></div><d=
iv><span style=3D"font-size:12.8px">If you can find me a function that prod=
uces better code when UB is invoked around the return value, I'm all ey=
es and ears. Until then, the performance argument fails at the first test.=
=C2=A0</span></div></div></blockquote><div><br></div></span><div>This is a =
pointless task, because you are reserving yourself the right to contort the=
function to reproduce the actual behavior selected by the compiler; you ca=
n do this by decompiling the generated code to non-idiomatic C++. The quest=
ion is which version of the function is more readable and maintainable.</di=
v><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><span><div dir=3D"ltr"><div=
><span style=3D"font-size:12.8px"></span></div><div><span style=3D"font-siz=
e:12.8px">I have shown you facts.</span></div><div><span style=3D"font-size=
:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">Refute with=
facts, or please kindly stop and think.</span></div><div><span style=3D"fo=
nt-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px"><br>=
</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><s=
pan style=3D"font-size:12.8px"><br></span></div></div><div class=3D"gmail_e=
xtra"><br><div class=3D"gmail_quote"><span>On 20 December 2017 at 16:12, Ni=
col Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com" targ=
et=3D"_blank">jmckesson@gmail.com</a>></span> wrote:<br></span><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><span><div dir=3D"ltr"><span>On Wednesday, December 2=
0, 2017 at 7:31:37 AM UTC-5, Richard Hodges wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">=
After: imperative, mutating, asymmetric, braided control flow.</span><div><=
span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-s=
ize:12.8px">You're nitpicking. The author of the UB foo argued that UB =
was necessary for performance. It's not.</span></div></div></blockquote=
><div><br></div></span><div>So you've in favor of writing ugly code jus=
t to avoid the performance penalty for your idea? I have a hard time findin=
g that to be convincing.</div><div><br></div><div>People don't add vari=
ables unless they need them, and this code doesn't <i>need</i> them. Ev=
erything here is static and based on literals, so there's no reason to =
have a variable. Not unless you're pedantic about some UB that will nev=
er happen.</div><div><br></div><div>That code should fail a code review for=
being needlessly complicated.</div><span><div><i><br></i></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><span style=3D"font-size=
:12.8px">It hinders performance. You know full well that you can express th=
e intent of the contact to a human reader at zero cost with an assert and/o=
r contract documentation,</span></div></div></blockquote><div><br></div></s=
pan><div>So long as the number of enumerators doesn't exceed the compil=
er limits on the number of function or template arguments. `switch` stateme=
nts either have no such limits or have a lot higher limits.</div><div><br><=
/div><div>Not to mention this requires manually entering the enumerators an=
additional time. DRY is a thing for a reason.</div><div><i><br></i></div><=
div>It's better to just let compilers <i>do their jobs</i>. They've=
been looking out for missing enumerators on `switch` conditions for over a=
decade; why should we start hard-coding that into our programs?</div><div>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></span><span>
<p></p>
-- <br><span>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></span>
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@isoc<wbr>pp.org</a>.<span><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></span><spa=
n>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/07ff3dff-9b90-425e-98ff-ec435ba12ca2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/07ff=
3dff-9b90-425e-98ff-ec435<wbr>ba12ca2%40isocpp.org</a>.<br>
</span></blockquote></div><br></div></span><span>
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/is<wbr>ocpp.org/d/topic/std-proposals<wbr>/U=
u2QViiWh4k/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isoc<wbr>pp.org</a>.<span><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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hYmZ43uKf_HYOMnK-uFaeDwR8DaGoq1=
UjsUB3OtA9gwdQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-=
proposals<wbr>/CALvx3hYmZ43uKf_HYOMnK-uFaeDw<wbr>R8DaGoq1UjsUB3OtA9gwdQ%40m=
ail.<wbr>gmail.com</a>.<br>
</blockquote></div><br></div></div><span>
<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@isoc<wbr>pp.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></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdOY6NjGmhBeT2KBTxTMqGgm143i-BnvT=
zVGxNgmsH%2BGeLw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/st=
d-proposals<wbr>/CAJnLdOY6NjGmhBeT2KBTxTMqGgm1<wbr>43i-BnvTzVGxNgmsH%2BGeLw=
%40mai<wbr>l.gmail.com</a>.<br>
</blockquote></div><br></div><div class=3D"quoted-text">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/U=
u2QViiWh4k/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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/CALvx3hb1KcvHZQQvrqOJ%3DGj-f3btYNXRBc=
Q%3DX%3D0Ooqk%2BnyWHNg%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/=
msgid/std-<wbr>proposals/<wbr>CALvx3hb1KcvHZQQvrqOJ%3DGj-<wbr>f3btYNXRBcQ%3=
DX%3D0Ooqk%<wbr>2BnyWHNg%40mail.gmail.com</a>.<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/CAJnLdOZojGkf5Mh3EKPfmwh8tr9Dep1Di-nq=
62hFxGsM4aFiog%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZojGkf5Mh3=
EKPfmwh8tr9Dep1Di-nq62hFxGsM4aFiog%40mail.gmail.com</a>.<br />
--089e0821370cc5c2ce0560c9363a--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Wed, 20 Dec 2017 18:52:19 +0100
Raw View
--94eb2c05e33cb79ab30560c93e32
Content-Type: text/plain; charset="UTF-8"
To continue...
Here's a function which looks a little like our better foo() function, but
returns a large, complex object.
Note how this too can be written in such a way as to exhibit no UB ever,
and is also optimally efficient:
struct floom
{
std::string a,b,c,d,e,f,g;
};
floom make_floom(Values x)
{
auto make_e1 = [] {
return floom { "aa", "ab", "ac", "ad", "ae", "af", "ag"};
};
auto make_e2 = [] {
return floom { "a", "b", "c", "d", "e", "f", "g"};
};
switch(x) {
case E1:
return make_e1();
case E2:
return make_e2();
}
return make_e2();
}
Again, consistent, expressive, preserves warnings in the switch, RVO
happens, and *completely obvious* what happens if you pass in an incorrect
argument.
assembler from 'gcc -O2' (note the position of the one and only conditional
branch):
make_floom(Values):
lea r11, [rdi+16]
test esi, esi
lea rax, [rdi+208]
lea rdx, [rdi+176]
lea rcx, [rdi+144]
lea r8, [rdi+112]
lea r9, [rdi+80]
lea r10, [rdi+48]
mov QWORD PTR [rdi], r11
je .L18
mov esi, 97
mov QWORD PTR [rdi+32], r10
mov r10d, 98
mov WORD PTR [rdi+16], si
mov WORD PTR [rdi+48], r10w
mov r11d, 99
mov QWORD PTR [rdi+64], r9
mov QWORD PTR [rdi+96], r8
mov esi, 100
mov r8d, 101
mov r9d, 102
mov r10d, 103
mov QWORD PTR [rdi+192], rax
mov QWORD PTR [rdi+8], 1
mov rax, rdi
mov QWORD PTR [rdi+40], 1
mov QWORD PTR [rdi+72], 1
mov WORD PTR [rdi+80], r11w
mov QWORD PTR [rdi+104], 1
mov WORD PTR [rdi+112], si
mov QWORD PTR [rdi+128], rcx
mov QWORD PTR [rdi+136], 1
mov WORD PTR [rdi+144], r8w
mov QWORD PTR [rdi+160], rdx
mov QWORD PTR [rdi+168], 1
mov WORD PTR [rdi+176], r9w
mov QWORD PTR [rdi+200], 1
mov WORD PTR [rdi+208], r10w
ret
..L18:
mov r11d, 24929
mov QWORD PTR [rdi+32], r10
mov esi, 25185
mov WORD PTR [rdi+16], r11w
mov QWORD PTR [rdi+64], r9
mov r10d, 25697
mov r9d, 25441
mov QWORD PTR [rdi+128], rcx
mov r11d, 25953
mov QWORD PTR [rdi+160], rdx
mov ecx, 26465
mov edx, 26209
mov QWORD PTR [rdi+192], rax
mov QWORD PTR [rdi+8], 2
mov rax, rdi
mov BYTE PTR [rdi+18], 0
mov WORD PTR [rdi+48], si
mov QWORD PTR [rdi+40], 2
mov BYTE PTR [rdi+50], 0
mov WORD PTR [rdi+80], r9w
mov QWORD PTR [rdi+72], 2
mov BYTE PTR [rdi+82], 0
mov QWORD PTR [rdi+96], r8
mov WORD PTR [rdi+112], r10w
mov QWORD PTR [rdi+104], 2
mov BYTE PTR [rdi+114], 0
mov WORD PTR [rdi+144], r11w
mov QWORD PTR [rdi+136], 2
mov BYTE PTR [rdi+146], 0
mov WORD PTR [rdi+176], dx
mov QWORD PTR [rdi+168], 2
mov BYTE PTR [rdi+178], 0
mov WORD PTR [rdi+208], cx
mov QWORD PTR [rdi+200], 2
mov BYTE PTR [rdi+210], 0
ret
https://godbolt.org/g/X2A5Jj
On 20 December 2017 at 18:21, Richard Hodges <hodges.r@gmail.com> wrote:
> > Since the function is never called, the fact that it does not return or
> returns garbage simply cannot affect the program's running. Therefore, by
> this definition, this program will run correctly.
>
> A function that is never called either,
>
> * has no place in the program in the first place. Just delete it, or
>
> * may be called in some later modification to the program, so it had
> better be correct, by the strictest definition of the term.
>
> This is another straw-man.
>
>
>
>
> On 20 December 2017 at 18:17, Richard Hodges <hodges.r@gmail.com> wrote:
>
>> > Do we need to bring the discussion on signed integer overflow and
>> shifting again?
>>
>> No, what we're going to do is keep the thread on topic. The topic is
>> around allowing a function that advertises that it returns a value to not
>> return a value.
>>
>> Show me a function that performs better when there is a control path that
>> does not return a value that does not produce code at least as good when
>> written so that all control paths return a value.
>>
>>
>> On 20 December 2017 at 18:13, Thiago Macieira <thiago@macieira.org>
>> wrote:
>>
>>> On quarta-feira, 20 de dezembro de 2017 07:59:42 PST Richard Hodges
>>> wrote:
>>> > I am still waiting for code that compiles better when UB is involved
>>> guys.
>>>
>>> Do we need to bring the discussion on signed integer overflow and
>>> shifting
>>> again? I thought I was quite clear that the code was faster in both
>>> cases.
>>>
>>> More importantly, UB is *not* involved. That's the entire point. UB can
>>> only
>>> happen if the function is misused in the first place. If that happens,
>>> the
>>> result you get is nonsense, regardless of whether that was caused by you
>>> or by
>>> the compiler.
>>>
>>> --
>>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>> Software Architect - Intel Open Source Technology Center
>>>
>>> --
>>> 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/is
>>> ocpp.org/d/msgid/std-proposals/1806941.Rp44EGdGQP%40tjmaciei-mobl1.
>>>
>>
>>
>
--
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/CALvx3hYbX9ftMDFDnSGP9wK-0ZC43qXfcqVUz-nZpc3hZ9nMXw%40mail.gmail.com.
--94eb2c05e33cb79ab30560c93e32
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">To continue...<div><br></div><div>Here's a function wh=
ich looks a little like our better foo() function, but returns a large, com=
plex object.</div><div><br></div><div>Note how this too can be written in s=
uch a way as to exhibit no UB ever, and is also optimally efficient:</div><=
div><br></div><div><div style=3D"background-color:rgb(255,255,254);line-hei=
ght:21px"><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><f=
ont face=3D"monospace, monospace"><span style=3D"color:rgb(0,0,255)">struct=
</span> floom</font></div><div style=3D"color:rgb(0,0,0);font-size:14px;whi=
te-space:pre"><font face=3D"monospace, monospace">{</font></div><div style=
=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><font face=3D"monospac=
e, monospace"> std::string a,b,c,d,e,f,g;</font></div><div style=3D"colo=
r:rgb(0,0,0);font-size:14px;white-space:pre"><font face=3D"monospace, monos=
pace">};</font></div><font face=3D"monospace, monospace" style=3D"color:rgb=
(0,0,0);font-size:14px;white-space:pre"><br></font><div style=3D"color:rgb(=
0,0,0);font-size:14px;white-space:pre"><font face=3D"monospace, monospace">=
floom make_floom(Values x)</font></div><div style=3D"color:rgb(0,0,0);font-=
size:14px;white-space:pre"><font face=3D"monospace, monospace">{</font></di=
v><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><font face=
=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">auto</span=
> make_e1 =3D [] {</font></div><div style=3D"color:rgb(0,0,0);font-size:14p=
x;white-space:pre"><font face=3D"monospace, monospace"> <span style=
=3D"color:rgb(0,0,255)">return</span> floom { <span style=3D"color:rgb(163,=
21,21)">"aa"</span>, <span style=3D"color:rgb(163,21,21)">"a=
b"</span>, <span style=3D"color:rgb(163,21,21)">"ac"</span>,=
<span style=3D"color:rgb(163,21,21)">"ad"</span>, <span style=3D=
"color:rgb(163,21,21)">"ae"</span>, <span style=3D"color:rgb(163,=
21,21)">"af"</span>, <span style=3D"color:rgb(163,21,21)">"a=
g"</span>};</font></div><div style=3D"color:rgb(0,0,0);font-size:14px;=
white-space:pre"><font face=3D"monospace, monospace"> };</font></div><fo=
nt face=3D"monospace, monospace" style=3D"color:rgb(0,0,0);font-size:14px;w=
hite-space:pre"><br></font><div style=3D"color:rgb(0,0,0);font-size:14px;wh=
ite-space:pre"><font face=3D"monospace, monospace"> <span style=3D"color=
:rgb(0,0,255)">auto</span> make_e2 =3D [] {</font></div><div style=3D"color=
:rgb(0,0,0);font-size:14px;white-space:pre"><font face=3D"monospace, monosp=
ace"> <span style=3D"color:rgb(0,0,255)">return</span> floom { <span=
style=3D"color:rgb(163,21,21)">"a"</span>, <span style=3D"color:=
rgb(163,21,21)">"b"</span>, <span style=3D"color:rgb(163,21,21)">=
"c"</span>, <span style=3D"color:rgb(163,21,21)">"d"</s=
pan>, <span style=3D"color:rgb(163,21,21)">"e"</span>, <span styl=
e=3D"color:rgb(163,21,21)">"f"</span>, <span style=3D"color:rgb(1=
63,21,21)">"g"</span>};</font></div><div style=3D"color:rgb(0,0,0=
);font-size:14px;white-space:pre"><font face=3D"monospace, monospace"> }=
;</font></div><font face=3D"monospace, monospace" style=3D"color:rgb(0,0,0)=
;font-size:14px;white-space:pre"><br></font><div style=3D"color:rgb(0,0,0);=
font-size:14px;white-space:pre"><font face=3D"monospace, monospace"> <sp=
an style=3D"color:rgb(0,0,255)">switch</span>(x) {</font></div><div style=
=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><font face=3D"monospac=
e, monospace"> <span style=3D"color:rgb(0,0,255)">case</span> E1:</font>=
</div><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><font =
face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">re=
turn</span> make_e1();</font></div><div style=3D"color:rgb(0,0,0);font-size=
:14px;white-space:pre"><font face=3D"monospace, monospace"> <span style=
=3D"color:rgb(0,0,255)">case</span> E2:</font></div><div style=3D"color:rgb=
(0,0,0);font-size:14px;white-space:pre"><font face=3D"monospace, monospace"=
> <span style=3D"color:rgb(0,0,255)">return</span> make_e2();</font>=
</div><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><font =
face=3D"monospace, monospace"> }</font></div><font face=3D"monospace, mo=
nospace" style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><br></fo=
nt><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><font fac=
e=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">return</s=
pan> make_e2();</font></div><div style=3D"color:rgb(0,0,0);font-size:14px;w=
hite-space:pre"><font face=3D"monospace, monospace">}</font></div><div styl=
e=3D"color:rgb(0,0,0);font-size:14px;white-space:pre;font-family:"Fira=
Mono""><br></div><div style=3D"color:rgb(0,0,0);font-size:14px;white-=
space:pre"><font face=3D"arial, helvetica, sans-serif">Again, consistent, e=
xpressive, preserves warnings in the switch, RVO happens, and *completely o=
bvious* what happens if you pass in an incorrect argument.</font></div><div=
style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><font face=3D"ar=
ial, helvetica, sans-serif"><br></font></div><div style=3D"color:rgb(0,0,0)=
;font-size:14px;white-space:pre"><font face=3D"arial, helvetica, sans-serif=
">assembler from 'gcc -O2' (note the position of the one and only c=
onditional branch):</font></div><div style=3D"color:rgb(0,0,0);font-size:14=
px;white-space:pre"><font face=3D"arial, helvetica, sans-serif"><br></font>=
</div><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><div s=
tyle=3D"line-height:21px"><div><span style=3D"color:rgb(0,128,128)"><font f=
ace=3D"monospace, monospace">make_floom(Values):</font></span></div><div><f=
ont face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)=
">lea</span> <span style=3D"color:rgb(72,100,170)">r11</span>, [<span s=
tyle=3D"color:rgb(72,100,170)">rdi</span>+<span style=3D"color:rgb(9,136,90=
)">16</span>]</font></div><div><font face=3D"monospace, monospace"> =
<span style=3D"color:rgb(0,0,255)">test</span> <span style=3D"color:rgb(=
72,100,170)">esi</span>, <span style=3D"color:rgb(72,100,170)">esi</span></=
font></div><div><font face=3D"monospace, monospace"> <span style=3D"=
color:rgb(0,0,255)">lea</span> <span style=3D"color:rgb(72,100,170)">ra=
x</span>, [<span style=3D"color:rgb(72,100,170)">rdi</span>+<span style=3D"=
color:rgb(9,136,90)">208</span>]</font></div><div><font face=3D"monospace, =
monospace"> <span style=3D"color:rgb(0,0,255)">lea</span> <span =
style=3D"color:rgb(72,100,170)">rdx</span>, [<span style=3D"color:rgb(72,10=
0,170)">rdi</span>+<span style=3D"color:rgb(9,136,90)">176</span>]</font></=
div><div><font face=3D"monospace, monospace"> <span style=3D"color:r=
gb(0,0,255)">lea</span> <span style=3D"color:rgb(72,100,170)">rcx</span=
>, [<span style=3D"color:rgb(72,100,170)">rdi</span>+<span style=3D"color:r=
gb(9,136,90)">144</span>]</font></div><div><font face=3D"monospace, monospa=
ce"> <span style=3D"color:rgb(0,0,255)">lea</span> <span style=
=3D"color:rgb(72,100,170)">r8</span>, [<span style=3D"color:rgb(72,100,170)=
">rdi</span>+<span style=3D"color:rgb(9,136,90)">112</span>]</font></div><d=
iv><font face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0=
,255)">lea</span> <span style=3D"color:rgb(72,100,170)">r9</span>, [<sp=
an style=3D"color:rgb(72,100,170)">rdi</span>+<span style=3D"color:rgb(9,13=
6,90)">80</span>]</font></div><div><font face=3D"monospace, monospace"> =
<span style=3D"color:rgb(0,0,255)">lea</span> <span style=3D"color:=
rgb(72,100,170)">r10</span>, [<span style=3D"color:rgb(72,100,170)">rdi</sp=
an>+<span style=3D"color:rgb(9,136,90)">48</span>]</font></div><div><font f=
ace=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">mov=
</span> <span style=3D"color:rgb(128,128,128)">QWORD</span> <span style=
=3D"color:rgb(128,128,128)">PTR</span> [<span style=3D"color:rgb(72,100,170=
)">rdi</span>], <span style=3D"color:rgb(72,100,170)">r11</span></font></di=
v><div><font face=3D"monospace, monospace"> <span style=3D"color:rgb=
(0,0,255)">je</span> <span style=3D"color:rgb(0,128,128)">.L18</span><=
/font></div><div><font face=3D"monospace, monospace"> <span style=3D=
"color:rgb(0,0,255)">mov</span> <span style=3D"color:rgb(72,100,170)">e=
si</span>, <span style=3D"color:rgb(9,136,90)">97</span></font></div><div><=
font face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255=
)">mov</span> <span style=3D"color:rgb(128,128,128)">QWORD</span> <span=
style=3D"color:rgb(128,128,128)">PTR</span> [<span style=3D"color:rgb(72,1=
00,170)">rdi</span>+<span style=3D"color:rgb(9,136,90)">32</span>], <span s=
tyle=3D"color:rgb(72,100,170)">r10</span></font></div><div><font face=3D"mo=
nospace, monospace"> <span style=3D"color:rgb(0,0,255)">mov</span> =
<span style=3D"color:rgb(72,100,170)">r10d</span>, <span style=3D"color:=
rgb(9,136,90)">98</span></font></div><div><font face=3D"monospace, monospac=
e"> <span style=3D"color:rgb(0,0,255)">mov</span> <span style=3D=
"color:rgb(128,128,128)">WORD</span> <span style=3D"color:rgb(128,128,128)"=
>PTR</span> [<span style=3D"color:rgb(72,100,170)">rdi</span>+<span style=
=3D"color:rgb(9,136,90)">16</span>], <span style=3D"color:rgb(72,100,170)">=
si</span></font></div><div><font face=3D"monospace, monospace"> <spa=
n style=3D"color:rgb(0,0,255)">mov</span> <span style=3D"color:rgb(128,=
128,128)">WORD</span> <span style=3D"color:rgb(128,128,128)">PTR</span> [<s=
pan style=3D"color:rgb(72,100,170)">rdi</span>+<span style=3D"color:rgb(9,1=
36,90)">48</span>], <span style=3D"color:rgb(72,100,170)">r10w</span></font=
></div><div><font face=3D"monospace, monospace"> <span style=3D"colo=
r:rgb(0,0,255)">mov</span> <span style=3D"color:rgb(72,100,170)">r11d</=
span>, <span style=3D"color:rgb(9,136,90)">99</span></font></div><div><font=
face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">m=
ov</span> <span style=3D"color:rgb(128,128,128)">QWORD</span> <span sty=
le=3D"color:rgb(128,128,128)">PTR</span> [<span style=3D"color:rgb(72,100,1=
70)">rdi</span>+<span style=3D"color:rgb(9,136,90)">64</span>], <span style=
=3D"color:rgb(72,100,170)">r9</span></font></div><div><font face=3D"monospa=
ce, monospace"> <span style=3D"color:rgb(0,0,255)">mov</span> <s=
pan style=3D"color:rgb(128,128,128)">QWORD</span> <span style=3D"color:rgb(=
128,128,128)">PTR</span> [<span style=3D"color:rgb(72,100,170)">rdi</span>+=
<span style=3D"color:rgb(9,136,90)">96</span>], <span style=3D"color:rgb(72=
,100,170)">r8</span></font></div><div><font face=3D"monospace, monospace"> =
<span style=3D"color:rgb(0,0,255)">mov</span> <span style=3D"col=
or:rgb(72,100,170)">esi</span>, <span style=3D"color:rgb(9,136,90)">100</sp=
an></font></div><div><font face=3D"monospace, monospace"> <span styl=
e=3D"color:rgb(0,0,255)">mov</span> <span style=3D"color:rgb(72,100,170=
)">r8d</span>, <span style=3D"color:rgb(9,136,90)">101</span></font></div><=
div><font face=3D"monospace, monospace"> <span style=3D"color:rgb(0,=
0,255)">mov</span> <span style=3D"color:rgb(72,100,170)">r9d</span>, <s=
pan style=3D"color:rgb(9,136,90)">102</span></font></div><div><font face=3D=
"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">mov</span=
> <span style=3D"color:rgb(72,100,170)">r10d</span>, <span style=3D"col=
or:rgb(9,136,90)">103</span></font></div><div><font face=3D"monospace, mono=
space"> <span style=3D"color:rgb(0,0,255)">mov</span> <span styl=
e=3D"color:rgb(128,128,128)">QWORD</span> <span style=3D"color:rgb(128,128,=
128)">PTR</span> [<span style=3D"color:rgb(72,100,170)">rdi</span>+<span st=
yle=3D"color:rgb(9,136,90)">192</span>], <span style=3D"color:rgb(72,100,17=
0)">rax</span></font></div><div><font face=3D"monospace, monospace"> =
<span style=3D"color:rgb(0,0,255)">mov</span> <span style=3D"color:rgb=
(128,128,128)">QWORD</span> <span style=3D"color:rgb(128,128,128)">PTR</spa=
n> [<span style=3D"color:rgb(72,100,170)">rdi</span>+<span style=3D"color:r=
gb(9,136,90)">8</span>], <span style=3D"color:rgb(9,136,90)">1</span></font=
></div><div><font face=3D"monospace, monospace"> <span style=3D"colo=
r:rgb(0,0,255)">mov</span> <span style=3D"color:rgb(72,100,170)">rax</s=
pan>, <span style=3D"color:rgb(72,100,170)">rdi</span></font></div><div><fo=
nt face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)"=
>mov</span> <span style=3D"color:rgb(128,128,128)">QWORD</span> <span s=
tyle=3D"color:rgb(128,128,128)">PTR</span> [<span style=3D"color:rgb(72,100=
,170)">rdi</span>+<span style=3D"color:rgb(9,136,90)">40</span>], <span sty=
le=3D"color:rgb(9,136,90)">1</span></font></div><div><font face=3D"monospac=
e, monospace"> <span style=3D"color:rgb(0,0,255)">mov</span> <sp=
an style=3D"color:rgb(128,128,128)">QWORD</span> <span style=3D"color:rgb(1=
28,128,128)">PTR</span> [<span style=3D"color:rgb(72,100,170)">rdi</span>+<=
span style=3D"color:rgb(9,136,90)">72</span>], <span style=3D"color:rgb(9,1=
36,90)">1</span></font></div><div><font face=3D"monospace, monospace"> =
<span style=3D"color:rgb(0,0,255)">mov</span> <span style=3D"color:r=
gb(128,128,128)">WORD</span> <span style=3D"color:rgb(128,128,128)">PTR</sp=
an> [<span style=3D"color:rgb(72,100,170)">rdi</span>+<span style=3D"color:=
rgb(9,136,90)">80</span>], <span style=3D"color:rgb(72,100,170)">r11w</span=
></font></div><div><font face=3D"monospace, monospace"> <span style=
=3D"color:rgb(0,0,255)">mov</span> <span style=3D"color:rgb(128,128,128=
)">QWORD</span> <span style=3D"color:rgb(128,128,128)">PTR</span> [<span st=
yle=3D"color:rgb(72,100,170)">rdi</span>+<span style=3D"color:rgb(9,136,90)=
">104</span>], <span style=3D"color:rgb(9,136,90)">1</span></font></div><di=
v><font face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,=
255)">mov</span> <span style=3D"color:rgb(128,128,128)">WORD</span> <sp=
an style=3D"color:rgb(128,128,128)">PTR</span> [<span style=3D"color:rgb(72=
,100,170)">rdi</span>+<span style=3D"color:rgb(9,136,90)">112</span>], <spa=
n style=3D"color:rgb(72,100,170)">si</span></font></div><div><font face=3D"=
monospace, monospace"> <span style=3D"color:rgb(0,0,255)">mov</span>=
<span style=3D"color:rgb(128,128,128)">QWORD</span> <span style=3D"col=
or:rgb(128,128,128)">PTR</span> [<span style=3D"color:rgb(72,100,170)">rdi<=
/span>+<span style=3D"color:rgb(9,136,90)">128</span>], <span style=3D"colo=
r:rgb(72,100,170)">rcx</span></font></div><div><font face=3D"monospace, mon=
ospace"> <span style=3D"color:rgb(0,0,255)">mov</span> <span sty=
le=3D"color:rgb(128,128,128)">QWORD</span> <span style=3D"color:rgb(128,128=
,128)">PTR</span> [<span style=3D"color:rgb(72,100,170)">rdi</span>+<span s=
tyle=3D"color:rgb(9,136,90)">136</span>], <span style=3D"color:rgb(9,136,90=
)">1</span></font></div><div><font face=3D"monospace, monospace"> <s=
pan style=3D"color:rgb(0,0,255)">mov</span> <span style=3D"color:rgb(12=
8,128,128)">WORD</span> <span style=3D"color:rgb(128,128,128)">PTR</span> [=
<span style=3D"color:rgb(72,100,170)">rdi</span>+<span style=3D"color:rgb(9=
,136,90)">144</span>], <span style=3D"color:rgb(72,100,170)">r8w</span></fo=
nt></div><div><font face=3D"monospace, monospace"> <span style=3D"co=
lor:rgb(0,0,255)">mov</span> <span style=3D"color:rgb(128,128,128)">QWO=
RD</span> <span style=3D"color:rgb(128,128,128)">PTR</span> [<span style=3D=
"color:rgb(72,100,170)">rdi</span>+<span style=3D"color:rgb(9,136,90)">160<=
/span>], <span style=3D"color:rgb(72,100,170)">rdx</span></font></div><div>=
<font face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,25=
5)">mov</span> <span style=3D"color:rgb(128,128,128)">QWORD</span> <spa=
n style=3D"color:rgb(128,128,128)">PTR</span> [<span style=3D"color:rgb(72,=
100,170)">rdi</span>+<span style=3D"color:rgb(9,136,90)">168</span>], <span=
style=3D"color:rgb(9,136,90)">1</span></font></div><div><font face=3D"mono=
space, monospace"> <span style=3D"color:rgb(0,0,255)">mov</span> =
<span style=3D"color:rgb(128,128,128)">WORD</span> <span style=3D"color:rg=
b(128,128,128)">PTR</span> [<span style=3D"color:rgb(72,100,170)">rdi</span=
>+<span style=3D"color:rgb(9,136,90)">176</span>], <span style=3D"color:rgb=
(72,100,170)">r9w</span></font></div><div><font face=3D"monospace, monospac=
e"> <span style=3D"color:rgb(0,0,255)">mov</span> <span style=3D=
"color:rgb(128,128,128)">QWORD</span> <span style=3D"color:rgb(128,128,128)=
">PTR</span> [<span style=3D"color:rgb(72,100,170)">rdi</span>+<span style=
=3D"color:rgb(9,136,90)">200</span>], <span style=3D"color:rgb(9,136,90)">1=
</span></font></div><div><font face=3D"monospace, monospace"> <span =
style=3D"color:rgb(0,0,255)">mov</span> <span style=3D"color:rgb(128,12=
8,128)">WORD</span> <span style=3D"color:rgb(128,128,128)">PTR</span> [<spa=
n style=3D"color:rgb(72,100,170)">rdi</span>+<span style=3D"color:rgb(9,136=
,90)">208</span>], <span style=3D"color:rgb(72,100,170)">r10w</span></font>=
</div><div><font face=3D"monospace, monospace"> <span style=3D"color=
:rgb(0,0,255)">ret</span></font></div><div><span style=3D"color:rgb(0,128,1=
28)"><font face=3D"monospace, monospace">.L18:</font></span></div><div><fon=
t face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">=
mov</span> <span style=3D"color:rgb(72,100,170)">r11d</span>, <span sty=
le=3D"color:rgb(9,136,90)">24929</span></font></div><div><font face=3D"mono=
space, monospace"> <span style=3D"color:rgb(0,0,255)">mov</span> =
<span style=3D"color:rgb(128,128,128)">QWORD</span> <span style=3D"color:r=
gb(128,128,128)">PTR</span> [<span style=3D"color:rgb(72,100,170)">rdi</spa=
n>+<span style=3D"color:rgb(9,136,90)">32</span>], <span style=3D"color:rgb=
(72,100,170)">r10</span></font></div><div><font face=3D"monospace, monospac=
e"> <span style=3D"color:rgb(0,0,255)">mov</span> <span style=3D=
"color:rgb(72,100,170)">esi</span>, <span style=3D"color:rgb(9,136,90)">251=
85</span></font></div><div><font face=3D"monospace, monospace"> <spa=
n style=3D"color:rgb(0,0,255)">mov</span> <span style=3D"color:rgb(128,=
128,128)">WORD</span> <span style=3D"color:rgb(128,128,128)">PTR</span> [<s=
pan style=3D"color:rgb(72,100,170)">rdi</span>+<span style=3D"color:rgb(9,1=
36,90)">16</span>], <span style=3D"color:rgb(72,100,170)">r11w</span></font=
></div><div><font face=3D"monospace, monospace"> <span style=3D"colo=
r:rgb(0,0,255)">mov</span> <span style=3D"color:rgb(128,128,128)">QWORD=
</span> <span style=3D"color:rgb(128,128,128)">PTR</span> [<span style=3D"c=
olor:rgb(72,100,170)">rdi</span>+<span style=3D"color:rgb(9,136,90)">64</sp=
an>], <span style=3D"color:rgb(72,100,170)">r9</span></font></div><div><fon=
t face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">=
mov</span> <span style=3D"color:rgb(72,100,170)">r10d</span>, <span sty=
le=3D"color:rgb(9,136,90)">25697</span></font></div><div><font face=3D"mono=
space, monospace"> <span style=3D"color:rgb(0,0,255)">mov</span> =
<span style=3D"color:rgb(72,100,170)">r9d</span>, <span style=3D"color:rgb=
(9,136,90)">25441</span></font></div><div><font face=3D"monospace, monospac=
e"> <span style=3D"color:rgb(0,0,255)">mov</span> <span style=3D=
"color:rgb(128,128,128)">QWORD</span> <span style=3D"color:rgb(128,128,128)=
">PTR</span> [<span style=3D"color:rgb(72,100,170)">rdi</span>+<span style=
=3D"color:rgb(9,136,90)">128</span>], <span style=3D"color:rgb(72,100,170)"=
>rcx</span></font></div><div><font face=3D"monospace, monospace"> <s=
pan style=3D"color:rgb(0,0,255)">mov</span> <span style=3D"color:rgb(72=
,100,170)">r11d</span>, <span style=3D"color:rgb(9,136,90)">25953</span></f=
ont></div><div><font face=3D"monospace, monospace"> <span style=3D"c=
olor:rgb(0,0,255)">mov</span> <span style=3D"color:rgb(128,128,128)">QW=
ORD</span> <span style=3D"color:rgb(128,128,128)">PTR</span> [<span style=
=3D"color:rgb(72,100,170)">rdi</span>+<span style=3D"color:rgb(9,136,90)">1=
60</span>], <span style=3D"color:rgb(72,100,170)">rdx</span></font></div><d=
iv><font face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0=
,255)">mov</span> <span style=3D"color:rgb(72,100,170)">ecx</span>, <sp=
an style=3D"color:rgb(9,136,90)">26465</span></font></div><div><font face=
=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">mov</s=
pan> <span style=3D"color:rgb(72,100,170)">edx</span>, <span style=3D"c=
olor:rgb(9,136,90)">26209</span></font></div><div><font face=3D"monospace, =
monospace"> <span style=3D"color:rgb(0,0,255)">mov</span> <span =
style=3D"color:rgb(128,128,128)">QWORD</span> <span style=3D"color:rgb(128,=
128,128)">PTR</span> [<span style=3D"color:rgb(72,100,170)">rdi</span>+<spa=
n style=3D"color:rgb(9,136,90)">192</span>], <span style=3D"color:rgb(72,10=
0,170)">rax</span></font></div><div><font face=3D"monospace, monospace"> =
<span style=3D"color:rgb(0,0,255)">mov</span> <span style=3D"color=
:rgb(128,128,128)">QWORD</span> <span style=3D"color:rgb(128,128,128)">PTR<=
/span> [<span style=3D"color:rgb(72,100,170)">rdi</span>+<span style=3D"col=
or:rgb(9,136,90)">8</span>], <span style=3D"color:rgb(9,136,90)">2</span></=
font></div><div><font face=3D"monospace, monospace"> <span style=3D"=
color:rgb(0,0,255)">mov</span> <span style=3D"color:rgb(72,100,170)">ra=
x</span>, <span style=3D"color:rgb(72,100,170)">rdi</span></font></div><div=
><font face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,2=
55)">mov</span> <span style=3D"color:rgb(0,128,128)">BYTE</span> <span =
style=3D"color:rgb(128,128,128)">PTR</span> [<span style=3D"color:rgb(72,10=
0,170)">rdi</span>+<span style=3D"color:rgb(9,136,90)">18</span>], <span st=
yle=3D"color:rgb(9,136,90)">0</span></font></div><div><font face=3D"monospa=
ce, monospace"> <span style=3D"color:rgb(0,0,255)">mov</span> <s=
pan style=3D"color:rgb(128,128,128)">WORD</span> <span style=3D"color:rgb(1=
28,128,128)">PTR</span> [<span style=3D"color:rgb(72,100,170)">rdi</span>+<=
span style=3D"color:rgb(9,136,90)">48</span>], <span style=3D"color:rgb(72,=
100,170)">si</span></font></div><div><font face=3D"monospace, monospace"> =
<span style=3D"color:rgb(0,0,255)">mov</span> <span style=3D"colo=
r:rgb(128,128,128)">QWORD</span> <span style=3D"color:rgb(128,128,128)">PTR=
</span> [<span style=3D"color:rgb(72,100,170)">rdi</span>+<span style=3D"co=
lor:rgb(9,136,90)">40</span>], <span style=3D"color:rgb(9,136,90)">2</span>=
</font></div><div><font face=3D"monospace, monospace"> <span style=
=3D"color:rgb(0,0,255)">mov</span> <span style=3D"color:rgb(0,128,128)"=
>BYTE</span> <span style=3D"color:rgb(128,128,128)">PTR</span> [<span style=
=3D"color:rgb(72,100,170)">rdi</span>+<span style=3D"color:rgb(9,136,90)">5=
0</span>], <span style=3D"color:rgb(9,136,90)">0</span></font></div><div><f=
ont face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)=
">mov</span> <span style=3D"color:rgb(128,128,128)">WORD</span> <span s=
tyle=3D"color:rgb(128,128,128)">PTR</span> [<span style=3D"color:rgb(72,100=
,170)">rdi</span>+<span style=3D"color:rgb(9,136,90)">80</span>], <span sty=
le=3D"color:rgb(72,100,170)">r9w</span></font></div><div><font face=3D"mono=
space, monospace"> <span style=3D"color:rgb(0,0,255)">mov</span> =
<span style=3D"color:rgb(128,128,128)">QWORD</span> <span style=3D"color:r=
gb(128,128,128)">PTR</span> [<span style=3D"color:rgb(72,100,170)">rdi</spa=
n>+<span style=3D"color:rgb(9,136,90)">72</span>], <span style=3D"color:rgb=
(9,136,90)">2</span></font></div><div><font face=3D"monospace, monospace"> =
<span style=3D"color:rgb(0,0,255)">mov</span> <span style=3D"col=
or:rgb(0,128,128)">BYTE</span> <span style=3D"color:rgb(128,128,128)">PTR</=
span> [<span style=3D"color:rgb(72,100,170)">rdi</span>+<span style=3D"colo=
r:rgb(9,136,90)">82</span>], <span style=3D"color:rgb(9,136,90)">0</span></=
font></div><div><font face=3D"monospace, monospace"> <span style=3D"=
color:rgb(0,0,255)">mov</span> <span style=3D"color:rgb(128,128,128)">Q=
WORD</span> <span style=3D"color:rgb(128,128,128)">PTR</span> [<span style=
=3D"color:rgb(72,100,170)">rdi</span>+<span style=3D"color:rgb(9,136,90)">9=
6</span>], <span style=3D"color:rgb(72,100,170)">r8</span></font></div><div=
><font face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,2=
55)">mov</span> <span style=3D"color:rgb(128,128,128)">WORD</span> <spa=
n style=3D"color:rgb(128,128,128)">PTR</span> [<span style=3D"color:rgb(72,=
100,170)">rdi</span>+<span style=3D"color:rgb(9,136,90)">112</span>], <span=
style=3D"color:rgb(72,100,170)">r10w</span></font></div><div><font face=3D=
"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">mov</span=
> <span style=3D"color:rgb(128,128,128)">QWORD</span> <span style=3D"co=
lor:rgb(128,128,128)">PTR</span> [<span style=3D"color:rgb(72,100,170)">rdi=
</span>+<span style=3D"color:rgb(9,136,90)">104</span>], <span style=3D"col=
or:rgb(9,136,90)">2</span></font></div><div><font face=3D"monospace, monosp=
ace"> <span style=3D"color:rgb(0,0,255)">mov</span> <span style=
=3D"color:rgb(0,128,128)">BYTE</span> <span style=3D"color:rgb(128,128,128)=
">PTR</span> [<span style=3D"color:rgb(72,100,170)">rdi</span>+<span style=
=3D"color:rgb(9,136,90)">114</span>], <span style=3D"color:rgb(9,136,90)">0=
</span></font></div><div><font face=3D"monospace, monospace"> <span =
style=3D"color:rgb(0,0,255)">mov</span> <span style=3D"color:rgb(128,12=
8,128)">WORD</span> <span style=3D"color:rgb(128,128,128)">PTR</span> [<spa=
n style=3D"color:rgb(72,100,170)">rdi</span>+<span style=3D"color:rgb(9,136=
,90)">144</span>], <span style=3D"color:rgb(72,100,170)">r11w</span></font>=
</div><div><font face=3D"monospace, monospace"> <span style=3D"color=
:rgb(0,0,255)">mov</span> <span style=3D"color:rgb(128,128,128)">QWORD<=
/span> <span style=3D"color:rgb(128,128,128)">PTR</span> [<span style=3D"co=
lor:rgb(72,100,170)">rdi</span>+<span style=3D"color:rgb(9,136,90)">136</sp=
an>], <span style=3D"color:rgb(9,136,90)">2</span></font></div><div><font f=
ace=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">mov=
</span> <span style=3D"color:rgb(0,128,128)">BYTE</span> <span style=3D=
"color:rgb(128,128,128)">PTR</span> [<span style=3D"color:rgb(72,100,170)">=
rdi</span>+<span style=3D"color:rgb(9,136,90)">146</span>], <span style=3D"=
color:rgb(9,136,90)">0</span></font></div><div><font face=3D"monospace, mon=
ospace"> <span style=3D"color:rgb(0,0,255)">mov</span> <span sty=
le=3D"color:rgb(128,128,128)">WORD</span> <span style=3D"color:rgb(128,128,=
128)">PTR</span> [<span style=3D"color:rgb(72,100,170)">rdi</span>+<span st=
yle=3D"color:rgb(9,136,90)">176</span>], <span style=3D"color:rgb(72,100,17=
0)">dx</span></font></div><div><font face=3D"monospace, monospace"> =
<span style=3D"color:rgb(0,0,255)">mov</span> <span style=3D"color:rgb(=
128,128,128)">QWORD</span> <span style=3D"color:rgb(128,128,128)">PTR</span=
> [<span style=3D"color:rgb(72,100,170)">rdi</span>+<span style=3D"color:rg=
b(9,136,90)">168</span>], <span style=3D"color:rgb(9,136,90)">2</span></fon=
t></div><div><font face=3D"monospace, monospace"> <span style=3D"col=
or:rgb(0,0,255)">mov</span> <span style=3D"color:rgb(0,128,128)">BYTE</=
span> <span style=3D"color:rgb(128,128,128)">PTR</span> [<span style=3D"col=
or:rgb(72,100,170)">rdi</span>+<span style=3D"color:rgb(9,136,90)">178</spa=
n>], <span style=3D"color:rgb(9,136,90)">0</span></font></div><div><font fa=
ce=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">mov<=
/span> <span style=3D"color:rgb(128,128,128)">WORD</span> <span style=
=3D"color:rgb(128,128,128)">PTR</span> [<span style=3D"color:rgb(72,100,170=
)">rdi</span>+<span style=3D"color:rgb(9,136,90)">208</span>], <span style=
=3D"color:rgb(72,100,170)">cx</span></font></div><div><font face=3D"monospa=
ce, monospace"> <span style=3D"color:rgb(0,0,255)">mov</span> <s=
pan style=3D"color:rgb(128,128,128)">QWORD</span> <span style=3D"color:rgb(=
128,128,128)">PTR</span> [<span style=3D"color:rgb(72,100,170)">rdi</span>+=
<span style=3D"color:rgb(9,136,90)">200</span>], <span style=3D"color:rgb(9=
,136,90)">2</span></font></div><div><font face=3D"monospace, monospace"> =
<span style=3D"color:rgb(0,0,255)">mov</span> <span style=3D"color=
:rgb(0,128,128)">BYTE</span> <span style=3D"color:rgb(128,128,128)">PTR</sp=
an> [<span style=3D"color:rgb(72,100,170)">rdi</span>+<span style=3D"color:=
rgb(9,136,90)">210</span>], <span style=3D"color:rgb(9,136,90)">0</span></f=
ont></div><div><font face=3D"monospace, monospace"> <span style=3D"c=
olor:rgb(0,0,255)">ret</span></font></div><div style=3D"font-family:"F=
ira Mono""><span style=3D"color:rgb(0,0,255)"><br></span></div></div><=
/div><div><font face=3D"arial, helvetica, sans-serif"><a href=3D"https://go=
dbolt.org/g/X2A5Jj"><font color=3D"#000000"><span style=3D"font-size:14px;w=
hite-space:pre">https://godbolt.org/g/X2A5Jj</span></font><br></a></font></=
div><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><font fa=
ce=3D"arial, helvetica, sans-serif"><br></font></div></div></div></div><div=
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 20 December 2017 a=
t 18:21, Richard Hodges <span dir=3D"ltr"><<a href=3D"mailto:hodges.r@gm=
ail.com" target=3D"_blank">hodges.r@gmail.com</a>></span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><span style=3D=
"font-size:12.8px">> Since the function is never called,=C2=A0</span><sp=
an style=3D"font-size:12.8px">the fact that it does not return or returns g=
arbage simply cannot affect the=C2=A0</span><span style=3D"font-size:12.8px=
">program's running. Therefore, by this definition, this program will r=
un=C2=A0</span><span style=3D"font-size:12.8px">correctly.</span><br><div><=
span style=3D"font-size:12.8px"><br></span></div></span><div><span style=3D=
"font-size:12.8px">A function that is never called either,</span></div><div=
><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font=
-size:12.8px">* has no place in the program in the first place. Just delete=
it, or</span></div><div><span style=3D"font-size:12.8px"><br></span></div>=
<div><span style=3D"font-size:12.8px">* may be called in some later modific=
ation to the program, so it had better be correct, by the strictest definit=
ion of the term.</span></div><div><span style=3D"font-size:12.8px"><br></sp=
an></div><div><span style=3D"font-size:12.8px">This is another straw-man.</=
span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><spa=
n style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size=
:12.8px"><br></span></div></div><div class=3D"HOEnZb"><div class=3D"h5"><di=
v class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 20 December 2017 =
at 18:17, Richard Hodges <span dir=3D"ltr"><<a href=3D"mailto:hodges.r@g=
mail.com" target=3D"_blank">hodges.r@gmail.com</a>></span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr">>=C2=A0<span style=3D"font-=
size:12.8px">Do we need to bring the discussion on signed integer overflow =
and shifting=C2=A0</span><span style=3D"font-size:12.8px">again?=C2=A0</spa=
n><div><span style=3D"font-size:12.8px"><br></span></div><div><span style=
=3D"font-size:12.8px">No, what we're going to do is keep the thread on =
topic. The topic is around allowing a function that advertises that it retu=
rns a value to not return a value.</span></div><div><span style=3D"font-siz=
e:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">Show me a =
function that performs better when there is a control path that does not re=
turn a value that does not produce code at least as good when written so th=
at all control paths return a value.</span></div><div><span style=3D"font-s=
ize:12.8px"><br></span></div></div><div class=3D"gmail_extra"><br><div clas=
s=3D"gmail_quote">On 20 December 2017 at 18:13, Thiago Macieira <span dir=
=3D"ltr"><<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiag=
o@macieira.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><spa=
n>On quarta-feira, 20 de dezembro de 2017 07:59:42 PST Richard Hodges wrote=
:<br>
> I am still waiting for code that compiles better when UB is involved g=
uys.<br>
<br>
</span>Do we need to bring the discussion on signed integer overflow and sh=
ifting<br>
again? I thought I was quite clear that the code was faster in both cases.<=
br>
<br>
More importantly, UB is *not* involved. That's the entire point. UB can=
only<br>
happen if the function is misused in the first place. If that happens, the<=
br>
result you get is nonsense, regardless of whether that was caused by you or=
by<br>
the compiler.<span><br>
<span><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
</span><span>--<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.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></span>To view this discussion on the web visit <a href=3D"https://g=
roups.google.com/a/isocpp.org/d/msgid/std-proposals/1806941.Rp44EGdGQP%40tj=
maciei-mobl1" rel=3D"noreferrer" target=3D"_blank">https://groups.google.co=
m/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/1806941.Rp44EGdGQP%40tjmacie=
i<wbr>-mobl1</a>.<br>
</blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></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/CALvx3hYbX9ftMDFDnSGP9wK-0ZC43qXfcqVU=
z-nZpc3hZ9nMXw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hYbX9ftMDFD=
nSGP9wK-0ZC43qXfcqVUz-nZpc3hZ9nMXw%40mail.gmail.com</a>.<br />
--94eb2c05e33cb79ab30560c93e32--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 20 Dec 2017 17:55:40 +0000
Raw View
--001a114b3186c440740560c94a82
Content-Type: text/plain; charset="UTF-8"
On 20 Dec 2017 17:02, "Richard Hodges" <hodges.r@gmail.com> wrote:
> The churn comes from functions that don't have a return or an annotation
that that is intended,
We have already seen that these "intended no return" functions result in
worse code. This is precisely because the compiler cannot deduce intent. In
every other conversation about UB, there would be unanimous agreement that
UB is to be avoided.
For some unfathomable reason, on this issue, some wish to defy the evidence
before them and continue to demand the right to write UB functions without
a diagnostic - to the detriment of the vast majority who simply want
functions to do defined things.
How do I know that the majority want functions to do defined things?
Because the universally accepted process for writing and testing code is to
write tests. What do tests do? They verify the claims of the function's
author. What do UB functions do? They refuse to make any claims. Is that
testable? No. Is it useful? Quad erat demonstrandum, no.
That is completely incorrect. Functions with undefined behavior are fully
testable; one has only to honor their (narrow) contact.
> and the halting problem issue is that a compiler doesn't know which of those
functions are used and which ones unused
Totally irrelevant. The compiler doesn't know or care about the colour of
my socks either. Code either has defined behaviour, or it's a useless
liability.
Code with narrow contracts is useful.
> Which leads to false positives.
All UB is a positively an error. The correct (and performant) thing to do
is fix it.
Only if it is encountered.
> but since it's not, and there's existing valid code and breakage thereof
to consider
Do you remember when we moved from K&R function declarations to ANSI
function declarations? I do. Everyone coped just fine. No-one demanded the
right to continue to write
func(x,y)
double x;
int y;
{
if (x > 0)
return y;
}
**this** is the origin on the UB on non-specified returns. Almost
everything else got fixed. This got forgotten.
> trying to mandate a diagnostic for a missing return is fighting an uphill
battle.
One of my engineers, an experienced guy with 20 years writing c++, spent
the first half of today diagnosing something that turned out to be a result
of exactly this. Forgetting to return the shared_ptr he had created. In a
function he had written 30 minutes prior. The crash occurred in thread 3,
nowhere near the offending code that was executed in thread 1.
So you're admitting that you don't use Werror=return-type nor
fsanitize=return? And yet you want to force this into the language?
Half a day. Over something the compiler could, no, *should* have told him
on the first compile.
This happens a lot, all over the world, every day. The combined loss of
productivity easily outweighs the minor inconvenience of fixing a few
lazily-written, demonstrably suboptimal, leaf functions.
You and the current committee stance on this, are wrong. It is a problem.
Not all developers are as vociferous as me, so why don't you ask the others
whether they'd prefer to have this? Ask, not tell.
Ask the gcc developers whether they have considered making Wreturn-type a
default error.
On 20 December 2017 at 17:36, Ville Voutilainen <ville.voutilainen@gmail.com
> wrote:
> On 20 December 2017 at 18:17, Jake Arkinstall <jake.arkinstall@gmail.com>
> wrote:
> >
> >
> > On 20 Dec 2017 15:55, "Ville Voutilainen" <ville.voutilainen@gmail.com>
> > wrote:
> >
> > VV: We could go towards a direction of making the lack of return
> > ill-formed. Compilers already diagnose it, by default.
> > CC: But how do you know you call the function?
> > VV: I don't. That runs into the Halting Problem. This would therefore
> > cause unnecessary churn in valid code. Consider
> > the idea withdrawn. Let's kill it if it comes up in the form of a
> proposal.
> > CC: Agreed.
> >
> >
> > Wow. Was there someone at the meeting holding up a sign saying "[citation
> > needed]" when the halting problem was brought up? Adding something at the
> > end of functions that have a non-returning branch (whether accessible or
> > not) is hardly solving the halting problem or causing churn. It never
> gets
> > run, assuming the function behaved beforehand.
>
> The churn comes from functions that don't have a return or an
> annotation that that is intended,
> and the halting problem issue is that a compiler doesn't know which of
> those functions are used
> and which ones unused. Which leads to false positives. Were this a
> from-scratch matter, we might
> well decide to diagnose the lack of return, but since it's not, and
> there's existing valid code
> and breakage thereof to consider, trying to mandate a diagnostic for a
> missing return is fighting
> an uphill battle.
>
> You are all more than welcome to continue to misunderstand that or
> claim that such considerations
> are brought up by idiots, but if you choose to do so, I honestly
> wonder why this thread exists, considering
> that there seems to be a strong effort by the supposed proponents of
> the idea to convince everybody
> else that they don't really want this idea to succeed.
>
> --
>
> 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/is
> ocpp.org/d/msgid/std-proposals/CAFk2RUaxu_thbrRbqxL-
> nuvZkQnVvKP1rfE_XB%2B342AcLUcrag%40mail.gmail.com.
>
--
You received this message because you are subscribed to a topic in the
Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/
isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
To unsubscribe from this group and all its topics, 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/CALvx3haEDQgDKne-
9UtVWY7jGkhbgoXB6HZT0vQSFAiW13NJmg%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3haEDQgDKne-9UtVWY7jGkhbgoXB6HZT0vQSFAiW13NJmg%40mail.gmail.com?utm_medium=email&utm_source=footer>
..
--
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/CAJnLdOZZGXq%3DE7Gtsv7Qo10%3DfTkN4OY7Yke4MaZZm3Ku1qpZ0g%40mail.gmail.com.
--001a114b3186c440740560c94a82
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On 20 Dec 2017 17:02, "Richard Hodges" <<a href=3D"m=
ailto:hodges.r@gmail.com">hodges.r@gmail.com</a>> wrote:<br type=3D"attr=
ibution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"quoted-tex=
t">>=C2=A0<span style=3D"font-size:12.8px">The churn comes from function=
s that don't have a return or an=C2=A0</span><span style=3D"font-size:1=
2.8px">annotation that that is intended,</span><div><span style=3D"font-siz=
e:12.8px"><br></span></div></div><div><span style=3D"font-size:12.8px">We h=
ave already seen that these "intended no return" functions result=
in worse code. This is precisely because the compiler cannot deduce intent=
.. In every other conversation about UB, there would be unanimous agreement =
that UB is to be avoided.</span></div><div><span style=3D"font-size:12.8px"=
><br></span></div><div><span style=3D"font-size:12.8px">For some unfathomab=
le reason, on this issue, some wish to defy the evidence before them and co=
ntinue to demand the right to write UB functions without a diagnostic - to =
the detriment of the vast majority who simply want functions to do defined =
things.</span></div><div><span style=3D"font-size:12.8px"><br></span></div>=
<div><span style=3D"font-size:12.8px">How do I know that the majority want =
functions to do defined things? Because the universally accepted process fo=
r writing and testing code is to write tests. What do tests do? They verify=
the claims of the function's author. What do UB functions do? They ref=
use to make any claims. Is that testable? No. Is it useful? Quad erat demon=
strandum, no.</span></div><div class=3D"quoted-text"><div><span style=3D"fo=
nt-size:12.8px"></span></div></div></div></blockquote></div></div></div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">That is completely incorrect. Fu=
nctions with undefined behavior are fully testable; one has only to honor t=
heir (narrow) contact.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"a=
uto"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote clas=
s=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div class=3D"quoted-text"><div><span style=3D"fo=
nt-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">>=
=C2=A0</span><span style=3D"font-size:12.8px">and the halting problem issue=
is that a compiler doesn't know which of=C2=A0</span><span style=3D"fo=
nt-size:12.8px">those functions are used=C2=A0</span><span style=3D"font-si=
ze:12.8px">and which ones unused</span></div><div><span style=3D"font-size:=
12.8px"><br></span></div></div><div><span style=3D"font-size:12.8px">Totall=
y irrelevant. The compiler doesn't know or care about the colour of my =
socks either. Code either has defined behaviour, or it's a useless liab=
ility.</span></div><div class=3D"quoted-text"><div><span style=3D"font-size=
:12.8px"></span></div></div></div></blockquote></div></div></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">Code with narrow contracts is useful.=
=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gma=
il_extra"><div class=3D"gmail_quote"><blockquote class=3D"quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div class=3D"quoted-text"><div><span style=3D"font-size:12.8px"><br></=
span></div><div><span style=3D"font-size:12.8px">>=C2=A0</span><span sty=
le=3D"font-size:12.8px">Which leads to false positives.</span></div><div><s=
pan style=3D"font-size:12.8px"><br></span></div></div><div><span style=3D"f=
ont-size:12.8px">All UB is a positively an error. The correct (and performa=
nt) thing to do is fix it.</span></div><div class=3D"quoted-text"><div><spa=
n style=3D"font-size:12.8px"></span></div></div></div></blockquote></div></=
div></div><div dir=3D"auto"><br></div><div dir=3D"auto">Only if it is encou=
ntered.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div class=3D"quoted-text"><div><span style=3D"font-size:12.8px"=
><br></span></div><div><span style=3D"font-size:12.8px">>=C2=A0</span><s=
pan style=3D"font-size:12.8px">but since it's not, and=C2=A0</span><spa=
n style=3D"font-size:12.8px">there's existing valid code=C2=A0</span><s=
pan style=3D"font-size:12.8px">and breakage thereof to consider</span></div=
><div><span style=3D"font-size:12.8px"><br></span></div></div><div><span st=
yle=3D"font-size:12.8px">Do you remember when we moved from K&R functio=
n declarations to ANSI function declarations? I do. Everyone coped just fin=
e. No-one demanded the right to continue to write</span></div><div><span st=
yle=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.=
8px"><font face=3D"monospace, monospace">func(x,y)</font></span></div><div>=
<span style=3D"font-size:12.8px"><font face=3D"monospace, monospace">double=
x;</font></span></div><div><span style=3D"font-size:12.8px"><font face=3D"=
monospace, monospace">int y;</font></span></div><div><span style=3D"font-si=
ze:12.8px"><font face=3D"monospace, monospace">{</font></span></div><div><s=
pan style=3D"font-size:12.8px"><font face=3D"monospace, monospace">=C2=A0 i=
f (x > 0)</font></span></div><div><span style=3D"font-size:12.8px"><font=
face=3D"monospace, monospace">=C2=A0 =C2=A0 return y;</font></span></div><=
div><span style=3D"font-size:12.8px"><font face=3D"monospace, monospace">}<=
/font></span></div><div><span style=3D"font-size:12.8px"><br></span></div><=
div><span style=3D"font-size:12.8px">**this** is the origin on the UB on no=
n-specified returns. Almost everything else got fixed. This got forgotten.<=
/span></div><div class=3D"quoted-text"><div><span style=3D"font-size:12.8px=
"><br></span></div><div><span style=3D"font-size:12.8px"><br></span></div><=
div><span style=3D"font-size:12.8px">>=C2=A0</span><span style=3D"font-s=
ize:12.8px">trying to mandate a diagnostic for a=C2=A0</span><span style=3D=
"font-size:12.8px">missing return is fighting=C2=A0</span><span style=3D"fo=
nt-size:12.8px">an uphill battle.</span></div><div><span style=3D"font-size=
:12.8px"><br></span></div></div><div><span style=3D"font-size:12.8px">One o=
f my engineers, an experienced guy with 20 years writing c++, spent the fir=
st half of today diagnosing something that turned out to be a result of exa=
ctly this. Forgetting to return the shared_ptr he had created. In a functio=
n he had written 30 minutes prior. The crash occurred in thread 3, nowhere =
near the offending code that was executed in thread 1.</span></div><div><sp=
an style=3D"font-size:12.8px"></span></div></div></blockquote></div></div><=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">So you're admitting =
that you don't use Werror=3Dreturn-type nor fsanitize=3Dreturn? And yet=
you want to force this into the language?=C2=A0</div><div dir=3D"auto"><br=
></div><div dir=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_quo=
te"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><span style=3D"font-size=
:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">Half a day.=
Over something the compiler could, no, *should* have told him on the first=
compile.</span></div><div><span style=3D"font-size:12.8px"><br></span></di=
v><div><span style=3D"font-size:12.8px">This happens a lot, all over the wo=
rld, every day. The combined loss of productivity easily outweighs the mino=
r inconvenience of fixing a few lazily-written, demonstrably suboptimal, le=
af functions.</span></div><div><span style=3D"font-size:12.8px"><br></span>=
</div><div><span style=3D"font-size:12.8px">You and the current committee s=
tance on this, are wrong. It is a problem. Not all developers are as vocife=
rous as me, so why don't you ask the others whether they'd prefer t=
o have this? Ask, not tell.</span></div><div><span style=3D"font-size:12.8p=
x"></span></div></div></blockquote></div></div></div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">Ask the gcc developers whether they have considered=
making Wreturn-type a default error.=C2=A0</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><=
blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div><span style=3D"font-size:12.8=
px"><br></span></div><div><span style=3D"font-size:12.8px"><br></span></div=
><div><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_qu=
ote"><div class=3D"quoted-text">On 20 December 2017 at 17:36, Ville Voutila=
inen <span dir=3D"ltr"><<a href=3D"mailto:ville.voutilainen@gmail.com" t=
arget=3D"_blank">ville.voutilainen@gmail.com</a>></span> wrote:<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div class=3D"elided-text"><span>On 20 Dece=
mber 2017 at 18:17, Jake Arkinstall <<a href=3D"mailto:jake.arkinstall@g=
mail.com" target=3D"_blank">jake.arkinstall@gmail.com</a>> wrote:<br>
><br>
><br>
> On 20 Dec 2017 15:55, "Ville Voutilainen" <<a href=3D"mai=
lto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.=
com</a>><br>
> wrote:<br>
><br>
> VV: We could go towards a direction of making the lack of return<br>
> ill-formed. Compilers already diagnose it, by default.<br>
> CC: But how do you know you call the function?<br>
> VV: I don't. That runs into the Halting Problem. This would theref=
ore<br>
> cause unnecessary churn in valid code. Consider<br>
> the idea withdrawn. Let's kill it if it comes up in the form of a =
proposal.<br>
> CC: Agreed.<br>
><br>
><br>
> Wow. Was there someone at the meeting holding up a sign saying "[=
citation<br>
> needed]" when the halting problem was brought up? Adding somethin=
g at the<br>
> end of functions that have a non-returning branch (whether accessible =
or<br>
> not) is hardly solving the halting problem or causing churn. It never =
gets<br>
> run, assuming the function behaved beforehand.<br>
<br>
</span>The churn comes from functions that don't have a return or an<br=
>
annotation that that is intended,<br>
and the halting problem issue is that a compiler doesn't know which of<=
br>
those functions are used<br>
and which ones unused. Which leads to false positives. Were this a<br>
from-scratch matter, we might<br>
well decide to diagnose the lack of return, but since it's not, and<br>
there's existing valid code<br>
and breakage thereof to consider, trying to mandate a diagnostic for a<br>
missing return is fighting<br>
an uphill battle.<br>
<br>
You are all more than welcome to continue to misunderstand that or<br>
claim that such considerations<br>
are brought up by idiots, but if you choose to do so, I honestly<br>
wonder why this thread exists, considering<br>
that there seems to be a strong effort by the supposed proponents of<br>
the idea to convince everybody<br>
else that they don't really want this idea to succeed.<br>
</div><span><br>
--<div class=3D"quoted-text"><br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<div class=3D"quoted=
-text"><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></span><div class=3D"quoted-text">To view this discussion on the web =
visit <a href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposa=
ls/CAFk2RUaxu_thbrRbqxL-nuvZkQnVvKP1rfE_XB%2B342AcLUcrag%40mail.gmail.com" =
rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/is<wbr>ocp=
p.org/d/msgid/std-proposals<wbr>/CAFk2RUaxu_thbrRbqxL-<wbr>nuvZkQnVvKP1rfE_=
XB%2B342AcLUcr<wbr>ag%40mail.gmail.com</a>.<br>
</div></blockquote></div><br></div><div class=3D"quoted-text">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/U=
u2QViiWh4k/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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/CALvx3haEDQgDKne-9UtVWY7jGkhbgoXB6HZT=
0vQSFAiW13NJmg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-=
<wbr>proposals/CALvx3haEDQgDKne-<wbr>9UtVWY7jGkhbgoXB6HZT0vQSFAiW13<wbr>NJm=
g%40mail.gmail.com</a>.<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/CAJnLdOZZGXq%3DE7Gtsv7Qo10%3DfTkN4OY7=
Yke4MaZZm3Ku1qpZ0g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZZGXq%=
3DE7Gtsv7Qo10%3DfTkN4OY7Yke4MaZZm3Ku1qpZ0g%40mail.gmail.com</a>.<br />
--001a114b3186c440740560c94a82--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 20 Dec 2017 09:59:56 -0800 (PST)
Raw View
------=_Part_3300_865359797.1513792796564
Content-Type: multipart/alternative;
boundary="----=_Part_3301_2098417396.1513792796564"
------=_Part_3301_2098417396.1513792796564
Content-Type: text/plain; charset="UTF-8"
On Wednesday, December 20, 2017 at 12:02:32 PM UTC-5, Richard Hodges wrote:
>
> > The churn comes from functions that don't have a return or an annotation
> that that is intended,
>
> We have already seen that these "intended no return" functions result in
> worse code. This is precisely because the compiler cannot deduce intent. In
> every other conversation about UB, there would be unanimous agreement that
> UB is to be avoided.
>
No, we would not find "unanimous agreement" on such things. You didn't
agree that this should be a compile error:
int *ptr = nullptr;
*ptr = 5;
Equally importantly, you seem to be arguing from a position of ideology:
that UB is bad and therefore doing* anything*, no matter how painful, to
remove UB is unquestionably good.
In the real world, that's not how things work. Any change must take into
account the cost to users.
For some unfathomable reason, on this issue, some wish to defy the evidence
> before them and continue to demand the right to write UB functions without
> a diagnostic - to the detriment of the vast majority who simply want
> functions to do defined things.
>
Can you present evidence for the existence of this "vast majority" who are
willing to have entire codebases be broken by this?
How do I know that the majority want functions to do defined things?
> Because the universally accepted process for writing and testing code is to
> write tests. What do tests do? They verify the claims of the function's
> author. What do UB functions do? They refuse to make any claims. Is that
> testable? No. Is it useful? Quad erat demonstrandum, no.
>
The fallacy in your argument is "They refuse to make any claims." That is
untrue. The enum/switch example that's been tossed around very much makes
claims: if you pass in an enumerator of those types, then you get a string
back. That's the claim, and it is testable.
As for completely empty functions with return values, even those have a
purpose: metaprogramming and reflection. You can use `decltype` and
unevaluated contexts to inquire about parameters and the return type, all
without actually calling the function.
So no, your statement is not valid.
> but since it's not, and there's existing valid code and breakage thereof
> to consider
>
> Do you remember when we moved from K&R function declarations to ANSI
> function declarations? I do.
>
I also remember other facts:
1) ANSI function declarations were already widely used before C89, as
compiler extensions.
2) We have many orders of magnitude more code now than we did back then.
3) K&R function declarations* are still legal*.
Everyone coped just fine. No-one demanded the right to continue to write
>
> func(x,y)
> double x;
> int y;
> {
> if (x > 0)
> return y;
> }
>
> **this** is the origin on the UB on non-specified returns. Almost
> everything else got fixed. This got forgotten.
>
>
> > trying to mandate a diagnostic for a missing return is fighting an
> uphill battle.
>
> One of my engineers, an experienced guy with 20 years writing c++, spent
> the first half of today diagnosing something that turned out to be a result
> of exactly this. Forgetting to return the shared_ptr he had created. In a
> function he had written 30 minutes prior. The crash occurred in thread 3,
> nowhere near the offending code that was executed in thread 1.
>
> Half a day. Over something the compiler could, no, *should* have told him
> on the first compile.
>
Did he forget to compile with warnings? In my experience, compilers will
warn on failing to return something if there is no return statement at all.
This happens a lot, all over the world, every day. The combined loss of
> productivity easily outweighs the minor inconvenience of fixing a few
> lazily-written, demonstrably suboptimal, leaf functions.
>
Easily said, but not easily demonstrated.
>
--
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/e34e4113-e0b4-4e6e-99c2-281bb0c6bd9d%40isocpp.org.
------=_Part_3301_2098417396.1513792796564
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, December 20, 2017 at 12:02:32 PM UTC-5, Rich=
ard Hodges 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">>=C2=A0<span style=3D"font-size:12.8px">The churn comes from functio=
ns that don't have a return or an=C2=A0</span><span style=3D"font-size:=
12.8px">annotation that that is intended,</span><div><span style=3D"font-si=
ze:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">We have a=
lready seen that these "intended no return" functions result in w=
orse code. This is precisely because the compiler cannot deduce intent. In =
every other conversation about UB, there would be unanimous agreement that =
UB is to be avoided.</span></div></div></blockquote><div><br></div><div>No,=
we would not find "unanimous agreement" on such things. You didn=
't agree that this should be a compile error:</div><div><br></div><div =
class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-w=
rap: break-word; background-color: rgb(250, 250, 250);"><code class=3D"pret=
typrint"><div class=3D"subprettyprint"><span class=3D"styled-by-prettify" s=
tyle=3D"color: #008;">int</span><span class=3D"styled-by-prettify" style=3D=
"color: #000;"> </span><span class=3D"styled-by-prettify" style=3D"color: #=
660;">*</span><span class=3D"styled-by-prettify" style=3D"color: #000;">ptr=
</span><span class=3D"styled-by-prettify" style=3D"color: #660;">=3D</span=
><span class=3D"styled-by-prettify" style=3D"color: #000;"> </span><span cl=
ass=3D"styled-by-prettify" style=3D"color: #008;">nullptr</span><span class=
=3D"styled-by-prettify" style=3D"color: #660;">;</span><span class=3D"style=
d-by-prettify" style=3D"color: #000;"><br></span><span class=3D"styled-by-p=
rettify" style=3D"color: #660;">*</span><span class=3D"styled-by-prettify" =
style=3D"color: #000;">ptr </span><span class=3D"styled-by-prettify" style=
=3D"color: #660;">=3D</span><span class=3D"styled-by-prettify" style=3D"col=
or: #000;"> </span><span class=3D"styled-by-prettify" style=3D"color: #066;=
">5</span><span class=3D"styled-by-prettify" style=3D"color: #660;">;</span=
><span class=3D"styled-by-prettify" style=3D"color: #000;"><br></span></div=
></code></div><div><br></div><div>Equally importantly, you seem to be argui=
ng from a position of ideology: that UB is bad and therefore doing<i> anyth=
ing</i>, no matter how painful, to remove UB is unquestionably good.</div><=
div><br></div><div>In the real world, that's not how things work. Any c=
hange must take into account the cost to users.<br></div><div><i><br></i></=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><spa=
n style=3D"font-size:12.8px">For some unfathomable reason, on this issue, s=
ome wish to defy the evidence before them and continue to demand the right =
to write UB functions without a diagnostic - to the detriment of the vast m=
ajority who simply want functions to do defined things.</span></div></div><=
/blockquote><div><br></div><div>Can you present evidence for the existence =
of this "vast majority" who are willing to have entire codebases =
be broken by this?</div><div><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><div><span style=3D"font-size:12.8px">How do I kn=
ow that the majority want functions to do defined things? Because the unive=
rsally accepted process for writing and testing code is to write tests. Wha=
t do tests do? They verify the claims of the function's author. What do=
UB functions do? They refuse to make any claims. </span><span style=3D"fon=
t-size:12.8px">Is that testable? No. Is it useful? Quad erat demonstrandum,=
no.</span></div></div></blockquote><div><br></div><div>The fallacy in your=
argument is "<span style=3D"display: inline !important; float: none; =
background-color: transparent; color: rgb(34, 34, 34); font-family: "A=
rial","Helvetica",sans-serif; font-size: 12.8px; font-style:=
normal; font-variant: normal; font-weight: 400; letter-spacing: normal; or=
phans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-t=
ransform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-s=
pacing: 0px;">They refuse to make any claims." That is untrue. The enu=
m/switch example that's been tossed around very much makes claims: if y=
ou pass in an enumerator of those types, then you get a string back. That&#=
39;s the claim, and it is testable.</span></div><div><br></div><div>As for =
completely empty functions with return values, even those have a purpose: m=
etaprogramming and reflection. You can use `decltype` and unevaluated conte=
xts to inquire about parameters and the return type, all without actually c=
alling the function.</div><div><br></div><div>So no, your statement is not =
valid.</div><div><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"><div><span style=3D"font-size:12.8px">>=C2=A0</span><span =
style=3D"font-size:12.8px">but since it's not, and=C2=A0</span><span st=
yle=3D"font-size:12.8px">there's existing valid code=C2=A0</span><span =
style=3D"font-size:12.8px">and breakage thereof to consider</span></div><di=
v><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"fon=
t-size:12.8px">Do you remember when we moved from K&R function declarat=
ions to ANSI function declarations? I do.</span></div></div></blockquote><d=
iv><br></div><div>I also remember other facts:</div><div><br></div><div>1) =
ANSI function declarations were already widely used before C89, as compiler=
extensions.</div><div>2) We have many orders of magnitude more code now th=
an we did back then.</div><div>3) K&R function declarations<i> are stil=
l legal</i>.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div dir=3D"ltr"><div><span style=3D"font-size:12.8px">Everyone coped ju=
st fine. No-one demanded the right to continue to write</span></div><div><s=
pan style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-si=
ze:12.8px"><font face=3D"monospace, monospace">func(x,y)</font></span></div=
><div><span style=3D"font-size:12.8px"><font face=3D"monospace, monospace">=
double x;</font></span></div><div><span style=3D"font-size:12.8px"><font fa=
ce=3D"monospace, monospace">int y;</font></span></div><div><span style=3D"f=
ont-size:12.8px"><font face=3D"monospace, monospace">{</font></span></div><=
div><span style=3D"font-size:12.8px"><font face=3D"monospace, monospace">=
=C2=A0 if (x > 0)</font></span></div><div><span style=3D"font-size:12.8p=
x"><font face=3D"monospace, monospace">=C2=A0 =C2=A0 return y;</font></span=
></div><div><span style=3D"font-size:12.8px"><font face=3D"monospace, monos=
pace">}</font></span></div><div><span style=3D"font-size:12.8px"><br></span=
></div><div><span style=3D"font-size:12.8px">**this** is the origin on the =
UB on non-specified returns. Almost everything else got fixed. This got for=
gotten.</span></div><div><span style=3D"font-size:12.8px"><br></span></div>=
<div><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"=
font-size:12.8px">>=C2=A0</span><span style=3D"font-size:12.8px">trying =
to mandate a diagnostic for a=C2=A0</span><span style=3D"font-size:12.8px">=
missing return is fighting=C2=A0</span><span style=3D"font-size:12.8px">an =
uphill battle.</span></div><div><span style=3D"font-size:12.8px"><br></span=
></div><div><span style=3D"font-size:12.8px">One of my engineers, an experi=
enced guy with 20 years writing c++, spent the first half of today diagnosi=
ng something that turned out to be a result of exactly this. Forgetting to =
return the shared_ptr he had created. In a function he had written 30 minut=
es prior. The crash occurred in thread 3, nowhere near the offending code t=
hat was executed in thread 1.</span></div><div><span style=3D"font-size:12.=
8px"><br></span></div><div><span style=3D"font-size:12.8px">Half a day. Ove=
r something the compiler could, no, *should* have told him on the first com=
pile.</span></div></div></blockquote><div><br></div><div>Did he forget to c=
ompile with warnings? In my experience, compilers will warn on failing to r=
eturn something if there is no return statement at all.</div><div><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><span s=
tyle=3D"font-size:12.8px">This happens a lot, all over the world, every day=
.. </span><span style=3D"font-size:12.8px">The combined loss of productivity=
easily outweighs the minor inconvenience of fixing a few lazily-written, d=
emonstrably suboptimal, leaf functions.</span></div></div></blockquote><div=
><br></div><div>Easily said, but not easily demonstrated.<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">
</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/e34e4113-e0b4-4e6e-99c2-281bb0c6bd9d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e34e4113-e0b4-4e6e-99c2-281bb0c6bd9d=
%40isocpp.org</a>.<br />
------=_Part_3301_2098417396.1513792796564--
------=_Part_3300_865359797.1513792796564--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 20 Dec 2017 10:10:26 -0800 (PST)
Raw View
------=_Part_3199_2053756358.1513793426096
Content-Type: multipart/alternative;
boundary="----=_Part_3200_108903027.1513793426097"
------=_Part_3200_108903027.1513793426097
Content-Type: text/plain; charset="UTF-8"
On Wednesday, December 20, 2017 at 12:52:23 PM UTC-5, Richard Hodges wrote:
>
> To continue...
>
> Here's a function which looks a little like our better foo() function, but
> returns a large, complex object.
>
> Note how this too can be written in such a way as to exhibit no UB ever,
> and is also optimally efficient:
>
> struct floom
> {
> std::string a,b,c,d,e,f,g;
> };
>
> floom make_floom(Values x)
> {
> auto make_e1 = [] {
> return floom { "aa", "ab", "ac", "ad", "ae", "af", "ag"};
> };
>
> auto make_e2 = [] {
> return floom { "a", "b", "c", "d", "e", "f", "g"};
> };
>
> switch(x) {
> case E1:
> return make_e1();
> case E2:
> return make_e2();
> }
>
> return make_e2();
> }
>
I'm not really sure what the point of this example is. The expected way to
write this code is:
floom make_floom(Values x)
{
switch(x) {
case E1:
return { "aa", "ab", "ac", "ad", "ae", "af", "ag"};
default:
return { "a", "b", "c", "d", "e", "f", "g"};
}
}
This removes two pointless lambdas. The use of `default` makes it clear
what the function's contract is: that for `make_floom`, it is perfectly
valid to call:
make_floom(std::numeric_limits<std::underlying_type_t<Values>>::max);
That is the contract for the code you have written, so it should clearly be
spelled out in your code. And using `default` does that.
However, if what you want to communicate is that it's not legal to pass
values other than the specific enumerators, then you do this:
floom make_floom(Values x)
{
switch(x) {
case E1:
return { "aa", "ab", "ac", "ad", "ae", "af", "ag"};
case E2:
return { "a", "b", "c", "d", "e", "f", "g"};
}
throw some_exception{};
}
Or you make use of `expected` or similar error code types.
But even this puts the entire range of legal
`std::underlying_type_t<Values>` as part of the function's acceptable
values. If you want a narrow contract like `vector::operator[]`, you do
this:
floom make_floom(Values x)
{
switch(x) {
case E1:
return { "aa", "ab", "ac", "ad", "ae", "af", "ag"};
case E2:
return { "a", "b", "c", "d", "e", "f", "g"};
}
}
My overall point is that we're not talking about the* same function*.
You're creating a new function with a distinct meaning and a different
contract.
You are essentially saying that the language should prevent us from ever
making functions with narrow contracts. I do not hold to that.
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7889e750-bace-45ad-bc5a-e421a2f56626%40isocpp.org.
------=_Part_3200_108903027.1513793426097
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, December 20, 2017 at 12:52:23 PM UTC-5, Rich=
ard Hodges 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">To continue...<div><br></div><div>Here's a function which looks a l=
ittle like our better foo() function, but returns a large, complex object.<=
/div><div><br></div><div>Note how this too can be written in such a way as =
to exhibit no UB ever, and is also optimally efficient:</div><div><br></div=
><div><div style=3D"background-color:rgb(255,255,254);line-height:21px"><di=
v style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><font face=3D"m=
onospace, monospace"><span style=3D"color:rgb(0,0,255)">struct</span> floom=
</font></div><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"=
><font face=3D"monospace, monospace">{</font></div><div style=3D"color:rgb(=
0,0,0);font-size:14px;white-space:pre"><font face=3D"monospace, monospace">=
std::string a,b,c,d,e,f,g;</font></div><div style=3D"color:rgb(0,0,0);f=
ont-size:14px;white-space:pre"><font face=3D"monospace, monospace">};</font=
></div><font face=3D"monospace, monospace" style=3D"color:rgb(0,0,0);font-s=
ize:14px;white-space:pre"><br></font><div style=3D"color:rgb(0,0,0);font-si=
ze:14px;white-space:pre"><font face=3D"monospace, monospace">floom make_flo=
om(Values x)</font></div><div style=3D"color:rgb(0,0,0);font-size:14px;whit=
e-space:pre"><font face=3D"monospace, monospace">{</font></div><div style=
=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><font face=3D"monospac=
e, monospace"> <span style=3D"color:rgb(0,0,255)">auto</span> make_e1 =
=3D [] {</font></div><div style=3D"color:rgb(0,0,0);font-size:14px;white-sp=
ace:pre"><font face=3D"monospace, monospace"> <span style=3D"color:r=
gb(0,0,255)">return</span> floom { <span style=3D"color:rgb(163,21,21)">&qu=
ot;aa"</span>, <span style=3D"color:rgb(163,21,21)">"ab"</sp=
an>, <span style=3D"color:rgb(163,21,21)">"ac"</span>, <span styl=
e=3D"color:rgb(163,21,21)">"ad"</span>, <span style=3D"color:rgb(=
163,21,21)">"ae"</span>, <span style=3D"color:rgb(163,21,21)">&qu=
ot;af"</span>, <span style=3D"color:rgb(163,21,21)">"ag"</sp=
an>};</font></div><div style=3D"color:rgb(0,0,0);font-size:14px;white-space=
:pre"><font face=3D"monospace, monospace"> };</font></div><font face=3D"=
monospace, monospace" style=3D"color:rgb(0,0,0);font-size:14px;white-space:=
pre"><br></font><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:p=
re"><font face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,25=
5)">auto</span> make_e2 =3D [] {</font></div><div style=3D"color:rgb(0,0,0)=
;font-size:14px;white-space:pre"><font face=3D"monospace, monospace"> =
<span style=3D"color:rgb(0,0,255)">return</span> floom { <span style=3D"c=
olor:rgb(163,21,21)">"a"</span>, <span style=3D"color:rgb(163,21,=
21)">"b"</span>, <span style=3D"color:rgb(163,21,21)">"c&quo=
t;</span>, <span style=3D"color:rgb(163,21,21)">"d"</span>, <span=
style=3D"color:rgb(163,21,21)">"e"</span>, <span style=3D"color:=
rgb(163,21,21)">"f"</span>, <span style=3D"color:rgb(163,21,21)">=
"g"</span>};</font></div><div style=3D"color:rgb(0,0,0);font-size=
:14px;white-space:pre"><font face=3D"monospace, monospace"> };</font></d=
iv><font face=3D"monospace, monospace" style=3D"color:rgb(0,0,0);font-size:=
14px;white-space:pre"><br></font><div style=3D"color:rgb(0,0,0);font-size:1=
4px;white-space:pre"><font face=3D"monospace, monospace"> <span style=3D=
"color:rgb(0,0,255)">switch</span>(x) {</font></div><div style=3D"color:rgb=
(0,0,0);font-size:14px;white-space:pre"><font face=3D"monospace, monospace"=
> <span style=3D"color:rgb(0,0,255)">case</span> E1:</font></div><div st=
yle=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><font face=3D"monos=
pace, monospace"> <span style=3D"color:rgb(0,0,255)">return</span> m=
ake_e1();</font></div><div style=3D"color:rgb(0,0,0);font-size:14px;white-s=
pace:pre"><font face=3D"monospace, monospace"> <span style=3D"color:rgb(=
0,0,255)">case</span> E2:</font></div><div style=3D"color:rgb(0,0,0);font-s=
ize:14px;white-space:pre"><font face=3D"monospace, monospace"> <span=
style=3D"color:rgb(0,0,255)">return</span> make_e2();</font></div><div sty=
le=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><font face=3D"monosp=
ace, monospace"> }</font></div><font face=3D"monospace, monospace" style=
=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><br></font><div style=
=3D"color:rgb(0,0,0);font-size:14px;white-space:pre"><font face=3D"monospac=
e, monospace"> <span style=3D"color:rgb(0,0,255)">return</span> make_e2(=
);</font></div><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:pr=
e"><font face=3D"monospace, monospace">}</font></div></div></div></div></bl=
ockquote><div><br></div><div>I'm not really sure what the point of this=
example is. The expected way to write this code is:</div><div><br></div><d=
iv class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); wor=
d-wrap: break-word; background-color: rgb(250, 250, 250);"><code class=3D"p=
rettyprint"><div class=3D"subprettyprint"><span class=3D"styled-by-prettify=
" style=3D"color: #000;">floom make_floom</span><span class=3D"styled-by-pr=
ettify" style=3D"color: #660;">(</span><span class=3D"styled-by-prettify" s=
tyle=3D"color: #606;">Values</span><span class=3D"styled-by-prettify" style=
=3D"color: #000;"> x</span><span class=3D"styled-by-prettify" style=3D"colo=
r: #660;">)</span><span class=3D"styled-by-prettify" style=3D"color: #000;"=
><br></span><span class=3D"styled-by-prettify" style=3D"color: #660;">{</sp=
an><span class=3D"styled-by-prettify" style=3D"color: #000;"><br>=C2=A0 =C2=
=A0 </span><span class=3D"styled-by-prettify" style=3D"color: #008;">switch=
</span><span class=3D"styled-by-prettify" style=3D"color: #660;">(</span><s=
pan class=3D"styled-by-prettify" style=3D"color: #000;">x</span><span class=
=3D"styled-by-prettify" style=3D"color: #660;">)</span><span class=3D"style=
d-by-prettify" style=3D"color: #000;"> </span><span class=3D"styled-by-pret=
tify" style=3D"color: #660;">{</span><span class=3D"styled-by-prettify" sty=
le=3D"color: #000;"><br><br>=C2=A0 =C2=A0 </span><span class=3D"styled-by-p=
rettify" style=3D"color: #008;">case</span><span class=3D"styled-by-prettif=
y" style=3D"color: #000;"> E1</span><span class=3D"styled-by-prettify" styl=
e=3D"color: #660;">:</span><span class=3D"styled-by-prettify" style=3D"colo=
r: #000;"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span class=3D"styled-by-p=
rettify" style=3D"color: #008;">return</span><span class=3D"styled-by-prett=
ify" style=3D"color: #000;"> </span><span class=3D"styled-by-prettify" styl=
e=3D"color: #660;">{</span><span class=3D"styled-by-prettify" style=3D"colo=
r: #000;"> </span><span class=3D"styled-by-prettify" style=3D"color: #080;"=
>"aa"</span><span class=3D"styled-by-prettify" style=3D"color: #6=
60;">,</span><span class=3D"styled-by-prettify" style=3D"color: #000;"> </s=
pan><span class=3D"styled-by-prettify" style=3D"color: #080;">"ab"=
;</span><span class=3D"styled-by-prettify" style=3D"color: #660;">,</span><=
span class=3D"styled-by-prettify" style=3D"color: #000;"> </span><span clas=
s=3D"styled-by-prettify" style=3D"color: #080;">"ac"</span><span =
class=3D"styled-by-prettify" style=3D"color: #660;">,</span><span class=3D"=
styled-by-prettify" style=3D"color: #000;"> </span><span class=3D"styled-by=
-prettify" style=3D"color: #080;">"ad"</span><span class=3D"style=
d-by-prettify" style=3D"color: #660;">,</span><span class=3D"styled-by-pret=
tify" style=3D"color: #000;"> </span><span class=3D"styled-by-prettify" sty=
le=3D"color: #080;">"ae"</span><span class=3D"styled-by-prettify"=
style=3D"color: #660;">,</span><span class=3D"styled-by-prettify" style=3D=
"color: #000;"> </span><span class=3D"styled-by-prettify" style=3D"color: #=
080;">"af"</span><span class=3D"styled-by-prettify" style=3D"colo=
r: #660;">,</span><span class=3D"styled-by-prettify" style=3D"color: #000;"=
> </span><span class=3D"styled-by-prettify" style=3D"color: #080;">"ag=
"</span><span class=3D"styled-by-prettify" style=3D"color: #660;">};</=
span><span class=3D"styled-by-prettify" style=3D"color: #000;"><br>=C2=A0 =
=C2=A0 </span><span class=3D"styled-by-prettify" style=3D"color: #008;">def=
ault</span><span class=3D"styled-by-prettify" style=3D"color: #660;">:</spa=
n><span class=3D"styled-by-prettify" style=3D"color: #000;"><br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 </span><span class=3D"styled-by-prettify" style=3D"color:=
#008;">return</span><span class=3D"styled-by-prettify" style=3D"color: #00=
0;"> </span><span class=3D"styled-by-prettify" style=3D"color: #660;">{</sp=
an><span class=3D"styled-by-prettify" style=3D"color: #000;"> </span><span =
class=3D"styled-by-prettify" style=3D"color: #080;">"a"</span><sp=
an class=3D"styled-by-prettify" style=3D"color: #660;">,</span><span class=
=3D"styled-by-prettify" style=3D"color: #000;"> </span><span class=3D"style=
d-by-prettify" style=3D"color: #080;">"b"</span><span class=3D"st=
yled-by-prettify" style=3D"color: #660;">,</span><span class=3D"styled-by-p=
rettify" style=3D"color: #000;"> </span><span class=3D"styled-by-prettify" =
style=3D"color: #080;">"c"</span><span class=3D"styled-by-prettif=
y" style=3D"color: #660;">,</span><span class=3D"styled-by-prettify" style=
=3D"color: #000;"> </span><span class=3D"styled-by-prettify" style=3D"color=
: #080;">"d"</span><span class=3D"styled-by-prettify" style=3D"co=
lor: #660;">,</span><span class=3D"styled-by-prettify" style=3D"color: #000=
;"> </span><span class=3D"styled-by-prettify" style=3D"color: #080;">"=
e"</span><span class=3D"styled-by-prettify" style=3D"color: #660;">,</=
span><span class=3D"styled-by-prettify" style=3D"color: #000;"> </span><spa=
n class=3D"styled-by-prettify" style=3D"color: #080;">"f"</span><=
span class=3D"styled-by-prettify" style=3D"color: #660;">,</span><span clas=
s=3D"styled-by-prettify" style=3D"color: #000;"> </span><span class=3D"styl=
ed-by-prettify" style=3D"color: #080;">"g"</span><span class=3D"s=
tyled-by-prettify" style=3D"color: #660;">};</span><span class=3D"styled-by=
-prettify" style=3D"color: #000;"><br>=C2=A0 =C2=A0 </span><span class=3D"s=
tyled-by-prettify" style=3D"color: #660;">}</span><span class=3D"styled-by-=
prettify" style=3D"color: #000;"><br></span><span class=3D"styled-by-pretti=
fy" style=3D"color: #660;">}</span></div></code></div><div><br></div><div>T=
his removes two pointless lambdas. The use of `default` makes it clear what=
the function's contract is: that for `make_floom`, it is perfectly val=
id to call:</div><div><br></div><div class=3D"prettyprint" style=3D"border:=
1px solid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb=
(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"=
><span class=3D"styled-by-prettify" style=3D"color: #000;">make_floom</span=
><span class=3D"styled-by-prettify" style=3D"color: #660;">(</span><span cl=
ass=3D"styled-by-prettify" style=3D"color: #000;">std</span><span class=3D"=
styled-by-prettify" style=3D"color: #660;">::</span><span class=3D"styled-b=
y-prettify" style=3D"color: #000;">numeric_limits</span><span class=3D"styl=
ed-by-prettify" style=3D"color: #660;"><</span><span class=3D"styled-by-=
prettify" style=3D"color: #000;">std</span><span class=3D"styled-by-prettif=
y" style=3D"color: #660;">::</span><span class=3D"styled-by-prettify" style=
=3D"color: #000;">underlying_type_t</span><span class=3D"styled-by-prettify=
" style=3D"color: #660;"><</span><span class=3D"styled-by-prettify" styl=
e=3D"color: #606;">Values</span><span class=3D"styled-by-prettify" style=3D=
"color: #660;">>>::</span><span class=3D"styled-by-prettify" style=3D=
"color: #000;">max</span><span class=3D"styled-by-prettify" style=3D"color:=
#660;">);</span><span class=3D"styled-by-prettify" style=3D"color: #000;">=
<br></span></div></code></div><br><div>That is the contract for the code yo=
u have written, so it should clearly be spelled out in your code. And using=
`default` does that.</div><div><br></div><div>However, if what you want to=
communicate is that it's not legal to pass values other than the speci=
fic enumerators, then you do this:</div><div><br></div><div class=3D"pretty=
print" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word=
; background-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div c=
lass=3D"subprettyprint"><span class=3D"styled-by-prettify" style=3D"color: =
#000;">floom make_floom</span><span class=3D"styled-by-prettify" style=3D"c=
olor: #660;">(</span><span class=3D"styled-by-prettify" style=3D"color: #60=
6;">Values</span><span class=3D"styled-by-prettify" style=3D"color: #000;">=
x</span><span class=3D"styled-by-prettify" style=3D"color: #660;">)</span>=
<span class=3D"styled-by-prettify" style=3D"color: #000;"><br></span><span =
class=3D"styled-by-prettify" style=3D"color: #660;">{</span><span class=3D"=
styled-by-prettify" style=3D"color: #000;"><br>=C2=A0 =C2=A0 </span><span c=
lass=3D"styled-by-prettify" style=3D"color: #008;">switch</span><span class=
=3D"styled-by-prettify" style=3D"color: #660;">(</span><span class=3D"style=
d-by-prettify" style=3D"color: #000;">x</span><span class=3D"styled-by-pret=
tify" style=3D"color: #660;">)</span><span class=3D"styled-by-prettify" sty=
le=3D"color: #000;"> </span><span class=3D"styled-by-prettify" style=3D"col=
or: #660;">{</span><span class=3D"styled-by-prettify" style=3D"color: #000;=
"><br>=C2=A0 =C2=A0 </span><span class=3D"styled-by-prettify" style=3D"colo=
r: #008;">case</span><span class=3D"styled-by-prettify" style=3D"color: #00=
0;"> E1</span><span class=3D"styled-by-prettify" style=3D"color: #660;">:</=
span><span class=3D"styled-by-prettify" style=3D"color: #000;"><br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 </span><span class=3D"styled-by-prettify" style=3D"col=
or: #008;">return</span><span class=3D"styled-by-prettify" style=3D"color: =
#000;"> </span><span class=3D"styled-by-prettify" style=3D"color: #660;">{<=
/span><span class=3D"styled-by-prettify" style=3D"color: #000;"> </span><sp=
an class=3D"styled-by-prettify" style=3D"color: #080;">"aa"</span=
><span class=3D"styled-by-prettify" style=3D"color: #660;">,</span><span cl=
ass=3D"styled-by-prettify" style=3D"color: #000;"> </span><span class=3D"st=
yled-by-prettify" style=3D"color: #080;">"ab"</span><span class=
=3D"styled-by-prettify" style=3D"color: #660;">,</span><span class=3D"style=
d-by-prettify" style=3D"color: #000;"> </span><span class=3D"styled-by-pret=
tify" style=3D"color: #080;">"ac"</span><span class=3D"styled-by-=
prettify" style=3D"color: #660;">,</span><span class=3D"styled-by-prettify"=
style=3D"color: #000;"> </span><span class=3D"styled-by-prettify" style=3D=
"color: #080;">"ad"</span><span class=3D"styled-by-prettify" styl=
e=3D"color: #660;">,</span><span class=3D"styled-by-prettify" style=3D"colo=
r: #000;"> </span><span class=3D"styled-by-prettify" style=3D"color: #080;"=
>"ae"</span><span class=3D"styled-by-prettify" style=3D"color: #6=
60;">,</span><span class=3D"styled-by-prettify" style=3D"color: #000;"> </s=
pan><span class=3D"styled-by-prettify" style=3D"color: #080;">"af"=
;</span><span class=3D"styled-by-prettify" style=3D"color: #660;">,</span><=
span class=3D"styled-by-prettify" style=3D"color: #000;"> </span><span clas=
s=3D"styled-by-prettify" style=3D"color: #080;">"ag"</span><span =
class=3D"styled-by-prettify" style=3D"color: #660;">};</span><span class=3D=
"styled-by-prettify" style=3D"color: #000;"><br>=C2=A0 =C2=A0 </span><span =
class=3D"styled-by-prettify" style=3D"color: #008;">case</span><span class=
=3D"styled-by-prettify" style=3D"color: #000;"> E2</span><span class=3D"sty=
led-by-prettify" style=3D"color: #660;">:</span><span class=3D"styled-by-pr=
ettify" style=3D"color: #000;"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span=
class=3D"styled-by-prettify" style=3D"color: #008;">return</span><span cla=
ss=3D"styled-by-prettify" style=3D"color: #000;"> </span><span class=3D"sty=
led-by-prettify" style=3D"color: #660;">{</span><span class=3D"styled-by-pr=
ettify" style=3D"color: #000;"> </span><span class=3D"styled-by-prettify" s=
tyle=3D"color: #080;">"a"</span><span class=3D"styled-by-prettify=
" style=3D"color: #660;">,</span><span class=3D"styled-by-prettify" style=
=3D"color: #000;"> </span><span class=3D"styled-by-prettify" style=3D"color=
: #080;">"b"</span><span class=3D"styled-by-prettify" style=3D"co=
lor: #660;">,</span><span class=3D"styled-by-prettify" style=3D"color: #000=
;"> </span><span class=3D"styled-by-prettify" style=3D"color: #080;">"=
c"</span><span class=3D"styled-by-prettify" style=3D"color: #660;">,</=
span><span class=3D"styled-by-prettify" style=3D"color: #000;"> </span><spa=
n class=3D"styled-by-prettify" style=3D"color: #080;">"d"</span><=
span class=3D"styled-by-prettify" style=3D"color: #660;">,</span><span clas=
s=3D"styled-by-prettify" style=3D"color: #000;"> </span><span class=3D"styl=
ed-by-prettify" style=3D"color: #080;">"e"</span><span class=3D"s=
tyled-by-prettify" style=3D"color: #660;">,</span><span class=3D"styled-by-=
prettify" style=3D"color: #000;"> </span><span class=3D"styled-by-prettify"=
style=3D"color: #080;">"f"</span><span class=3D"styled-by-pretti=
fy" style=3D"color: #660;">,</span><span class=3D"styled-by-prettify" style=
=3D"color: #000;"> </span><span class=3D"styled-by-prettify" style=3D"color=
: #080;">"g"</span><span class=3D"styled-by-prettify" style=3D"co=
lor: #660;">};</span><span class=3D"styled-by-prettify" style=3D"color: #00=
0;"><br>=C2=A0 =C2=A0 </span><span class=3D"styled-by-prettify" style=3D"co=
lor: #660;">}</span><span class=3D"styled-by-prettify" style=3D"color: #000=
;"><br><br>=C2=A0 =C2=A0 </span><span class=3D"styled-by-prettify" style=3D=
"color: #008;">throw</span><span class=3D"styled-by-prettify" style=3D"colo=
r: #000;"> some_exception</span><span class=3D"styled-by-prettify" style=3D=
"color: #660;">{};</span><span class=3D"styled-by-prettify" style=3D"color:=
#000;"><br></span><span class=3D"styled-by-prettify" style=3D"color: #660;=
">}</span></div></code></div><div><br></div><div>Or you make use of `expect=
ed` or similar error code types.</div><div><br></div><div>But even this put=
s the entire range of legal `std::underlying_type_t<Values>` as part =
of the function's acceptable values. If you want a narrow contract like=
`vector::operator[]`, you do this:</div><div><br></div><div class=3D"prett=
yprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-wor=
d; background-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div =
class=3D"subprettyprint"><span class=3D"styled-by-prettify" style=3D"color:=
#000;">floom make_floom</span><span class=3D"styled-by-prettify" style=3D"=
color: #660;">(</span><span class=3D"styled-by-prettify" style=3D"color: #6=
06;">Values</span><span class=3D"styled-by-prettify" style=3D"color: #000;"=
> x</span><span class=3D"styled-by-prettify" style=3D"color: #660;">)</span=
><span class=3D"styled-by-prettify" style=3D"color: #000;"><br></span><span=
class=3D"styled-by-prettify" style=3D"color: #660;">{</span><span class=3D=
"styled-by-prettify" style=3D"color: #000;"><br>=C2=A0 =C2=A0 </span><span =
class=3D"styled-by-prettify" style=3D"color: #008;">switch</span><span clas=
s=3D"styled-by-prettify" style=3D"color: #660;">(</span><span class=3D"styl=
ed-by-prettify" style=3D"color: #000;">x</span><span class=3D"styled-by-pre=
ttify" style=3D"color: #660;">)</span><span class=3D"styled-by-prettify" st=
yle=3D"color: #000;"> </span><span class=3D"styled-by-prettify" style=3D"co=
lor: #660;">{</span><span class=3D"styled-by-prettify" style=3D"color: #000=
;"><br>=C2=A0 =C2=A0 </span><span class=3D"styled-by-prettify" style=3D"col=
or: #008;">case</span><span class=3D"styled-by-prettify" style=3D"color: #0=
00;"> E1</span><span class=3D"styled-by-prettify" style=3D"color: #660;">:<=
/span><span class=3D"styled-by-prettify" style=3D"color: #000;"><br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 </span><span class=3D"styled-by-prettify" style=3D"col=
or: #008;">return</span><span class=3D"styled-by-prettify" style=3D"color: =
#000;"> </span><span class=3D"styled-by-prettify" style=3D"color: #660;">{<=
/span><span class=3D"styled-by-prettify" style=3D"color: #000;"> </span><sp=
an class=3D"styled-by-prettify" style=3D"color: #080;">"aa"</span=
><span class=3D"styled-by-prettify" style=3D"color: #660;">,</span><span cl=
ass=3D"styled-by-prettify" style=3D"color: #000;"> </span><span class=3D"st=
yled-by-prettify" style=3D"color: #080;">"ab"</span><span class=
=3D"styled-by-prettify" style=3D"color: #660;">,</span><span class=3D"style=
d-by-prettify" style=3D"color: #000;"> </span><span class=3D"styled-by-pret=
tify" style=3D"color: #080;">"ac"</span><span class=3D"styled-by-=
prettify" style=3D"color: #660;">,</span><span class=3D"styled-by-prettify"=
style=3D"color: #000;"> </span><span class=3D"styled-by-prettify" style=3D=
"color: #080;">"ad"</span><span class=3D"styled-by-prettify" styl=
e=3D"color: #660;">,</span><span class=3D"styled-by-prettify" style=3D"colo=
r: #000;"> </span><span class=3D"styled-by-prettify" style=3D"color: #080;"=
>"ae"</span><span class=3D"styled-by-prettify" style=3D"color: #6=
60;">,</span><span class=3D"styled-by-prettify" style=3D"color: #000;"> </s=
pan><span class=3D"styled-by-prettify" style=3D"color: #080;">"af"=
;</span><span class=3D"styled-by-prettify" style=3D"color: #660;">,</span><=
span class=3D"styled-by-prettify" style=3D"color: #000;"> </span><span clas=
s=3D"styled-by-prettify" style=3D"color: #080;">"ag"</span><span =
class=3D"styled-by-prettify" style=3D"color: #660;">};</span><span class=3D=
"styled-by-prettify" style=3D"color: #000;"><br>=C2=A0 =C2=A0 </span><span =
class=3D"styled-by-prettify" style=3D"color: #008;">case</span><span class=
=3D"styled-by-prettify" style=3D"color: #000;"> E2</span><span class=3D"sty=
led-by-prettify" style=3D"color: #660;">:</span><span class=3D"styled-by-pr=
ettify" style=3D"color: #000;"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span=
class=3D"styled-by-prettify" style=3D"color: #008;">return</span><span cla=
ss=3D"styled-by-prettify" style=3D"color: #000;"> </span><span class=3D"sty=
led-by-prettify" style=3D"color: #660;">{</span><span class=3D"styled-by-pr=
ettify" style=3D"color: #000;"> </span><span class=3D"styled-by-prettify" s=
tyle=3D"color: #080;">"a"</span><span class=3D"styled-by-prettify=
" style=3D"color: #660;">,</span><span class=3D"styled-by-prettify" style=
=3D"color: #000;"> </span><span class=3D"styled-by-prettify" style=3D"color=
: #080;">"b"</span><span class=3D"styled-by-prettify" style=3D"co=
lor: #660;">,</span><span class=3D"styled-by-prettify" style=3D"color: #000=
;"> </span><span class=3D"styled-by-prettify" style=3D"color: #080;">"=
c"</span><span class=3D"styled-by-prettify" style=3D"color: #660;">,</=
span><span class=3D"styled-by-prettify" style=3D"color: #000;"> </span><spa=
n class=3D"styled-by-prettify" style=3D"color: #080;">"d"</span><=
span class=3D"styled-by-prettify" style=3D"color: #660;">,</span><span clas=
s=3D"styled-by-prettify" style=3D"color: #000;"> </span><span class=3D"styl=
ed-by-prettify" style=3D"color: #080;">"e"</span><span class=3D"s=
tyled-by-prettify" style=3D"color: #660;">,</span><span class=3D"styled-by-=
prettify" style=3D"color: #000;"> </span><span class=3D"styled-by-prettify"=
style=3D"color: #080;">"f"</span><span class=3D"styled-by-pretti=
fy" style=3D"color: #660;">,</span><span class=3D"styled-by-prettify" style=
=3D"color: #000;"> </span><span class=3D"styled-by-prettify" style=3D"color=
: #080;">"g"</span><span class=3D"styled-by-prettify" style=3D"co=
lor: #660;">};</span><span class=3D"styled-by-prettify" style=3D"color: #00=
0;"><br>=C2=A0 =C2=A0 </span><span class=3D"styled-by-prettify" style=3D"co=
lor: #660;">}</span><span class=3D"styled-by-prettify" style=3D"color: #000=
;"><br></span><span class=3D"styled-by-prettify" style=3D"color: #660;">}</=
span></div></code></div><div><br></div><div>My overall point is that we'=
;re not talking about the<i> same function</i>. You're creating a new f=
unction with a distinct meaning and a different contract.</div><div><br></d=
iv><div>You are essentially saying that the language should prevent us from=
ever making functions with narrow contracts. I do not hold to that.<i></i>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<i></i></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/7889e750-bace-45ad-bc5a-e421a2f56626%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7889e750-bace-45ad-bc5a-e421a2f56626=
%40isocpp.org</a>.<br />
------=_Part_3200_108903027.1513793426097--
------=_Part_3199_2053756358.1513793426096--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Wed, 20 Dec 2017 19:12:48 +0100
Raw View
--94eb2c05b4baeec6bd0560c98715
Content-Type: text/plain; charset="UTF-8"
> Can you present evidence for the existence of this "vast majority" who
are willing to have entire codebases be broken by this?
Can you present evidence that "entire codebases" will be broken by this? It
seems as if you're suggesting that "entire codebases" depend on UB. That
would be an extraordinary claim.
> As for completely empty functions with return values, even those have a
purpose: metaprogramming and reflection. You can use `decltype` and
unevaluated contexts to inquire about parameters and the return type, all
without actually calling the function.
This is another straw man. Such functions can certainly be trivially
defined to contain no UB, as demonstrated. The fact that you are deducing
return types of them means that at some point, somehow, directly or
indirectly, you intend eventually to call them.
Let's leave definitionless functions whose sole use is in metaprogramming
out of this. If there is no function body defined then we are talking about
a signature, not a function.
> Did he forget to compile with warnings? In my experience, compilers will
warn on failing to return something if there is no return statement at all.
Clearly he did. Does this not underline my position perfectly clearly? C++
should make making mistakes hard by default, not easy by default. Even vets
are caught out.
> Easily said, but not easily demonstrated.
It's a shame I did not log every time I have found this bug in a
developer's code. The man-hours spent doing just that over the past 20
years would easily outweigh the cost of me personally re-writing a very
large proportion of the "UB because performance" functions in existence.
On 20 December 2017 at 18:59, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, December 20, 2017 at 12:02:32 PM UTC-5, Richard Hodges wrote:
>>
>> > The churn comes from functions that don't have a return or an annotation
>> that that is intended,
>>
>> We have already seen that these "intended no return" functions result in
>> worse code. This is precisely because the compiler cannot deduce intent. In
>> every other conversation about UB, there would be unanimous agreement that
>> UB is to be avoided.
>>
>
> No, we would not find "unanimous agreement" on such things. You didn't
> agree that this should be a compile error:
>
> int *ptr = nullptr;
> *ptr = 5;
>
> Equally importantly, you seem to be arguing from a position of ideology:
> that UB is bad and therefore doing* anything*, no matter how painful, to
> remove UB is unquestionably good.
>
> In the real world, that's not how things work. Any change must take into
> account the cost to users.
>
> For some unfathomable reason, on this issue, some wish to defy the
>> evidence before them and continue to demand the right to write UB functions
>> without a diagnostic - to the detriment of the vast majority who simply
>> want functions to do defined things.
>>
>
> Can you present evidence for the existence of this "vast majority" who are
> willing to have entire codebases be broken by this?
>
> How do I know that the majority want functions to do defined things?
>> Because the universally accepted process for writing and testing code is to
>> write tests. What do tests do? They verify the claims of the function's
>> author. What do UB functions do? They refuse to make any claims. Is that
>> testable? No. Is it useful? Quad erat demonstrandum, no.
>>
>
> The fallacy in your argument is "They refuse to make any claims." That is
> untrue. The enum/switch example that's been tossed around very much makes
> claims: if you pass in an enumerator of those types, then you get a string
> back. That's the claim, and it is testable.
>
> As for completely empty functions with return values, even those have a
> purpose: metaprogramming and reflection. You can use `decltype` and
> unevaluated contexts to inquire about parameters and the return type, all
> without actually calling the function.
>
> So no, your statement is not valid.
>
> > but since it's not, and there's existing valid code and breakage
>> thereof to consider
>>
>> Do you remember when we moved from K&R function declarations to ANSI
>> function declarations? I do.
>>
>
> I also remember other facts:
>
> 1) ANSI function declarations were already widely used before C89, as
> compiler extensions.
> 2) We have many orders of magnitude more code now than we did back then.
> 3) K&R function declarations* are still legal*.
>
> Everyone coped just fine. No-one demanded the right to continue to write
>>
>> func(x,y)
>> double x;
>> int y;
>> {
>> if (x > 0)
>> return y;
>> }
>>
>> **this** is the origin on the UB on non-specified returns. Almost
>> everything else got fixed. This got forgotten.
>>
>>
>> > trying to mandate a diagnostic for a missing return is fighting an
>> uphill battle.
>>
>> One of my engineers, an experienced guy with 20 years writing c++, spent
>> the first half of today diagnosing something that turned out to be a result
>> of exactly this. Forgetting to return the shared_ptr he had created. In a
>> function he had written 30 minutes prior. The crash occurred in thread 3,
>> nowhere near the offending code that was executed in thread 1.
>>
>> Half a day. Over something the compiler could, no, *should* have told him
>> on the first compile.
>>
>
> Did he forget to compile with warnings? In my experience, compilers will
> warn on failing to return something if there is no return statement at all.
>
> This happens a lot, all over the world, every day. The combined loss of
>> productivity easily outweighs the minor inconvenience of fixing a few
>> lazily-written, demonstrably suboptimal, leaf functions.
>>
>
> Easily said, but not easily demonstrated.
>
>> --
> 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/e34e4113-e0b4-4e6e-
> 99c2-281bb0c6bd9d%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e34e4113-e0b4-4e6e-99c2-281bb0c6bd9d%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CALvx3hZAUmsOr_OtGpU%2B7Y9bvgkBYHAoYPR-J-xO6V_qHxQ2Ew%40mail.gmail.com.
--94eb2c05b4baeec6bd0560c98715
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">Can you present=
evidence for the existence of this "vast majority" who are willi=
ng to have entire codebases be broken by this?</span><div><span style=3D"fo=
nt-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">Can =
you present evidence that "entire codebases" will be broken by th=
is? It seems as if you're suggesting that "entire codebases" =
depend on UB. That would be an extraordinary claim.</span></div><div><span =
style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:1=
2.8px">>=C2=A0</span><span style=3D"font-size:12.8px">As for completely =
empty functions with return values, even those have a purpose: metaprogramm=
ing and reflection. You can use `decltype` and unevaluated contexts to inqu=
ire about parameters and the return type, all without actually calling the =
function.</span></div><div><span style=3D"font-size:12.8px"><br></span></di=
v><div><span style=3D"font-size:12.8px">This is another straw man. Such fun=
ctions can certainly be trivially defined to contain no UB, as demonstrated=
.. The fact that you are deducing return types of them means that at some po=
int, somehow, directly or indirectly, you intend eventually to call them.=
=C2=A0</span></div><div><span style=3D"font-size:12.8px"><br></span></div><=
div><span style=3D"font-size:12.8px">Let's leave definitionless functio=
ns whose sole use is in metaprogramming out of this. If there is no functio=
n body defined then we are talking about a signature, not a function.</span=
></div><div><span style=3D"font-size:12.8px"><br></span></div><div><span st=
yle=3D"font-size:12.8px">>=C2=A0</span><span style=3D"font-size:12.8px">=
Did he forget to compile with warnings? In my experience, compilers will wa=
rn on failing to return something if there is no return statement at all.</=
span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><spa=
n style=3D"font-size:12.8px">Clearly he did. Does this not underline my pos=
ition perfectly clearly? C++ should make making mistakes hard by default, n=
ot easy by default. Even vets are caught out.</span></div><div><span style=
=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px=
">>=C2=A0</span><span style=3D"font-size:12.8px">Easily said, but not ea=
sily demonstrated.</span></div><div><span style=3D"font-size:12.8px"><br></=
span></div><div><span style=3D"font-size:12.8px">It's a shame I did not=
log every time I have found this bug in a developer's code. The man-ho=
urs spent doing just that over the past 20 years would easily outweigh the =
cost of me personally re-writing a very large proportion of the "UB be=
cause performance" functions in existence.</span></div><div><span styl=
e=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8p=
x"><br></span></div><div><span style=3D"font-size:12.8px"><br></span></div>=
<div><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"=
font-size:12.8px"><br></span></div></div><div class=3D"gmail_extra"><br><di=
v class=3D"gmail_quote">On 20 December 2017 at 18:59, Nicol Bolas <span dir=
=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmcke=
sson@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr"><span class=3D"">On Wednesday, December 20, 2017 at 12:02:32 P=
M UTC-5, Richard Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">The churn comes from=
functions that don't have a return or an=C2=A0</span><span style=3D"fo=
nt-size:12.8px">annotation that that is intended,</span><div><span style=3D=
"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">W=
e have already seen that these "intended no return" functions res=
ult in worse code. This is precisely because the compiler cannot deduce int=
ent. In every other conversation about UB, there would be unanimous agreeme=
nt that UB is to be avoided.</span></div></div></blockquote><div><br></div>=
</span><div>No, we would not find "unanimous agreement" on such t=
hings. You didn't agree that this should be a compile error:</div><div>=
<br></div><div class=3D"m_-570854204507205193prettyprint" style=3D"border:1=
px solid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,250=
,250)"><code class=3D"m_-570854204507205193prettyprint"><div class=3D"m_-57=
0854204507205193subprettyprint"><span class=3D"m_-570854204507205193styled-=
by-prettify" style=3D"color:#008">int</span><span class=3D"m_-5708542045072=
05193styled-by-prettify" style=3D"color:#000"> </span><span class=3D"m_-570=
854204507205193styled-by-prettify" style=3D"color:#660">*</span><span class=
=3D"m_-570854204507205193styled-by-prettify" style=3D"color:#000">ptr </spa=
n><span class=3D"m_-570854204507205193styled-by-prettify" style=3D"color:#6=
60">=3D</span><span class=3D"m_-570854204507205193styled-by-prettify" style=
=3D"color:#000"> </span><span class=3D"m_-570854204507205193styled-by-prett=
ify" style=3D"color:#008">nullptr</span><span class=3D"m_-57085420450720519=
3styled-by-prettify" style=3D"color:#660">;</span><span class=3D"m_-5708542=
04507205193styled-by-prettify" style=3D"color:#000"><br></span><span class=
=3D"m_-570854204507205193styled-by-prettify" style=3D"color:#660">*</span><=
span class=3D"m_-570854204507205193styled-by-prettify" style=3D"color:#000"=
>ptr </span><span class=3D"m_-570854204507205193styled-by-prettify" style=
=3D"color:#660">=3D</span><span class=3D"m_-570854204507205193styled-by-pre=
ttify" style=3D"color:#000"> </span><span class=3D"m_-570854204507205193sty=
led-by-prettify" style=3D"color:#066">5</span><span class=3D"m_-57085420450=
7205193styled-by-prettify" style=3D"color:#660">;</span><span class=3D"m_-5=
70854204507205193styled-by-prettify" style=3D"color:#000"><br></span></div>=
</code></div><div><br></div><div>Equally importantly, you seem to be arguin=
g from a position of ideology: that UB is bad and therefore doing<i> anythi=
ng</i>, no matter how painful, to remove UB is unquestionably good.</div><d=
iv><br></div><div>In the real world, that's not how things work. Any ch=
ange must take into account the cost to users.<br></div><span class=3D""><d=
iv><i><br></i></div><blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div><span style=3D"font-size:12.8px">For some unfathomable reason, on th=
is issue, some wish to defy the evidence before them and continue to demand=
the right to write UB functions without a diagnostic - to the detriment of=
the vast majority who simply want functions to do defined things.</span></=
div></div></blockquote><div><br></div></span><div>Can you present evidence =
for the existence of this "vast majority" who are willing to have=
entire codebases be broken by this?</div><span class=3D""><div><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><span style=3D=
"font-size:12.8px">How do I know that the majority want functions to do def=
ined things? Because the universally accepted process for writing and testi=
ng code is to write tests. What do tests do? They verify the claims of the =
function's author. What do UB functions do? They refuse to make any cla=
ims. </span><span style=3D"font-size:12.8px">Is that testable? No. Is it us=
eful? Quad erat demonstrandum, no.</span></div></div></blockquote><div><br>=
</div></span><div>The fallacy in your argument is "<span style=3D"disp=
lay:inline!important;float:none;background-color:transparent;color:rgb(34,3=
4,34);font-family:"Arial","Helvetica",sans-serif;font-s=
ize:12.8px;font-style:normal;font-variant:normal;font-weight:400;letter-spa=
cing:normal;text-align:left;text-decoration:none;text-indent:0px;text-trans=
form:none;white-space:normal;word-spacing:0px">They refuse to make any clai=
ms." That is untrue. The enum/switch example that's been tossed ar=
ound very much makes claims: if you pass in an enumerator of those types, t=
hen you get a string back. That's the claim, and it is testable.</span>=
</div><div><br></div><div>As for completely empty functions with return val=
ues, even those have a purpose: metaprogramming and reflection. You can use=
`decltype` and unevaluated contexts to inquire about parameters and the re=
turn type, all without actually calling the function.</div><div><br></div><=
div>So no, your statement is not valid.</div><span class=3D""><div><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><span style=
=3D"font-size:12.8px">>=C2=A0</span><span style=3D"font-size:12.8px">but=
since it's not, and=C2=A0</span><span style=3D"font-size:12.8px">there=
's existing valid code=C2=A0</span><span style=3D"font-size:12.8px">and=
breakage thereof to consider</span></div><div><span style=3D"font-size:12.=
8px"><br></span></div><div><span style=3D"font-size:12.8px">Do you remember=
when we moved from K&R function declarations to ANSI function declarat=
ions? I do.</span></div></div></blockquote><div><br></div></span><div>I als=
o remember other facts:</div><div><br></div><div>1) ANSI function declarati=
ons were already widely used before C89, as compiler extensions.</div><div>=
2) We have many orders of magnitude more code now than we did back then.</d=
iv><div>3) K&R function declarations<i> are still legal</i>.</div><div>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span cl=
ass=3D""><div><span style=3D"font-size:12.8px">Everyone coped just fine. No=
-one demanded the right to continue to write</span></div><div><span style=
=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px=
"><font face=3D"monospace, monospace">func(x,y)</font></span></div><div><sp=
an style=3D"font-size:12.8px"><font face=3D"monospace, monospace">double x;=
</font></span></div><div><span style=3D"font-size:12.8px"><font face=3D"mon=
ospace, monospace">int y;</font></span></div><div><span style=3D"font-size:=
12.8px"><font face=3D"monospace, monospace">{</font></span></div><div><span=
style=3D"font-size:12.8px"><font face=3D"monospace, monospace">=C2=A0 if (=
x > 0)</font></span></div><div><span style=3D"font-size:12.8px"><font fa=
ce=3D"monospace, monospace">=C2=A0 =C2=A0 return y;</font></span></div><div=
><span style=3D"font-size:12.8px"><font face=3D"monospace, monospace">}</fo=
nt></span></div><div><span style=3D"font-size:12.8px"><br></span></div><div=
><span style=3D"font-size:12.8px">**this** is the origin on the UB on non-s=
pecified returns. Almost everything else got fixed. This got forgotten.</sp=
an></div><div><span style=3D"font-size:12.8px"><br></span></div><div><span =
style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:1=
2.8px">>=C2=A0</span><span style=3D"font-size:12.8px">trying to mandate =
a diagnostic for a=C2=A0</span><span style=3D"font-size:12.8px">missing ret=
urn is fighting=C2=A0</span><span style=3D"font-size:12.8px">an uphill batt=
le.</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div=
><span style=3D"font-size:12.8px">One of my engineers, an experienced guy w=
ith 20 years writing c++, spent the first half of today diagnosing somethin=
g that turned out to be a result of exactly this. Forgetting to return the =
shared_ptr he had created. In a function he had written 30 minutes prior. T=
he crash occurred in thread 3, nowhere near the offending code that was exe=
cuted in thread 1.</span></div><div><span style=3D"font-size:12.8px"><br></=
span></div></span><span class=3D""><div><span style=3D"font-size:12.8px">Ha=
lf a day. Over something the compiler could, no, *should* have told him on =
the first compile.</span></div></span></div></blockquote><div><br></div><di=
v>Did he forget to compile with warnings? In my experience, compilers will =
warn on failing to return something if there is no return statement at all.=
</div><span class=3D""><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div><span style=3D"font-size:12.8px">This happens a lo=
t, all over the world, every day. </span><span style=3D"font-size:12.8px">T=
he combined loss of productivity easily outweighs the minor inconvenience o=
f fixing a few lazily-written, demonstrably suboptimal, leaf functions.</sp=
an></div></div></blockquote><div><br></div></span><div>Easily said, but not=
easily demonstrated.<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
</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/e34e4113-e0b4-4e6e-99c2-281bb0c6bd9d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/e34e=
4113-e0b4-4e6e-<wbr>99c2-281bb0c6bd9d%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/CALvx3hZAUmsOr_OtGpU%2B7Y9bvgkBYHAoYP=
R-J-xO6V_qHxQ2Ew%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZAUmsOr_=
OtGpU%2B7Y9bvgkBYHAoYPR-J-xO6V_qHxQ2Ew%40mail.gmail.com</a>.<br />
--94eb2c05b4baeec6bd0560c98715--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Wed, 20 Dec 2017 19:23:31 +0100
Raw View
--001a113fbc084d0f5a0560c9ae6b
Content-Type: text/plain; charset="UTF-8"
> This removes two pointless lambdas. The use of `default` makes it clear
what the function's contract is: that for `make_floom`, it is perfectly
valid to call:
The reason for writing it this way is to address the concern expressed
above the 'default:' clause removing the possibility of a warning on an
unhandled case. It also addresses the performance concern. The point is
that this is one of a myriad of ways to provide a better solution than UB
when it comes to return values.
I am well aware of the various ways the function can be expressed, and the
difference between exception-based contracts and exceptionless contracts.
The contract of the example function is (as you well know):
* I won't throw unless I'm out of memory
* valid arguments are E1 and E2
* if you pass anything other than that, I'll treat it as E2
Which is unequivocally better than the alternative:
* I won't throw unless I'm out of memory
* valid arguments are E1 and E2
* if you pass anything other than that, I'll probably crash at some
undefined point in the future if you're lucky. If you're not, I might just
expose your passwords to someone, corrupt the 1000-hour-old campaign save,
or invert USDJPY or something. Who knows? Who even cares? What does it all
mean anyway?
Now, for the record, I prefer exceptions when contracts are violated, but
I'm not mandating that here.
I'm merely responding to the concerns of a sceptical
game/FX/fintech/protein modelling/flight control system developer who
wrongly thinks he is buying performance with UB. He's not. He's buying UB
with UB, and gaining nothing.
On 20 December 2017 at 19:10, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, December 20, 2017 at 12:52:23 PM UTC-5, Richard Hodges wrote:
>>
>> To continue...
>>
>> Here's a function which looks a little like our better foo() function,
>> but returns a large, complex object.
>>
>> Note how this too can be written in such a way as to exhibit no UB ever,
>> and is also optimally efficient:
>>
>> struct floom
>> {
>> std::string a,b,c,d,e,f,g;
>> };
>>
>> floom make_floom(Values x)
>> {
>> auto make_e1 = [] {
>> return floom { "aa", "ab", "ac", "ad", "ae", "af", "ag"};
>> };
>>
>> auto make_e2 = [] {
>> return floom { "a", "b", "c", "d", "e", "f", "g"};
>> };
>>
>> switch(x) {
>> case E1:
>> return make_e1();
>> case E2:
>> return make_e2();
>> }
>>
>> return make_e2();
>> }
>>
>
> I'm not really sure what the point of this example is. The expected way to
> write this code is:
>
> floom make_floom(Values x)
> {
> switch(x) {
>
> case E1:
> return { "aa", "ab", "ac", "ad", "ae", "af", "ag"};
> default:
> return { "a", "b", "c", "d", "e", "f", "g"};
> }
> }
>
> This removes two pointless lambdas. The use of `default` makes it clear
> what the function's contract is: that for `make_floom`, it is perfectly
> valid to call:
>
> make_floom(std::numeric_limits<std::underlying_type_t<Values>>::max);
>
> That is the contract for the code you have written, so it should clearly
> be spelled out in your code. And using `default` does that.
>
> However, if what you want to communicate is that it's not legal to pass
> values other than the specific enumerators, then you do this:
>
> floom make_floom(Values x)
> {
> switch(x) {
> case E1:
> return { "aa", "ab", "ac", "ad", "ae", "af", "ag"};
> case E2:
> return { "a", "b", "c", "d", "e", "f", "g"};
> }
>
> throw some_exception{};
> }
>
> Or you make use of `expected` or similar error code types.
>
> But even this puts the entire range of legal `std::underlying_type_t<Values>`
> as part of the function's acceptable values. If you want a narrow contract
> like `vector::operator[]`, you do this:
>
> floom make_floom(Values x)
> {
> switch(x) {
> case E1:
> return { "aa", "ab", "ac", "ad", "ae", "af", "ag"};
> case E2:
> return { "a", "b", "c", "d", "e", "f", "g"};
> }
> }
>
> My overall point is that we're not talking about the* same function*.
> You're creating a new function with a distinct meaning and a different
> contract.
>
> You are essentially saying that the language should prevent us from ever
> making functions with narrow contracts. I do not hold to that.
>
>> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/7889e750-bace-45ad-
> bc5a-e421a2f56626%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7889e750-bace-45ad-bc5a-e421a2f56626%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CALvx3hbBJ%3DBg1%2BVJMOUnFPw6Ztmqva-eny%2BfXKEUbwZ%2BCSYGmw%40mail.gmail.com.
--001a113fbc084d0f5a0560c9ae6b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">This removes tw=
o pointless lambdas. The use of `default` makes it clear what the function&=
#39;s contract is: that for `make_floom`, it is perfectly valid to call:</s=
pan><div><span style=3D"font-size:12.8px"><br></span></div><div><span style=
=3D"font-size:12.8px">The reason for writing it this way is to address the =
concern expressed above the 'default:' clause removing the possibil=
ity of a warning on an unhandled case. It also addresses the performance co=
ncern. The point is that this is one of a myriad of ways to provide a bette=
r solution than UB when it comes to return values.</span></div><div><span s=
tyle=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12=
..8px">I am well aware of the various ways the function can be expressed, an=
d the difference between exception-based contracts and exceptionless contra=
cts.</span></div><div><span style=3D"font-size:12.8px"><br></span></div><di=
v><span style=3D"font-size:12.8px">The contract of the example function is =
(as you well know):</span></div><div><span style=3D"font-size:12.8px"><br><=
/span></div><div><span style=3D"font-size:12.8px">* I won't throw unles=
s I'm out of memory</span></div><div><span style=3D"font-size:12.8px">*=
valid arguments are E1 and E2</span></div><div><span style=3D"font-size:12=
..8px">* if you pass anything other than that, I'll treat it as E2</span=
></div><div><span style=3D"font-size:12.8px"><br></span></div><div><span st=
yle=3D"font-size:12.8px">Which is unequivocally better than the alternative=
:</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><=
div><span style=3D"font-size:12.8px">* I won't throw unless I'm out=
of memory</span></div><div><span style=3D"font-size:12.8px">* valid argume=
nts are E1 and E2</span></div><div><span style=3D"font-size:12.8px">* if yo=
u pass anything other than that, I'll probably crash at some undefined =
point in the future if you're lucky. If you're not, I might just ex=
pose your passwords to someone, corrupt the 1000-hour-old campaign save, or=
invert USDJPY or something. Who knows? Who even cares? What does it all me=
an anyway?</span></div></div><div><span style=3D"font-size:12.8px"><br></sp=
an></div><div><span style=3D"font-size:12.8px">Now, for the record, I prefe=
r exceptions when contracts are violated, but I'm not mandating that he=
re.=C2=A0</span></div><div><span style=3D"font-size:12.8px"><br></span></di=
v><div><span style=3D"font-size:12.8px">I'm merely responding to the co=
ncerns of a sceptical game/FX/fintech/protein modelling/flight control syst=
em developer who wrongly thinks he is buying performance with UB. He's =
not. He's buying UB with UB, and gaining nothing.</span></div><div><spa=
n style=3D"font-size:12.8px">=C2=A0</span></div><div><br></div><div><br></d=
iv><div><span style=3D"font-size:12.8px"><br></span></div><div><span style=
=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px=
"><br></span></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail=
_quote">On 20 December 2017 at 19:10, Nicol Bolas <span dir=3D"ltr"><<a =
href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</=
a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><sp=
an class=3D"">On Wednesday, December 20, 2017 at 12:52:23 PM UTC-5, Richard=
Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">To c=
ontinue...<div><br></div><div>Here's a function which looks a little li=
ke our better foo() function, but returns a large, complex object.</div><di=
v><br></div><div>Note how this too can be written in such a way as to exhib=
it no UB ever, and is also optimally efficient:</div><div><br></div><div><d=
iv style=3D"background-color:rgb(255,255,254);line-height:21px"><div style=
=3D"color:rgb(0,0,0);font-size:14px;white-space:pre-wrap"><font face=3D"mon=
ospace, monospace"><span style=3D"color:rgb(0,0,255)">struct</span> floom</=
font></div><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre-wr=
ap"><font face=3D"monospace, monospace">{</font></div><div style=3D"color:r=
gb(0,0,0);font-size:14px;white-space:pre-wrap"><font face=3D"monospace, mon=
ospace"> std::string a,b,c,d,e,f,g;</font></div><div style=3D"color:rgb(=
0,0,0);font-size:14px;white-space:pre-wrap"><font face=3D"monospace, monosp=
ace">};</font></div><font face=3D"monospace, monospace" style=3D"color:rgb(=
0,0,0);font-size:14px;white-space:pre-wrap"><br></font><div style=3D"color:=
rgb(0,0,0);font-size:14px;white-space:pre-wrap"><font face=3D"monospace, mo=
nospace">floom make_floom(Values x)</font></div><div style=3D"color:rgb(0,0=
,0);font-size:14px;white-space:pre-wrap"><font face=3D"monospace, monospace=
">{</font></div><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:p=
re-wrap"><font face=3D"monospace, monospace"> <span style=3D"color:rgb(0=
,0,255)">auto</span> make_e1 =3D [] {</font></div><div style=3D"color:rgb(0=
,0,0);font-size:14px;white-space:pre-wrap"><font face=3D"monospace, monospa=
ce"> <span style=3D"color:rgb(0,0,255)">return</span> floom { <span =
style=3D"color:rgb(163,21,21)">"aa"</span>, <span style=3D"color:=
rgb(163,21,21)">"ab"</span>, <span style=3D"color:rgb(163,21,21)"=
>"ac"</span>, <span style=3D"color:rgb(163,21,21)">"ad"=
</span>, <span style=3D"color:rgb(163,21,21)">"ae"</span>, <span =
style=3D"color:rgb(163,21,21)">"af"</span>, <span style=3D"color:=
rgb(163,21,21)">"ag"</span>};</font></div><div style=3D"color:rgb=
(0,0,0);font-size:14px;white-space:pre-wrap"><font face=3D"monospace, monos=
pace"> };</font></div><font face=3D"monospace, monospace" style=3D"color=
:rgb(0,0,0);font-size:14px;white-space:pre-wrap"><br></font><div style=3D"c=
olor:rgb(0,0,0);font-size:14px;white-space:pre-wrap"><font face=3D"monospac=
e, monospace"> <span style=3D"color:rgb(0,0,255)">auto</span> make_e2 =
=3D [] {</font></div><div style=3D"color:rgb(0,0,0);font-size:14px;white-sp=
ace:pre-wrap"><font face=3D"monospace, monospace"> <span style=3D"co=
lor:rgb(0,0,255)">return</span> floom { <span style=3D"color:rgb(163,21,21)=
">"a"</span>, <span style=3D"color:rgb(163,21,21)">"b"<=
/span>, <span style=3D"color:rgb(163,21,21)">"c"</span>, <span st=
yle=3D"color:rgb(163,21,21)">"d"</span>, <span style=3D"color:rgb=
(163,21,21)">"e"</span>, <span style=3D"color:rgb(163,21,21)">&qu=
ot;f"</span>, <span style=3D"color:rgb(163,21,21)">"g"</span=
>};</font></div><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:p=
re-wrap"><font face=3D"monospace, monospace"> };</font></div><font face=
=3D"monospace, monospace" style=3D"color:rgb(0,0,0);font-size:14px;white-sp=
ace:pre-wrap"><br></font><div style=3D"color:rgb(0,0,0);font-size:14px;whit=
e-space:pre-wrap"><font face=3D"monospace, monospace"> <span style=3D"co=
lor:rgb(0,0,255)">switch</span>(x) {</font></div><div style=3D"color:rgb(0,=
0,0);font-size:14px;white-space:pre-wrap"><font face=3D"monospace, monospac=
e"> <span style=3D"color:rgb(0,0,255)">case</span> E1:</font></div><div =
style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre-wrap"><font face=
=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">return=
</span> make_e1();</font></div><div style=3D"color:rgb(0,0,0);font-size:14p=
x;white-space:pre-wrap"><font face=3D"monospace, monospace"> <span style=
=3D"color:rgb(0,0,255)">case</span> E2:</font></div><div style=3D"color:rgb=
(0,0,0);font-size:14px;white-space:pre-wrap"><font face=3D"monospace, monos=
pace"> <span style=3D"color:rgb(0,0,255)">return</span> make_e2();</=
font></div><div style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre-wr=
ap"><font face=3D"monospace, monospace"> }</font></div><font face=3D"mon=
ospace, monospace" style=3D"color:rgb(0,0,0);font-size:14px;white-space:pre=
-wrap"><br></font><div style=3D"color:rgb(0,0,0);font-size:14px;white-space=
:pre-wrap"><font face=3D"monospace, monospace"> <span style=3D"color:rgb=
(0,0,255)">return</span> make_e2();</font></div><div style=3D"color:rgb(0,0=
,0);font-size:14px;white-space:pre-wrap"><font face=3D"monospace, monospace=
">}</font></div></div></div></div></blockquote><div><br></div></span><div>I=
'm not really sure what the point of this example is. The expected way =
to write this code is:</div><div><br></div><div class=3D"m_7434617114999168=
20prettyprint" style=3D"border:1px solid rgb(187,187,187);word-wrap:break-w=
ord;background-color:rgb(250,250,250)"><code class=3D"m_743461711499916820p=
rettyprint"><div class=3D"m_743461711499916820subprettyprint"><span class=
=3D"m_743461711499916820styled-by-prettify" style=3D"color:#000">floom make=
_floom</span><span class=3D"m_743461711499916820styled-by-prettify" style=
=3D"color:#660">(</span><span class=3D"m_743461711499916820styled-by-pretti=
fy" style=3D"color:#606">Values</span><span class=3D"m_743461711499916820st=
yled-by-prettify" style=3D"color:#000"> x</span><span class=3D"m_7434617114=
99916820styled-by-prettify" style=3D"color:#660">)</span><span class=3D"m_7=
43461711499916820styled-by-prettify" style=3D"color:#000"><br></span><span =
class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#660">{</sp=
an><span class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#0=
00"><br>=C2=A0 =C2=A0 </span><span class=3D"m_743461711499916820styled-by-p=
rettify" style=3D"color:#008">switch</span><span class=3D"m_743461711499916=
820styled-by-prettify" style=3D"color:#660">(</span><span class=3D"m_743461=
711499916820styled-by-prettify" style=3D"color:#000">x</span><span class=3D=
"m_743461711499916820styled-by-prettify" style=3D"color:#660">)</span><span=
class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#000"> </s=
pan><span class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#=
660">{</span><span class=3D"m_743461711499916820styled-by-prettify" style=
=3D"color:#000"><br><br>=C2=A0 =C2=A0 </span><span class=3D"m_7434617114999=
16820styled-by-prettify" style=3D"color:#008">case</span><span class=3D"m_7=
43461711499916820styled-by-prettify" style=3D"color:#000"> E1</span><span c=
lass=3D"m_743461711499916820styled-by-prettify" style=3D"color:#660">:</spa=
n><span class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#00=
0"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span class=3D"m_7434617114999168=
20styled-by-prettify" style=3D"color:#008">return</span><span class=3D"m_74=
3461711499916820styled-by-prettify" style=3D"color:#000"> </span><span clas=
s=3D"m_743461711499916820styled-by-prettify" style=3D"color:#660">{</span><=
span class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#000">=
</span><span class=3D"m_743461711499916820styled-by-prettify" style=3D"col=
or:#080">"aa"</span><span class=3D"m_743461711499916820styled-by-=
prettify" style=3D"color:#660">,</span><span class=3D"m_743461711499916820s=
tyled-by-prettify" style=3D"color:#000"> </span><span class=3D"m_7434617114=
99916820styled-by-prettify" style=3D"color:#080">"ab"</span><span=
class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#660">,</s=
pan><span class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#=
000"> </span><span class=3D"m_743461711499916820styled-by-prettify" style=
=3D"color:#080">"ac"</span><span class=3D"m_743461711499916820sty=
led-by-prettify" style=3D"color:#660">,</span><span class=3D"m_743461711499=
916820styled-by-prettify" style=3D"color:#000"> </span><span class=3D"m_743=
461711499916820styled-by-prettify" style=3D"color:#080">"ad"</spa=
n><span class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#66=
0">,</span><span class=3D"m_743461711499916820styled-by-prettify" style=3D"=
color:#000"> </span><span class=3D"m_743461711499916820styled-by-prettify" =
style=3D"color:#080">"ae"</span><span class=3D"m_7434617114999168=
20styled-by-prettify" style=3D"color:#660">,</span><span class=3D"m_7434617=
11499916820styled-by-prettify" style=3D"color:#000"> </span><span class=3D"=
m_743461711499916820styled-by-prettify" style=3D"color:#080">"af"=
</span><span class=3D"m_743461711499916820styled-by-prettify" style=3D"colo=
r:#660">,</span><span class=3D"m_743461711499916820styled-by-prettify" styl=
e=3D"color:#000"> </span><span class=3D"m_743461711499916820styled-by-prett=
ify" style=3D"color:#080">"ag"</span><span class=3D"m_74346171149=
9916820styled-by-prettify" style=3D"color:#660">};</span><span class=3D"m_7=
43461711499916820styled-by-prettify" style=3D"color:#000"><br>=C2=A0 =C2=A0=
</span><span class=3D"m_743461711499916820styled-by-prettify" style=3D"col=
or:#008">default</span><span class=3D"m_743461711499916820styled-by-prettif=
y" style=3D"color:#660">:</span><span class=3D"m_743461711499916820styled-b=
y-prettify" style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><sp=
an class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#008">re=
turn</span><span class=3D"m_743461711499916820styled-by-prettify" style=3D"=
color:#000"> </span><span class=3D"m_743461711499916820styled-by-prettify" =
style=3D"color:#660">{</span><span class=3D"m_743461711499916820styled-by-p=
rettify" style=3D"color:#000"> </span><span class=3D"m_743461711499916820st=
yled-by-prettify" style=3D"color:#080">"a"</span><span class=3D"m=
_743461711499916820styled-by-prettify" style=3D"color:#660">,</span><span c=
lass=3D"m_743461711499916820styled-by-prettify" style=3D"color:#000"> </spa=
n><span class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#08=
0">"b"</span><span class=3D"m_743461711499916820styled-by-prettif=
y" style=3D"color:#660">,</span><span class=3D"m_743461711499916820styled-b=
y-prettify" style=3D"color:#000"> </span><span class=3D"m_74346171149991682=
0styled-by-prettify" style=3D"color:#080">"c"</span><span class=
=3D"m_743461711499916820styled-by-prettify" style=3D"color:#660">,</span><s=
pan class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#000"> =
</span><span class=3D"m_743461711499916820styled-by-prettify" style=3D"colo=
r:#080">"d"</span><span class=3D"m_743461711499916820styled-by-pr=
ettify" style=3D"color:#660">,</span><span class=3D"m_743461711499916820sty=
led-by-prettify" style=3D"color:#000"> </span><span class=3D"m_743461711499=
916820styled-by-prettify" style=3D"color:#080">"e"</span><span cl=
ass=3D"m_743461711499916820styled-by-prettify" style=3D"color:#660">,</span=
><span class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#000=
"> </span><span class=3D"m_743461711499916820styled-by-prettify" style=3D"c=
olor:#080">"f"</span><span class=3D"m_743461711499916820styled-by=
-prettify" style=3D"color:#660">,</span><span class=3D"m_743461711499916820=
styled-by-prettify" style=3D"color:#000"> </span><span class=3D"m_743461711=
499916820styled-by-prettify" style=3D"color:#080">"g"</span><span=
class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#660">};</=
span><span class=3D"m_743461711499916820styled-by-prettify" style=3D"color:=
#000"><br>=C2=A0 =C2=A0 </span><span class=3D"m_743461711499916820styled-by=
-prettify" style=3D"color:#660">}</span><span class=3D"m_743461711499916820=
styled-by-prettify" style=3D"color:#000"><br></span><span class=3D"m_743461=
711499916820styled-by-prettify" style=3D"color:#660">}</span></div></code><=
/div><div><br></div><div>This removes two pointless lambdas. The use of `de=
fault` makes it clear what the function's contract is: that for `make_f=
loom`, it is perfectly valid to call:</div><div><br></div><div class=3D"m_7=
43461711499916820prettyprint" style=3D"border:1px solid rgb(187,187,187);wo=
rd-wrap:break-word;background-color:rgb(250,250,250)"><code class=3D"m_7434=
61711499916820prettyprint"><div class=3D"m_743461711499916820subprettyprint=
"><span class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#00=
0">make_floom</span><span class=3D"m_743461711499916820styled-by-prettify" =
style=3D"color:#660">(</span><span class=3D"m_743461711499916820styled-by-p=
rettify" style=3D"color:#000">std</span><span class=3D"m_743461711499916820=
styled-by-prettify" style=3D"color:#660">::</span><span class=3D"m_74346171=
1499916820styled-by-prettify" style=3D"color:#000">numeric_limits</span><sp=
an class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#660"><w=
br><</span><span class=3D"m_743461711499916820styled-by-prettify" style=
=3D"color:#000">std</span><span class=3D"m_743461711499916820styled-by-pret=
tify" style=3D"color:#660">::</span><span class=3D"m_743461711499916820styl=
ed-by-prettify" style=3D"color:#000">underlying_type_t</span><span class=3D=
"m_743461711499916820styled-by-prettify" style=3D"color:#660"><</span><s=
pan class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#606">V=
alues</span><span class=3D"m_743461711499916820styled-by-prettify" style=3D=
"color:#660"><wbr>>>::</span><span class=3D"m_743461711499916820style=
d-by-prettify" style=3D"color:#000">max</span><span class=3D"m_743461711499=
916820styled-by-prettify" style=3D"color:#660">);</span><span class=3D"m_74=
3461711499916820styled-by-prettify" style=3D"color:#000"><br></span></div><=
/code></div><br><div>That is the contract for the code you have written, so=
it should clearly be spelled out in your code. And using `default` does th=
at.</div><div><br></div><div>However, if what you want to communicate is th=
at it's not legal to pass values other than the specific enumerators, t=
hen you do this:</div><div><br></div><div class=3D"m_743461711499916820pret=
typrint" style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;ba=
ckground-color:rgb(250,250,250)"><code class=3D"m_743461711499916820prettyp=
rint"><div class=3D"m_743461711499916820subprettyprint"><span class=3D"m_74=
3461711499916820styled-by-prettify" style=3D"color:#000">floom make_floom</=
span><span class=3D"m_743461711499916820styled-by-prettify" style=3D"color:=
#660">(</span><span class=3D"m_743461711499916820styled-by-prettify" style=
=3D"color:#606">Values</span><span class=3D"m_743461711499916820styled-by-p=
rettify" style=3D"color:#000"> x</span><span class=3D"m_743461711499916820s=
tyled-by-prettify" style=3D"color:#660">)</span><span class=3D"m_7434617114=
99916820styled-by-prettify" style=3D"color:#000"><br></span><span class=3D"=
m_743461711499916820styled-by-prettify" style=3D"color:#660">{</span><span =
class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#000"><br>=
=C2=A0 =C2=A0 </span><span class=3D"m_743461711499916820styled-by-prettify"=
style=3D"color:#008">switch</span><span class=3D"m_743461711499916820style=
d-by-prettify" style=3D"color:#660">(</span><span class=3D"m_74346171149991=
6820styled-by-prettify" style=3D"color:#000">x</span><span class=3D"m_74346=
1711499916820styled-by-prettify" style=3D"color:#660">)</span><span class=
=3D"m_743461711499916820styled-by-prettify" style=3D"color:#000"> </span><s=
pan class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#660">{=
</span><span class=3D"m_743461711499916820styled-by-prettify" style=3D"colo=
r:#000"><br>=C2=A0 =C2=A0 </span><span class=3D"m_743461711499916820styled-=
by-prettify" style=3D"color:#008">case</span><span class=3D"m_7434617114999=
16820styled-by-prettify" style=3D"color:#000"> E1</span><span class=3D"m_74=
3461711499916820styled-by-prettify" style=3D"color:#660">:</span><span clas=
s=3D"m_743461711499916820styled-by-prettify" style=3D"color:#000"><br>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 </span><span class=3D"m_743461711499916820styled-b=
y-prettify" style=3D"color:#008">return</span><span class=3D"m_743461711499=
916820styled-by-prettify" style=3D"color:#000"> </span><span class=3D"m_743=
461711499916820styled-by-prettify" style=3D"color:#660">{</span><span class=
=3D"m_743461711499916820styled-by-prettify" style=3D"color:#000"> </span><s=
pan class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#080">&=
quot;aa"</span><span class=3D"m_743461711499916820styled-by-prettify" =
style=3D"color:#660">,</span><span class=3D"m_743461711499916820styled-by-p=
rettify" style=3D"color:#000"> </span><span class=3D"m_743461711499916820st=
yled-by-prettify" style=3D"color:#080">"ab"</span><span class=3D"=
m_743461711499916820styled-by-prettify" style=3D"color:#660">,</span><span =
class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#000"> </sp=
an><span class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#0=
80">"ac"</span><span class=3D"m_743461711499916820styled-by-prett=
ify" style=3D"color:#660">,</span><span class=3D"m_743461711499916820styled=
-by-prettify" style=3D"color:#000"> </span><span class=3D"m_743461711499916=
820styled-by-prettify" style=3D"color:#080">"ad"</span><span clas=
s=3D"m_743461711499916820styled-by-prettify" style=3D"color:#660">,</span><=
span class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#000">=
</span><span class=3D"m_743461711499916820styled-by-prettify" style=3D"col=
or:#080">"ae"</span><span class=3D"m_743461711499916820styled-by-=
prettify" style=3D"color:#660">,</span><span class=3D"m_743461711499916820s=
tyled-by-prettify" style=3D"color:#000"> </span><span class=3D"m_7434617114=
99916820styled-by-prettify" style=3D"color:#080">"af"</span><span=
class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#660">,</s=
pan><span class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#=
000"> </span><span class=3D"m_743461711499916820styled-by-prettify" style=
=3D"color:#080">"ag"</span><span class=3D"m_743461711499916820sty=
led-by-prettify" style=3D"color:#660">};</span><span class=3D"m_74346171149=
9916820styled-by-prettify" style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><s=
pan class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#008">c=
ase</span><span class=3D"m_743461711499916820styled-by-prettify" style=3D"c=
olor:#000"> E2</span><span class=3D"m_743461711499916820styled-by-prettify"=
style=3D"color:#660">:</span><span class=3D"m_743461711499916820styled-by-=
prettify" style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span=
class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#008">retu=
rn</span><span class=3D"m_743461711499916820styled-by-prettify" style=3D"co=
lor:#000"> </span><span class=3D"m_743461711499916820styled-by-prettify" st=
yle=3D"color:#660">{</span><span class=3D"m_743461711499916820styled-by-pre=
ttify" style=3D"color:#000"> </span><span class=3D"m_743461711499916820styl=
ed-by-prettify" style=3D"color:#080">"a"</span><span class=3D"m_7=
43461711499916820styled-by-prettify" style=3D"color:#660">,</span><span cla=
ss=3D"m_743461711499916820styled-by-prettify" style=3D"color:#000"> </span>=
<span class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#080"=
>"b"</span><span class=3D"m_743461711499916820styled-by-prettify"=
style=3D"color:#660">,</span><span class=3D"m_743461711499916820styled-by-=
prettify" style=3D"color:#000"> </span><span class=3D"m_743461711499916820s=
tyled-by-prettify" style=3D"color:#080">"c"</span><span class=3D"=
m_743461711499916820styled-by-prettify" style=3D"color:#660">,</span><span =
class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#000"> </sp=
an><span class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#0=
80">"d"</span><span class=3D"m_743461711499916820styled-by-pretti=
fy" style=3D"color:#660">,</span><span class=3D"m_743461711499916820styled-=
by-prettify" style=3D"color:#000"> </span><span class=3D"m_7434617114999168=
20styled-by-prettify" style=3D"color:#080">"e"</span><span class=
=3D"m_743461711499916820styled-by-prettify" style=3D"color:#660">,</span><s=
pan class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#000"> =
</span><span class=3D"m_743461711499916820styled-by-prettify" style=3D"colo=
r:#080">"f"</span><span class=3D"m_743461711499916820styled-by-pr=
ettify" style=3D"color:#660">,</span><span class=3D"m_743461711499916820sty=
led-by-prettify" style=3D"color:#000"> </span><span class=3D"m_743461711499=
916820styled-by-prettify" style=3D"color:#080">"g"</span><span cl=
ass=3D"m_743461711499916820styled-by-prettify" style=3D"color:#660">};</spa=
n><span class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#00=
0"><br>=C2=A0 =C2=A0 </span><span class=3D"m_743461711499916820styled-by-pr=
ettify" style=3D"color:#660">}</span><span class=3D"m_743461711499916820sty=
led-by-prettify" style=3D"color:#000"><br><br>=C2=A0 =C2=A0 </span><span cl=
ass=3D"m_743461711499916820styled-by-prettify" style=3D"color:#008">throw</=
span><span class=3D"m_743461711499916820styled-by-prettify" style=3D"color:=
#000"> some_exception</span><span class=3D"m_743461711499916820styled-by-pr=
ettify" style=3D"color:#660">{};</span><span class=3D"m_743461711499916820s=
tyled-by-prettify" style=3D"color:#000"><br></span><span class=3D"m_7434617=
11499916820styled-by-prettify" style=3D"color:#660">}</span></div></code></=
div><div><br></div><div>Or you make use of `expected` or similar error code=
types.</div><div><br></div><div>But even this puts the entire range of leg=
al `std::underlying_type_t<<wbr>Values>` as part of the function'=
s acceptable values. If you want a narrow contract like `vector::operator[]=
`, you do this:</div><div><br></div><div class=3D"m_743461711499916820prett=
yprint" style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;bac=
kground-color:rgb(250,250,250)"><code class=3D"m_743461711499916820prettypr=
int"><div class=3D"m_743461711499916820subprettyprint"><span class=3D"m_743=
461711499916820styled-by-prettify" style=3D"color:#000">floom make_floom</s=
pan><span class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#=
660">(</span><span class=3D"m_743461711499916820styled-by-prettify" style=
=3D"color:#606">Values</span><span class=3D"m_743461711499916820styled-by-p=
rettify" style=3D"color:#000"> x</span><span class=3D"m_743461711499916820s=
tyled-by-prettify" style=3D"color:#660">)</span><span class=3D"m_7434617114=
99916820styled-by-prettify" style=3D"color:#000"><br></span><span class=3D"=
m_743461711499916820styled-by-prettify" style=3D"color:#660">{</span><span =
class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#000"><br>=
=C2=A0 =C2=A0 </span><span class=3D"m_743461711499916820styled-by-prettify"=
style=3D"color:#008">switch</span><span class=3D"m_743461711499916820style=
d-by-prettify" style=3D"color:#660">(</span><span class=3D"m_74346171149991=
6820styled-by-prettify" style=3D"color:#000">x</span><span class=3D"m_74346=
1711499916820styled-by-prettify" style=3D"color:#660">)</span><span class=
=3D"m_743461711499916820styled-by-prettify" style=3D"color:#000"> </span><s=
pan class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#660">{=
</span><span class=3D"m_743461711499916820styled-by-prettify" style=3D"colo=
r:#000"><br>=C2=A0 =C2=A0 </span><span class=3D"m_743461711499916820styled-=
by-prettify" style=3D"color:#008">case</span><span class=3D"m_7434617114999=
16820styled-by-prettify" style=3D"color:#000"> E1</span><span class=3D"m_74=
3461711499916820styled-by-prettify" style=3D"color:#660">:</span><span clas=
s=3D"m_743461711499916820styled-by-prettify" style=3D"color:#000"><br>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 </span><span class=3D"m_743461711499916820styled-b=
y-prettify" style=3D"color:#008">return</span><span class=3D"m_743461711499=
916820styled-by-prettify" style=3D"color:#000"> </span><span class=3D"m_743=
461711499916820styled-by-prettify" style=3D"color:#660">{</span><span class=
=3D"m_743461711499916820styled-by-prettify" style=3D"color:#000"> </span><s=
pan class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#080">&=
quot;aa"</span><span class=3D"m_743461711499916820styled-by-prettify" =
style=3D"color:#660">,</span><span class=3D"m_743461711499916820styled-by-p=
rettify" style=3D"color:#000"> </span><span class=3D"m_743461711499916820st=
yled-by-prettify" style=3D"color:#080">"ab"</span><span class=3D"=
m_743461711499916820styled-by-prettify" style=3D"color:#660">,</span><span =
class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#000"> </sp=
an><span class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#0=
80">"ac"</span><span class=3D"m_743461711499916820styled-by-prett=
ify" style=3D"color:#660">,</span><span class=3D"m_743461711499916820styled=
-by-prettify" style=3D"color:#000"> </span><span class=3D"m_743461711499916=
820styled-by-prettify" style=3D"color:#080">"ad"</span><span clas=
s=3D"m_743461711499916820styled-by-prettify" style=3D"color:#660">,</span><=
span class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#000">=
</span><span class=3D"m_743461711499916820styled-by-prettify" style=3D"col=
or:#080">"ae"</span><span class=3D"m_743461711499916820styled-by-=
prettify" style=3D"color:#660">,</span><span class=3D"m_743461711499916820s=
tyled-by-prettify" style=3D"color:#000"> </span><span class=3D"m_7434617114=
99916820styled-by-prettify" style=3D"color:#080">"af"</span><span=
class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#660">,</s=
pan><span class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#=
000"> </span><span class=3D"m_743461711499916820styled-by-prettify" style=
=3D"color:#080">"ag"</span><span class=3D"m_743461711499916820sty=
led-by-prettify" style=3D"color:#660">};</span><span class=3D"m_74346171149=
9916820styled-by-prettify" style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><s=
pan class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#008">c=
ase</span><span class=3D"m_743461711499916820styled-by-prettify" style=3D"c=
olor:#000"> E2</span><span class=3D"m_743461711499916820styled-by-prettify"=
style=3D"color:#660">:</span><span class=3D"m_743461711499916820styled-by-=
prettify" style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span=
class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#008">retu=
rn</span><span class=3D"m_743461711499916820styled-by-prettify" style=3D"co=
lor:#000"> </span><span class=3D"m_743461711499916820styled-by-prettify" st=
yle=3D"color:#660">{</span><span class=3D"m_743461711499916820styled-by-pre=
ttify" style=3D"color:#000"> </span><span class=3D"m_743461711499916820styl=
ed-by-prettify" style=3D"color:#080">"a"</span><span class=3D"m_7=
43461711499916820styled-by-prettify" style=3D"color:#660">,</span><span cla=
ss=3D"m_743461711499916820styled-by-prettify" style=3D"color:#000"> </span>=
<span class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#080"=
>"b"</span><span class=3D"m_743461711499916820styled-by-prettify"=
style=3D"color:#660">,</span><span class=3D"m_743461711499916820styled-by-=
prettify" style=3D"color:#000"> </span><span class=3D"m_743461711499916820s=
tyled-by-prettify" style=3D"color:#080">"c"</span><span class=3D"=
m_743461711499916820styled-by-prettify" style=3D"color:#660">,</span><span =
class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#000"> </sp=
an><span class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#0=
80">"d"</span><span class=3D"m_743461711499916820styled-by-pretti=
fy" style=3D"color:#660">,</span><span class=3D"m_743461711499916820styled-=
by-prettify" style=3D"color:#000"> </span><span class=3D"m_7434617114999168=
20styled-by-prettify" style=3D"color:#080">"e"</span><span class=
=3D"m_743461711499916820styled-by-prettify" style=3D"color:#660">,</span><s=
pan class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#000"> =
</span><span class=3D"m_743461711499916820styled-by-prettify" style=3D"colo=
r:#080">"f"</span><span class=3D"m_743461711499916820styled-by-pr=
ettify" style=3D"color:#660">,</span><span class=3D"m_743461711499916820sty=
led-by-prettify" style=3D"color:#000"> </span><span class=3D"m_743461711499=
916820styled-by-prettify" style=3D"color:#080">"g"</span><span cl=
ass=3D"m_743461711499916820styled-by-prettify" style=3D"color:#660">};</spa=
n><span class=3D"m_743461711499916820styled-by-prettify" style=3D"color:#00=
0"><br>=C2=A0 =C2=A0 </span><span class=3D"m_743461711499916820styled-by-pr=
ettify" style=3D"color:#660">}</span><span class=3D"m_743461711499916820sty=
led-by-prettify" style=3D"color:#000"><br></span><span class=3D"m_743461711=
499916820styled-by-prettify" style=3D"color:#660">}</span></div></code></di=
v><div><br></div><div>My overall point is that we're not talking about =
the<i> same function</i>. You're creating a new function with a distinc=
t meaning and a different contract.</div><div><br></div><div>You are essent=
ially saying that the language should prevent us from ever making functions=
with narrow contracts. I do not hold to that.<i></i><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex">
<i></i></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/7889e750-bace-45ad-bc5a-e421a2f56626%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/7889=
e750-bace-45ad-<wbr>bc5a-e421a2f56626%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/CALvx3hbBJ%3DBg1%2BVJMOUnFPw6Ztmqva-e=
ny%2BfXKEUbwZ%2BCSYGmw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hbB=
J%3DBg1%2BVJMOUnFPw6Ztmqva-eny%2BfXKEUbwZ%2BCSYGmw%40mail.gmail.com</a>.<br=
/>
--001a113fbc084d0f5a0560c9ae6b--
.
Author: Jared Grubb <jared.grubb@gmail.com>
Date: Wed, 20 Dec 2017 10:34:35 -0800 (PST)
Raw View
------=_Part_3378_862946644.1513794875134
Content-Type: multipart/alternative;
boundary="----=_Part_3379_160745378.1513794875134"
------=_Part_3379_160745378.1513794875134
Content-Type: text/plain; charset="UTF-8"
On Wednesday, December 20, 2017 at 9:17:45 AM UTC-8, Richard Hodges wrote:
>
> > Do we need to bring the discussion on signed integer overflow and
> shifting again?
>
> No, what we're going to do is keep the thread on topic. The topic is
> around allowing a function that advertises that it returns a value to not
> return a value.
>
> Show me a function that performs better when there is a control path that
> does not return a value that does not produce code at least as good when
> written so that all control paths return a value.
>
This appears to satisfy your requirements:
std::string foo(bool flag) {
if (flag) return "x";
}
Clang: https://godbolt.org/g/NEXMRk
GCC: https://godbolt.org/g/46o9sa
Interestingly, clang sees the UB here and completely removes the test.
Adding any extra return statement would disturb that optimization.
GCC does not remove the test, but does generate longer code when you add a
final return statement. My x86-asm midi-chlorians are not
strong enough to know whether there's any significant perforamance
difference or not, but it is objectively more assembly.
This hopefully satisfies your curiousity for an example that generates
better assembly with this UB than it would if the programmer (or compiler)
had to add more return's.
--
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/a252c1ab-549f-4d9e-b3f6-4c2a4edf286b%40isocpp.org.
------=_Part_3379_160745378.1513794875134
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, December 20, 2017 at 9:17:45 AM UTC-=
8, Richard Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">Do we need to bring t=
he discussion on signed integer overflow and shifting=C2=A0</span><span sty=
le=3D"font-size:12.8px">again?=C2=A0</span><div><span style=3D"font-size:12=
..8px"><br></span></div><div><span style=3D"font-size:12.8px">No, what we=
9;re going to do is keep the thread on topic. The topic is around allowing =
a function that advertises that it returns a value to not return a value.</=
span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><spa=
n style=3D"font-size:12.8px">Show me a function that performs better when t=
here is a control path that does not return a value that does not produce c=
ode at least as good when written so that all control paths return a value.=
</span></div></div></blockquote><div><br>This appears to satisfy your requi=
rements:</div><div><br></div><div><div style=3D"color: #000000;background-c=
olor: #fffffe;font-family: Fira Mono;font-weight: normal;font-size: 14px;li=
ne-height: 21px;white-space: pre;"><span style=3D"color: #000000;">std::str=
ing foo(</span><span style=3D"color: #0000ff;">bool</span><span style=3D"co=
lor: #000000;"> flag) {</span><div><span style=3D"color: #000000;"> </span=
><span style=3D"color: #0000ff;">if</span><span style=3D"color: #000000;"> =
(flag) </span><span style=3D"color: #0000ff;">return</span><span style=3D"c=
olor: #000000;"> </span><span style=3D"color: #a31515;">"x"</span=
><span style=3D"color: #000000;">;</span></div><div><span style=3D"color: #=
000000;">}</span></div><div><span style=3D"color: #000000;"><br></span></di=
v><div><div><span style=3D"color: #000000;">Clang: https://godbolt.org/g/NE=
XMRk</span></div><span style=3D"color: #000000;">GCC: https://godbolt.org/g=
/46o9sa</span></div><div><span style=3D"color: #000000;"><br></span></div>I=
nterestingly, clang sees the UB here and completely removes the test. Addin=
g any extra return statement would disturb that optimization.</div><div sty=
le=3D"color: #000000;background-color: #fffffe;font-family: Fira Mono;font-=
weight: normal;font-size: 14px;line-height: 21px;white-space: pre;"><br></d=
iv><div style=3D"color: #000000;background-color: #fffffe;font-family: Fira=
Mono;font-weight: normal;font-size: 14px;line-height: 21px;white-space: pr=
e;">GCC does not remove the test, but does generate longer code when you ad=
d a final return statement. My x86-asm midi-chlorians are not <br></div><di=
v style=3D"color: #000000;background-color: #fffffe;font-family: Fira Mono;=
font-weight: normal;font-size: 14px;line-height: 21px;white-space: pre;">st=
rong enough to know whether there's any significant perforamance differ=
ence or not, but it is objectively more assembly.</div><div style=3D"color:=
#000000;background-color: #fffffe;font-family: Fira Mono;font-weight: norm=
al;font-size: 14px;line-height: 21px;white-space: pre;"><br></div><div styl=
e=3D"color: #000000;background-color: #fffffe;font-family: Fira Mono;font-w=
eight: normal;font-size: 14px;line-height: 21px;white-space: pre;">This hop=
efully satisfies your curiousity for an example that generates better assem=
bly with this UB than it would if the programmer (or compiler) had to add m=
ore return's.<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/a252c1ab-549f-4d9e-b3f6-4c2a4edf286b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a252c1ab-549f-4d9e-b3f6-4c2a4edf286b=
%40isocpp.org</a>.<br />
------=_Part_3379_160745378.1513794875134--
------=_Part_3378_862946644.1513794875134--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 20 Dec 2017 10:41:01 -0800 (PST)
Raw View
------=_Part_3476_767114436.1513795261112
Content-Type: multipart/alternative;
boundary="----=_Part_3477_1023710658.1513795261112"
------=_Part_3477_1023710658.1513795261112
Content-Type: text/plain; charset="UTF-8"
On Wednesday, December 20, 2017 at 1:12:51 PM UTC-5, Richard Hodges wrote:
>
> > Can you present evidence for the existence of this "vast majority" who
> are willing to have entire codebases be broken by this?
>
> Can you present evidence that "entire codebases" will be broken by this?
> It seems as if you're suggesting that "entire codebases" depend on UB.
>
You seem to have difficulty understanding the idea that you can write code
which does not "depend on UB" despite* not* having all code paths issue a
return.
So perhaps we have a different idea of what "depending on UB" means. UB
only happens when you encounter it* at runtime*. It is not a compile-time
concept; it is runtime behavior.
As for "entire codebases", all it takes is one function not having a return
statement in each codepath to make the codebase no longer compile.
> As for completely empty functions with return values, even those have a
> purpose: metaprogramming and reflection. You can use `decltype` and
> unevaluated contexts to inquire about parameters and the return type, all
> without actually calling the function.
>
> This is another straw man. Such functions can certainly be trivially
> defined to contain no UB, as demonstrated.
>
Hence requiring "churn" (ie: someone actually adding something to the
function, despite the program never exhibiting UB). That's not a strawman;
that's what we're actually talking about.
--
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/5777112f-ad46-4719-8c4c-9c797d0ff036%40isocpp.org.
------=_Part_3477_1023710658.1513795261112
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, December 20, 2017 at 1:12:51 PM UTC-5, Richa=
rd Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">>=C2=A0<span style=3D"font-size:12.8px">Can you present evidence for =
the existence of this "vast majority" who are willing to have ent=
ire codebases be broken by this?</span><div><span style=3D"font-size:12.8px=
"><br></span></div><div><span style=3D"font-size:12.8px">Can you present ev=
idence that "entire codebases" will be broken by this? It seems a=
s if you're suggesting that "entire codebases" depend on UB.<=
/span></div></div></blockquote><div><br></div><div>You seem to have difficu=
lty understanding the idea that you can write code which does not "dep=
end on UB" despite<i> not</i> having all code paths issue a return.</d=
iv><div><br></div><div>So perhaps we have a different idea of what "de=
pending on UB" means. UB only happens when you encounter it<i> at runt=
ime</i>. It is not a compile-time concept; it is runtime behavior.</div><di=
v><br></div><div>As for "entire codebases", all it takes is one f=
unction not having a return statement in each codepath to make the codebase=
no longer compile.<br></div><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div><span style=3D"font-size:12.8px">>=
=C2=A0</span><span style=3D"font-size:12.8px">As for completely empty funct=
ions with return values, even those have a purpose: metaprogramming and ref=
lection. You can use `decltype` and unevaluated contexts to inquire about p=
arameters and the return type, all without actually calling the function.</=
span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><spa=
n style=3D"font-size:12.8px">This is another straw man. Such functions can =
certainly be trivially defined to contain no UB, as demonstrated.</span></d=
iv></div></blockquote><div><br></div><div>Hence requiring "churn"=
(ie: someone actually adding something to the function, despite the progra=
m never exhibiting UB). That's not a strawman; that's what we'r=
e actually talking about.</div><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;">
</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/5777112f-ad46-4719-8c4c-9c797d0ff036%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5777112f-ad46-4719-8c4c-9c797d0ff036=
%40isocpp.org</a>.<br />
------=_Part_3477_1023710658.1513795261112--
------=_Part_3476_767114436.1513795261112--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Wed, 20 Dec 2017 19:43:09 +0100
Raw View
--f403045c48667be0200560c9f481
Content-Type: text/plain; charset="UTF-8"
> This appears to satisfy your requirements
Too easy:
#include <string>
std::string foo(bool flag) {
const char* true_result = "x";
const char* false_result = "x";
if (flag)
return true_result;
else
return false_result;
}
gcc -O2 -std=c++17
foo[abi:cxx11](bool):
lea rax, [rdi+16]
push rbx
mov edx, OFFSET FLAT:.LC2+1
mov rbx, rdi
mov esi, OFFSET FLAT:.LC2
mov QWORD PTR [rdi], rax
call void std::__cxx11::basic_string<char, std::char_traits<char>, std::
allocator<char> >::_M_construct<char const*>(char const*, char const*, std::
forward_iterator_tag) [clone .isra.16]
mov rax, rbx
pop rbx
ret
clang 5.0:
foo[abi:cxx11](bool): # @foo[abi:cxx11](bool)
lea rax, [rdi + 16]
mov qword ptr [rdi], rax
mov word ptr [rdi + 16], 120
mov qword ptr [rdi + 8], 1
mov rax, rdi
ret
gcc -O2 -std=c++17
Next?
On 20 December 2017 at 19:34, Jared Grubb <jared.grubb@gmail.com> wrote:
>
>
> On Wednesday, December 20, 2017 at 9:17:45 AM UTC-8, Richard Hodges wrote:
>>
>> > Do we need to bring the discussion on signed integer overflow and
>> shifting again?
>>
>> No, what we're going to do is keep the thread on topic. The topic is
>> around allowing a function that advertises that it returns a value to not
>> return a value.
>>
>> Show me a function that performs better when there is a control path that
>> does not return a value that does not produce code at least as good when
>> written so that all control paths return a value.
>>
>
> This appears to satisfy your requirements:
>
> std::string foo(bool flag) {
> if (flag) return "x";
> }
>
> Clang: https://godbolt.org/g/NEXMRk
> GCC: https://godbolt.org/g/46o9sa
>
> Interestingly, clang sees the UB here and completely removes the test.
> Adding any extra return statement would disturb that optimization.
>
> GCC does not remove the test, but does generate longer code when you add a
> final return statement. My x86-asm midi-chlorians are not
> strong enough to know whether there's any significant perforamance
> difference or not, but it is objectively more assembly.
>
> This hopefully satisfies your curiousity for an example that generates
> better assembly with this UB than it would if the programmer (or compiler)
> had to add more return's.
>
> --
> 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/a252c1ab-549f-4d9e-
> b3f6-4c2a4edf286b%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a252c1ab-549f-4d9e-b3f6-4c2a4edf286b%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CALvx3hbr8VRJJ%2BiuVDU9zwREihy7NDmjcHUnW7Qq8Fbpepc1LQ%40mail.gmail.com.
--f403045c48667be0200560c9f481
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">> This appears to satisfy your requirements<div><br></d=
iv><div>Too easy:</div><div><br></div><div><div style=3D"color:rgb(0,0,0);b=
ackground-color:rgb(255,255,254);font-size:14px;line-height:21px;white-spac=
e:pre"><div><font face=3D"monospace, monospace"><span style=3D"color:rgb(0,=
0,255)">#include</span> <string></font></div><font face=3D"monospace,=
monospace"><br></font><div><font face=3D"monospace, monospace">std::string=
foo(<span style=3D"color:rgb(0,0,255)">bool</span> flag) {</font></div><di=
v><font face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)=
">const</span> <span style=3D"color:rgb(0,0,255)">char</span>* true_result =
=3D <span style=3D"color:rgb(163,21,21)">"x"</span>;</font></div>=
<div><font face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,2=
55)">const</span> <span style=3D"color:rgb(0,0,255)">char</span>* false_res=
ult =3D <span style=3D"color:rgb(163,21,21)">"x"</span>;</font></=
div><div><font face=3D"monospace, monospace"> <span style=3D"color:rgb(0=
,0,255)">if</span> (flag) </font></div><div><font face=3D"monospace, monosp=
ace"> <span style=3D"color:rgb(0,0,255)">return</span> true_result;<=
/font></div><div><font face=3D"monospace, monospace"> <span style=3D"col=
or:rgb(0,0,255)">else</span></font></div><div><font face=3D"monospace, mono=
space"> <span style=3D"color:rgb(0,0,255)">return</span> false_resul=
t;</font></div><div><font face=3D"monospace, monospace">}</font></div><br><=
/div></div><div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,254)=
;font-family:"Fira Mono";font-size:14px;line-height:21px;white-sp=
ace:pre">gcc -O2 -std=3Dc++17</div><div style=3D"color:rgb(0,0,0);backgroun=
d-color:rgb(255,255,254);font-family:"Fira Mono";font-size:14px;l=
ine-height:21px;white-space:pre"><br></div><div style=3D"color:rgb(0,0,0);b=
ackground-color:rgb(255,255,254);font-size:14px;line-height:21px;white-spac=
e:pre"><div style=3D"line-height:21px"><div><span style=3D"color:rgb(0,128,=
128)"><font face=3D"monospace, monospace">foo[abi:cxx11](bool):</font></spa=
n></div><div><font face=3D"monospace, monospace"> <span style=3D"color:rgb=
(0,0,255)">lea</span> <span style=3D"color:rgb(72,100,170)">rax</span>, [<s=
pan style=3D"color:rgb(72,100,170)">rdi</span>+<span style=3D"color:rgb(9,1=
36,90)">16</span>]</font></div><div><font face=3D"monospace, monospace"> <=
span style=3D"color:rgb(0,0,255)">push</span> <span style=3D"color:rgb(72,1=
00,170)">rbx</span></font></div><div><font face=3D"monospace, monospace"> =
<span style=3D"color:rgb(0,0,255)">mov</span> <span style=3D"color:rgb(72,1=
00,170)">edx</span>, <span style=3D"color:rgb(0,128,128)">OFFSET</span> <sp=
an style=3D"color:rgb(0,128,128)">FLAT</span>:<span style=3D"color:rgb(0,12=
8,128)">.LC2</span>+<span style=3D"color:rgb(9,136,90)">1</span></font></di=
v><div><font face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,2=
55)">mov</span> <span style=3D"color:rgb(72,100,170)">rbx</span>, <span sty=
le=3D"color:rgb(72,100,170)">rdi</span></font></div><div><font face=3D"mono=
space, monospace"> <span style=3D"color:rgb(0,0,255)">mov</span> <span sty=
le=3D"color:rgb(72,100,170)">esi</span>, <span style=3D"color:rgb(0,128,128=
)">OFFSET</span> <span style=3D"color:rgb(0,128,128)">FLAT</span>:<span sty=
le=3D"color:rgb(0,128,128)">.LC2</span></font></div><div><font face=3D"mono=
space, monospace"> <span style=3D"color:rgb(0,0,255)">mov</span> <span sty=
le=3D"color:rgb(128,128,128)">QWORD</span> <span style=3D"color:rgb(128,128=
,128)">PTR</span> [<span style=3D"color:rgb(72,100,170)">rdi</span>], <span=
style=3D"color:rgb(72,100,170)">rax</span></font></div><div><font face=3D"=
monospace, monospace"> <span style=3D"color:rgb(0,0,255)">call</span> <spa=
n style=3D"color:rgb(0,128,128)">void</span> <span style=3D"color:rgb(0,128=
,128)">std</span>::<span style=3D"color:rgb(0,128,128)">__cxx11</span>::<sp=
an style=3D"color:rgb(0,128,128)">basic_string</span><<span style=3D"col=
or:rgb(0,128,128)">char</span>, <span style=3D"color:rgb(0,128,128)">std</s=
pan>::<span style=3D"color:rgb(0,128,128)">char_traits</span><<span styl=
e=3D"color:rgb(0,128,128)">char</span>>, <span style=3D"color:rgb(0,128,=
128)">std</span>::<span style=3D"color:rgb(0,128,128)">allocator</span><=
<span style=3D"color:rgb(0,128,128)">char</span>> >::<span style=3D"c=
olor:rgb(0,128,128)">_M_construct</span><<span style=3D"color:rgb(0,128,=
128)">char</span> <span style=3D"color:rgb(0,128,128)">const</span>*>(<s=
pan style=3D"color:rgb(0,128,128)">char</span> <span style=3D"color:rgb(0,1=
28,128)">const</span>*, <span style=3D"color:rgb(0,128,128)">char</span> <s=
pan style=3D"color:rgb(0,128,128)">const</span>*, <span style=3D"color:rgb(=
0,128,128)">std</span>::<span style=3D"color:rgb(0,128,128)">forward_iterat=
or_tag</span>) [<span style=3D"color:rgb(0,128,128)">clone</span> <span sty=
le=3D"color:rgb(0,128,128)">.isra.16</span>]</font></div><div><font face=3D=
"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">mov</span> <spa=
n style=3D"color:rgb(72,100,170)">rax</span>, <span style=3D"color:rgb(72,1=
00,170)">rbx</span></font></div><div><font face=3D"monospace, monospace"> =
<span style=3D"color:rgb(0,0,255)">pop</span> <span style=3D"color:rgb(72,1=
00,170)">rbx</span></font></div><div><font face=3D"monospace, monospace"> =
<span style=3D"color:rgb(0,0,255)">ret</span></font></div><div style=3D"fon=
t-family:"Fira Mono""><span style=3D"color:rgb(0,0,255)"><br></sp=
an></div><div><span style=3D"color:rgb(0,0,255)"><font face=3D"arial, helve=
tica, sans-serif">clang 5.0:</font></span></div><div><span style=3D"color:r=
gb(0,0,255)"><font face=3D"arial, helvetica, sans-serif"><br></font></span>=
</div><div><div style=3D"line-height:21px"><div><font face=3D"monospace, mo=
nospace"><span style=3D"color:rgb(0,128,128)">foo[abi:cxx11](bool): # @foo[=
abi:cxx11</span>](<span style=3D"color:rgb(0,128,128)">bool</span>)</font><=
/div><div><font face=3D"monospace, monospace"> <span style=3D"color:rgb(0,=
0,255)">lea</span> <span style=3D"color:rgb(72,100,170)">rax</span>, [<span=
style=3D"color:rgb(72,100,170)">rdi</span> + <span style=3D"color:rgb(9,13=
6,90)">16</span>]</font></div><div><font face=3D"monospace, monospace"> <s=
pan style=3D"color:rgb(0,0,255)">mov</span> <span style=3D"color:rgb(0,128,=
128)">qword</span> <span style=3D"color:rgb(0,128,128)">ptr</span> [<span s=
tyle=3D"color:rgb(72,100,170)">rdi</span>], <span style=3D"color:rgb(72,100=
,170)">rax</span></font></div><div><font face=3D"monospace, monospace"> <s=
pan style=3D"color:rgb(0,0,255)">mov</span> <span style=3D"color:rgb(0,128,=
128)">word</span> <span style=3D"color:rgb(0,128,128)">ptr</span> [<span st=
yle=3D"color:rgb(72,100,170)">rdi</span> + <span style=3D"color:rgb(9,136,9=
0)">16</span>], <span style=3D"color:rgb(9,136,90)">120</span></font></div>=
<div><font face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255=
)">mov</span> <span style=3D"color:rgb(0,128,128)">qword</span> <span style=
=3D"color:rgb(0,128,128)">ptr</span> [<span style=3D"color:rgb(72,100,170)"=
>rdi</span> + <span style=3D"color:rgb(9,136,90)">8</span>], <span style=3D=
"color:rgb(9,136,90)">1</span></font></div><div><font face=3D"monospace, mo=
nospace"> <span style=3D"color:rgb(0,0,255)">mov</span> <span style=3D"col=
or:rgb(72,100,170)">rax</span>, <span style=3D"color:rgb(72,100,170)">rdi</=
span></font></div><div><font face=3D"monospace, monospace"> <span style=3D=
"color:rgb(0,0,255)">ret</span></font></div><div style=3D"font-family:"=
;Fira Mono""><span style=3D"color:rgb(0,0,255)"><br></span></div><div =
style=3D"font-family:"Fira Mono""><div style=3D"line-height:21px"=
>gcc -O2 -std=3Dc++17</div><div style=3D"line-height:21px"><br></div><div s=
tyle=3D"line-height:21px">Next?</div><div style=3D"line-height:21px"><br></=
div><div><br></div></div></div></div></div></div><div style=3D"color:rgb(0,=
0,0);background-color:rgb(255,255,254);font-family:"Fira Mono";fo=
nt-size:14px;line-height:21px;white-space:pre"><br></div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On 20 December 2017 at 19:3=
4, Jared Grubb <span dir=3D"ltr"><<a href=3D"mailto:jared.grubb@gmail.co=
m" target=3D"_blank">jared.grubb@gmail.com</a>></span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><br><br>On Wednes=
day, December 20, 2017 at 9:17:45 AM UTC-8, Richard Hodges wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr">>=C2=A0<span style=3D"fon=
t-size:12.8px">Do we need to bring the discussion on signed integer overflo=
w and shifting=C2=A0</span><span style=3D"font-size:12.8px">again?=C2=A0</s=
pan><div><span style=3D"font-size:12.8px"><br></span></div><div><span style=
=3D"font-size:12.8px">No, what we're going to do is keep the thread on =
topic. The topic is around allowing a function that advertises that it retu=
rns a value to not return a value.</span></div><div><span style=3D"font-siz=
e:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">Show me a =
function that performs better when there is a control path that does not re=
turn a value that does not produce code at least as good when written so th=
at all control paths return a value.</span></div></div></blockquote></span>=
<div><br>This appears to satisfy your requirements:</div><div><br></div><di=
v><div style=3D"color:#000000;background-color:#fffffe;font-family:Fira Mon=
o;font-weight:normal;font-size:14px;line-height:21px;white-space:pre-wrap">=
<span style=3D"color:#000000">std::string foo(</span><span style=3D"color:#=
0000ff">bool</span><span style=3D"color:#000000"> flag) {</span><div><span =
style=3D"color:#000000"> </span><span style=3D"color:#0000ff">if</span><sp=
an style=3D"color:#000000"> (flag) </span><span style=3D"color:#0000ff">ret=
urn</span><span style=3D"color:#000000"> </span><span style=3D"color:#a3151=
5">"x"</span><span style=3D"color:#000000">;</span></div><div><sp=
an style=3D"color:#000000">}</span></div><div><span style=3D"color:#000000"=
><br></span></div><div><div><span style=3D"color:#000000">Clang: <a href=3D=
"https://godbolt.org/g/NEXMRk" target=3D"_blank">https://godbolt.org/g/NEXM=
Rk</a></span></div><span style=3D"color:#000000">GCC: <a href=3D"https://go=
dbolt.org/g/46o9sa" target=3D"_blank">https://godbolt.org/g/46o9sa</a></spa=
n></div><div><span style=3D"color:#000000"><br></span></div>Interestingly, =
clang sees the UB here and completely removes the test. Adding any extra re=
turn statement would disturb that optimization.</div><div style=3D"color:#0=
00000;background-color:#fffffe;font-family:Fira Mono;font-weight:normal;fon=
t-size:14px;line-height:21px;white-space:pre-wrap"><br></div><div style=3D"=
color:#000000;background-color:#fffffe;font-family:Fira Mono;font-weight:no=
rmal;font-size:14px;line-height:21px;white-space:pre-wrap">GCC does not rem=
ove the test, but does generate longer code when you add a final return sta=
tement. My x86-asm midi-chlorians are not <br></div><div style=3D"color:#00=
0000;background-color:#fffffe;font-family:Fira Mono;font-weight:normal;font=
-size:14px;line-height:21px;white-space:pre-wrap">strong enough to know whe=
ther there's any significant perforamance difference or not, but it is =
objectively more assembly.</div><div style=3D"color:#000000;background-colo=
r:#fffffe;font-family:Fira Mono;font-weight:normal;font-size:14px;line-heig=
ht:21px;white-space:pre-wrap"><br></div><div style=3D"color:#000000;backgro=
und-color:#fffffe;font-family:Fira Mono;font-weight:normal;font-size:14px;l=
ine-height:21px;white-space:pre-wrap">This hopefully satisfies your curious=
ity for an example that generates better assembly with this UB than it woul=
d if the programmer (or compiler) had to add more return's.<br></div></=
div></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/a252c1ab-549f-4d9e-b3f6-4c2a4edf286b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/a252=
c1ab-549f-4d9e-<wbr>b3f6-4c2a4edf286b%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/CALvx3hbr8VRJJ%2BiuVDU9zwREihy7NDmjcH=
UnW7Qq8Fbpepc1LQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hbr8VRJJ%=
2BiuVDU9zwREihy7NDmjcHUnW7Qq8Fbpepc1LQ%40mail.gmail.com</a>.<br />
--f403045c48667be0200560c9f481--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 20 Dec 2017 10:43:18 -0800 (PST)
Raw View
------=_Part_3425_373304904.1513795398457
Content-Type: multipart/alternative;
boundary="----=_Part_3426_836439887.1513795398457"
------=_Part_3426_836439887.1513795398457
Content-Type: text/plain; charset="UTF-8"
On Wednesday, December 20, 2017 at 1:23:34 PM UTC-5, Richard Hodges wrote:
>
> > This removes two pointless lambdas. The use of `default` makes it clear
> what the function's contract is: that for `make_floom`, it is perfectly
> valid to call:
>
> The reason for writing it this way is to address the concern expressed
> above the 'default:' clause removing the possibility of a warning on an
> unhandled case. It also addresses the performance concern. The point is
> that this is one of a myriad of ways to provide a better solution than UB
> when it comes to return values.
>
But it's not a "better solution"; it's merely a *different* one.
We* know* how to write functions with wide contracts. That's a solved
problem. The question is what we do in cases where* we don't want to* have
a wide contract.
You're effectively saying that narrow contracts are bad. You can believe
that if you like, but it's not a belief you should impose on other people.
`std::unreachable` (or however we end up spelling it) is the solution for
people who want to write narrow contracts. But that should not be *required*;
only encouraged.
I am well aware of the various ways the function can be expressed, and the
> difference between exception-based contracts and exceptionless contracts.
>
> The contract of the example function is (as you well know):
>
> * I won't throw unless I'm out of memory
> * valid arguments are E1 and E2
> * if you pass anything other than that, I'll treat it as E2
>
> Which is unequivocally better than the alternative:
>
And who are you to decide what is "unequivocally better" for other people?
We're grown ups; we can make choices for ourselves about what kind of
contracts we want.
Again, this is why `vector::operator[]` has a different contract from
`vector::at()`.
* I won't throw unless I'm out of memory
> * valid arguments are E1 and E2
> * if you pass anything other than that, I'll probably crash at some
> undefined point in the future if you're lucky. If you're not, I might just
> expose your passwords to someone, corrupt the 1000-hour-old campaign save,
> or invert USDJPY or something. Who knows? Who even cares? What does it all
> mean anyway?
>
> Now, for the record, I prefer exceptions when contracts are violated, but
> I'm not mandating that here.
>
Then you seem to have a misunderstanding of what a contract means. A
"contract" is an agreement between the caller and the callee, such that if
the caller violates the agreement, then all bets are off. Contracts specify
things which are not part of a function's interface, things which are
assumed rather than verified.
If you throw on incorrect input values, that's part of the function's
interface. And therefore, it's well-defined behavior. And therefore, such
cases are *not* a violation of the contract of the function.
You can rely on `vector::at()` to throw if its out of range. You cannot
rely on `vector::operator[]` doing anything if its out of range. `at` has a
wider contract (more acceptable values) than `operator[]`.
> I'm merely responding to the concerns of a sceptical
> game/FX/fintech/protein modelling/flight control system developer who
> wrongly thinks he is buying performance with UB. He's not. He's buying UB
> with UB, and gaining nothing.
>
--
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/cd792ea4-516e-4e7c-b557-f3e1dd5c4706%40isocpp.org.
------=_Part_3426_836439887.1513795398457
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, December 20, 2017 at 1:23:34 PM UTC-5, Richa=
rd Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">>=C2=A0<span style=3D"font-size:12.8px">This removes two pointless la=
mbdas. The use of `default` makes it clear what the function's contract=
is: that for `make_floom`, it is perfectly valid to call:</span><div><span=
style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:=
12.8px">The reason for writing it this way is to address the concern expres=
sed above the 'default:' clause removing the possibility of a warni=
ng on an unhandled case. It also addresses the performance concern. The poi=
nt is that this is one of a myriad of ways to provide a better solution tha=
n UB when it comes to return values.</span></div></div></blockquote><div><b=
r></div><div>But it's not a "better solution"; it's merel=
y a <i>different</i> one.</div><div><br></div><div>We<i> know</i> how to wr=
ite functions with wide contracts. That's a solved problem. The questio=
n is what we do in cases where<i> we don't want to</i> have a wide cont=
ract.</div><div><br></div><div>You're effectively saying that narrow co=
ntracts are bad. You can believe that if you like, but it's not a belie=
f you should impose on other people.</div><div><br></div><div>`std::unreach=
able` (or however we end up spelling it) is the solution for people who wan=
t to write narrow contracts. But that should not be <i>required</i>; only e=
ncouraged.</div><div><i><br></i></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr"><div><span style=3D"font-size:12.8px">I am well aw=
are of the various ways the function can be expressed, and the difference b=
etween exception-based contracts and exceptionless contracts.</span></div><=
div><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"f=
ont-size:12.8px">The contract of the example function is (as you well know)=
:</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><=
span style=3D"font-size:12.8px">* I won't throw unless I'm out of m=
emory</span></div><div><span style=3D"font-size:12.8px">* valid arguments a=
re E1 and E2</span></div><div><span style=3D"font-size:12.8px">* if you pas=
s anything other than that, I'll treat it as E2</span></div><div><span =
style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:1=
2.8px">Which is unequivocally better than the alternative:</span></div></di=
v></blockquote><div><br></div><div>And who are you to decide what is "=
unequivocally better" for other people? We're grown ups; we can ma=
ke choices for ourselves about what kind of contracts we want.</div><div><b=
r></div><div>Again, this is why `vector::operator[]` has a different contra=
ct from `vector::at()`.</div><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div><span style=3D"font-size:12.8px">* I wo=
n't throw unless I'm out of memory</span></div><div><div><span styl=
e=3D"font-size:12.8px">* valid arguments are E1 and E2</span></div><div><sp=
an style=3D"font-size:12.8px">* if you pass anything other than that, I'=
;ll probably crash at some undefined point in the future if you're luck=
y. If you're not, I might just expose your passwords to someone, corrup=
t the 1000-hour-old campaign save, or invert USDJPY or something. Who knows=
? Who even cares? What does it all mean anyway?</span></div></div><div><spa=
n style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size=
:12.8px">Now, for the record, I prefer exceptions when contracts are violat=
ed, but I'm not mandating that here.</span></div></div></blockquote><di=
v><br></div><div>Then you seem to have a misunderstanding of what a contrac=
t means. A "contract" is an agreement between the caller and the =
callee, such that if the caller violates the agreement, then all bets are o=
ff. Contracts specify things which are not part of a function's interfa=
ce, things which are assumed rather than verified.</div><div><br></div><div=
>If you throw on incorrect input values, that's part of the function=
9;s interface. And therefore, it's well-defined behavior. And therefore=
, such cases are <i>not</i> a violation of the contract of the function.</d=
iv><div><br></div><div>You can rely on `vector::at()` to throw if its out o=
f range. You cannot rely on `vector::operator[]` doing anything if its out =
of range. `at` has a wider contract (more acceptable values) than `operator=
[]`.</div><div>=C2=A0</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"><div><span style=3D"font-size:12.8px">I'm merely respondi=
ng to the concerns of a sceptical game/FX/fintech/protein modelling/flight =
control system developer who wrongly thinks he is buying performance with U=
B. He's not. He's buying UB with UB, and gaining nothing.</span><br=
></div></div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/cd792ea4-516e-4e7c-b557-f3e1dd5c4706%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cd792ea4-516e-4e7c-b557-f3e1dd5c4706=
%40isocpp.org</a>.<br />
------=_Part_3426_836439887.1513795398457--
------=_Part_3425_373304904.1513795398457--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Wed, 20 Dec 2017 19:48:49 +0100
Raw View
--001a114aad78c6d71f0560ca0896
Content-Type: text/plain; charset="UTF-8"
> We're grown ups; we can make choices for ourselves about what kind of
contracts we want.
And for you 'grownups' who want to lay landmines, there will be
std::unreachable(), which hopefully will the the first step on the path to
sanity, which is not to allow little terrorists to leave landmines in code
without telling the complier that that is what you intended.
On 20 December 2017 at 19:43, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, December 20, 2017 at 1:23:34 PM UTC-5, Richard Hodges wrote:
>>
>> > This removes two pointless lambdas. The use of `default` makes it
>> clear what the function's contract is: that for `make_floom`, it is
>> perfectly valid to call:
>>
>> The reason for writing it this way is to address the concern expressed
>> above the 'default:' clause removing the possibility of a warning on an
>> unhandled case. It also addresses the performance concern. The point is
>> that this is one of a myriad of ways to provide a better solution than UB
>> when it comes to return values.
>>
>
> But it's not a "better solution"; it's merely a *different* one.
>
> We* know* how to write functions with wide contracts. That's a solved
> problem. The question is what we do in cases where* we don't want to*
> have a wide contract.
>
> You're effectively saying that narrow contracts are bad. You can believe
> that if you like, but it's not a belief you should impose on other people.
>
> `std::unreachable` (or however we end up spelling it) is the solution for
> people who want to write narrow contracts. But that should not be
> *required*; only encouraged.
>
> I am well aware of the various ways the function can be expressed, and the
>> difference between exception-based contracts and exceptionless contracts.
>>
>> The contract of the example function is (as you well know):
>>
>> * I won't throw unless I'm out of memory
>> * valid arguments are E1 and E2
>> * if you pass anything other than that, I'll treat it as E2
>>
>> Which is unequivocally better than the alternative:
>>
>
> And who are you to decide what is "unequivocally better" for other people?
> We're grown ups; we can make choices for ourselves about what kind of
> contracts we want.
>
> Again, this is why `vector::operator[]` has a different contract from
> `vector::at()`.
>
> * I won't throw unless I'm out of memory
>> * valid arguments are E1 and E2
>> * if you pass anything other than that, I'll probably crash at some
>> undefined point in the future if you're lucky. If you're not, I might just
>> expose your passwords to someone, corrupt the 1000-hour-old campaign save,
>> or invert USDJPY or something. Who knows? Who even cares? What does it all
>> mean anyway?
>>
>> Now, for the record, I prefer exceptions when contracts are violated, but
>> I'm not mandating that here.
>>
>
> Then you seem to have a misunderstanding of what a contract means. A
> "contract" is an agreement between the caller and the callee, such that if
> the caller violates the agreement, then all bets are off. Contracts specify
> things which are not part of a function's interface, things which are
> assumed rather than verified.
>
> If you throw on incorrect input values, that's part of the function's
> interface. And therefore, it's well-defined behavior. And therefore, such
> cases are *not* a violation of the contract of the function.
>
> You can rely on `vector::at()` to throw if its out of range. You cannot
> rely on `vector::operator[]` doing anything if its out of range. `at` has a
> wider contract (more acceptable values) than `operator[]`.
>
>
>> I'm merely responding to the concerns of a sceptical
>> game/FX/fintech/protein modelling/flight control system developer who
>> wrongly thinks he is buying performance with UB. He's not. He's buying UB
>> with UB, and gaining nothing.
>>
> --
> 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/cd792ea4-516e-4e7c-
> b557-f3e1dd5c4706%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cd792ea4-516e-4e7c-b557-f3e1dd5c4706%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CALvx3hZ4N3Cd472UQ-w5A4ChPY%2BdnMzRYuq-NJnQOksLLdvkSA%40mail.gmail.com.
--001a114aad78c6d71f0560ca0896
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">We're grown=
ups; we can make choices for ourselves about what kind of contracts we wan=
t.</span><div><span style=3D"font-size:12.8px"><br></span></div><div><span =
style=3D"font-size:12.8px">And for you 'grownups' who want to lay l=
andmines, there will be std::unreachable(), which hopefully will the the fi=
rst step on the path to sanity, which is not to allow little terrorists to =
leave landmines in code without telling the complier that that is what you =
intended.</span></div><div><span style=3D"font-size:12.8px"><br></span></di=
v><div><span style=3D"font-size:12.8px"><br></span></div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On 20 December 2017 at 19:4=
3, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com"=
target=3D"_blank">jmckesson@gmail.com</a>></span> wrote:<br><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On Wednesday, Decembe=
r 20, 2017 at 1:23:34 PM UTC-5, Richard Hodges 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">>=C2=A0<span style=3D"font-size:12.8p=
x">This removes two pointless lambdas. The use of `default` makes it clear =
what the function's contract is: that for `make_floom`, it is perfectly=
valid to call:</span><div><span style=3D"font-size:12.8px"><br></span></di=
v><div><span style=3D"font-size:12.8px">The reason for writing it this way =
is to address the concern expressed above the 'default:' clause rem=
oving the possibility of a warning on an unhandled case. It also addresses =
the performance concern. The point is that this is one of a myriad of ways =
to provide a better solution than UB when it comes to return values.</span>=
</div></div></blockquote><div><br></div></span><div>But it's not a &quo=
t;better solution"; it's merely a <i>different</i> one.</div><div>=
<br></div><div>We<i> know</i> how to write functions with wide contracts. T=
hat's a solved problem. The question is what we do in cases where<i> we=
don't want to</i> have a wide contract.</div><div><br></div><div>You&#=
39;re effectively saying that narrow contracts are bad. You can believe tha=
t if you like, but it's not a belief you should impose on other people.=
</div><div><br></div><div>`std::unreachable` (or however we end up spelling=
it) is the solution for people who want to write narrow contracts. But tha=
t should not be <i>required</i>; only encouraged.</div><span class=3D""><di=
v><i><br></i></div><blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div><span style=3D"font-size:12.8px">I am well aware of the various ways =
the function can be expressed, and the difference between exception-based c=
ontracts and exceptionless contracts.</span></div><div><span style=3D"font-=
size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">The con=
tract of the example function is (as you well know):</span></div><div><span=
style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:=
12.8px">* I won't throw unless I'm out of memory</span></div><div><=
span style=3D"font-size:12.8px">* valid arguments are E1 and E2</span></div=
><div><span style=3D"font-size:12.8px">* if you pass anything other than th=
at, I'll treat it as E2</span></div><div><span style=3D"font-size:12.8p=
x"><br></span></div><div><span style=3D"font-size:12.8px">Which is unequivo=
cally better than the alternative:</span></div></div></blockquote><div><br>=
</div></span><div>And who are you to decide what is "unequivocally bet=
ter" for other people? We're grown ups; we can make choices for ou=
rselves about what kind of contracts we want.</div><div><br></div><div>Agai=
n, this is why `vector::operator[]` has a different contract from `vector::=
at()`.</div><span class=3D""><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div><span style=3D"font-size:12.8px">* I won'=
;t throw unless I'm out of memory</span></div><div><div><span style=3D"=
font-size:12.8px">* valid arguments are E1 and E2</span></div><div><span st=
yle=3D"font-size:12.8px">* if you pass anything other than that, I'll p=
robably crash at some undefined point in the future if you're lucky. If=
you're not, I might just expose your passwords to someone, corrupt the=
1000-hour-old campaign save, or invert USDJPY or something. Who knows? Who=
even cares? What does it all mean anyway?</span></div></div><div><span sty=
le=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8=
px">Now, for the record, I prefer exceptions when contracts are violated, b=
ut I'm not mandating that here.</span></div></div></blockquote><div><br=
></div></span><div>Then you seem to have a misunderstanding of what a contr=
act means. A "contract" is an agreement between the caller and th=
e callee, such that if the caller violates the agreement, then all bets are=
off. Contracts specify things which are not part of a function's inter=
face, things which are assumed rather than verified.</div><div><br></div><d=
iv>If you throw on incorrect input values, that's part of the function&=
#39;s interface. And therefore, it's well-defined behavior. And therefo=
re, such cases are <i>not</i> a violation of the contract of the function.<=
/div><div><br></div><div>You can rely on `vector::at()` to throw if its out=
of range. You cannot rely on `vector::operator[]` doing anything if its ou=
t of range. `at` has a wider contract (more acceptable values) than `operat=
or[]`.</div><span class=3D""><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div><span style=3D"font-size:12.8px">I'm m=
erely responding to the concerns of a sceptical game/FX/fintech/protein mod=
elling/flight control system developer who wrongly thinks he is buying perf=
ormance with UB. He's not. He's buying UB with UB, and gaining noth=
ing.</span><br></div></div>
</blockquote></span></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/cd792ea4-516e-4e7c-b557-f3e1dd5c4706%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/cd79=
2ea4-516e-4e7c-<wbr>b557-f3e1dd5c4706%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/CALvx3hZ4N3Cd472UQ-w5A4ChPY%2BdnMzRYu=
q-NJnQOksLLdvkSA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ4N3Cd47=
2UQ-w5A4ChPY%2BdnMzRYuq-NJnQOksLLdvkSA%40mail.gmail.com</a>.<br />
--001a114aad78c6d71f0560ca0896--
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Wed, 20 Dec 2017 20:23:41 +0000
Raw View
--f403045e5b84a0c3bc0560cb5c8b
Content-Type: text/plain; charset="UTF-8"
Can we just get over this entire thread by calling Dunning-Kruger and
moving on? Richard is clearly on a crusade to prove everyone else wrong and
I don't typically see a point in arguing with crusaders.
Feel free to ignore this advice, but heed this: you've been circling the
same arguments for a while now and nothing changes
OTOH...
@Richard: I'm not sure if "veterans" who don't enable their warnings early
and often can be really claimed to be good at this language. Like it or not
(and trust me, I'm not exactly a fan of this), but C++ is a language built
on the fundament of being compatible with code that already exists, as-is,
including build system flags. Sure, some things are being made illegal, but
your proposed change would break every code base I've worked on, which
pretty much guarantees a bunch of NB comments saying "burn this with fire".
So, if you can't be convinced by technical arguments, and that seems to be
the grounds of your crusade, maybe an argument of "this has 0 chance of
ever going even through just EWG" will convince you to abandon your cause?
On Wed, Dec 20, 2017, 7:48 PM Richard Hodges <hodges.r@gmail.com> wrote:
> > We're grown ups; we can make choices for ourselves about what kind of
> contracts we want.
>
> And for you 'grownups' who want to lay landmines, there will be
> std::unreachable(), which hopefully will the the first step on the path to
> sanity, which is not to allow little terrorists to leave landmines in code
> without telling the complier that that is what you intended.
>
>
>
> On 20 December 2017 at 19:43, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>> On Wednesday, December 20, 2017 at 1:23:34 PM UTC-5, Richard Hodges wrote:
>>>
>>> > This removes two pointless lambdas. The use of `default` makes it
>>> clear what the function's contract is: that for `make_floom`, it is
>>> perfectly valid to call:
>>>
>>> The reason for writing it this way is to address the concern expressed
>>> above the 'default:' clause removing the possibility of a warning on an
>>> unhandled case. It also addresses the performance concern. The point is
>>> that this is one of a myriad of ways to provide a better solution than UB
>>> when it comes to return values.
>>>
>>
>> But it's not a "better solution"; it's merely a *different* one.
>>
>> We* know* how to write functions with wide contracts. That's a solved
>> problem. The question is what we do in cases where* we don't want to*
>> have a wide contract.
>>
>> You're effectively saying that narrow contracts are bad. You can believe
>> that if you like, but it's not a belief you should impose on other people.
>>
>> `std::unreachable` (or however we end up spelling it) is the solution for
>> people who want to write narrow contracts. But that should not be
>> *required*; only encouraged.
>>
>> I am well aware of the various ways the function can be expressed, and
>>> the difference between exception-based contracts and exceptionless
>>> contracts.
>>>
>>> The contract of the example function is (as you well know):
>>>
>>> * I won't throw unless I'm out of memory
>>> * valid arguments are E1 and E2
>>> * if you pass anything other than that, I'll treat it as E2
>>>
>>> Which is unequivocally better than the alternative:
>>>
>>
>> And who are you to decide what is "unequivocally better" for other
>> people? We're grown ups; we can make choices for ourselves about what kind
>> of contracts we want.
>>
>> Again, this is why `vector::operator[]` has a different contract from
>> `vector::at()`.
>>
>> * I won't throw unless I'm out of memory
>>> * valid arguments are E1 and E2
>>> * if you pass anything other than that, I'll probably crash at some
>>> undefined point in the future if you're lucky. If you're not, I might just
>>> expose your passwords to someone, corrupt the 1000-hour-old campaign save,
>>> or invert USDJPY or something. Who knows? Who even cares? What does it all
>>> mean anyway?
>>>
>>> Now, for the record, I prefer exceptions when contracts are violated,
>>> but I'm not mandating that here.
>>>
>>
>> Then you seem to have a misunderstanding of what a contract means. A
>> "contract" is an agreement between the caller and the callee, such that if
>> the caller violates the agreement, then all bets are off. Contracts specify
>> things which are not part of a function's interface, things which are
>> assumed rather than verified.
>>
>> If you throw on incorrect input values, that's part of the function's
>> interface. And therefore, it's well-defined behavior. And therefore, such
>> cases are *not* a violation of the contract of the function.
>>
>> You can rely on `vector::at()` to throw if its out of range. You cannot
>> rely on `vector::operator[]` doing anything if its out of range. `at` has a
>> wider contract (more acceptable values) than `operator[]`.
>>
>>
>>> I'm merely responding to the concerns of a sceptical
>>> game/FX/fintech/protein modelling/flight control system developer who
>>> wrongly thinks he is buying performance with UB. He's not. He's buying UB
>>> with UB, and gaining nothing.
>>>
>> --
>> 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/cd792ea4-516e-4e7c-b557-f3e1dd5c4706%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cd792ea4-516e-4e7c-b557-f3e1dd5c4706%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
> --
> 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/CALvx3hZ4N3Cd472UQ-w5A4ChPY%2BdnMzRYuq-NJnQOksLLdvkSA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ4N3Cd472UQ-w5A4ChPY%2BdnMzRYuq-NJnQOksLLdvkSA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAPCFJdSYsO3ikBUrnNfjAP_bJnR%2B1bjCfaNRNbhxunHfS_ahCw%40mail.gmail.com.
--f403045e5b84a0c3bc0560cb5c8b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Can we just get over this entire thread by calling Dunning-K=
ruger and moving on? Richard is clearly on a crusade to prove everyone else=
wrong and I don't typically see a point in arguing with crusaders.</p>
<p dir=3D"ltr">Feel free to ignore this advice, but heed this: you've b=
een circling the same arguments for a while now and nothing changes</p>
<p dir=3D"ltr">OTOH...</p>
<p dir=3D"ltr">@Richard: I'm not sure if "veterans" who don&#=
39;t enable their warnings early and often can be really claimed to be good=
at this language. Like it or not (and trust me, I'm not exactly a fan =
of this), but C++ is a language built on the fundament of being compatible =
with code that already exists, as-is, including build system flags. Sure, s=
ome things are being made illegal, but your proposed change would break eve=
ry code base I've worked on, which pretty much guarantees a bunch of NB=
comments saying "burn this with fire".</p>
<p dir=3D"ltr">So, if you can't be convinced by technical arguments, an=
d that seems to be the grounds of your crusade, maybe an argument of "=
this has 0 chance of ever going even through just EWG" will convince y=
ou to abandon your cause?</p>
<br><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, Dec 20, 2017, 7:48 =
PM Richard Hodges <<a href=3D"mailto:hodges.r@gmail.com">hodges.r@gmail.=
com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
>>=C2=A0<span style=3D"font-size:12.8px">We're grown ups; we can mak=
e choices for ourselves about what kind of contracts we want.</span><div><s=
pan style=3D"font-size:12.8px"><br></span></div></div><div dir=3D"ltr"><div=
><span style=3D"font-size:12.8px">And for you 'grownups' who want t=
o lay landmines, there will be std::unreachable(), which hopefully will the=
the first step on the path to sanity, which is not to allow little terrori=
sts to leave landmines in code without telling the complier that that is wh=
at you intended.</span></div><div><span style=3D"font-size:12.8px"><br></sp=
an></div><div><span style=3D"font-size:12.8px"><br></span></div></div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 20 December 2017 at=
19:43, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail=
..com" target=3D"_blank">jmckesson@gmail.com</a>></span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><span>On Wednesday, December 20, =
2017 at 1:23:34 PM UTC-5, Richard Hodges wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">Thi=
s removes two pointless lambdas. The use of `default` makes it clear what t=
he function's contract is: that for `make_floom`, it is perfectly valid=
to call:</span><div><span style=3D"font-size:12.8px"><br></span></div><div=
><span style=3D"font-size:12.8px">The reason for writing it this way is to =
address the concern expressed above the 'default:' clause removing =
the possibility of a warning on an unhandled case. It also addresses the pe=
rformance concern. The point is that this is one of a myriad of ways to pro=
vide a better solution than UB when it comes to return values.</span></div>=
</div></blockquote><div><br></div></span><div>But it's not a "bett=
er solution"; it's merely a <i>different</i> one.</div><div><br></=
div><div>We<i> know</i> how to write functions with wide contracts. That=
9;s a solved problem. The question is what we do in cases where<i> we don&#=
39;t want to</i> have a wide contract.</div><div><br></div><div>You're =
effectively saying that narrow contracts are bad. You can believe that if y=
ou like, but it's not a belief you should impose on other people.</div>=
<div><br></div><div>`std::unreachable` (or however we end up spelling it) i=
s the solution for people who want to write narrow contracts. But that shou=
ld not be <i>required</i>; only encouraged.</div><span><div><i><br></i></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><span style=
=3D"font-size:12.8px">I am well aware of the various ways the function can =
be expressed, and the difference between exception-based contracts and exce=
ptionless contracts.</span></div><div><span style=3D"font-size:12.8px"><br>=
</span></div><div><span style=3D"font-size:12.8px">The contract of the exam=
ple function is (as you well know):</span></div><div><span style=3D"font-si=
ze:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">* I won&#=
39;t throw unless I'm out of memory</span></div><div><span style=3D"fon=
t-size:12.8px">* valid arguments are E1 and E2</span></div><div><span style=
=3D"font-size:12.8px">* if you pass anything other than that, I'll trea=
t it as E2</span></div><div><span style=3D"font-size:12.8px"><br></span></d=
iv><div><span style=3D"font-size:12.8px">Which is unequivocally better than=
the alternative:</span></div></div></blockquote><div><br></div></span><div=
>And who are you to decide what is "unequivocally better" for oth=
er people? We're grown ups; we can make choices for ourselves about wha=
t kind of contracts we want.</div><div><br></div><div>Again, this is why `v=
ector::operator[]` has a different contract from `vector::at()`.</div><span=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv><span style=3D"font-size:12.8px">* I won't throw unless I'm out =
of memory</span></div><div><div><span style=3D"font-size:12.8px">* valid ar=
guments are E1 and E2</span></div><div><span style=3D"font-size:12.8px">* i=
f you pass anything other than that, I'll probably crash at some undefi=
ned point in the future if you're lucky. If you're not, I might jus=
t expose your passwords to someone, corrupt the 1000-hour-old campaign save=
, or invert USDJPY or something. Who knows? Who even cares? What does it al=
l mean anyway?</span></div></div><div><span style=3D"font-size:12.8px"><br>=
</span></div><div><span style=3D"font-size:12.8px">Now, for the record, I p=
refer exceptions when contracts are violated, but I'm not mandating tha=
t here.</span></div></div></blockquote><div><br></div></span><div>Then you =
seem to have a misunderstanding of what a contract means. A "contract&=
quot; is an agreement between the caller and the callee, such that if the c=
aller violates the agreement, then all bets are off. Contracts specify thin=
gs which are not part of a function's interface, things which are assum=
ed rather than verified.</div><div><br></div><div>If you throw on incorrect=
input values, that's part of the function's interface. And therefo=
re, it's well-defined behavior. And therefore, such cases are <i>not</i=
> a violation of the contract of the function.</div><div><br></div><div>You=
can rely on `vector::at()` to throw if its out of range. You cannot rely o=
n `vector::operator[]` doing anything if its out of range. `at` has a wider=
contract (more acceptable values) than `operator[]`.</div><span><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><spa=
n style=3D"font-size:12.8px">I'm merely responding to the concerns of a=
sceptical game/FX/fintech/protein modelling/flight control system develope=
r who wrongly thinks he is buying performance with UB. He's not. He'=
;s buying UB with UB, and gaining nothing.</span><br></div></div>
</blockquote></span></div><span>
<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@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/cd792ea4-516e-4e7c-b557-f3e1dd5c4706%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cd792ea4-516e-=
4e7c-b557-f3e1dd5c4706%40isocpp.org</a>.<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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ4N3Cd472UQ-w5A4ChPY%2BdnMzRYu=
q-NJnQOksLLdvkSA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CALvx3hZ4N3Cd472UQ-w5A4ChPY%2BdnMzRYuq-NJnQOksLLdvkSA%40mail.gmail.c=
om</a>.<br>
</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/CAPCFJdSYsO3ikBUrnNfjAP_bJnR%2B1bjCfa=
NRNbhxunHfS_ahCw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdSYsO3ikB=
UrnNfjAP_bJnR%2B1bjCfaNRNbhxunHfS_ahCw%40mail.gmail.com</a>.<br />
--f403045e5b84a0c3bc0560cb5c8b--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Wed, 20 Dec 2017 21:37:50 +0100
Raw View
--f403045c48669b4fa90560cb8e2f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
> Can we just get over this entire thread by calling Dunning-Kruger and
moving on?
No, because that is intellectually lazy, solves nothing, and merely
guarantees that the current unsatisfactory state of affairs will be
challenged again, and again, and again.
> but C++ is a language built on the fundament of being compatible with
code that already exists, as-is
Not correct. things get deprecated, and then removed.
e.g. register keyword, auto_ptr, current_exception. This is not a valid
argument.
> So, if you can't be convinced by technical arguments
I am waiting to see a valid technical argument. So far every example UB
function has been trivially replaced (by me) by a defined behaviour one at
zero performance cost, and often an improvement.
Plus, we have an upcoming standard function to signal the intent not to
return.
We are grown-ups. We recognise that there are challenges to progress, but
we do not shy away from them.
On 20 December 2017 at 21:23, Micha=C5=82 Dominiak <griwes@griwes.info> wro=
te:
> Can we just get over this entire thread by calling Dunning-Kruger and
> moving on? Richard is clearly on a crusade to prove everyone else wrong a=
nd
> I don't typically see a point in arguing with crusaders.
>
> Feel free to ignore this advice, but heed this: you've been circling the
> same arguments for a while now and nothing changes
>
> OTOH...
>
> @Richard: I'm not sure if "veterans" who don't enable their warnings earl=
y
> and often can be really claimed to be good at this language. Like it or n=
ot
> (and trust me, I'm not exactly a fan of this), but C++ is a language buil=
t
> on the fundament of being compatible with code that already exists, as-is=
,
> including build system flags. Sure, some things are being made illegal, b=
ut
> your proposed change would break every code base I've worked on, which
> pretty much guarantees a bunch of NB comments saying "burn this with fire=
".
>
> So, if you can't be convinced by technical arguments, and that seems to b=
e
> the grounds of your crusade, maybe an argument of "this has 0 chance of
> ever going even through just EWG" will convince you to abandon your cause=
?
>
> On Wed, Dec 20, 2017, 7:48 PM Richard Hodges <hodges.r@gmail.com> wrote:
>
>> > We're grown ups; we can make choices for ourselves about what kind of
>> contracts we want.
>>
>> And for you 'grownups' who want to lay landmines, there will be
>> std::unreachable(), which hopefully will the the first step on the path =
to
>> sanity, which is not to allow little terrorists to leave landmines in co=
de
>> without telling the complier that that is what you intended.
>>
>>
>>
>> On 20 December 2017 at 19:43, Nicol Bolas <jmckesson@gmail.com> wrote:
>>
>>> On Wednesday, December 20, 2017 at 1:23:34 PM UTC-5, Richard Hodges
>>> wrote:
>>>>
>>>> > This removes two pointless lambdas. The use of `default` makes it
>>>> clear what the function's contract is: that for `make_floom`, it is
>>>> perfectly valid to call:
>>>>
>>>> The reason for writing it this way is to address the concern expressed
>>>> above the 'default:' clause removing the possibility of a warning on a=
n
>>>> unhandled case. It also addresses the performance concern. The point i=
s
>>>> that this is one of a myriad of ways to provide a better solution than=
UB
>>>> when it comes to return values.
>>>>
>>>
>>> But it's not a "better solution"; it's merely a *different* one.
>>>
>>> We* know* how to write functions with wide contracts. That's a solved
>>> problem. The question is what we do in cases where* we don't want to*
>>> have a wide contract.
>>>
>>> You're effectively saying that narrow contracts are bad. You can believ=
e
>>> that if you like, but it's not a belief you should impose on other peop=
le.
>>>
>>> `std::unreachable` (or however we end up spelling it) is the solution
>>> for people who want to write narrow contracts. But that should not be
>>> *required*; only encouraged.
>>>
>>> I am well aware of the various ways the function can be expressed, and
>>>> the difference between exception-based contracts and exceptionless
>>>> contracts.
>>>>
>>>> The contract of the example function is (as you well know):
>>>>
>>>> * I won't throw unless I'm out of memory
>>>> * valid arguments are E1 and E2
>>>> * if you pass anything other than that, I'll treat it as E2
>>>>
>>>> Which is unequivocally better than the alternative:
>>>>
>>>
>>> And who are you to decide what is "unequivocally better" for other
>>> people? We're grown ups; we can make choices for ourselves about what k=
ind
>>> of contracts we want.
>>>
>>> Again, this is why `vector::operator[]` has a different contract from
>>> `vector::at()`.
>>>
>>> * I won't throw unless I'm out of memory
>>>> * valid arguments are E1 and E2
>>>> * if you pass anything other than that, I'll probably crash at some
>>>> undefined point in the future if you're lucky. If you're not, I might =
just
>>>> expose your passwords to someone, corrupt the 1000-hour-old campaign s=
ave,
>>>> or invert USDJPY or something. Who knows? Who even cares? What does it=
all
>>>> mean anyway?
>>>>
>>>> Now, for the record, I prefer exceptions when contracts are violated,
>>>> but I'm not mandating that here.
>>>>
>>>
>>> Then you seem to have a misunderstanding of what a contract means. A
>>> "contract" is an agreement between the caller and the callee, such that=
if
>>> the caller violates the agreement, then all bets are off. Contracts spe=
cify
>>> things which are not part of a function's interface, things which are
>>> assumed rather than verified.
>>>
>>> If you throw on incorrect input values, that's part of the function's
>>> interface. And therefore, it's well-defined behavior. And therefore, su=
ch
>>> cases are *not* a violation of the contract of the function.
>>>
>>> You can rely on `vector::at()` to throw if its out of range. You cannot
>>> rely on `vector::operator[]` doing anything if its out of range. `at` h=
as a
>>> wider contract (more acceptable values) than `operator[]`.
>>>
>>>
>>>> I'm merely responding to the concerns of a sceptical
>>>> game/FX/fintech/protein modelling/flight control system developer who
>>>> wrongly thinks he is buying performance with UB. He's not. He's buying=
UB
>>>> with UB, and gaining nothing.
>>>>
>>> --
>>> 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/cd792ea4-516e-4e7c-
>>> b557-f3e1dd5c4706%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cd792ea4-=
516e-4e7c-b557-f3e1dd5c4706%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>
>>> .
>>>
>>
>> --
>> 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-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/CALvx3hZ4N3Cd472UQ-w5A4ChPY%2BdnMzRYuq-
>> NJnQOksLLdvkSA%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ4N=
3Cd472UQ-w5A4ChPY%2BdnMzRYuq-NJnQOksLLdvkSA%40mail.gmail.com?utm_medium=3De=
mail&utm_source=3Dfooter>
>> .
>>
> --
> 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/CAPCFJdSYsO3ikBUrnNfjAP_bJnR%
> 2B1bjCfaNRNbhxunHfS_ahCw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdSYsO=
3ikBUrnNfjAP_bJnR%2B1bjCfaNRNbhxunHfS_ahCw%40mail.gmail.com?utm_medium=3Dem=
ail&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/CALvx3hbL_d9wrm36WLUaudvXCsz325KMLnPOc0-rRUWwmZ5=
cOQ%40mail.gmail.com.
--f403045c48669b4fa90560cb8e2f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>>=C2=A0<span style=3D"font-size:12.8px">Can we jus=
t get over this entire thread by calling Dunning-Kruger and moving on?</spa=
n></div><div><span style=3D"font-size:12.8px"><br></span></div><div><span s=
tyle=3D"font-size:12.8px">No, because that is intellectually lazy, solves n=
othing, and merely guarantees that the current unsatisfactory state of affa=
irs will be challenged again, and again, and again.</span></div><div><br></=
div>>=C2=A0<span style=3D"font-size:12.8px">but C++ is a language built =
on the fundament of being compatible with code that already exists, as-is</=
span><div><span style=3D"font-size:12.8px"><br></span></div><div><span styl=
e=3D"font-size:12.8px">Not correct. things get deprecated, and then removed=
..</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><=
span style=3D"font-size:12.8px">e.g. register keyword, auto_ptr, current_ex=
ception. This is not a valid argument.</span></div><div><span style=3D"font=
-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">>=
=C2=A0</span><span style=3D"font-size:12.8px">So, if you can't be convi=
nced by technical arguments</span></div><div><span style=3D"font-size:12.8p=
x"><br></span></div><div><span style=3D"font-size:12.8px">I am waiting to s=
ee a valid technical argument. So far every example UB function has been tr=
ivially replaced (by me) by a defined behaviour one at zero performance cos=
t, and often an improvement.</span></div><div><span style=3D"font-size:12.8=
px"><br></span></div><div><span style=3D"font-size:12.8px">Plus, we have an=
upcoming standard function to signal the intent not to return.</span></div=
><div><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D=
"font-size:12.8px">We are grown-ups. We recognise that there are challenges=
to progress, but we do not shy away from them.</span></div><div><span styl=
e=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8p=
x"><br></span></div><div><span style=3D"font-size:12.8px"><br></span></div>=
</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 20 Decem=
ber 2017 at 21:23, Micha=C5=82 Dominiak <span dir=3D"ltr"><<a href=3D"ma=
ilto:griwes@griwes.info" target=3D"_blank">griwes@griwes.info</a>></span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">Can we just get o=
ver this entire thread by calling Dunning-Kruger and moving on? Richard is =
clearly on a crusade to prove everyone else wrong and I don't typically=
see a point in arguing with crusaders.</p>
<p dir=3D"ltr">Feel free to ignore this advice, but heed this: you've b=
een circling the same arguments for a while now and nothing changes</p>
<p dir=3D"ltr">OTOH...</p>
<p dir=3D"ltr">@Richard: I'm not sure if "veterans" who don&#=
39;t enable their warnings early and often can be really claimed to be good=
at this language. Like it or not (and trust me, I'm not exactly a fan =
of this), but C++ is a language built on the fundament of being compatible =
with code that already exists, as-is, including build system flags. Sure, s=
ome things are being made illegal, but your proposed change would break eve=
ry code base I've worked on, which pretty much guarantees a bunch of NB=
comments saying "burn this with fire".</p>
<p dir=3D"ltr">So, if you can't be convinced by technical arguments, an=
d that seems to be the grounds of your crusade, maybe an argument of "=
this has 0 chance of ever going even through just EWG" will convince y=
ou to abandon your cause?</p>
<br><div class=3D"gmail_quote"><div><div class=3D"h5"><div dir=3D"ltr">On W=
ed, Dec 20, 2017, 7:48 PM Richard Hodges <<a href=3D"mailto:hodges.r@gma=
il.com" target=3D"_blank">hodges.r@gmail.com</a>> wrote:<br></div></div>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><div dir=3D"ltr=
">>=C2=A0<span style=3D"font-size:12.8px">We're grown ups; we can ma=
ke choices for ourselves about what kind of contracts we want.</span><div><=
span style=3D"font-size:12.8px"><br></span></div></div><div dir=3D"ltr"><di=
v><span style=3D"font-size:12.8px">And for you 'grownups' who want =
to lay landmines, there will be std::unreachable(), which hopefully will th=
e the first step on the path to sanity, which is not to allow little terror=
ists to leave landmines in code without telling the complier that that is w=
hat you intended.</span></div><div><span style=3D"font-size:12.8px"><br></s=
pan></div><div><span style=3D"font-size:12.8px"><br></span></div></div><div=
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 20 December 2017 a=
t 19:43, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmai=
l.com" target=3D"_blank">jmckesson@gmail.com</a>></span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><span>On Wednesday, December 20,=
2017 at 1:23:34 PM UTC-5, Richard Hodges wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">Th=
is removes two pointless lambdas. The use of `default` makes it clear what =
the function's contract is: that for `make_floom`, it is perfectly vali=
d to call:</span><div><span style=3D"font-size:12.8px"><br></span></div><di=
v><span style=3D"font-size:12.8px">The reason for writing it this way is to=
address the concern expressed above the 'default:' clause removing=
the possibility of a warning on an unhandled case. It also addresses the p=
erformance concern. The point is that this is one of a myriad of ways to pr=
ovide a better solution than UB when it comes to return values.</span></div=
></div></blockquote><div><br></div></span><div>But it's not a "bet=
ter solution"; it's merely a <i>different</i> one.</div><div><br><=
/div><div>We<i> know</i> how to write functions with wide contracts. That&#=
39;s a solved problem. The question is what we do in cases where<i> we don&=
#39;t want to</i> have a wide contract.</div><div><br></div><div>You're=
effectively saying that narrow contracts are bad. You can believe that if =
you like, but it's not a belief you should impose on other people.</div=
><div><br></div><div>`std::unreachable` (or however we end up spelling it) =
is the solution for people who want to write narrow contracts. But that sho=
uld not be <i>required</i>; only encouraged.</div><span><div><i><br></i></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><span styl=
e=3D"font-size:12.8px">I am well aware of the various ways the function can=
be expressed, and the difference between exception-based contracts and exc=
eptionless contracts.</span></div><div><span style=3D"font-size:12.8px"><br=
></span></div><div><span style=3D"font-size:12.8px">The contract of the exa=
mple function is (as you well know):</span></div><div><span style=3D"font-s=
ize:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">* I won&=
#39;t throw unless I'm out of memory</span></div><div><span style=3D"fo=
nt-size:12.8px">* valid arguments are E1 and E2</span></div><div><span styl=
e=3D"font-size:12.8px">* if you pass anything other than that, I'll tre=
at it as E2</span></div><div><span style=3D"font-size:12.8px"><br></span></=
div><div><span style=3D"font-size:12.8px">Which is unequivocally better tha=
n the alternative:</span></div></div></blockquote><div><br></div></span><di=
v>And who are you to decide what is "unequivocally better" for ot=
her people? We're grown ups; we can make choices for ourselves about wh=
at kind of contracts we want.</div><div><br></div><div>Again, this is why `=
vector::operator[]` has a different contract from `vector::at()`.</div><spa=
n><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin=
-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><=
div><span style=3D"font-size:12.8px">* I won't throw unless I'm out=
of memory</span></div><div><div><span style=3D"font-size:12.8px">* valid a=
rguments are E1 and E2</span></div><div><span style=3D"font-size:12.8px">* =
if you pass anything other than that, I'll probably crash at some undef=
ined point in the future if you're lucky. If you're not, I might ju=
st expose your passwords to someone, corrupt the 1000-hour-old campaign sav=
e, or invert USDJPY or something. Who knows? Who even cares? What does it a=
ll mean anyway?</span></div></div><div><span style=3D"font-size:12.8px"><br=
></span></div><div><span style=3D"font-size:12.8px">Now, for the record, I =
prefer exceptions when contracts are violated, but I'm not mandating th=
at here.</span></div></div></blockquote><div><br></div></span><div>Then you=
seem to have a misunderstanding of what a contract means. A "contract=
" is an agreement between the caller and the callee, such that if the =
caller violates the agreement, then all bets are off. Contracts specify thi=
ngs which are not part of a function's interface, things which are assu=
med rather than verified.</div><div><br></div><div>If you throw on incorrec=
t input values, that's part of the function's interface. And theref=
ore, it's well-defined behavior. And therefore, such cases are <i>not</=
i> a violation of the contract of the function.</div><div><br></div><div>Yo=
u can rely on `vector::at()` to throw if its out of range. You cannot rely =
on `vector::operator[]` doing anything if its out of range. `at` has a wide=
r contract (more acceptable values) than `operator[]`.</div><span><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><spa=
n style=3D"font-size:12.8px">I'm merely responding to the concerns of a=
sceptical game/FX/fintech/protein modelling/flight control system develope=
r who wrongly thinks he is buying performance with UB. He's not. He'=
;s buying UB with UB, and gaining nothing.</span><br></div></div>
</blockquote></span></div><span>
<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/cd792ea4-516e-4e7c-b557-f3e1dd5c4706%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/cd79=
2ea4-516e-4e7c-<wbr>b557-f3e1dd5c4706%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" 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></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ4N3Cd472UQ-w5A4ChPY%2BdnMzRYu=
q-NJnQOksLLdvkSA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/CALvx3hZ4N3Cd472UQ-<wbr>w5A4ChPY%2BdnMzRYuq-<wbr>NJnQOksLL=
dvkSA%40mail.gmail.<wbr>com</a>.<br>
</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/CAPCFJdSYsO3ikBUrnNfjAP_bJnR%2B1bjCfa=
NRNbhxunHfS_ahCw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/<wbr>CAPCFJdSYsO3ikBUrnNfjAP_bJnR%<wbr>2B1bjCfaNRNbhxunHfS=
_ahCw%<wbr>40mail.gmail.com</a>.<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/CALvx3hbL_d9wrm36WLUaudvXCsz325KMLnPO=
c0-rRUWwmZ5cOQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hbL_d9wrm36=
WLUaudvXCsz325KMLnPOc0-rRUWwmZ5cOQ%40mail.gmail.com</a>.<br />
--f403045c48669b4fa90560cb8e2f--
.
Author: Myriachan <myriachan@gmail.com>
Date: Wed, 20 Dec 2017 13:09:39 -0800 (PST)
Raw View
------=_Part_3637_1405073253.1513804179528
Content-Type: multipart/alternative;
boundary="----=_Part_3638_1284101651.1513804179529"
------=_Part_3638_1284101651.1513804179529
Content-Type: text/plain; charset="UTF-8"
On Wednesday, December 20, 2017 at 12:37:53 PM UTC-8, Richard Hodges wrote:
>
> I am waiting to see a valid technical argument. So far every example UB
> function has been trivially replaced (by me) by a defined behaviour one at
> zero performance cost, and often an improvement.
>
> Plus, we have an upcoming standard function to signal the intent not to
> return.
>
> We are grown-ups. We recognise that there are challenges to progress, but
> we do not shy away from them.
>
>
So if a function truly cannot return in some case, you would require that
you call a noreturn function in order to suppress a compiler error?
Example:
int function(int x)
{
if (x < 0)
{
#ifdef _WIN32
TerminateProcess(GetCurrentProcess(), 1);
#else
kill(getpid(), SIGKILL);
#endif
}
else
{
return x * 2;
}
}
In this contrived example, if x is negative, the function will not return.
TerminateProcess and kill are not declared [[noreturn]], because if you
target a different process than yourself or use a signal other than
SIGKILL, they will return. You would require a call to a noreturn function
here (e.g. std::unreachable) to avoid a compiler warning?
Here's another example:
int meow(unsigned x)
{
switch (x % 3)
{
case 0:
return 1;
case 1:
case 2:
return 4;
}
}
Would std::unreachable be required somewhere here? A sufficiently-smart
compiler could deduce that x % 3 can only produce one of three values, but
in general, this degenerates into the halting problem.
A final example relates to exhaustive switches based on the range of a type.
int opcode_size_65816(std::uint8_t opcode, bool flagM, bool flagX)
{
switch (opcode)
{
case 0x00: return 2;
...
case 0xA9: return flagM ? 2 : 3;
...
case 0xFF: return 4;
}
}
Since all 256 opcodes are well-defined on 65816, such a function would
cover the entire possibility space of a uint8_t. Would a std::unreachable
call or similar be required here, or would the compiler have to deduce that
all 256 possibilities have been covered?
I'm probably well-known here for generally wanting to give definitions to
currently undefined behavior, but this is one case where the undefined
behavior makes a lot of sense.
Melissa
--
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/4996d660-ae2e-40a3-be1a-1679c5d340d6%40isocpp.org.
------=_Part_3638_1284101651.1513804179529
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, December 20, 2017 at 12:37:53 PM UTC-8, Rich=
ard Hodges 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"><span style=3D"font-size:12.8px">I am waiting to see a valid technical =
argument. So far every example UB function has been trivially replaced (by =
me) by a defined behaviour one at zero performance cost, and often an impro=
vement.</span><div><span style=3D"font-size:12.8px"><br></span></div><div><=
span style=3D"font-size:12.8px">Plus, we have an upcoming standard function=
to signal the intent not to return.</span></div><div><span style=3D"font-s=
ize:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">We are g=
rown-ups. We recognise that there are challenges to progress, but we do not=
shy away from them.</span></div></div><br></blockquote><div><br></div><div=
>So if a function truly cannot return in some case, you would require that =
you call a noreturn function in order to suppress a compiler error?=C2=A0 E=
xample:</div><div><br></div><div>int function(int x)</div><div>{</div><div>=
=C2=A0=C2=A0=C2=A0 if (x < 0)</div><div>=C2=A0=C2=A0=C2=A0 {</div><div>=
=C2=A0=C2=A0=C2=A0 #ifdef _WIN32</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 TerminateProcess(GetCurrentProcess(), 1);</div><div>=C2=A0=C2=
=A0=C2=A0 #else</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 kill(g=
etpid(), SIGKILL);</div><div>=C2=A0=C2=A0=C2=A0 #endif<br></div><div>=C2=A0=
=C2=A0=C2=A0 }</div><div>=C2=A0=C2=A0=C2=A0 else</div><div>=C2=A0=C2=A0=C2=
=A0 {</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return x * 2;<br=
></div><div>=C2=A0=C2=A0=C2=A0 }<br></div><div>}</div><div><br></div><div>I=
n this contrived example, if x is negative, the function will not return.=
=C2=A0 TerminateProcess and kill are not declared [[noreturn]], because if =
you target a different process than yourself or use a signal other than SIG=
KILL, they will return.=C2=A0 You would require a call to a noreturn functi=
on here (e.g. std::unreachable) to avoid a compiler warning?</div><div><br>=
</div><div>Here's another example:</div><div><br></div><div>int meow(un=
signed x)<br>{</div><div>=C2=A0=C2=A0=C2=A0 switch (x % 3)</div><div>=C2=A0=
=C2=A0=C2=A0 {</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 0:=
</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 return 1;</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 1:<=
/div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 2:</div><div>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return 4;<b=
r></div><div>=C2=A0=C2=A0=C2=A0 }<br></div><div>}</div><div><br></div><div>=
Would std::unreachable be required somewhere here?=C2=A0 A sufficiently-sma=
rt compiler could deduce that x % 3 can only produce one of three values, b=
ut in general, this degenerates into the halting problem.</div><div><br></d=
iv><div>A final example relates to exhaustive switches based on the range o=
f a type.<br></div><div><br></div><div>int opcode_size_65816(std::uint8_t o=
pcode, bool flagM, bool flagX)</div><div>{</div><div>=C2=A0=C2=A0=C2=A0 swi=
tch (opcode)</div><div>=C2=A0=C2=A0=C2=A0 {<br></div><div>=C2=A0 =C2=A0=C2=
=A0 =C2=A0=C2=A0 case 0x00: return 2;</div><div>=C2=A0 =C2=A0=C2=A0 =C2=A0=
=C2=A0 ...</div><div>=C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 case 0xA9: return fla=
gM ? 2 : 3;</div><div>=C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 ...</div><div>=C2=A0=
=C2=A0=C2=A0 =C2=A0=C2=A0 case 0xFF: return 4;</div><div>=C2=A0=C2=A0=C2=
=A0 }<br></div><div>}</div><div><br></div><div>Since all 256 opcodes are we=
ll-defined on 65816, such a function would cover the entire possibility spa=
ce of a uint8_t.=C2=A0 Would a std::unreachable call or similar be required=
here, or would the compiler have to deduce that all 256 possibilities have=
been covered?</div><div><br></div><div><br></div><div>I'm probably wel=
l-known here for generally wanting to give definitions to currently undefin=
ed behavior, but this is one case where the undefined behavior makes a lot =
of sense.<br></div><div><br></div><div>Melissa<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/4996d660-ae2e-40a3-be1a-1679c5d340d6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4996d660-ae2e-40a3-be1a-1679c5d340d6=
%40isocpp.org</a>.<br />
------=_Part_3638_1284101651.1513804179529--
------=_Part_3637_1405073253.1513804179528--
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Wed, 20 Dec 2017 21:29:06 +0000
Raw View
--001a1135253af30cb50560cc45b6
Content-Type: text/plain; charset="UTF-8"
Whilst I'm not decided on this (I'm more confused about *some* of the moot
arguments against it, which is why I am continuing to reply), can we please
stop imagining that this is halting-problem related? If something isn't
obvious to the compiler, it (NOT the programmer) can simply add a command
to the very end.
On 20 Dec 2017 21:09, "Myriachan" <myriachan@gmail.com> wrote:
Here's another example:
int meow(unsigned x)
{
switch (x % 3)
{
case 0:
return 1;
case 1:
case 2:
return 4;
}
}
Would std::unreachable be required somewhere here? A sufficiently-smart
compiler could deduce that x % 3 can only produce one of three values, but
in general, this degenerates into the halting problem.
int meow(unsigned x)
{
switch (x % 3)
{
case 0:
return 1;
case 1:
case 2:
return 4;
}
return std::unreachable<int>(); // or whatever it should be. Inserted
by the compiler.
}
The last line never gets reached for a well-formed function. In every case
of a function that does return properly, but there are possibilities
allowed by the underlying type that have a non-returning path, nothing is
broken. Whatsoever. Even if this is applied in every function, even one
with a return on the last line, there is no effect until UB comes into
play. The halting problem is NOTHING to do with this, because the compiler
doesn't need to solve it. That argument is complete and utter nonsense.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNi7-DB%3D3%3DK17EiqhFrVKK6MWdYmb3i4YD3TzazOpAkWA%40mail.gmail.com.
--001a1135253af30cb50560cc45b6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">Whilst I'm not decided on this (I'm more confused=
about <i>some</i> of the moot arguments against it, which is why I am cont=
inuing to reply), can we please stop imagining that this is halting-problem=
related? If something isn't obvious to the compiler, it (NOT the progr=
ammer) can simply add a command to the very end.<br><div class=3D"gmail_ext=
ra" dir=3D"auto"><br><div class=3D"gmail_quote">On 20 Dec 2017 21:09, "=
;Myriachan" <<a href=3D"mailto:myriachan@gmail.com">myriachan@gmail=
..com</a>> wrote:<br type=3D"attribution"><blockquote class=3D"quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div class=3D"quoted-text">Here's another example:</div><div=
><br></div><div>int meow(unsigned x)<br>{</div><div>=C2=A0=C2=A0=C2=A0 swit=
ch (x % 3)</div><div>=C2=A0=C2=A0=C2=A0 {</div><div>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 case 0:</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return 1;</div><div>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 case 1:</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 case 2:</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 return 4;<br></div><div>=C2=A0=C2=A0=C2=A0 }<br></div=
><div>}</div><div><br></div><div>Would std::unreachable be required somewhe=
re here?=C2=A0 A sufficiently-smart compiler could deduce that x % 3 can on=
ly produce one of three values, but in general, this degenerates into the h=
alting problem.</div></div></blockquote></div></div><div dir=3D"auto"><br><=
/div><div dir=3D"auto"><div style=3D"font-family:sans-serif" dir=3D"auto">i=
nt meow(unsigned x)<br>{</div><div style=3D"font-family:sans-serif" dir=3D"=
auto">=C2=A0=C2=A0=C2=A0 switch (x % 3)</div><div style=3D"font-family:sans=
-serif" dir=3D"auto">=C2=A0=C2=A0=C2=A0 {</div><div style=3D"font-family:sa=
ns-serif" dir=3D"auto">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 0:</=
div><div style=3D"font-family:sans-serif" dir=3D"auto">=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return 1;</div><div style=
=3D"font-family:sans-serif" dir=3D"auto">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 case 1:</div><div style=3D"font-family:sans-serif" dir=3D"auto">=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 2:</div><div style=3D"font-=
family:sans-serif" dir=3D"auto">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 return 4;<br></div><div style=3D"font-family:sans-=
serif" dir=3D"auto">=C2=A0 =C2=A0 }<br></div><div style=3D"font-family:sans=
-serif" dir=3D"auto">=C2=A0 =C2=A0 return std::unreachable<int>(); //=
or whatever it should be. Inserted by the compiler.</div><div style=3D"fon=
t-family:sans-serif" dir=3D"auto">}</div><div style=3D"font-family:sans-ser=
if" dir=3D"auto"><br></div><div style=3D"font-family:sans-serif" dir=3D"aut=
o">The last line never gets reached for a well-formed function. In every ca=
se of a function that does return properly, but there are possibilities all=
owed by the underlying type that have a non-returning path, nothing is brok=
en. Whatsoever. Even if this is applied in every function, even one with a =
return on the last line, there is no effect until UB comes into play. The h=
alting problem is NOTHING to do with this, because the compiler doesn't=
need to solve it. That argument is complete and utter nonsense.</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/CAC%2B0CCNi7-DB%3D3%3DK17EiqhFrVKK6MW=
dYmb3i4YD3TzazOpAkWA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNi=
7-DB%3D3%3DK17EiqhFrVKK6MWdYmb3i4YD3TzazOpAkWA%40mail.gmail.com</a>.<br />
--001a1135253af30cb50560cc45b6--
.
Author: Ren Industries <renindustries@gmail.com>
Date: Wed, 20 Dec 2017 16:44:05 -0500
Raw View
--f403043974e89613460560cc7b98
Content-Type: text/plain; charset="UTF-8"
On Dec 20, 2017 16:29, "Jake Arkinstall" <jake.arkinstall@gmail.com> wrote:
Whilst I'm not decided on this (I'm more confused about *some* of the moot
arguments against it, which is why I am continuing to reply), can we please
stop imagining that this is halting-problem related? If something isn't
obvious to the compiler, it (NOT the programmer) can simply add a command
to the very end
No it can't. Not if it wants inlinability to be preserved, which is very
important for leaf functions.
On 20 Dec 2017 21:09, "Myriachan" <myriachan@gmail.com> wrote:
Here's another example:
int meow(unsigned x)
{
switch (x % 3)
{
case 0:
return 1;
case 1:
case 2:
return 4;
}
}
Would std::unreachable be required somewhere here? A sufficiently-smart
compiler could deduce that x % 3 can only produce one of three values, but
in general, this degenerates into the halting problem.
int meow(unsigned x)
{
switch (x % 3)
{
case 0:
return 1;
case 1:
case 2:
return 4;
}
return std::unreachable<int>(); // or whatever it should be. Inserted
by the compiler.
}
The last line never gets reached for a well-formed function. In every case
of a function that does return properly, but there are possibilities
allowed by the underlying type that have a non-returning path, nothing is
broken. Whatsoever. Even if this is applied in every function, even one
with a return on the last line, there is no effect until UB comes into
play. The halting problem is NOTHING to do with this, because the compiler
doesn't need to solve it. That argument is complete and utter nonsense
Nothing is broken but the performance of the code. Which is pretty
important.
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/
isocpp.org/d/msgid/std-proposals/CAC%2B0CCNi7-DB%3D3%
3DK17EiqhFrVKK6MWdYmb3i4YD3TzazOpAkWA%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNi7-DB%3D3%3DK17EiqhFrVKK6MWdYmb3i4YD3TzazOpAkWA%40mail.gmail.com?utm_medium=email&utm_source=footer>
..
--
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/CAMD6iD_8W6ivdOjEHRzc5ve7C8o%2Br4g2f7688HXD59wgBKx_vA%40mail.gmail.com.
--f403043974e89613460560cc7b98
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On Dec 20, 2017 16:29, "Jake Arkinstall" <<a href=3D=
"mailto:jake.arkinstall@gmail.com">jake.arkinstall@gmail.com</a>> wrote:=
<br type=3D"attribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto">Whilst =
I'm not decided on this (I'm more confused about <i>some</i> of the=
moot arguments against it, which is why I am continuing to reply), can we =
please stop imagining that this is halting-problem related? If something is=
n't obvious to the compiler, it (NOT the programmer) can simply add a c=
ommand to the very end</div></blockquote></div></div></div><div dir=3D"auto=
"><br></div><div dir=3D"auto">No it can't. Not if it wants inlinability=
to be preserved, which is very important for leaf functions.=C2=A0</div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_extra"><div=
class=3D"gmail_quote"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div clas=
s=3D"quoted-text"><div class=3D"gmail_extra" dir=3D"auto"><br><div class=3D=
"gmail_quote">On 20 Dec 2017 21:09, "Myriachan" <<a href=3D"ma=
ilto:myriachan@gmail.com" target=3D"_blank">myriachan@gmail.com</a>> wro=
te:<br type=3D"attribution"><blockquote class=3D"m_-950142606147649787quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><div class=3D"m_-950142606147649787quoted-text">Here's =
another example:</div><div><br></div><div>int meow(unsigned x)<br>{</div><d=
iv>=C2=A0=C2=A0=C2=A0 switch (x % 3)</div><div>=C2=A0=C2=A0=C2=A0 {</div><d=
iv>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 0:</div><div>=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return 1;</div><d=
iv>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 1:</div><div>=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 2:</div><div>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return 4;<br></div><div>=C2=
=A0=C2=A0=C2=A0 }<br></div><div>}</div><div><br></div><div>Would std::unrea=
chable be required somewhere here?=C2=A0 A sufficiently-smart compiler coul=
d deduce that x % 3 can only produce one of three values, but in general, t=
his degenerates into the halting problem.</div></div></blockquote></div></d=
iv><div dir=3D"auto"><br></div></div><div dir=3D"auto"><div class=3D"quoted=
-text"><div style=3D"font-family:sans-serif" dir=3D"auto">int meow(unsigned=
x)<br>{</div><div style=3D"font-family:sans-serif" dir=3D"auto">=C2=A0=C2=
=A0=C2=A0 switch (x % 3)</div><div style=3D"font-family:sans-serif" dir=3D"=
auto">=C2=A0=C2=A0=C2=A0 {</div><div style=3D"font-family:sans-serif" dir=
=3D"auto">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 0:</div><div styl=
e=3D"font-family:sans-serif" dir=3D"auto">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return 1;</div><div style=3D"font-family:=
sans-serif" dir=3D"auto">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 1:=
</div><div style=3D"font-family:sans-serif" dir=3D"auto">=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 case 2:</div><div style=3D"font-family:sans-serif"=
dir=3D"auto">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 return 4;<br></div><div style=3D"font-family:sans-serif" dir=3D"auto=
">=C2=A0 =C2=A0 }<br></div></div><div style=3D"font-family:sans-serif" dir=
=3D"auto">=C2=A0 =C2=A0 return std::unreachable<int>(); // or whateve=
r it should be. Inserted by the compiler.</div><div style=3D"font-family:sa=
ns-serif" dir=3D"auto">}</div><div style=3D"font-family:sans-serif" dir=3D"=
auto"><br></div><div style=3D"font-family:sans-serif" dir=3D"auto">The last=
line never gets reached for a well-formed function. In every case of a fun=
ction that does return properly, but there are possibilities allowed by the=
underlying type that have a non-returning path, nothing is broken. Whatsoe=
ver. Even if this is applied in every function, even one with a return on t=
he last line, there is no effect until UB comes into play. The halting prob=
lem is NOTHING to do with this, because the compiler doesn't need to so=
lve it. That argument is complete and utter nonsense</div></div></div></blo=
ckquote></div></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">Not=
hing is broken but the performance of the code. Which is pretty important.<=
/div><div dir=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div class=3D"quoted-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/CAC%2B0CCNi7-DB%3D3%3DK17EiqhFrVKK6MW=
dYmb3i4YD3TzazOpAkWA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgi=
d/std-<wbr>proposals/CAC%2B0CCNi7-DB%3D3%<wbr>3DK17EiqhFrVKK6MWdYmb3i4YD3Tz=
a<wbr>zOpAkWA%40mail.gmail.com</a>.<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/CAMD6iD_8W6ivdOjEHRzc5ve7C8o%2Br4g2f7=
688HXD59wgBKx_vA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD_8W6ivdO=
jEHRzc5ve7C8o%2Br4g2f7688HXD59wgBKx_vA%40mail.gmail.com</a>.<br />
--f403043974e89613460560cc7b98--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Wed, 20 Dec 2017 23:46:35 +0100
Raw View
--001a1143e71e0fb94c0560cd5bbb
Content-Type: text/plain; charset="UTF-8"
Melissa wrote:
Some great examples. Of the three I believe the first is the best, or at
least the most problematic for my position, but not unduly so.
int function(int x)
{
if (x < 0)
{
#ifdef _WIN32
TerminateProcess(GetCurrentProcess(), 1);
#else
kill(getpid(), SIGKILL);
#endif
// this is sufficient to signal intent
std::unreachable(); // or whatever is decided.
}
else
{
return x * 2;
}
}
int meow(unsigned x)
{
switch (x % 3)
{
case 0:
return 1;
case 1:
case 2:
return 4;
}
// this is patently unreachable, but I take your point. x % 3 could be
replaced with a
// function that we know or assume returns 0-3, so...
std::unreachable(); // or equivalent
// of course we could have replaced the case 1 and 2 clauses with default:
- that would achieve
// the same thing.
}
int opcode_size_65816(std::uint8_t opcode, bool flagM, bool flagX)
{
switch (opcode)
{
case 0x00: return 2;
....
case 0xA9: return flagM ? 2 : 3;
....
case 0xFF: return 4;
}
// if all cases are checked, this is obviously unreachable, but if we don't
wish to entrust
// compilers with knowing that, we have
std::unreachable(); // or equivalent. It's a reasonable signal of intent.
// And if the compiler is able to prove that it's a lie,
// why not compel the compiler to call you on the lie?
}
Note: There is precedent for providing tools to convince the compiler that
you are telling the truth. e.g. static_cast. And if the compiler knows
you're not
telling the truth, it will produce a compiler error at the point of the lie.
If that's true for static_cast, why not for assertions of unreachability?
On 20 December 2017 at 22:44, Ren Industries <renindustries@gmail.com>
wrote:
>
>
> On Dec 20, 2017 16:29, "Jake Arkinstall" <jake.arkinstall@gmail.com>
> wrote:
>
> Whilst I'm not decided on this (I'm more confused about *some* of the
> moot arguments against it, which is why I am continuing to reply), can we
> please stop imagining that this is halting-problem related? If something
> isn't obvious to the compiler, it (NOT the programmer) can simply add a
> command to the very end
>
>
> No it can't. Not if it wants inlinability to be preserved, which is very
> important for leaf functions.
>
>
> On 20 Dec 2017 21:09, "Myriachan" <myriachan@gmail.com> wrote:
>
> Here's another example:
>
> int meow(unsigned x)
> {
> switch (x % 3)
> {
> case 0:
> return 1;
> case 1:
> case 2:
> return 4;
> }
> }
>
> Would std::unreachable be required somewhere here? A sufficiently-smart
> compiler could deduce that x % 3 can only produce one of three values, but
> in general, this degenerates into the halting problem.
>
>
> int meow(unsigned x)
> {
> switch (x % 3)
> {
> case 0:
> return 1;
> case 1:
> case 2:
> return 4;
> }
> return std::unreachable<int>(); // or whatever it should be. Inserted
> by the compiler.
> }
>
> The last line never gets reached for a well-formed function. In every case
> of a function that does return properly, but there are possibilities
> allowed by the underlying type that have a non-returning path, nothing is
> broken. Whatsoever. Even if this is applied in every function, even one
> with a return on the last line, there is no effect until UB comes into
> play. The halting problem is NOTHING to do with this, because the compiler
> doesn't need to solve it. That argument is complete and utter nonsense
>
>
> Nothing is broken but the performance of the code. Which is pretty
> important.
>
> --
> 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/is
> ocpp.org/d/msgid/std-proposals/CAC%2B0CCNi7-DB%3D3%3DK17Eiqh
> FrVKK6MWdYmb3i4YD3TzazOpAkWA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNi7-DB%3D3%3DK17EiqhFrVKK6MWdYmb3i4YD3TzazOpAkWA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
>
> --
> 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/CAMD6iD_8W6ivdOjEHRzc5ve7C8o%
> 2Br4g2f7688HXD59wgBKx_vA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD_8W6ivdOjEHRzc5ve7C8o%2Br4g2f7688HXD59wgBKx_vA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CALvx3hZFM1M%2Bx%2B0CvO%2BBTGOarqE_F0piDBQ4Y%2B5h-bj1jONLMA%40mail.gmail.com.
--001a1143e71e0fb94c0560cd5bbb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span style=3D"font-size:12.8px">Melissa wrote:</span><div=
><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font=
-size:12.8px">Some great examples. Of the three I believe the first is the =
best, or at least the most problematic for my position, but not unduly so.<=
/span></div><div><br></div><div><span style=3D"font-size:12.8px"><br></span=
></div><div><div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,254=
);font-size:14px;line-height:21px;white-space:pre"><div><font face=3D"monos=
pace, monospace"><span style=3D"color:rgb(0,0,255)">int</span> function(<sp=
an style=3D"color:rgb(0,0,255)">int</span> x)</font></div><div><font face=
=3D"monospace, monospace">{</font></div><div><font face=3D"monospace, monos=
pace"> <span style=3D"color:rgb(0,0,255)">if</span> (x < <span style=
=3D"color:rgb(9,136,90)">0</span>)</font></div><div><font face=3D"monospace=
, monospace"> {</font></div><div><font face=3D"monospace, monospace"> =
#ifdef _WIN32</font></div><div><font face=3D"monospace, monospace"> =
TerminateProcess(GetCurrentProcess(), <span style=3D"color:rgb(9,136,90)">=
1</span>);</font></div><div><font face=3D"monospace, monospace"> #<span =
style=3D"color:rgb(0,0,255)">else</span></font></div><div><font face=3D"mon=
ospace, monospace"> kill(getpid(), SIGKILL);</font></div><div><font =
face=3D"monospace, monospace"> #endif</font></div><div><font face=3D"mon=
ospace, monospace"> <span style=3D"color:rgb(0,128,0)">// this is su=
fficient to signal intent</span></font></div><div><font face=3D"monospace, =
monospace"> std::unreachable(); <span style=3D"color:rgb(0,128,0)">=
// or whatever is decided.</span></font></div><div><font face=3D"monospace,=
monospace"> }</font></div><div><font face=3D"monospace, monospace"> =
<span style=3D"color:rgb(0,0,255)">else</span></font></div><div><font face=
=3D"monospace, monospace"> {</font></div><div><font face=3D"monospace, m=
onospace"> <span style=3D"color:rgb(0,0,255)">return</span> x * <spa=
n style=3D"color:rgb(9,136,90)">2</span>;</font></div><div><font face=3D"mo=
nospace, monospace"> }</font></div><div><font face=3D"monospace, monospa=
ce">}</font></div><font face=3D"monospace, monospace"><br></font><div><font=
face=3D"monospace, monospace"><span style=3D"color:rgb(0,0,255)">int</span=
> meow(<span style=3D"color:rgb(0,0,255)">unsigned</span> x)</font></div><d=
iv><font face=3D"monospace, monospace">{</font></div><div><font face=3D"mon=
ospace, monospace"> <span style=3D"color:rgb(0,0,255)">switch</span> (x =
% <span style=3D"color:rgb(9,136,90)">3</span>)</font></div><div><font face=
=3D"monospace, monospace"> {</font></div><div><font face=3D"monospace, m=
onospace"> <span style=3D"color:rgb(0,0,255)">case</span> <span styl=
e=3D"color:rgb(9,136,90)">0</span>:</font></div><div><font face=3D"monospac=
e, monospace"> <span style=3D"color:rgb(0,0,255)">return</span> =
<span style=3D"color:rgb(9,136,90)">1</span>;</font></div><div><font face=
=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">case</=
span> <span style=3D"color:rgb(9,136,90)">1</span>:</font></div><div><font =
face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">ca=
se</span> <span style=3D"color:rgb(9,136,90)">2</span>:</font></div><div><f=
ont face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,=
255)">return</span> <span style=3D"color:rgb(9,136,90)">4</span>;</font></d=
iv><div><font face=3D"monospace, monospace"> }</font></div><div><font fa=
ce=3D"monospace, monospace"> <span style=3D"color:rgb(0,128,0)">// this =
is patently unreachable, but I take your point. x % 3 could be replaced wit=
h a </span></font></div><div><font face=3D"monospace, monospace"> <span =
style=3D"color:rgb(0,128,0)">// function that we know or assume returns 0-3=
, so...</span></font></div><div><font face=3D"monospace, monospace"> std=
::unreachable(); <span style=3D"color:rgb(0,128,0)">// or equivalent</span=
></font></div><div><font face=3D"monospace, monospace"> <span style=3D"c=
olor:rgb(0,128,0)">// of course we could have replaced the case 1 and 2 cla=
uses with default: - that would achieve</span></font></div><div><font face=
=3D"monospace, monospace"> <span style=3D"color:rgb(0,128,0)">// the sam=
e thing.</span></font></div><div><font face=3D"monospace, monospace">}</fon=
t></div><font face=3D"monospace, monospace"><br></font><div><font face=3D"m=
onospace, monospace"><span style=3D"color:rgb(0,0,255)">int</span> opcode_s=
ize_65816(std::uint8_t opcode, <span style=3D"color:rgb(0,0,255)">bool</spa=
n> flagM, <span style=3D"color:rgb(0,0,255)">bool</span> flagX)</font></div=
><div><font face=3D"monospace, monospace">{</font></div><div><font face=3D"=
monospace, monospace"> <span style=3D"color:rgb(0,0,255)">switch</span> =
(opcode)</font></div><div><font face=3D"monospace, monospace"> {</font><=
/div><div><font face=3D"monospace, monospace"> <span style=3D"color:=
rgb(0,0,255)">case</span> <span style=3D"color:rgb(48,48,192)">0x00</span>:=
<span style=3D"color:rgb(0,0,255)">return</span> <span style=3D"color:rgb(=
9,136,90)">2</span>;</font></div><div><font face=3D"monospace, monospace"> =
...</font></div><div><font face=3D"monospace, monospace"> <sp=
an style=3D"color:rgb(0,0,255)">case</span> <span style=3D"color:rgb(48,48,=
192)">0xA9</span>: <span style=3D"color:rgb(0,0,255)">return</span> flagM ?=
<span style=3D"color:rgb(9,136,90)">2</span> : <span style=3D"color:rgb(9,=
136,90)">3</span>;</font></div><div><font face=3D"monospace, monospace"> =
...</font></div><div><font face=3D"monospace, monospace"> <span=
style=3D"color:rgb(0,0,255)">case</span> <span style=3D"color:rgb(48,48,19=
2)">0xFF</span>: <span style=3D"color:rgb(0,0,255)">return</span> <span sty=
le=3D"color:rgb(9,136,90)">4</span>;</font></div><div><font face=3D"monospa=
ce, monospace"> }</font></div><div><font face=3D"monospace, monospace"> =
<span style=3D"color:rgb(0,128,0)">// if all cases are checked, this is =
obviously unreachable, but if we don't wish to entrust</span></font></d=
iv><div><font face=3D"monospace, monospace"> <span style=3D"color:rgb(0,=
128,0)">// compilers with knowing that, we have</span></font></div><div><fo=
nt face=3D"monospace, monospace"> std::unreachable(); <span style=3D"col=
or:rgb(0,128,0)">// or equivalent. It's a reasonable signal of intent. =
</span></font></div><div><font face=3D"monospace, monospace"><span style=3D=
"color:rgb(0,128,0)"> // And if the compiler is able to prove that it=
9;s a lie, </span></font></div><div><font face=3D"monospace, monospace"><sp=
an style=3D"color:rgb(0,128,0)"> // why not compel the compiler to call =
you on the lie?</span></font></div><div><font face=3D"monospace, monospace"=
>}</font></div><br></div></div><div><span style=3D"font-size:12.8px"><br></=
span></div><div><span style=3D"font-size:12.8px">Note:=C2=A0</span><span st=
yle=3D"font-size:12.8px">There is precedent for providing tools to convince=
the compiler that you are telling the truth. e.g. static_cast. And if the =
compiler knows you're not</span></div><div><span style=3D"font-size:12.=
8px">telling the truth, it will produce a compiler error at the point of th=
e lie.</span></div><div><span style=3D"font-size:12.8px"><br></span></div><=
div><span style=3D"font-size:12.8px">If that's true for static_cast, wh=
y not for assertions of unreachability?</span></div><div><span style=3D"fon=
t-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px"><br><=
/span><table cellpadding=3D"0" class=3D"gmail-cf gmail-gJ" style=3D"font-si=
ze:12.8px"><tbody></tbody></table></div></div><div class=3D"gmail_extra"><b=
r><div class=3D"gmail_quote">On 20 December 2017 at 22:44, Ren Industries <=
span dir=3D"ltr"><<a href=3D"mailto:renindustries@gmail.com" target=3D"_=
blank">renindustries@gmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"auto"><span class=3D""><div><br><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On Dec 20, 2017 16:29, "Jake =
Arkinstall" <<a href=3D"mailto:jake.arkinstall@gmail.com" target=3D=
"_blank">jake.arkinstall@gmail.com</a>> wrote:<br type=3D"attribution"><=
blockquote class=3D"m_416811850446203069quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto">Whilst I'=
m not decided on this (I'm more confused about <i>some</i> of the moot =
arguments against it, which is why I am continuing to reply), can we please=
stop imagining that this is halting-problem related? If something isn'=
t obvious to the compiler, it (NOT the programmer) can simply add a command=
to the very end</div></blockquote></div></div></div><div dir=3D"auto"><br>=
</div></span><div dir=3D"auto">No it can't. Not if it wants inlinabilit=
y to be preserved, which is very important for leaf functions.=C2=A0</div><=
span class=3D""><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D=
"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"m_41681185044=
6203069quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"auto"><div class=3D"m_416811850446203069quoted-text"=
><div class=3D"gmail_extra" dir=3D"auto"><br><div class=3D"gmail_quote">On =
20 Dec 2017 21:09, "Myriachan" <<a href=3D"mailto:myriachan@gm=
ail.com" target=3D"_blank">myriachan@gmail.com</a>> wrote:<br type=3D"at=
tribution"><blockquote class=3D"m_416811850446203069m_-950142606147649787qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div class=3D"m_416811850446203069m_-950142606147649787q=
uoted-text">Here's another example:</div><div><br></div><div>int meow(u=
nsigned x)<br>{</div><div>=C2=A0=C2=A0=C2=A0 switch (x % 3)</div><div>=C2=
=A0=C2=A0=C2=A0 {</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case=
0:</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 return 1;</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case =
1:</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 2:</div><div>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return 4=
;<br></div><div>=C2=A0=C2=A0=C2=A0 }<br></div><div>}</div><div><br></div><d=
iv>Would std::unreachable be required somewhere here?=C2=A0 A sufficiently-=
smart compiler could deduce that x % 3 can only produce one of three values=
, but in general, this degenerates into the halting problem.</div></div></b=
lockquote></div></div><div dir=3D"auto"><br></div></div><div dir=3D"auto"><=
div class=3D"m_416811850446203069quoted-text"><div style=3D"font-family:san=
s-serif" dir=3D"auto">int meow(unsigned x)<br>{</div><div style=3D"font-fam=
ily:sans-serif" dir=3D"auto">=C2=A0=C2=A0=C2=A0 switch (x % 3)</div><div st=
yle=3D"font-family:sans-serif" dir=3D"auto">=C2=A0=C2=A0=C2=A0 {</div><div =
style=3D"font-family:sans-serif" dir=3D"auto">=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 case 0:</div><div style=3D"font-family:sans-serif" dir=3D"a=
uto">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ret=
urn 1;</div><div style=3D"font-family:sans-serif" dir=3D"auto">=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 1:</div><div style=3D"font-family:sans-=
serif" dir=3D"auto">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 2:</div=
><div style=3D"font-family:sans-serif" dir=3D"auto">=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return 4;<br></div><div style=
=3D"font-family:sans-serif" dir=3D"auto">=C2=A0 =C2=A0 }<br></div></div><di=
v style=3D"font-family:sans-serif" dir=3D"auto">=C2=A0 =C2=A0 return std::u=
nreachable<int>(); // or whatever it should be. Inserted by the compi=
ler.</div><div style=3D"font-family:sans-serif" dir=3D"auto">}</div><div st=
yle=3D"font-family:sans-serif" dir=3D"auto"><br></div><div style=3D"font-fa=
mily:sans-serif" dir=3D"auto">The last line never gets reached for a well-f=
ormed function. In every case of a function that does return properly, but =
there are possibilities allowed by the underlying type that have a non-retu=
rning path, nothing is broken. Whatsoever. Even if this is applied in every=
function, even one with a return on the last line, there is no effect unti=
l UB comes into play. The halting problem is NOTHING to do with this, becau=
se the compiler doesn't need to solve it. That argument is complete and=
utter nonsense</div></div></div></blockquote></div></div></div><div dir=3D=
"auto"><br></div></span><div dir=3D"auto">Nothing is broken but the perform=
ance of the code. Which is pretty important.</div><span class=3D""><div dir=
=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote=
class=3D"m_416811850446203069quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div class=3D"m_416811850446203069quoted-=
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@isoc<wbr>pp.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/CAC%2B0CCNi7-DB%3D3%3DK17EiqhFrVKK6MW=
dYmb3i4YD3TzazOpAkWA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgi=
d/std-proposals<wbr>/CAC%2B0CCNi7-DB%3D3%3DK17Eiqh<wbr>FrVKK6MWdYmb3i4YD3Tz=
azOpAkWA%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div><br></div></div></span></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/CAMD6iD_8W6ivdOjEHRzc5ve7C8o%2Br4g2f7=
688HXD59wgBKx_vA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/CAMD6iD_<wbr>8W6ivdOjEHRzc5ve7C8o%<wbr>2Br4g2f7688HXD59wgB=
Kx_vA%<wbr>40mail.gmail.com</a>.<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/CALvx3hZFM1M%2Bx%2B0CvO%2BBTGOarqE_F0=
piDBQ4Y%2B5h-bj1jONLMA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZF=
M1M%2Bx%2B0CvO%2BBTGOarqE_F0piDBQ4Y%2B5h-bj1jONLMA%40mail.gmail.com</a>.<br=
/>
--001a1143e71e0fb94c0560cd5bbb--
.
Author: Erich Keane <erich.keane@verizon.net>
Date: Wed, 20 Dec 2017 14:47:49 -0800 (PST)
Raw View
------=_Part_3882_1591439298.1513810069908
Content-Type: multipart/alternative;
boundary="----=_Part_3883_2101252499.1513810069909"
------=_Part_3883_2101252499.1513810069909
Content-Type: text/plain; charset="UTF-8"
Both Clang and GCC emit the 2nd bit of code for both, even under O1. see:
https://godbolt.org/g/qpX7A3
This is a vastly reduced example where it is clear to see the optimization,
however in my experience as a compiler author, I've seen many cases where
taking advantage of UB is a massive improvement.
On Tuesday, December 19, 2017 at 10:48:09 PM UTC-8, Richard Hodges wrote:
>
>
> The irony here is that if I actually write that (i.e. express intent
> explicitly and actually code in the U of B) the same compiler, with the
> same command line settings gives me this:
>
> foo(int):
> test edi, edi
> mov edx, OFFSET FLAT:.LC1
> mov eax, OFFSET FLAT:.LC0
> cmovne rax, rdx
> ret
>
> Which is better code.
>
> Explain to me again how developers get better performance by leaving UB
> paths in template leaf functions? This argument is just nonsense.
>
> The actual fact of the matter is that UB *prevents* optimisations. The ISO
> c++ committee would do the community a great service by preventing it
> wherever possible.
>
> In the case of a non-taken return path, it is always possible to express
> the algorithm correctly. There is no need for c++ to allow this sloppy
> approach.
>
>
--
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/7edb3535-3c32-42ed-ac1b-1c1fc2c970ff%40isocpp.org.
------=_Part_3883_2101252499.1513810069909
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Both Clang and GCC emit the 2nd bit of code for both, even=
under O1.=C2=A0 see: https://godbolt.org/g/qpX7A3<br><br>This is a vastly =
reduced example where it is clear to see the optimization, however in my ex=
perience as a compiler author, I've seen many cases where taking advant=
age of UB is a massive improvement.=C2=A0 <br><br><br>On Tuesday, December =
19, 2017 at 10:48:09 PM UTC-8, Richard Hodges wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr"><br><div><div>The irony here is that=
if I actually write that (i.e. express intent explicitly and actually code=
in the U of B) the same compiler, with the same command line settings give=
s me this:</div><div><br></div><div><div style=3D"color:rgb(0,0,0);backgrou=
nd-color:rgb(255,255,254);font-size:14px;line-height:21px;white-space:pre">=
<div><span style=3D"color:rgb(0,128,128)"><font face=3D"courier new, monosp=
ace">foo(int):</font></span></div><div><font face=3D"courier new, monospace=
"> <span style=3D"color:#0000ff">test</span> <span style=3D"color=
:#4864aa">edi</span>, <span style=3D"color:#4864aa">edi</span></font></div>=
<div><font face=3D"courier new, monospace"> <span style=3D"color:#00=
00ff">mov</span> <span style=3D"color:#4864aa">edx</span>, <span style=
=3D"color:#008080">OFFSET</span> <span style=3D"color:#008080">FLAT</span>:=
<span style=3D"color:#008080">.LC1</span></font></div><div><font face=3D"co=
urier new, monospace"> <span style=3D"color:#0000ff">mov</span> =
<span style=3D"color:#4864aa">eax</span>, <span style=3D"color:#008080">OFF=
SET</span> <span style=3D"color:#008080">FLAT</span>:<span style=3D"color:#=
008080">.LC0</span></font></div><div><font face=3D"courier new, monospace">=
<span style=3D"color:#0000ff">cmovne</span> <span style=3D"color:#=
4864aa">rax</span>, <span style=3D"color:#4864aa">rdx</span></font></div><d=
iv><font face=3D"courier new, monospace"> <span style=3D"color:#0000=
ff">ret</span></font></div></div></div><br>Which is better code.</div><div>=
<br></div><div>Explain to me again how developers get better performance by=
leaving UB paths in template leaf functions? This argument is just nonsens=
e.</div><div><br></div><div>The actual fact of the matter is that UB *preve=
nts* optimisations. The ISO c++ committee would do the community a great se=
rvice by preventing it wherever possible.</div><div><br></div><div>In the c=
ase of a non-taken return path, it is always possible to express the algori=
thm correctly. There is no need for c++ to allow this sloppy approach.</div=
><br></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/7edb3535-3c32-42ed-ac1b-1c1fc2c970ff%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7edb3535-3c32-42ed-ac1b-1c1fc2c970ff=
%40isocpp.org</a>.<br />
------=_Part_3883_2101252499.1513810069909--
------=_Part_3882_1591439298.1513810069908--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 20 Dec 2017 23:06:39 +0000
Raw View
--001a1148e9fce7ac560560cda2e7
Content-Type: text/plain; charset="UTF-8"
On 20 Dec 2017 9:29 pm, "Jake Arkinstall" <jake.arkinstall@gmail.com> wrote:
Whilst I'm not decided on this (I'm more confused about *some* of the moot
arguments against it, which is why I am continuing to reply), can we please
stop imagining that this is halting-problem related? If something isn't
obvious to the compiler, it (NOT the programmer) can simply add a command
to the very end.
This is what happens currently; the compiler tags those code paths
unreachable. Unless you're talking about adding overhead, in which case
this is what happens if you enable the return sanitizer.
On 20 Dec 2017 21:09, "Myriachan" <myriachan@gmail.com> wrote:
Here's another example:
int meow(unsigned x)
{
switch (x % 3)
{
case 0:
return 1;
case 1:
case 2:
return 4;
}
}
Would std::unreachable be required somewhere here? A sufficiently-smart
compiler could deduce that x % 3 can only produce one of three values, but
in general, this degenerates into the halting problem.
int meow(unsigned x)
{
switch (x % 3)
{
case 0:
return 1;
case 1:
case 2:
return 4;
}
return std::unreachable<int>(); // or whatever it should be. Inserted
by the compiler.
}
The last line never gets reached for a well-formed function. In every case
of a function that does return properly, but there are possibilities
allowed by the underlying type that have a non-returning path, nothing is
broken. Whatsoever. Even if this is applied in every function, even one
with a return on the last line, there is no effect until UB comes into
play. The halting problem is NOTHING to do with this, because the compiler
doesn't need to solve it. That argument is complete and utter nonsense.
--
You received this message because you are subscribed to a topic in the
Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/
isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/
isocpp.org/d/msgid/std-proposals/CAC%2B0CCNi7-DB%3D3%
3DK17EiqhFrVKK6MWdYmb3i4YD3TzazOpAkWA%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNi7-DB%3D3%3DK17EiqhFrVKK6MWdYmb3i4YD3TzazOpAkWA%40mail.gmail.com?utm_medium=email&utm_source=footer>
..
--
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/CAJnLdOa%3DSRR-LNb%2BuHxQAyUZs4nXPiARB68uM8dQ8trrq7JyJQ%40mail.gmail.com.
--001a1148e9fce7ac560560cda2e7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On 20 Dec 2017 9:29 pm, "Jake Arkinstall" <<a href=
=3D"mailto:jake.arkinstall@gmail.com">jake.arkinstall@gmail.com</a>> wro=
te:<br type=3D"attribution"><blockquote class=3D"quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto">Whil=
st I'm not decided on this (I'm more confused about <i>some</i> of =
the moot arguments against it, which is why I am continuing to reply), can =
we please stop imagining that this is halting-problem related? If something=
isn't obvious to the compiler, it (NOT the programmer) can simply add =
a command to the very end.<div class=3D"quoted-text"></div></div></blockquo=
te></div></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">This is =
what happens currently; the compiler tags those code paths unreachable.=C2=
=A0 Unless you're talking about adding overhead, in which case this is =
what happens if you enable the return sanitizer.=C2=A0</div><div dir=3D"aut=
o"><br></div><div dir=3D"auto"><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div class=3D"quoted-t=
ext"><br><div class=3D"gmail_extra" dir=3D"auto"><br><div class=3D"gmail_qu=
ote">On 20 Dec 2017 21:09, "Myriachan" <<a href=3D"mailto:myri=
achan@gmail.com" target=3D"_blank">myriachan@gmail.com</a>> wrote:<br ty=
pe=3D"attribution"><blockquote class=3D"m_8553995229919921623quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"m_8553995229919921623quoted-text">Here's another=
example:</div><div><br></div><div>int meow(unsigned x)<br>{</div><div>=C2=
=A0=C2=A0=C2=A0 switch (x % 3)</div><div>=C2=A0=C2=A0=C2=A0 {</div><div>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 0:</div><div>=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return 1;</div><div>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 1:</div><div>=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 2:</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return 4;<br></div><div>=C2=A0=C2=
=A0=C2=A0 }<br></div><div>}</div><div><br></div><div>Would std::unreachable=
be required somewhere here?=C2=A0 A sufficiently-smart compiler could dedu=
ce that x % 3 can only produce one of three values, but in general, this de=
generates into the halting problem.</div></div></blockquote></div></div><di=
v dir=3D"auto"><br></div></div><div dir=3D"auto"><div class=3D"quoted-text"=
><div style=3D"font-family:sans-serif" dir=3D"auto">int meow(unsigned x)<br=
>{</div><div style=3D"font-family:sans-serif" dir=3D"auto">=C2=A0=C2=A0=C2=
=A0 switch (x % 3)</div><div style=3D"font-family:sans-serif" dir=3D"auto">=
=C2=A0=C2=A0=C2=A0 {</div><div style=3D"font-family:sans-serif" dir=3D"auto=
">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 0:</div><div style=3D"fon=
t-family:sans-serif" dir=3D"auto">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 return 1;</div><div style=3D"font-family:sans-s=
erif" dir=3D"auto">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 1:</div>=
<div style=3D"font-family:sans-serif" dir=3D"auto">=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 case 2:</div><div style=3D"font-family:sans-serif" dir=
=3D"auto">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 return 4;<br></div><div style=3D"font-family:sans-serif" dir=3D"auto">=
=C2=A0 =C2=A0 }<br></div></div><div style=3D"font-family:sans-serif" dir=3D=
"auto">=C2=A0 =C2=A0 return std::unreachable<int>(); // or whatever i=
t should be. Inserted by the compiler.</div><div style=3D"font-family:sans-=
serif" dir=3D"auto">}</div><div style=3D"font-family:sans-serif" dir=3D"aut=
o"><br></div><div style=3D"font-family:sans-serif" dir=3D"auto">The last li=
ne never gets reached for a well-formed function. In every case of a functi=
on that does return properly, but there are possibilities allowed by the un=
derlying type that have a non-returning path, nothing is broken. Whatsoever=
.. Even if this is applied in every function, even one with a return on the =
last line, there is no effect until UB comes into play. The halting problem=
is NOTHING to do with this, because the compiler doesn't need to solve=
it. That argument is complete and utter nonsense.</div></div></div><div cl=
ass=3D"quoted-text">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/U=
u2QViiWh4k/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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/CAC%2B0CCNi7-DB%3D3%3DK17EiqhFrVKK6MW=
dYmb3i4YD3TzazOpAkWA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgi=
d/std-<wbr>proposals/CAC%2B0CCNi7-DB%3D3%<wbr>3DK17EiqhFrVKK6MWdYmb3i4YD3Tz=
a<wbr>zOpAkWA%40mail.gmail.com</a>.<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/CAJnLdOa%3DSRR-LNb%2BuHxQAyUZs4nXPiAR=
B68uM8dQ8trrq7JyJQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOa%3DSR=
R-LNb%2BuHxQAyUZs4nXPiARB68uM8dQ8trrq7JyJQ%40mail.gmail.com</a>.<br />
--001a1148e9fce7ac560560cda2e7--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 20 Dec 2017 20:04:40 -0600
Raw View
On quarta-feira, 20 de dezembro de 2017 11:17:42 CST Richard Hodges wrote:
> No, what we're going to do is keep the thread on topic. The topic is around
> allowing a function that advertises that it returns a value to not return a
> value.
Correct. And I agree that it should behave properly and return for all valid
input values.
Pass an invalid input (violating preconditions) and all bets are lost. We do
not need to discuss what happens when you abuse the contract because the
mistake was the abuse.
That's different from defensive coding. As I said, I do require defensive
coding in my own code and from others, but that doesn't mean I need to impose
that on everyone.
> Show me a function that performs better when there is a control path that
> does not return a value that does not produce code at least as good when
> written so that all control paths return a value.
I did. You saw the assembly: it performs as good as the one you wrote, plus it
was more readable (IMO).
> A function that is never called either,
>
> * has no place in the program in the first place. Just delete it, or
If it's deleted, it has no address. Then it can't be used as a marker, which
may have been its entire purpose.
> * may be called in some later modification to the program, so it had better
> be correct, by the strictest definition of the term.
Again, that's defensive coding. Good practices are good and all, but we need
not impose it on everyone.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/2735193.6QQXDYXs0R%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 20 Dec 2017 20:11:01 -0600
Raw View
On quarta-feira, 20 de dezembro de 2017 16:46:35 CST Richard Hodges wrote:
> If that's true for static_cast, why not for assertions of unreachability?
Backwards compatibility.
A green field solution does not work for a brown field. We need to cope with
existing code.
Adding std::unreachable() now is a good start. Maybe in 10 or 15 years, we can
consider raising the "falling off the edge of the function" to error. Just not
today.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/35207831.EC1pebZLK5%40tjmaciei-mobl1.
.
Author: Myriachan <myriachan@gmail.com>
Date: Wed, 20 Dec 2017 18:55:22 -0800 (PST)
Raw View
------=_Part_4317_279100426.1513824922879
Content-Type: multipart/alternative;
boundary="----=_Part_4318_1526567480.1513824922880"
------=_Part_4318_1526567480.1513824922880
Content-Type: text/plain; charset="UTF-8"
On Wednesday, December 20, 2017 at 1:29:08 PM UTC-8, Jake Arkinstall wrote:
>
> Whilst I'm not decided on this (I'm more confused about *some* of the
> moot arguments against it, which is why I am continuing to reply), can we
> please stop imagining that this is halting-problem related? If something
> isn't obvious to the compiler, it (NOT the programmer) can simply add a
> command to the very end.
>
> int meow(unsigned x)
> {
> switch (x % 3)
> {
> case 0:
> return 1;
> case 1:
> case 2:
> return 4;
> }
> return std::unreachable<int>(); // or whatever it should be. Inserted
> by the compiler.
> }
>
> The last line never gets reached for a well-formed function. In every case
> of a function that does return properly, but there are possibilities
> allowed by the underlying type that have a non-returning path, nothing is
> broken. Whatsoever. Even if this is applied in every function, even one
> with a return on the last line, there is no effect until UB comes into
> play. The halting problem is NOTHING to do with this, because the compiler
> doesn't need to solve it. That argument is complete and utter nonsense.
>
I'm kind of confused at this point. Wouldn't a compiler inserting
std::unreachable automatically like that be equivalent to the status quo?
The effect of std::unreachable is undefined behavior. Having
std::unreachable() there is equivalent to the current way things are done
if you don't have a return at all.
Is the entire thing being discussed in this thread simply a requirement
that we use a noreturn function in every code path of value-returning
functions where we don't have an explicit return?
Melissa
--
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/972a2a2a-d25f-4868-998c-7a0b4d3c1e03%40isocpp.org.
------=_Part_4318_1526567480.1513824922880
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, December 20, 2017 at 1:29:08 PM UTC-8, Jake =
Arkinstall wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"a=
uto">Whilst I'm not decided on this (I'm more confused about <i>som=
e</i> of the moot arguments against it, which is why I am continuing to rep=
ly), can we please stop imagining that this is halting-problem related? If =
something isn't obvious to the compiler, it (NOT the programmer) can si=
mply add a command to the very end.<br><br><div dir=3D"auto"><div style=3D"=
font-family:sans-serif" dir=3D"auto">int meow(unsigned x)<br>{</div><div st=
yle=3D"font-family:sans-serif" dir=3D"auto">=C2=A0=C2=A0=C2=A0 switch (x % =
3)</div><div style=3D"font-family:sans-serif" dir=3D"auto">=C2=A0=C2=A0=C2=
=A0 {</div><div style=3D"font-family:sans-serif" dir=3D"auto">=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 0:</div><div style=3D"font-family:sans-=
serif" dir=3D"auto">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 return 1;</div><div style=3D"font-family:sans-serif" dir=3D"au=
to">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 1:</div><div style=3D"f=
ont-family:sans-serif" dir=3D"auto">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 case 2:</div><div style=3D"font-family:sans-serif" dir=3D"auto">=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return 4;<br><=
/div><div style=3D"font-family:sans-serif" dir=3D"auto">=C2=A0 =C2=A0 }<br>=
</div><div style=3D"font-family:sans-serif" dir=3D"auto">=C2=A0 =C2=A0 retu=
rn std::unreachable<int>(); // or whatever it should be. Inserted by =
the compiler.</div><div style=3D"font-family:sans-serif" dir=3D"auto">}</di=
v><div style=3D"font-family:sans-serif" dir=3D"auto"><br></div><div style=
=3D"font-family:sans-serif" dir=3D"auto">The last line never gets reached f=
or a well-formed function. In every case of a function that does return pro=
perly, but there are possibilities allowed by the underlying type that have=
a non-returning path, nothing is broken. Whatsoever. Even if this is appli=
ed in every function, even one with a return on the last line, there is no =
effect until UB comes into play. The halting problem is NOTHING to do with =
this, because the compiler doesn't need to solve it. That argument is c=
omplete and utter nonsense.</div></div></div></blockquote><div><br></div><d=
iv><br></div><div>I'm kind of confused at this point.=C2=A0 Wouldn'=
t a compiler inserting std::unreachable automatically like that be equivale=
nt to the status quo?=C2=A0 The effect of std::unreachable is undefined beh=
avior.=C2=A0 Having std::unreachable() there is equivalent to the current w=
ay things are done if you don't have a return at all.</div><div><br></d=
iv><div>Is the entire thing being discussed in this thread simply a require=
ment that we use a noreturn function in every code path of value-returning =
functions where we don't have an explicit return?</div><div><br></div><=
div>Melissa<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/972a2a2a-d25f-4868-998c-7a0b4d3c1e03%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/972a2a2a-d25f-4868-998c-7a0b4d3c1e03=
%40isocpp.org</a>.<br />
------=_Part_4318_1526567480.1513824922880--
------=_Part_4317_279100426.1513824922879--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 20 Dec 2017 22:14:00 -0800 (PST)
Raw View
------=_Part_4787_618325707.1513836840747
Content-Type: multipart/alternative;
boundary="----=_Part_4788_21864192.1513836840748"
------=_Part_4788_21864192.1513836840748
Content-Type: text/plain; charset="UTF-8"
On Wednesday, December 20, 2017 at 3:37:53 PM UTC-5, Richard Hodges wrote:
>
> > Can we just get over this entire thread by calling Dunning-Kruger and
> moving on?
>
> No, because that is intellectually lazy, solves nothing, and merely
> guarantees that the current unsatisfactory state of affairs will be
> challenged again, and again, and again.
>
And they'll fail again and again and again. Because at the end of the day,
the fundamental problem will still remain:* it's a breaking change*.
That is not a step to be taken lightly. And certainly not for ideological
reasons.
> but C++ is a language built on the fundament of being compatible with
> code that already exists, as-is
>
> Not correct. things get deprecated, and then removed.
>
> e.g. register keyword, auto_ptr, current_exception. This is not a valid
> argument.
>
And each one of those removals took place only after careful consideration
of the costs. The committee looked hard at how often `register` and `auto`
were used in real code. `current_exception` was flat out *broken*; it
simply could not do what it was intended to do, and reliance upon it would
only end in tears. And `auto_ptr` by its very nature creates confusion.
And despite such careful consideration, there is even some pushback on
recent removals of things that are clear duplicates of much better stuff
<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0845r0.html>. All
based on the fact that some code just doesn't get updated, but we still
need to be able to use it.
Thus far, you have shown no consideration whatsoever to the costs. You have
repeatedly and categorically *dismissing* any question of how much code
would be broken by the change you desire. You have routinely mocked such
arguments, suggesting that repairing such code is simply a matter of "asking
an intern to do it
<https://groups.google.com/a/isocpp.org/d/msg/std-proposals/Uu2QViiWh4k/bNBBTqNoAgAJ>"
or whatever. Your "solution" to the header-only library issue is to create
some `extern "UBAllowed"` wrapper
<https://groups.google.com/a/isocpp.org/d/msg/std-proposals/Uu2QViiWh4k/cemDmZZmAgAJ>
..
Overall, you've treated the idea of backwards compatibility as something
beneath consideration. I don't agree with bringing back the `std::`binders,
but I at least* respect* the argument for doing so.
At no time do I get the impression that you respect the compatibility issue.
>
--
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/e9b43a8c-ad41-451d-b310-4b33f19bccd1%40isocpp.org.
------=_Part_4788_21864192.1513836840748
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, December 20, 2017 at 3:37:53 PM UTC-5, Richa=
rd Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div>>=C2=A0<span style=3D"font-size:12.8px">Can we just get over thi=
s entire thread by calling Dunning-Kruger and moving on?</span></div><div><=
span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-s=
ize:12.8px">No, because that is intellectually lazy, solves nothing, and me=
rely guarantees that the current unsatisfactory state of affairs will be ch=
allenged again, and again, and again.</span></div></div></blockquote><div><=
br></div><div>And they'll fail again and again and again. Because at th=
e end of the day, the fundamental problem will still remain:<i> it's a =
breaking change</i>.</div><div><br></div><div>That is not a step to be take=
n lightly. And certainly not for ideological reasons.</div><div><i><br></i>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>&g=
t;=C2=A0<span style=3D"font-size:12.8px">but C++ is a language built on the=
fundament of being compatible with code that already exists, as-is</span><=
/div><div><span style=3D"font-size:12.8px"><br></span></div><div><span styl=
e=3D"font-size:12.8px">Not correct. things get deprecated, and then removed=
..</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><=
span style=3D"font-size:12.8px">e.g. register keyword, auto_ptr, current_ex=
ception. This is not a valid argument.</span></div></div></blockquote><div>=
<br></div><div>And each one of those removals took place only after careful=
consideration of the costs. The committee looked hard at how often `regist=
er` and `auto` were used in real code. `current_exception` was flat out <i>=
broken</i>; it simply could not do what it was intended to do, and reliance=
upon it would only end in tears. And `auto_ptr` by its very nature creates=
confusion.</div><div><br></div><div>And despite such careful consideration=
, there is even <a href=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/pape=
rs/2017/p0845r0.html">some pushback on recent removals of things that are c=
lear duplicates of much better stuff</a>. All based on the fact that some c=
ode just doesn't get updated, but we still need to be able to use it.</=
div><div><br></div><div>Thus far, you have shown no consideration whatsoeve=
r to the costs. You have repeatedly and categorically <i>dismissing</i> any=
question of how much code would be broken by the change you desire. You ha=
ve routinely mocked such arguments, suggesting that repairing such code is =
simply a matter of "<a href=3D"https://groups.google.com/a/isocpp.org/=
d/msg/std-proposals/Uu2QViiWh4k/bNBBTqNoAgAJ">asking an intern to do it</a>=
" or whatever. Your "solution" to the header-only library is=
sue is to <a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-propo=
sals/Uu2QViiWh4k/cemDmZZmAgAJ">create some `extern "UBAllowed"` w=
rapper</a>.</div><div><br></div><div>Overall, you've treated the idea o=
f backwards compatibility as something beneath consideration. I don't a=
gree with bringing back the `std::`binders, but I at least<i> respect</i> t=
he argument for doing so.</div><div><br></div><div>At no time do I get the =
impression that you respect the compatibility issue.<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
#ccc solid;padding-left: 1ex;">
<i></i></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/e9b43a8c-ad41-451d-b310-4b33f19bccd1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e9b43a8c-ad41-451d-b310-4b33f19bccd1=
%40isocpp.org</a>.<br />
------=_Part_4788_21864192.1513836840748--
------=_Part_4787_618325707.1513836840747--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 20 Dec 2017 22:36:07 -0800 (PST)
Raw View
------=_Part_4723_2103213832.1513838167670
Content-Type: multipart/alternative;
boundary="----=_Part_4724_1646772379.1513838167670"
------=_Part_4724_1646772379.1513838167670
Content-Type: text/plain; charset="UTF-8"
On Wednesday, December 20, 2017 at 9:11:05 PM UTC-5, Thiago Macieira wrote:
>
> On quarta-feira, 20 de dezembro de 2017 16:46:35 CST Richard Hodges wrote:
> > If that's true for static_cast, why not for assertions of
> unreachability?
>
> Backwards compatibility.
>
> A green field solution does not work for a brown field. We need to cope
> with
> existing code.
>
> Adding std::unreachable() now is a good start. Maybe in 10 or 15 years, we
> can
> consider raising the "falling off the edge of the function" to error. Just
> not
> today.
>
I think it's important to recognize two things.
First, nobody here is arguing against `unreachable`. Nobody is saying that
it's a bad idea to mark such code. Indeed, I think most of us would agree
that seeing it used for this purpose would be a very good thing.
The point being argued is the title of the thread: whether it should be
ill-formed to* not* use `unreachable`.
Second, this is hardly the first time something like this has come up.
Consider `switch/case`. I think we can all agree, to some extent, that
default fall-through of `case` labels was a really bad idea. Fall-through
is obviously something we want, but making it the default and requiring the
use of `break` to get the typical behavior was not a good thing. And
personally, `case` fall-through has gotten me more than forgetting a return
statement.
And yet, we didn't get that fixed. Because we *can't*. It's just not
reasonable to radically change people's code like that. Even if you have no
default (that is, using neither break nor fallthrough nor some other jump
statement is ill-formed), you still break tons of working code. And while
you might be able to write a tool to add fallthrough where appropriate,
it's still breaking tons and tons of code.
We got the best that we can reasonably expect to get: an attribute. We can
use compiler switches to warn for lacking that attribute. And we can even
use switches to make that warning into an error.
We can all agree that we would* prefer* to have `break` be the default or
to just have no default and always be explicit. But that's not a viable
option, so we do the best we can.
So too here. If we were starting from a blank slate, it would probably be
reasonable to do as you suggest. But we're not starting from a blank slate,
nor will we ever be doing so. C++ is C++, and we're not allowed to just
change it however we want. The maintainers of the language have a
responsibility towards existing code. And that responsibility cannot be
ignored just because it's inconvenient.
So we should do the best we can: an attribute (or function or whatever; the
compiler can make it disappear) that marks a code path as never being
reached. Then, we can choose to compile with appropriate warnings, and even
treat them as errors.
It's not a perfect solution. But it is a* viable* one.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e00f2992-9fbf-4201-a9fe-a5ac2094fdb7%40isocpp.org.
------=_Part_4724_1646772379.1513838167670
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, December 20, 2017 at 9:11:05 PM UTC-=
5, Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On qu=
arta-feira, 20 de dezembro de 2017 16:46:35 CST Richard Hodges wrote:
<br>> If that's true for static_cast, why not for assertions of unre=
achability?
<br>
<br>Backwards compatibility.
<br>
<br>A green field solution does not work for a brown field. We need to cope=
with=20
<br>existing code.
<br>
<br>Adding std::unreachable() now is a good start. Maybe in 10 or 15 years,=
we can=20
<br>consider raising the "falling off the edge of the function" t=
o error. Just not=20
<br>today.<br></blockquote><div><br></div><div>I think it's important t=
o recognize two things.</div><div><br></div><div>First, nobody here is argu=
ing against `unreachable`. Nobody is saying that it's a bad idea to mar=
k such code. Indeed, I think most of us would agree that seeing it used for=
this purpose would be a very good thing.</div><div><br></div><div>The poin=
t being argued is the title of the thread: whether it should be ill-formed =
to<i> not</i> use `unreachable`.</div><div><br></div><div>Second, this is h=
ardly the first time something like this has come up.</div><div><br></div><=
div>Consider `switch/case`. I think we can all agree, to some extent, that =
default fall-through of `case` labels was a really bad idea. Fall-through i=
s obviously something we want, but making it the default and requiring the =
use of `break` to get the typical behavior was not a good thing. And person=
ally, `case` fall-through has gotten me more than forgetting a return state=
ment.</div><div><br></div><div>And yet, we didn't get that fixed. Becau=
se we <i>can't</i>. It's just not reasonable to radically change pe=
ople's code like that. Even if you have no default (that is, using neit=
her break nor fallthrough nor some other jump statement is ill-formed), you=
still break tons of working code. And while you might be able to write a t=
ool to add fallthrough where appropriate, it's still breaking tons and =
tons of code.</div><div><br></div><div>We got the best that we can reasonab=
ly expect to get: an attribute. We can use compiler switches to warn for la=
cking that attribute. And we can even use switches to make that warning int=
o an error.</div><div><br></div><div>We can all agree that we would<i> pref=
er</i> to have `break` be the default or to just have no default and always=
be explicit. But that's not a viable option, so we do the best we can.=
</div><div><br></div><div>So too here. If we were starting from a blank sla=
te, it would probably be reasonable to do as you suggest. But we're not=
starting from a blank slate, nor will we ever be doing so. C++ is C++, and=
we're not allowed to just change it however we want. The maintainers o=
f the language have a responsibility towards existing code. And that respon=
sibility cannot be ignored just because it's inconvenient.</div><div><b=
r></div><div>So we should do the best we can: an attribute (or function or =
whatever; the compiler can make it disappear) that marks a code path as nev=
er being reached. Then, we can choose to compile with appropriate warnings,=
and even treat them as errors.</div><div><br></div><div>It's not a per=
fect solution. But it is a<i> viable</i> one.<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/e00f2992-9fbf-4201-a9fe-a5ac2094fdb7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e00f2992-9fbf-4201-a9fe-a5ac2094fdb7=
%40isocpp.org</a>.<br />
------=_Part_4724_1646772379.1513838167670--
------=_Part_4723_2103213832.1513838167670--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Thu, 21 Dec 2017 08:18:51 +0100
Raw View
--001a1140a4fa134c770560d483fc
Content-Type: text/plain; charset="UTF-8"
Nicol:
> At no time do I get the impression that you respect the compatibility
issue.
This is a fair observation. c++98 code which has the keyword 'register' or
'auto' in it will no longer compile. Therefore the community, if it really
is compiling "old and untouched code", must be doing so in an old compiler
or a compiler set to an old standard.
When we move a library from 1.0 to 2.0, we expect some breaking changes.
Lessons have been learned. Concepts move on. What was considered correct
has been shown to have failed.
Deprecating and repurposing auto and register is a breaking, "1.0 to 2.0"
change, without doubt. Old programs will not compile on new compilers
without being set to -std=c++98. Good. There is a fallback position and we
can all move on. Everyone's needs are satisfied.
So, since the c++ committee have correctly, thoughtfully and boldly
"disregarded" the compatibility issue before, they can do it again. They
actually have form from 2011, if not much remaining courage.
> pushback on recent removals...
It is the nature of human beings that some prefer to look back to
comfortable nostalgia, "ah, we used to punch cards you know", and some
prefer progress - "Cool! Moon-landings! Hyperloops! Teslas!"
This biological history of the planet is unequivocal - you move forward or
you die out. For this reason, all backward-looking arguments are irrelevant
as they will sooner or later be extinguished by inevitability. It is never
worth engaging with chronic nostalgists.
> Thus far, you have shown no consideration whatsoever to the costs.
I am considering the present-day cost to productivity as being more of a
drain on humanity than the theoretical cost of annotating tricky code. All
those register and auto keywords vanished without fuss. Well, there may
have been some fuss, but we got through it without anyone feeling too hurt.
> Overall, you've treated the idea of backwards compatibility as something
beneath consideration.
Almost. c++17 should always be compatible with c++17, but there is no
reason whatsoever that c++20 needs to be fully compatible with c++17. After
all, some c++14 programs will no longer compile in c++17. We've been here
before. It's easy.
> At no time do I get the impression that you respect the compatibility
issue.
While I respect it, I do not regard it as a sacred cow. Neither clearly,
did the instigators of c++11 and c++17.
> First, nobody here is arguing against `unreachable`. Nobody is saying
that it's a bad idea to mark such code. Indeed, I think most of us would
agree that seeing it used for this purpose would be a very good thing.
Wonderful - we have consensus. Now that we're over arguing for argument's
sake, let's talk positively about how we achieve it. My proposed solution
may not be perfect. But I put my head above the parapet. You took your
shots and they bounced off my thick skin. Now let's go forward and see
about making things better. See what I'm doing here? Seeking to move
forward to solve something that we both know is broken. There may be a
3-step solution, or maybe it can be fixed in one stroke. But it *can* be
fixed.
> The point being argued is the title of the thread: whether it should be
ill-formed to* not* use `unreachable`.
I think we all agree that it *should* be, and we understand that there are
challenges around making it so, ultimately because of decisions taken in
1973. Let's stand on the shoulders of Mr Kernighan and Mr Ritchie, not in
their shadow,
> Consider `switch/case`.
No, let's not. It'a change of subject.
> We got the best that we can reasonably expect to get
What are you? Some kind of victim? In life, we stop getting what we want
when we give up responsibility. Take responsibility. Get the good stuff.
> So we should do the best we can:
Totally agree. Repurposing auto and causing register to be an error was
"the best we can". Let's do that. Now all we have to do is discuss timing
and method.
> It's not a perfect solution.
Then its not a solution, it's a mitigation. It's a step on the road to a
solution. Solution means that the problem is solved, and will never again
have to be considered.
Myriam:
I had another think about your first function. I think I have a better,
more expressive answer:
// Annotated noreturn. Great. The compiler is well aware that there is no
return path from
// calling this "function". In fact, it's not a function is it? It's a
sequence of code that terminates the process.
// there's no need to even generate a "ret" instruction or equivalent at
the end of it.
[[noreturn]]
void nuke()
{
#ifdef _WIN32
TerminateProcess(GetCurrentProcess(), 1);
#else
kill(getpid(), SIGKILL);
#endif
}
int function(int x)
{
if (x < 0)
{
nuke(); // the compiler implicitly knows that this cannot return. it can
emit "jmp _nuke(void)" rather than "call _nuke(void)"
}
else
{
return x * 2;
}
}
Now, the solution above does of course rely on the compiler actually
heeding the [[noreturn]] attribute. I don't think it's unreasonable to
mandate that in the next standard, this attribute should be a mandatory
part of the language and have the power of a keyword. I am not saying that
the compiler should insert code to check at runtime that it's not lying.
Having said that, there would be no harm in it doing so. A [[noreturn]]
"function" is by definition, not going to be called in a loop. It's going
to be called *at most once* per program run.
On 21 December 2017 at 07:14, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, December 20, 2017 at 3:37:53 PM UTC-5, Richard Hodges wrote:
>>
>> > Can we just get over this entire thread by calling Dunning-Kruger and
>> moving on?
>>
>> No, because that is intellectually lazy, solves nothing, and merely
>> guarantees that the current unsatisfactory state of affairs will be
>> challenged again, and again, and again.
>>
>
> And they'll fail again and again and again. Because at the end of the day,
> the fundamental problem will still remain:* it's a breaking change*.
>
> That is not a step to be taken lightly. And certainly not for ideological
> reasons.
>
> > but C++ is a language built on the fundament of being compatible with
>> code that already exists, as-is
>>
>> Not correct. things get deprecated, and then removed.
>>
>> e.g. register keyword, auto_ptr, current_exception. This is not a valid
>> argument.
>>
>
> And each one of those removals took place only after careful consideration
> of the costs. The committee looked hard at how often `register` and `auto`
> were used in real code. `current_exception` was flat out *broken*; it
> simply could not do what it was intended to do, and reliance upon it would
> only end in tears. And `auto_ptr` by its very nature creates confusion.
>
> And despite such careful consideration, there is even some pushback on
> recent removals of things that are clear duplicates of much better stuff
> <http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0845r0.html>.
> All based on the fact that some code just doesn't get updated, but we still
> need to be able to use it.
>
> Thus far, you have shown no consideration whatsoever to the costs. You
> have repeatedly and categorically *dismissing* any question of how much
> code would be broken by the change you desire. You have routinely mocked
> such arguments, suggesting that repairing such code is simply a matter of "asking
> an intern to do it
> <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/Uu2QViiWh4k/bNBBTqNoAgAJ>"
> or whatever. Your "solution" to the header-only library issue is to create
> some `extern "UBAllowed"` wrapper
> <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/Uu2QViiWh4k/cemDmZZmAgAJ>
> .
>
> Overall, you've treated the idea of backwards compatibility as something
> beneath consideration. I don't agree with bringing back the `std::`binders,
> but I at least* respect* the argument for doing so.
>
> At no time do I get the impression that you respect the compatibility
> issue.
>
>> --
> 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/e9b43a8c-ad41-451d-
> b310-4b33f19bccd1%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e9b43a8c-ad41-451d-b310-4b33f19bccd1%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CALvx3hYYp9m48iHM6%3DtWHtWwwKSjEnVvrg6bRQ-V3VhKOBGyAA%40mail.gmail.com.
--001a1140a4fa134c770560d483fc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Nicol:<div><br></div><div>>=C2=A0<span style=3D"font-si=
ze:12.8px">At no time do I get the impression that you respect the compatib=
ility issue.</span></div><div><span style=3D"font-size:12.8px"><br></span><=
/div><div><span style=3D"font-size:12.8px">This is a fair observation. c++9=
8 code which has the keyword 'register' or 'auto' in it wil=
l no longer compile. Therefore the community, if it really is compiling &qu=
ot;old and untouched code", must be doing so in an old compiler or a c=
ompiler set to an old standard.</span></div><div><span style=3D"font-size:1=
2.8px"><br></span></div><div><span style=3D"font-size:12.8px">When we move =
a library from 1.0 to 2.0, we expect some breaking changes. Lessons have be=
en learned. Concepts move on. What was considered correct has been shown to=
have failed.</span></div><div><span style=3D"font-size:12.8px"><br></span>=
</div><div><span style=3D"font-size:12.8px">Deprecating and repurposing=C2=
=A0auto and register is a breaking, "1.0 to 2.0" change, without =
doubt. Old programs will not compile on new compilers without being set to =
-std=3Dc++98. Good. There is a fallback position and we can all move on. Ev=
eryone's needs are satisfied.</span></div><div><span style=3D"font-size=
:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">So, since t=
he c++ committee have correctly, thoughtfully and boldly "disregarded&=
quot; the compatibility issue before, they can do it again. They actually h=
ave form from 2011, if not much remaining courage.</span></div><div><span s=
tyle=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12=
..8px">> pushback on recent removals...</span></div><div><span style=3D"f=
ont-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">It =
is the nature of human beings that some prefer to look back to comfortable =
nostalgia, "ah, we used to punch cards you know", and some prefer=
progress - "Cool! Moon-landings! Hyperloops! Teslas!"</span></di=
v><div><span style=3D"font-size:12.8px"><br></span></div><div><span style=
=3D"font-size:12.8px">This biological history of the planet is unequivocal =
- you move forward or you die out. For this reason, all backward-looking ar=
guments are irrelevant as they will sooner or later be extinguished by inev=
itability. It is never worth engaging with chronic nostalgists.</span></div=
><div><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D=
"font-size:12.8px">>=C2=A0</span><span style=3D"font-size:12.8px">Thus f=
ar, you have shown no consideration whatsoever to the costs.</span></div><d=
iv><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"fo=
nt-size:12.8px">I am considering the present-day cost to productivity as be=
ing more of a drain on humanity than the theoretical cost of annotating tri=
cky code. All those register and auto keywords vanished without fuss. Well,=
there may have been some fuss, but we got through it without anyone feelin=
g too hurt.</span></div><div><span style=3D"font-size:12.8px"><br></span></=
div><div><span style=3D"font-size:12.8px">=C2=A0>=C2=A0</span><span styl=
e=3D"font-size:12.8px">Overall, you've treated the idea of backwards co=
mpatibility as something beneath consideration.</span></div><div><span styl=
e=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8p=
x">Almost. c++17 should always be compatible with c++17, but there is no re=
ason whatsoever that c++20 needs to be fully compatible with c++17. After a=
ll, some c++14 programs will no longer compile in c++17. We've been her=
e before. It's easy.</span></div><div><span style=3D"font-size:12.8px">=
<br></span></div><div><span style=3D"font-size:12.8px">>=C2=A0</span><sp=
an style=3D"font-size:12.8px">At no time do I get the impression that you r=
espect the compatibility issue.</span></div><div><span style=3D"font-size:1=
2.8px"><br></span></div><div><span style=3D"font-size:12.8px">While I respe=
ct it, I do not regard it as a sacred cow. Neither clearly, did the instiga=
tors of c++11 and c++17.</span></div><div><span style=3D"font-size:12.8px">=
<br></span></div><div><span style=3D"font-size:12.8px">>=C2=A0</span><sp=
an style=3D"font-size:12.8px">First, nobody here is arguing against `unreac=
hable`. Nobody is saying that it's a bad idea to mark such code. Indeed=
, I think most of us would agree that seeing it used for this purpose would=
be a very good thing.</span></div><div><span style=3D"font-size:12.8px"><b=
r></span></div><div><span style=3D"font-size:12.8px">Wonderful - we have co=
nsensus. Now that we're over arguing for argument's sake, let's=
talk positively about how we achieve it. My proposed solution may not be p=
erfect. But I put my head above the parapet. You took your shots and they b=
ounced off my thick skin. Now let's go forward and see about making thi=
ngs better. See what I'm doing here? Seeking to move forward to solve s=
omething that we both know is broken. There may be a 3-step solution, or ma=
ybe it can be fixed in one stroke. But it *can* be fixed.</span></div><div>=
<span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-=
size:12.8px">>=C2=A0</span><span style=3D"font-size:12.8px">The point be=
ing argued is the title of the thread: whether it should be ill-formed to</=
span><i style=3D"font-size:12.8px">=C2=A0not</i><span style=3D"font-size:12=
..8px">=C2=A0use `unreachable`.</span></div><div><span style=3D"font-size:12=
..8px"><br></span></div><div><span style=3D"font-size:12.8px">I think we all=
agree that it *should* be, and we understand that there are challenges aro=
und making it so, ultimately because of decisions taken in 1973. Let's =
stand on the shoulders of Mr Kernighan and Mr Ritchie, not in their shadow,=
</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><s=
pan style=3D"font-size:12.8px">>=C2=A0</span><span style=3D"font-size:12=
..8px">Consider `switch/case`.</span></div><div><span style=3D"font-size:12.=
8px"><br></span></div><div><span style=3D"font-size:12.8px">No, let's n=
ot. It'a change of subject.</span></div><div><span style=3D"font-size:1=
2.8px"><br></span></div><div><span style=3D"font-size:12.8px">>=C2=A0</s=
pan><span style=3D"font-size:12.8px">We got the best that we can reasonably=
expect to get</span></div><div><span style=3D"font-size:12.8px"><br></span=
></div><div><span style=3D"font-size:12.8px">What are you? Some kind of vic=
tim? In life, we stop getting what we want when we give up responsibility. =
Take responsibility. Get the good stuff.</span></div><div><span style=3D"fo=
nt-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">>=
=C2=A0</span><span style=3D"font-size:12.8px">So we should do the best we c=
an:</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div=
><span style=3D"font-size:12.8px">Totally agree. Repurposing auto and causi=
ng register to be an error was "the best we can". Let's do th=
at. Now all we have to do is discuss timing and method.</span></div><div><s=
pan style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-si=
ze:12.8px">>=C2=A0</span><span style=3D"font-size:12.8px">It's not a=
perfect solution.</span></div><div><span style=3D"font-size:12.8px"><br></=
span></div><div><span style=3D"font-size:12.8px">Then its not a solution, i=
t's a mitigation. It's a step on the road to a solution. Solution m=
eans that the problem is solved, and will never again have to be considered=
..</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><=
span style=3D"font-size:12.8px">Myriam:</span></div><div><span style=3D"fon=
t-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">I had=
another think about your first function. I think I have a better, more exp=
ressive answer:</span></div><div><span style=3D"font-size:12.8px"><br></spa=
n></div><div><div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,25=
4);font-size:14px;line-height:21px;white-space:pre"><div style=3D""><span s=
tyle=3D"color:rgb(0,128,0)"><font face=3D"monospace, monospace">// Annotate=
d noreturn. Great. The compiler is well aware that there is no return path =
from</font></span></div><div style=3D""><span style=3D"color:rgb(0,128,0)">=
<font face=3D"monospace, monospace">// calling this "function". I=
n fact, it's not a function is it? It's a sequence of code that ter=
minates the process.</font></span></div><div style=3D""><span style=3D"colo=
r:rgb(0,128,0)"><font face=3D"monospace, monospace">// there's no need =
to even generate a "ret" instruction or equivalent at the end of =
it.</font></span></div><div style=3D""><span style=3D"color:rgb(128,128,128=
)"><font face=3D"monospace, monospace">[[noreturn]]</font></span></div><div=
style=3D""><font face=3D"monospace, monospace"><span style=3D"color:rgb(0,=
0,255)">void</span> nuke()</font></div><div style=3D""><font face=3D"monosp=
ace, monospace">{</font></div><div style=3D""><font face=3D"monospace, mono=
space"> #ifdef _WIN32</font></div><div style=3D""><font face=3D"monospac=
e, monospace"> TerminateProcess(GetCurrentProcess(), <span style=3D"=
color:rgb(9,136,90)">1</span>);</font></div><div style=3D""><font face=3D"m=
onospace, monospace"> #<span style=3D"color:rgb(0,0,255)">else</span></f=
ont></div><div style=3D""><font face=3D"monospace, monospace"> kill(=
getpid(), SIGKILL);</font></div><div style=3D""><font face=3D"monospace, mo=
nospace"> #endif</font></div><div style=3D""><font face=3D"monospace, mo=
nospace">}</font></div><font face=3D"monospace, monospace"><br></font><div =
style=3D""><font face=3D"monospace, monospace"><span style=3D"color:rgb(0,0=
,255)">int</span> function(<span style=3D"color:rgb(0,0,255)">int</span> x)=
</font></div><div style=3D""><font face=3D"monospace, monospace">{</font></=
div><div style=3D""><font face=3D"monospace, monospace"> <span style=3D"=
color:rgb(0,0,255)">if</span> (x < <span style=3D"color:rgb(9,136,90)">0=
</span>)</font></div><div style=3D""><font face=3D"monospace, monospace"> =
{</font></div><div style=3D""><font face=3D"monospace, monospace"> =
nuke(); </font><span style=3D"color:rgb(0,128,0);font-family:monospace,mon=
ospace">// the compiler implicitly knows that this cannot return. it can em=
it "jmp _nuke(void)" rather than "call _nuke(void)"</sp=
an></div><div style=3D""><font face=3D"monospace, monospace"> }</font></=
div><div style=3D""><font face=3D"monospace, monospace"> <span style=3D"=
color:rgb(0,0,255)">else</span></font></div><div style=3D""><font face=3D"m=
onospace, monospace"> {</font></div><div style=3D""><font face=3D"monosp=
ace, monospace"> <span style=3D"color:rgb(0,0,255)">return</span> x =
* <span style=3D"color:rgb(9,136,90)">2</span>;</font></div><div style=3D""=
><font face=3D"monospace, monospace"> }</font></div><div style=3D""><fon=
t face=3D"monospace, monospace">}</font></div><br></div></div><div><span st=
yle=3D"font-size:12.8px">Now, the solution above does of course rely on the=
compiler actually heeding the [[noreturn]] attribute. I don't think it=
's unreasonable to mandate that in the next standard, this attribute sh=
ould be a mandatory part of the language and have the power of a keyword. I=
am not saying that the compiler should insert code to check at runtime tha=
t it's not lying. Having said that, there would be no harm in it doing =
so. A [[noreturn]] "function" is by definition, not going to be c=
alled in a loop. It's going to be called *at most once* per program run=
..</span></div><div><span style=3D"font-size:12.8px"><br></span></div></div>=
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 21 December 20=
17 at 07:14, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@=
gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On Wednesda=
y, December 20, 2017 at 3:37:53 PM UTC-5, Richard Hodges wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>>=C2=A0<span style=3D"=
font-size:12.8px">Can we just get over this entire thread by calling Dunnin=
g-Kruger and moving on?</span></div><div><span style=3D"font-size:12.8px"><=
br></span></div><div><span style=3D"font-size:12.8px">No, because that is i=
ntellectually lazy, solves nothing, and merely guarantees that the current =
unsatisfactory state of affairs will be challenged again, and again, and ag=
ain.</span></div></div></blockquote><div><br></div></span><div>And they'=
;ll fail again and again and again. Because at the end of the day, the fund=
amental problem will still remain:<i> it's a breaking change</i>.</div>=
<div><br></div><div>That is not a step to be taken lightly. And certainly n=
ot for ideological reasons.</div><span class=3D""><div><i><br></i></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>>=C2=A0<span =
style=3D"font-size:12.8px">but C++ is a language built on the fundament of =
being compatible with code that already exists, as-is</span></div><div><spa=
n style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size=
:12.8px">Not correct. things get deprecated, and then removed.</span></div>=
<div><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"=
font-size:12.8px">e.g. register keyword, auto_ptr, current_exception. This =
is not a valid argument.</span></div></div></blockquote><div><br></div></sp=
an><div>And each one of those removals took place only after careful consid=
eration of the costs. The committee looked hard at how often `register` and=
`auto` were used in real code. `current_exception` was flat out <i>broken<=
/i>; it simply could not do what it was intended to do, and reliance upon i=
t would only end in tears. And `auto_ptr` by its very nature creates confus=
ion.</div><div><br></div><div>And despite such careful consideration, there=
is even <a href=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2017=
/p0845r0.html" target=3D"_blank">some pushback on recent removals of things=
that are clear duplicates of much better stuff</a>. All based on the fact =
that some code just doesn't get updated, but we still need to be able t=
o use it.</div><div><br></div><div>Thus far, you have shown no consideratio=
n whatsoever to the costs. You have repeatedly and categorically <i>dismiss=
ing</i> any question of how much code would be broken by the change you des=
ire. You have routinely mocked such arguments, suggesting that repairing su=
ch code is simply a matter of "<a href=3D"https://groups.google.com/a/=
isocpp.org/d/msg/std-proposals/Uu2QViiWh4k/bNBBTqNoAgAJ" target=3D"_blank">=
asking an intern to do it</a>" or whatever. Your "solution" =
to the header-only library issue is to <a href=3D"https://groups.google.com=
/a/isocpp.org/d/msg/std-proposals/Uu2QViiWh4k/cemDmZZmAgAJ" target=3D"_blan=
k">create some `extern "UBAllowed"` wrapper</a>.</div><div><br></=
div><div>Overall, you've treated the idea of backwards compatibility as=
something beneath consideration. I don't agree with bringing back the =
`std::`binders, but I at least<i> respect</i> the argument for doing so.</d=
iv><div><br></div><div>At no time do I get the impression that you respect =
the compatibility issue.<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
<i></i></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/e9b43a8c-ad41-451d-b310-4b33f19bccd1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/e9b4=
3a8c-ad41-451d-<wbr>b310-4b33f19bccd1%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/CALvx3hYYp9m48iHM6%3DtWHtWwwKSjEnVvrg=
6bRQ-V3VhKOBGyAA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hYYp9m48i=
HM6%3DtWHtWwwKSjEnVvrg6bRQ-V3VhKOBGyAA%40mail.gmail.com</a>.<br />
--001a1140a4fa134c770560d483fc--
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Thu, 21 Dec 2017 08:24:04 +0000
Raw View
--001a1146692af002730560d56c1d
Content-Type: text/plain; charset="UTF-8"
On Thu, Dec 21, 2017, 8:18 AM Richard Hodges <hodges.r@gmail.com> wrote:
> Nicol:
>
> > At no time do I get the impression that you respect the compatibility
> issue.
>
> This is a fair observation. c++98 code which has the keyword 'register' or
> 'auto' in it will no longer compile. Therefore the community, if it really
> is compiling "old and untouched code", must be doing so in an old compiler
> or a compiler set to an old standard.
>
> When we move a library from 1.0 to 2.0, we expect some breaking changes.
> Lessons have been learned. Concepts move on. What was considered correct
> has been shown to have failed.
>
> Deprecating and repurposing auto and register is a breaking, "1.0 to 2.0"
> change, without doubt. Old programs will not compile on new compilers
> without being set to -std=c++98. Good. There is a fallback position and we
> can all move on. Everyone's needs are satisfied.
>
> So, since the c++ committee have correctly, thoughtfully and boldly
> "disregarded" the compatibility issue before, they can do it again. They
> actually have form from 2011, if not much remaining courage.
>
No one disregarded this. Things have been removed only after thoughtful
consideration (which is something you are not doing) and, in most cases, a
long depreciation process, or after doing *research* that the break is not
huge enough to be a show stopper. Almost noone used the old meaning of
auto; and register was always a weird, almost unused thing.
And even then, some implementations are adamant that they won't actually
remove std::auto_ptr in the foreseeable future. The reason for this is
simple: the other features you mentioned being dropped weren't going to
cause *massive* breakage. Dropping auto_ptr is going to break some code, so
some implementations still decided to override the committee's decision.
But to the point: this discussion is moot because your proposed "solution"
will not get through EWG. And even if for some weird reason it did, it will
face great NB opposition.
And the funniest part is that compilers already do what you want them to
do, pretty much all of it - just enable warnings.
If you come to the committee with a proposal motivated by "I don't want to
enable warnings to get this warning", noone will take you seriously.
> > pushback on recent removals...
>
> It is the nature of human beings that some prefer to look back to
> comfortable nostalgia, "ah, we used to punch cards you know", and some
> prefer progress - "Cool! Moon-landings! Hyperloops! Teslas!"
>
> This biological history of the planet is unequivocal - you move forward or
> you die out. For this reason, all backward-looking arguments are irrelevant
> as they will sooner or later be extinguished by inevitability. It is never
> worth engaging with chronic nostalgists.
>
None of this matters, because it's the committee that decides where this
language goes.
> > Thus far, you have shown no consideration whatsoever to the costs.
>
> I am considering the present-day cost to productivity as being more of a
> drain on humanity than the theoretical cost of annotating tricky code. All
> those register and auto keywords vanished without fuss. Well, there may
> have been some fuss, but we got through it without anyone feeling too hurt.
>
You can get that productivity already by enabling sufficient warnings in
your implementation of choice. There's literally no reason not to do that.
> > Overall, you've treated the idea of backwards compatibility as
> something beneath consideration.
>
> Almost. c++17 should always be compatible with c++17, but there is no
> reason whatsoever that c++20 needs to be fully compatible with c++17. After
> all, some c++14 programs will no longer compile in c++17. We've been here
> before. It's easy.
>
> > At no time do I get the impression that you respect the compatibility
> issue.
>
> While I respect it, I do not regard it as a sacred cow. Neither clearly,
> did the instigators of c++11 and c++17
>
You are mistaking long process of research and consideration with your
thoughtless dismissal of the idea of compatibility.
> > First, nobody here is arguing against `unreachable`. Nobody is saying
> that it's a bad idea to mark such code. Indeed, I think most of us would
> agree that seeing it used for this purpose would be a very good thing.
>
> Wonderful - we have consensus. Now that we're over arguing for argument's
> sake, let's talk positively about how we achieve it. My proposed solution
> may not be perfect. But I put my head above the parapet. You took your
> shots and they bounced off my thick skin. Now let's go forward and see
> about making things better. See what I'm doing here? Seeking to move
> forward to solve something that we both know is broken. There may be a
> 3-step solution, or maybe it can be fixed in one stroke. But it *can* be
> fixed.
>
This whole paragraph is one based on a fallacious claim that we have
"consensus", which is nonsensical. We have consensus that std::unreachable
is something that we want, for expressly marking things as unreachable.
You've mistaken that for an agreement with your outlandish claims that all
code where you *could* use it should be required to do so, which ks
something that pretty much noone else agrees with you about.
The code without it is not broken, compilers have been warning about having
in obviously wrong cases like the ones you're using as an argument for ages
- and putting things like ud2 in the codegen on the UB paths. This is old
technology. Use warnings and you'll be good.
If your theoretical language would force me to mark code as unreachable in
the mod 3 case, I'd... not use your language. Because the compiler can
trivially see I'll never reach that.
Do you now how else it can see that? By looking at any path containing UB.
Which is why UB is a good thing, and again - it's not like we don't have
the technology to tell you your code is bad and broken.
> > The point being argued is the title of the thread: whether it should be
> ill-formed to* not* use `unreachable`.
>
> I think we all agree that it *should* be, and we understand that there are
> challenges around making it so, ultimately because of decisions taken in
> 1973. Let's stand on the shoulders of Mr Kernighan and Mr Ritchie, not in
> their shadow,
>
> > Consider `switch/case`.
>
> No, let's not. It'a change of subject.
>
> > We got the best that we can reasonably expect to get
>
> What are you? Some kind of victim? In life, we stop getting what we want
> when we give up responsibility. Take responsibility. Get the good stuff.
>
> > So we should do the best we can:
>
> Totally agree. Repurposing auto and causing register to be an error was
> "the best we can". Let's do that. Now all we have to do is discuss timing
> and method.
>
I'd say something here, but I'd said it multiple times in this mail
already...
My final point about it here: if you think compatibility is irrelevant, the
C++ standardization process is not for you. Bye.
> > It's not a perfect solution.
>
> Then its not a solution, it's a mitigation. It's a step on the road to a
> solution. Solution means that the problem is solved, and will never again
> have to be considered.
>
> Myriam:
>
> I had another think about your first function. I think I have a better,
> more expressive answer:
>
> // Annotated noreturn. Great. The compiler is well aware that there is no
> return path from
> // calling this "function". In fact, it's not a function is it? It's a
> sequence of code that terminates the process.
> // there's no need to even generate a "ret" instruction or equivalent at
> the end of it.
> [[noreturn]]
> void nuke()
> {
> #ifdef _WIN32
> TerminateProcess(GetCurrentProcess(), 1);
> #else
> kill(getpid(), SIGKILL);
> #endif
> }
>
> int function(int x)
> {
> if (x < 0)
> {
> nuke(); // the compiler implicitly knows that this cannot return. it can
> emit "jmp _nuke(void)" rather than "call _nuke(void)"
> }
> else
> {
> return x * 2;
> }
>
This is very bad, because in reality this original function would've been
longer and this destroys readability. 0/10 would not pass my code review.
>
> Now, the solution above does of course rely on the compiler actually
> heeding the [[noreturn]] attribute. I don't think it's unreasonable to
> mandate that in the next standard, this attribute should be a mandatory
> part of the language and have the power of a keyword. I am not saying that
> the compiler should insert code to check at runtime that it's not lying.
> Having said that, there would be no harm in it doing so. A [[noreturn]]
> "function" is by definition, not going to be called in a loop. It's going
> to be called *at most once* per program run.
>
>
> On 21 December 2017 at 07:14, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>> On Wednesday, December 20, 2017 at 3:37:53 PM UTC-5, Richard Hodges wrote:
>>>
>>> > Can we just get over this entire thread by calling Dunning-Kruger and
>>> moving on?
>>>
>>> No, because that is intellectually lazy, solves nothing, and merely
>>> guarantees that the current unsatisfactory state of affairs will be
>>> challenged again, and again, and again.
>>>
>>
>> And they'll fail again and again and again. Because at the end of the
>> day, the fundamental problem will still remain:* it's a breaking change*.
>>
>> That is not a step to be taken lightly. And certainly not for ideological
>> reasons.
>>
>> > but C++ is a language built on the fundament of being compatible with
>>> code that already exists, as-is
>>>
>>> Not correct. things get deprecated, and then removed.
>>>
>>> e.g. register keyword, auto_ptr, current_exception. This is not a valid
>>> argument.
>>>
>>
>> And each one of those removals took place only after careful
>> consideration of the costs. The committee looked hard at how often
>> `register` and `auto` were used in real code. `current_exception` was flat
>> out *broken*; it simply could not do what it was intended to do, and
>> reliance upon it would only end in tears. And `auto_ptr` by its very nature
>> creates confusion.
>>
>> And despite such careful consideration, there is even some pushback on
>> recent removals of things that are clear duplicates of much better stuff
>> <http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0845r0.html>.
>> All based on the fact that some code just doesn't get updated, but we still
>> need to be able to use it.
>>
>> Thus far, you have shown no consideration whatsoever to the costs. You
>> have repeatedly and categorically *dismissing* any question of how much
>> code would be broken by the change you desire. You have routinely mocked
>> such arguments, suggesting that repairing such code is simply a matter of "asking
>> an intern to do it
>> <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/Uu2QViiWh4k/bNBBTqNoAgAJ>"
>> or whatever. Your "solution" to the header-only library issue is to create
>> some `extern "UBAllowed"` wrapper
>> <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/Uu2QViiWh4k/cemDmZZmAgAJ>
>> .
>>
>> Overall, you've treated the idea of backwards compatibility as something
>> beneath consideration. I don't agree with bringing back the `std::`binders,
>> but I at least* respect* the argument for doing so.
>>
>> At no time do I get the impression that you respect the compatibility
>> issue.
>>
>>> --
>> 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/e9b43a8c-ad41-451d-b310-4b33f19bccd1%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e9b43a8c-ad41-451d-b310-4b33f19bccd1%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
> --
> 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/CALvx3hYYp9m48iHM6%3DtWHtWwwKSjEnVvrg6bRQ-V3VhKOBGyAA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hYYp9m48iHM6%3DtWHtWwwKSjEnVvrg6bRQ-V3VhKOBGyAA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAPCFJdRKxFJSDFUGYi1soxyVhEo7voTs3HeY9rV%2B%2BP_zG2k5tQ%40mail.gmail.com.
--001a1146692af002730560d56c1d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Dec 21, 2017, 8:18 AM R=
ichard Hodges <<a href=3D"mailto:hodges.r@gmail.com">hodges.r@gmail.com<=
/a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Nic=
ol:</div><div dir=3D"ltr"><div><br></div><div>>=C2=A0<span style=3D"font=
-size:12.8px">At no time do I get the impression that you respect the compa=
tibility issue.</span></div><div><span style=3D"font-size:12.8px"><br></spa=
n></div></div><div dir=3D"ltr"><div><span style=3D"font-size:12.8px">This i=
s a fair observation. c++98 code which has the keyword 'register' o=
r 'auto' in it will no longer compile. Therefore the community, if =
it really is compiling "old and untouched code", must be doing so=
in an old compiler or a compiler set to an old standard.</span></div><div>=
<span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-=
size:12.8px">When we move a library from 1.0 to 2.0, we expect some breakin=
g changes. Lessons have been learned. Concepts move on. What was considered=
correct has been shown to have failed.</span></div><div><span style=3D"fon=
t-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">Depre=
cating and repurposing=C2=A0auto and register is a breaking, "1.0 to 2=
..0" change, without doubt. Old programs will not compile on new compil=
ers without being set to -std=3Dc++98. Good. There is a fallback position a=
nd we can all move on. Everyone's needs are satisfied.</span></div><div=
><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font=
-size:12.8px">So, since the c++ committee have correctly, thoughtfully and =
boldly "disregarded" the compatibility issue before, they can do =
it again. They actually have form from 2011, if not much remaining courage.=
</span></div></div></blockquote></div><div><br></div><div>No one disregarde=
d this. Things have been removed only after thoughtful consideration (which=
is something you are not doing) and, in most cases, a long depreciation pr=
ocess, or after doing *research* that the break is not huge enough to be a =
show stopper. Almost noone used the old meaning of auto; and register was a=
lways a weird, almost unused thing.</div><div><br></div><div>And even then,=
some implementations are adamant that they won't actually remove std::=
auto_ptr in the foreseeable future. The reason for this is simple: the othe=
r features you mentioned being dropped weren't going to cause *massive*=
breakage. Dropping auto_ptr is going to break some code, so some implement=
ations still decided to override the committee's decision.</div><div><b=
r></div><div>But to the point: this discussion is moot because your propose=
d "solution" will not get through EWG. And even if for some weird=
reason it did, it will face great NB opposition.</div><div><br></div><div>=
And the funniest part is that compilers already do what you want them to do=
, pretty much all of it - just enable warnings.</div><div><br></div><div>If=
you come to the committee with a proposal motivated by "I don't w=
ant to enable warnings to get this warning", noone will take you serio=
usly.</div><div><br></div><div class=3D"gmail_quote"><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div><span style=3D"font-size:12.8px"><br></span>=
</div><div><span style=3D"font-size:12.8px">> pushback on recent removal=
s...</span></div><div><span style=3D"font-size:12.8px"><br></span></div><di=
v><span style=3D"font-size:12.8px">It is the nature of human beings that so=
me prefer to look back to comfortable nostalgia, "ah, we used to punch=
cards you know", and some prefer progress - "Cool! Moon-landings=
! Hyperloops! Teslas!"</span></div><div><span style=3D"font-size:12.8p=
x"><br></span></div><div><span style=3D"font-size:12.8px">This biological h=
istory of the planet is unequivocal - you move forward or you die out. For =
this reason, all backward-looking arguments are irrelevant as they will soo=
ner or later be extinguished by inevitability. It is never worth engaging w=
ith chronic nostalgists.</span></div></div></blockquote></div><div><br></di=
v><div>None of this matters, because it's the committee that decides wh=
ere this language goes.=C2=A0</div><div><br></div><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><span style=3D"font-=
size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">>=C2=
=A0</span><span style=3D"font-size:12.8px">Thus far, you have shown no cons=
ideration whatsoever to the costs.</span></div><div><span style=3D"font-siz=
e:12.8px"><br></span></div></div><div dir=3D"ltr"><div><span style=3D"font-=
size:12.8px">I am considering the present-day cost to productivity as being=
more of a drain on humanity than the theoretical cost of annotating tricky=
code. All those register and auto keywords vanished without fuss. Well, th=
ere may have been some fuss, but we got through it without anyone feeling t=
oo hurt.</span></div></div></blockquote></div><div><br></div><div>You can g=
et that productivity already by enabling sufficient warnings in your implem=
entation of choice. There's literally no reason not to do that.</div><d=
iv><br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr"><div><span style=3D"font-size:12.8px"><br></span></div><div><s=
pan style=3D"font-size:12.8px">=C2=A0>=C2=A0</span><span style=3D"font-s=
ize:12.8px">Overall, you've treated the idea of backwards compatibility=
as something beneath consideration.</span></div><div><span style=3D"font-s=
ize:12.8px"><br></span></div></div><div dir=3D"ltr"><div><span style=3D"fon=
t-size:12.8px">Almost. c++17 should always be compatible with c++17, but th=
ere is no reason whatsoever that c++20 needs to be fully compatible with c+=
+17. After all, some c++14 programs will no longer compile in c++17. We'=
;ve been here before. It's easy.</span></div></div><div dir=3D"ltr"><di=
v><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"fon=
t-size:12.8px">>=C2=A0</span><span style=3D"font-size:12.8px">At no time=
do I get the impression that you respect the compatibility issue.</span></=
div><div><span style=3D"font-size:12.8px"><br></span></div></div><div dir=
=3D"ltr"><div><span style=3D"font-size:12.8px">While I respect it, I do not=
regard it as a sacred cow. Neither clearly, did the instigators of c++11 a=
nd c++17</span></div></div></blockquote></div><div><br></div><div>You are m=
istaking long process of research and consideration with your thoughtless d=
ismissal of the idea of compatibility.</div><div><br></div><div class=3D"gm=
ail_quote"></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr"><div><span style=3D"font-size:12.8px"><br></span></div><di=
v><span style=3D"font-size:12.8px">>=C2=A0</span><span style=3D"font-siz=
e:12.8px">First, nobody here is arguing against `unreachable`. Nobody is sa=
ying that it's a bad idea to mark such code. Indeed, I think most of us=
would agree that seeing it used for this purpose would be a very good thin=
g.</span></div><div><span style=3D"font-size:12.8px"><br></span></div></div=
><div dir=3D"ltr"><div><span style=3D"font-size:12.8px">Wonderful - we have=
consensus. Now that we're over arguing for argument's sake, let=
9;s talk positively about how we achieve it. My proposed solution may not b=
e perfect. But I put my head above the parapet. You took your shots and the=
y bounced off my thick skin. Now let's go forward and see about making =
things better. See what I'm doing here? Seeking to move forward to solv=
e something that we both know is broken. There may be a 3-step solution, or=
maybe it can be fixed in one stroke. But it *can* be fixed.</span></div></=
div></blockquote></div><div><br></div><div>This whole paragraph is one base=
d on a fallacious claim that we have "consensus", which is nonsen=
sical. We have consensus that std::unreachable is something that we want, f=
or expressly marking things as unreachable. You've mistaken that for an=
agreement with your outlandish claims that all code where you *could* use =
it should be required to do so, which ks something that pretty much noone e=
lse agrees with you about.</div><div><br></div><div>The code without it is =
not broken, compilers have been warning about having in obviously wrong cas=
es like the ones you're using as an argument for ages - and putting thi=
ngs like ud2 in the codegen on the UB paths. This is old technology. Use wa=
rnings and you'll be good.</div><div><br></div><div>If your theoretical=
language would force me to mark code as unreachable in the mod 3 case, I&#=
39;d... not use your language. Because the compiler can trivially see I'=
;ll never reach that.</div><div><br></div><div>Do you now how else it can s=
ee that? By looking at any path containing UB. Which is why UB is a good th=
ing, and again - it's not like we don't have the technology to tell=
you your code is bad and broken.</div><div><br></div><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><span style=3D"f=
ont-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">>=
;=C2=A0</span><span style=3D"font-size:12.8px">The point being argued is th=
e title of the thread: whether it should be ill-formed to</span><i style=3D=
"font-size:12.8px">=C2=A0not</i><span style=3D"font-size:12.8px">=C2=A0use =
`unreachable`.</span></div><div><span style=3D"font-size:12.8px"><br></span=
></div></div><div dir=3D"ltr"><div><span style=3D"font-size:12.8px">I think=
we all agree that it *should* be, and we understand that there are challen=
ges around making it so, ultimately because of decisions taken in 1973. Let=
's stand on the shoulders of Mr Kernighan and Mr Ritchie, not in their =
shadow,</span></div><div><span style=3D"font-size:12.8px"><br></span></div>=
<div><span style=3D"font-size:12.8px">>=C2=A0</span><span style=3D"font-=
size:12.8px">Consider `switch/case`.</span></div><div><span style=3D"font-s=
ize:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">No, let&=
#39;s not. It'a change of subject.</span></div></div><div dir=3D"ltr"><=
div><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"f=
ont-size:12.8px">>=C2=A0</span><span style=3D"font-size:12.8px">We got t=
he best that we can reasonably expect to get</span></div><div><span style=
=3D"font-size:12.8px"><br></span></div></div><div dir=3D"ltr"><div><span st=
yle=3D"font-size:12.8px">What are you? Some kind of victim? In life, we sto=
p getting what we want when we give up responsibility. Take responsibility.=
Get the good stuff.</span></div></div><div dir=3D"ltr"><div><span style=3D=
"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">&=
gt;=C2=A0</span><span style=3D"font-size:12.8px">So we should do the best w=
e can:</span></div><div><span style=3D"font-size:12.8px"><br></span></div><=
/div><div dir=3D"ltr"><div><span style=3D"font-size:12.8px">Totally agree. =
Repurposing auto and causing register to be an error was "the best we =
can". Let's do that. Now all we have to do is discuss timing and m=
ethod.</span></div></div></blockquote></div><div><br></div><div>I'd say=
something here, but I'd said it multiple times in this mail already...=
</div><div><br></div><div>My final point about it here: if you think compat=
ibility is irrelevant, the C++ standardization process is not for you. Bye.=
</div><div><br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div><span style=3D"font-size:12.8px"><br></span></div=
><div><span style=3D"font-size:12.8px">>=C2=A0</span><span style=3D"font=
-size:12.8px">It's not a perfect solution.</span></div><div><span style=
=3D"font-size:12.8px"><br></span></div></div><div dir=3D"ltr"><div><span st=
yle=3D"font-size:12.8px">Then its not a solution, it's a mitigation. It=
's a step on the road to a solution. Solution means that the problem is=
solved, and will never again have to be considered.</span></div><div><span=
style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:=
12.8px">Myriam:</span></div><div><span style=3D"font-size:12.8px"><br></spa=
n></div><div><span style=3D"font-size:12.8px">I had another think about you=
r first function. I think I have a better, more expressive answer:</span></=
div><div><span style=3D"font-size:12.8px"><br></span></div><div><div style=
=3D"color:rgb(0,0,0);background-color:rgb(255,255,254);font-size:14px;line-=
height:21px;white-space:pre-wrap"><div><span style=3D"color:rgb(0,128,0)"><=
font face=3D"monospace, monospace">// Annotated noreturn. Great. The compil=
er is well aware that there is no return path from</font></span></div><div>=
<span style=3D"color:rgb(0,128,0)"><font face=3D"monospace, monospace">// c=
alling this "function". In fact, it's not a function is it? I=
t's a sequence of code that terminates the process.</font></span></div>=
<div><span style=3D"color:rgb(0,128,0)"><font face=3D"monospace, monospace"=
>// there's no need to even generate a "ret" instruction or e=
quivalent at the end of it.</font></span></div><div><span style=3D"color:rg=
b(128,128,128)"><font face=3D"monospace, monospace">[[noreturn]]</font></sp=
an></div><div><font face=3D"monospace, monospace"><span style=3D"color:rgb(=
0,0,255)">void</span> nuke()</font></div></div></div></div><div dir=3D"ltr"=
><div><div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,254);font=
-size:14px;line-height:21px;white-space:pre-wrap"><div><font face=3D"monosp=
ace, monospace">{</font></div><div><font face=3D"monospace, monospace"> =
#ifdef _WIN32</font></div><div><font face=3D"monospace, monospace"> =
TerminateProcess(GetCurrentProcess(), <span style=3D"color:rgb(9,136,90)">1=
</span>);</font></div><div><font face=3D"monospace, monospace"> #<span s=
tyle=3D"color:rgb(0,0,255)">else</span></font></div><div><font face=3D"mono=
space, monospace"> kill(getpid(), SIGKILL);</font></div><div><font f=
ace=3D"monospace, monospace"> #endif</font></div><div><font face=3D"mono=
space, monospace">}</font></div><font face=3D"monospace, monospace"><br></f=
ont><div><font face=3D"monospace, monospace"><span style=3D"color:rgb(0,0,2=
55)">int</span> function(<span style=3D"color:rgb(0,0,255)">int</span> x)</=
font></div><div><font face=3D"monospace, monospace">{</font></div><div><fon=
t face=3D"monospace, monospace"> <span style=3D"color:rgb(0,0,255)">if</=
span> (x < <span style=3D"color:rgb(9,136,90)">0</span>)</font></div><di=
v><font face=3D"monospace, monospace"> {</font></div></div></div></div><=
div dir=3D"ltr"><div><div style=3D"color:rgb(0,0,0);background-color:rgb(25=
5,255,254);font-size:14px;line-height:21px;white-space:pre-wrap"><div><font=
face=3D"monospace, monospace"> nuke(); </font><span style=3D"color:=
rgb(0,128,0);font-family:monospace,monospace">// the compiler implicitly kn=
ows that this cannot return. it can emit "jmp _nuke(void)" rather=
than "call _nuke(void)"</span></div></div></div></div><div dir=
=3D"ltr"><div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,254);f=
ont-size:14px;line-height:21px;white-space:pre-wrap"><div><font face=3D"mon=
ospace, monospace"> }</font></div><div><font face=3D"monospace, monospac=
e"> <span style=3D"color:rgb(0,0,255)">else</span></font></div><div><fon=
t face=3D"monospace, monospace"> {</font></div><div><font face=3D"monosp=
ace, monospace"> <span style=3D"color:rgb(0,0,255)">return</span> x =
* <span style=3D"color:rgb(9,136,90)">2</span>;</font></div><div><font face=
=3D"monospace, monospace"> }</font></div></div></div></blockquote></div>=
<div><br></div><div>This is very bad, because in reality this original func=
tion would've been longer and this destroys readability. 0/10 would not=
pass my code review.</div><div><br></div><div class=3D"gmail_quote"></div>=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,254);font-size:=
14px;line-height:21px;white-space:pre-wrap"><div><br></div><br></div></div>=
<div dir=3D"ltr"><div><div style=3D"color:rgb(0,0,0);background-color:rgb(2=
55,255,254);font-size:14px;line-height:21px;white-space:pre-wrap"></div></d=
iv><div><span style=3D"font-size:12.8px">Now, the solution above does of co=
urse rely on the compiler actually heeding the [[noreturn]] attribute. I do=
n't think it's unreasonable to mandate that in the next standard, t=
his attribute should be a mandatory part of the language and have the power=
of a keyword. I am not saying that the compiler should insert code to chec=
k at runtime that it's not lying. Having said that, there would be no h=
arm in it doing so. A [[noreturn]] "function" is by definition, n=
ot going to be called in a loop. It's going to be called *at most once*=
per program run.</span></div><div><span style=3D"font-size:12.8px"><br></s=
pan></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">O=
n 21 December 2017 at 07:14, Nicol Bolas <span dir=3D"ltr"><<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span>On Wed=
nesday, December 20, 2017 at 3:37:53 PM UTC-5, Richard Hodges wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>>=C2=A0<span styl=
e=3D"font-size:12.8px">Can we just get over this entire thread by calling D=
unning-Kruger and moving on?</span></div><div><span style=3D"font-size:12.8=
px"><br></span></div><div><span style=3D"font-size:12.8px">No, because that=
is intellectually lazy, solves nothing, and merely guarantees that the cur=
rent unsatisfactory state of affairs will be challenged again, and again, a=
nd again.</span></div></div></blockquote><div><br></div></span><div>And the=
y'll fail again and again and again. Because at the end of the day, the=
fundamental problem will still remain:<i> it's a breaking change</i>.<=
/div><div><br></div><div>That is not a step to be taken lightly. And certai=
nly not for ideological reasons.</div><span><div><i><br></i></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>>=C2=A0<span style=
=3D"font-size:12.8px">but C++ is a language built on the fundament of being=
compatible with code that already exists, as-is</span></div><div><span sty=
le=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8=
px">Not correct. things get deprecated, and then removed.</span></div><div>=
<span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-=
size:12.8px">e.g. register keyword, auto_ptr, current_exception. This is no=
t a valid argument.</span></div></div></blockquote><div><br></div></span><d=
iv>And each one of those removals took place only after careful considerati=
on of the costs. The committee looked hard at how often `register` and `aut=
o` were used in real code. `current_exception` was flat out <i>broken</i>; =
it simply could not do what it was intended to do, and reliance upon it wou=
ld only end in tears. And `auto_ptr` by its very nature creates confusion.<=
/div><div><br></div><div>And despite such careful consideration, there is e=
ven <a href=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2017/p084=
5r0.html" target=3D"_blank">some pushback on recent removals of things that=
are clear duplicates of much better stuff</a>. All based on the fact that =
some code just doesn't get updated, but we still need to be able to use=
it.</div><div><br></div><div>Thus far, you have shown no consideration wha=
tsoever to the costs. You have repeatedly and categorically <i>dismissing</=
i> any question of how much code would be broken by the change you desire. =
You have routinely mocked such arguments, suggesting that repairing such co=
de is simply a matter of "<a href=3D"https://groups.google.com/a/isocp=
p.org/d/msg/std-proposals/Uu2QViiWh4k/bNBBTqNoAgAJ" target=3D"_blank">askin=
g an intern to do it</a>" or whatever. Your "solution" to th=
e header-only library issue is to <a href=3D"https://groups.google.com/a/is=
ocpp.org/d/msg/std-proposals/Uu2QViiWh4k/cemDmZZmAgAJ" target=3D"_blank">cr=
eate some `extern "UBAllowed"` wrapper</a>.</div><div><br></div><=
div>Overall, you've treated the idea of backwards compatibility as some=
thing beneath consideration. I don't agree with bringing back the `std:=
:`binders, but I at least<i> respect</i> the argument for doing so.</div><d=
iv><br></div><div>At no time do I get the impression that you respect the c=
ompatibility issue.<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<i></i></blockquote></div><span>
<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@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/e9b43a8c-ad41-451d-b310-4b33f19bccd1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e9b43a8c-ad41-=
451d-b310-4b33f19bccd1%40isocpp.org</a>.<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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hYYp9m48iHM6%3DtWHtWwwKSjEnVvrg=
6bRQ-V3VhKOBGyAA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CALvx3hYYp9m48iHM6%3DtWHtWwwKSjEnVvrg6bRQ-V3VhKOBGyAA%40mail.gmail.c=
om</a>.<br>
</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/CAPCFJdRKxFJSDFUGYi1soxyVhEo7voTs3HeY=
9rV%2B%2BP_zG2k5tQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdRKxFJS=
DFUGYi1soxyVhEo7voTs3HeY9rV%2B%2BP_zG2k5tQ%40mail.gmail.com</a>.<br />
--001a1146692af002730560d56c1d--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Thu, 21 Dec 2017 10:55:35 +0100
Raw View
--f4030436096e9b14430560d6b35a
Content-Type: text/plain; charset="UTF-8"
On Wed, Dec 20, 2017 at 7:41 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> So perhaps we have a different idea of what "depending on UB" means. UB
only happens when you encounter it* at runtime*. It is not a compile-time
concept; it is runtime behavior.
That is not true in general, because the standard does not define UB as a
runtime concept, and not true in this particular case, because, for
example, MSVC, when given int foo() {}, produces a hard error.
Cheers,
V.
--
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/CAA7YVg087TchKJdacOr5TrWMqLpuq%2BabPtmCCrs7PUjQkC%2BH6Q%40mail.gmail.com.
--f4030436096e9b14430560d6b35a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Dec 20, 2017 at 7:41 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></s=
pan> wrote:<br><div><br></div><div>> So perhaps we have a different idea=
of what "depending on UB" means. UB only happens when you encoun=
ter it<i> at runtime</i>. It is not a compile-time concept; it is runtime b=
ehavior.</div><div><br></div><div>That is not true in general, because the =
standard does not define UB as a runtime concept, and not true in this part=
icular case, because, for example, MSVC, when given int foo() {}, produces =
a hard error.</div><div><br></div><div>Cheers,<br></div><div>V.</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/CAA7YVg087TchKJdacOr5TrWMqLpuq%2BabPt=
mCCrs7PUjQkC%2BH6Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg087Tch=
KJdacOr5TrWMqLpuq%2BabPtmCCrs7PUjQkC%2BH6Q%40mail.gmail.com</a>.<br />
--f4030436096e9b14430560d6b35a--
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Thu, 21 Dec 2017 10:19:09 +0000
Raw View
--001a1135253ae853660560d70778
Content-Type: text/plain; charset="UTF-8"
On 21 Dec 2017 02:55, "Myriachan" <myriachan@gmail.com> wrote:
I'm kind of confused at this point. Wouldn't a compiler inserting
std::unreachable automatically like that be equivalent to the status quo?
The effect of std::unreachable is undefined behavior.Having
std::unreachable() there is equivalent to the current way things are done
if you don't have a return at all.
Hmm, no that wasn't my intended result of using some std::unreachable. My
intended use is to throw a runtime error (whilst also claiming to return
the correct type, hence the template, so that in every function that uses
this properly there is *always* a returning path, even if the use of
std::unreachable terminates the program), not to welcome undefined
behaviour by eliminating that branch - that would make more sense as an
[[unreachable]] attribute, as a guide to the compiler. I'm thinking of a
standardised approach to escape UB.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCO5GFc7JK_Mfs60KbY18GuSANeiNrp%2B-kjTpigpkJ7wyA%40mail.gmail.com.
--001a1135253ae853660560d70778
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div class=3D"gmail_extra" dir=3D"auto"><div class=3D"gma=
il_quote">On 21 Dec 2017 02:55, "Myriachan" <<a href=3D"mailto=
:myriachan@gmail.com">myriachan@gmail.com</a>> wrote:<br type=3D"attribu=
tion"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"quoted-text">=
I'm kind of confused at this point.=C2=A0 Wouldn't a compiler inser=
ting std::unreachable automatically like that be equivalent to the status q=
uo?=C2=A0 The effect of std::unreachable is undefined behavior.Having std::=
unreachable() there is equivalent to the current way things are done if you=
don't have a return at all.</div></div></blockquote></div></div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">Hmm, no that wasn't my intended=
result of using some std::unreachable. My intended use is to throw a runti=
me error (whilst also claiming to return the correct type, hence the templa=
te, so that in every function that uses this properly there is <i>always</i=
> a returning path, even if the use of std::unreachable terminates the prog=
ram), not to welcome undefined behaviour by eliminating that branch - that =
would make more sense as an [[unreachable]] attribute, as a guide to the co=
mpiler. I'm thinking of a standardised approach to escape UB.</div><div=
class=3D"gmail_extra" dir=3D"auto"></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCO5GFc7JK_Mfs60KbY18GuSANeiNr=
p%2B-kjTpigpkJ7wyA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCO5GF=
c7JK_Mfs60KbY18GuSANeiNrp%2B-kjTpigpkJ7wyA%40mail.gmail.com</a>.<br />
--001a1135253ae853660560d70778--
.
Author: j c <james.a.cooper@gmail.com>
Date: Thu, 21 Dec 2017 10:42:31 +0000
Raw View
--089e082300d47129980560d75b9c
Content-Type: text/plain; charset="UTF-8"
This makes total sense to me, it's similar to how a program is terminated
if a function marked as noexcept actually throws.
I don't see how it would break code that has an impossible-to-take path
that doesn't return a value.
In code where the missing return path is taken you're already broken. Are
compiler writers under any obligation to generate the same code for UB
scenarios between versions? If 'anything can happen'/'all bets are off' for
UB scenarios then surely making that behaviour defined is allowed?
On Thursday, December 21, 2017, Jake Arkinstall <jake.arkinstall@gmail.com>
wrote:
> On 21 Dec 2017 02:55, "Myriachan" <myriachan@gmail.com> wrote:
>
> I'm kind of confused at this point. Wouldn't a compiler inserting
> std::unreachable automatically like that be equivalent to the status quo?
> The effect of std::unreachable is undefined behavior.Having
> std::unreachable() there is equivalent to the current way things are done
> if you don't have a return at all.
>
>
> Hmm, no that wasn't my intended result of using some std::unreachable. My
> intended use is to throw a runtime error (whilst also claiming to return
> the correct type, hence the template, so that in every function that uses
> this properly there is *always* a returning path, even if the use of
> std::unreachable terminates the program), not to welcome undefined
> behaviour by eliminating that branch - that would make more sense as an
> [[unreachable]] attribute, as a guide to the compiler. I'm thinking of a
> standardised approach to escape UB.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAC%2B0CCO5GFc7JK_
> Mfs60KbY18GuSANeiNrp%2B-kjTpigpkJ7wyA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCO5GFc7JK_Mfs60KbY18GuSANeiNrp%2B-kjTpigpkJ7wyA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAFQaeCDUFzRw%3Dh4bWMaG%3DfnhH14aWU3HNpsDkSB5SwXmd9J-DA%40mail.gmail.com.
--089e082300d47129980560d75b9c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
This makes total sense to me, it's similar to how a program is terminat=
ed if a function marked as noexcept actually throws.<div>I don't see ho=
w it would break code that has an impossible-to-take path that doesn't =
return a value.</div><div>In code where the missing return=C2=A0path is tak=
en you're already broken. Are compiler writers under any obligation to =
generate the same code for UB scenarios between versions? If 'anything =
can happen'/'all bets are off' for UB scenarios then surely mak=
ing that behaviour defined is allowed?<br><br>On Thursday, December 21, 201=
7, Jake Arkinstall <<a href=3D"mailto:jake.arkinstall@gmail.com">jake.ar=
kinstall@gmail.com</a>> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"auto"><div class=3D"gmail_extra" dir=3D"auto"><div class=3D"gmail_quot=
e">On 21 Dec 2017 02:55, "Myriachan" <<a href=3D"mailto:myriac=
han@gmail.com" target=3D"_blank">myriachan@gmail.com</a>> wrote:<br type=
=3D"attribution"><blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><div>I'm kind of confused at=
this point.=C2=A0 Wouldn't a compiler inserting std::unreachable autom=
atically like that be equivalent to the status quo?=C2=A0 The effect of std=
::unreachable is undefined behavior.Having std::unreachable() there is equi=
valent to the current way things are done if you don't have a return at=
all.</div></div></blockquote></div></div><div dir=3D"auto"><br></div><div =
dir=3D"auto">Hmm, no that wasn't my intended result of using some std::=
unreachable. My intended use is to throw a runtime error (whilst also claim=
ing to return the correct type, hence the template, so that in every functi=
on that uses this properly there is <i>always</i> a returning path, even if=
the use of std::unreachable terminates the program), not to welcome undefi=
ned behaviour by eliminating that branch - that would make more sense as an=
[[unreachable]] attribute, as a guide to the compiler. I'm thinking of=
a standardised approach to escape UB.</div><div class=3D"gmail_extra" dir=
=3D"auto"></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCO5GFc7JK_Mfs60KbY18GuSANeiNr=
p%2B-kjTpigpkJ7wyA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/=
std-<wbr>proposals/CAC%2B0CCO5GFc7JK_<wbr>Mfs60KbY18GuSANeiNrp%2B-<wbr>kjTp=
igpkJ7wyA%40mail.gmail.com</a><wbr>.<br>
</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/CAFQaeCDUFzRw%3Dh4bWMaG%3DfnhH14aWU3H=
NpsDkSB5SwXmd9J-DA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFQaeCDUFzRw=
%3Dh4bWMaG%3DfnhH14aWU3HNpsDkSB5SwXmd9J-DA%40mail.gmail.com</a>.<br />
--089e082300d47129980560d75b9c--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Thu, 21 Dec 2017 11:43:16 +0100
Raw View
--001a113f259827c6fe0560d75e05
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Thu, Dec 21, 2017 at 9:24 AM, Micha=C5=82 Dominiak <griwes@griwes.info> =
wrote:
> No one disregarded this. Things have been removed only after thoughtful
consideration (which is something you are not doing) and, in most cases, a
long depreciation process, or after doing *research* that the break is not
huge enough to be a show stopper. Almost noone used the old meaning of
auto; and register was always a weird, almost unused thing.
In my book of the back-stabbingest incompatible changes ever made, the
implicit noexcept for destructors holds one of the top lines. In my
opinion, incompatible changes that can only make legacy code fail to
compile are much, much, much less of an issue than changes that change the
runtime behaviour, fatally, in rare situations. Unless I misunderstand
something, Richard's proposing a compilation-breaking change rather than a
runtime-breaking change. You might be right that he may need to argue more
thoughtfully for his cause, but it is not right to state flat out "this
will never happen", because worse things have actually happened.
Cheers,
V.
--=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/CAA7YVg1ddzYYmDEOPwKFwtsCVH0CCH%3DaRHLaUVcei6d5G=
bab0g%40mail.gmail.com.
--001a113f259827c6fe0560d75e05
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Dec 21, 2017 at 9:24 AM, Micha=C5=82 Dominiak <span dir=3D"ltr"><<a =
href=3D"mailto:griwes@griwes.info" target=3D"_blank">griwes@griwes.info</a>=
></span> wrote:<br><div><br></div><div>> No one disregarded this. Thi=
ngs have been removed only after thoughtful consideration (which is somethi=
ng you are not doing) and, in most cases, a long depreciation process, or a=
fter doing *research* that the break is not huge enough to be a show stoppe=
r. Almost noone used the old meaning of auto; and register was always a wei=
rd, almost unused thing.</div><div><br></div><div><div><span style=3D"font-=
size:12.8px">In my book of the back-stabbingest incompatible changes ever m=
ade, the implicit noexcept for destructors holds one of the top lines. In m=
y opinion, incompatible changes that can only make legacy code fail to comp=
ile are much, much, much less of an issue than changes that change the runt=
ime behaviour, fatally, in rare situations. Unless I misunderstand somethin=
g, Richard's proposing a compilation-breaking change rather than a runt=
ime-breaking change. You might be right that he may need to argue more thou=
ghtfully for his cause, but it is not right to state flat out "this wi=
ll never happen", because worse things have actually happened.</span><=
/div></div><div><br></div><div>Cheers,</div><div>V.</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/CAA7YVg1ddzYYmDEOPwKFwtsCVH0CCH%3DaRH=
LaUVcei6d5Gbab0g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1ddzYYmD=
EOPwKFwtsCVH0CCH%3DaRHLaUVcei6d5Gbab0g%40mail.gmail.com</a>.<br />
--001a113f259827c6fe0560d75e05--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Thu, 21 Dec 2017 10:58:59 +0000
Raw View
--001a11417bc25158bd0560d79658
Content-Type: text/plain; charset="UTF-8"
On Thu, Dec 21, 2017 at 9:55 AM, Viacheslav Usov <via.usov@gmail.com> wrote:
> On Wed, Dec 20, 2017 at 7:41 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> > So perhaps we have a different idea of what "depending on UB" means. UB
> only happens when you encounter it* at runtime*. It is not a compile-time
> concept; it is runtime behavior.
>
> That is not true in general, because the standard does not define UB as a
> runtime concept,
>
An implementation is permitted to diagnose certain kinds of UB (typically
"ill-formed NDR") at translation time; it is however not required to (hence
NDR) and so the runtime behavior of such a program is undefined. In all
cases of UB dependent on a runtime condition, the program is required to be
translated and it is the runtime behavior that is undefined.
> and not true in this particular case, because, for example, MSVC, when
> given int foo() {}, produces a hard error.
>
That's non-conformant. There is no latitude for an implementation to
terminate translation of that function.
> Cheers,
> V.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/is
> ocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
> To unsubscribe from this group and all its topics, 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/is
> ocpp.org/d/msgid/std-proposals/CAA7YVg087TchKJdacOr5TrWMqLpu
> q%2BabPtmCCrs7PUjQkC%2BH6Q%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg087TchKJdacOr5TrWMqLpuq%2BabPtmCCrs7PUjQkC%2BH6Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAJnLdOYYY6HY%3DMs3U4nBh88pvxf8jgh0O_Wtjnkz_3-rCeTZtQ%40mail.gmail.com.
--001a11417bc25158bd0560d79658
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Dec 21, 2017 at 9:55 AM, Viacheslav Usov <span dir=3D"ltr"><=
<a href=3D"mailto:via.usov@gmail.com" target=3D"_blank">via.usov@gmail.com<=
/a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv class=3D"gmail_extra"><div class=3D"gmail_quote">On Wed, Dec 20, 2017 at=
7:41 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gma=
il.com" target=3D"_blank">jmckesson@gmail.com</a>></span> wrote:<br><div=
><br></div><div>> So perhaps we have a different idea of what "depe=
nding on UB" means. UB only happens when you encounter it<i> at runtim=
e</i>. It is not a compile-time concept; it is runtime behavior.</div><div>=
<br></div><div>That is not true in general, because the standard does not d=
efine UB as a runtime concept,</div></div></div></div></blockquote><div><br=
></div><div>An implementation is permitted to diagnose certain kinds of UB =
(typically "ill-formed NDR") at translation time; it is however n=
ot required to (hence NDR) and so the runtime behavior of such a program is=
undefined. In all cases of UB dependent on a runtime condition, the progra=
m is required to be translated and it is the runtime behavior that is undef=
ined.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div> and not true i=
n this particular case, because, for example, MSVC, when given int foo() {}=
, produces a hard error.</div></div></div></div></blockquote><div><br></div=
><div>That's non-conformant. There is no latitude for an implementation=
to terminate translation of that function.</div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote"><div></div><div>Cheers,<br></div><div>V.</div><div><br></=
div></div></div></div><span>
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/is<wbr>ocpp.org/d/topic/std-proposals<wbr>/U=
u2QViiWh4k/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isoc<wbr>pp.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/CAA7YVg087TchKJdacOr5TrWMqLpuq%2BabPt=
mCCrs7PUjQkC%2BH6Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/=
std-proposals<wbr>/CAA7YVg087TchKJdacOr5TrWMqLpu<wbr>q%2BabPtmCCrs7PUjQkC%2=
BH6Q%40m<wbr>ail.gmail.com</a>.<br>
</blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAJnLdOYYY6HY%3DMs3U4nBh88pvxf8jgh0O_=
Wtjnkz_3-rCeTZtQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYYY6HY%3=
DMs3U4nBh88pvxf8jgh0O_Wtjnkz_3-rCeTZtQ%40mail.gmail.com</a>.<br />
--001a11417bc25158bd0560d79658--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Thu, 21 Dec 2017 11:13:22 +0000
Raw View
--001a11417bc2c82e800560d7c9ec
Content-Type: text/plain; charset="UTF-8"
On Thu, Dec 21, 2017 at 10:19 AM, Jake Arkinstall <jake.arkinstall@gmail.com
> wrote:
> On 21 Dec 2017 02:55, "Myriachan" <myriachan@gmail.com> wrote:
>
> I'm kind of confused at this point. Wouldn't a compiler inserting
> std::unreachable automatically like that be equivalent to the status quo?
> The effect of std::unreachable is undefined behavior.Having
> std::unreachable() there is equivalent to the current way things are done
> if you don't have a return at all.
>
>
> Hmm, no that wasn't my intended result of using some std::unreachable. My
> intended use is to throw a runtime error (whilst also claiming to return
> the correct type, hence the template, so that in every function that uses
> this properly there is *always* a returning path, even if the use of
> std::unreachable terminates the program), not to welcome undefined
> behaviour by eliminating that branch - that would make more sense as an
> [[unreachable]] attribute, as a guide to the compiler. I'm thinking of a
> standardised approach to escape UB.
>
That would not be acceptable in a high-performance or no-exceptions
environment. In the former, a call to std::unreachable must be
negative-overhead; it must result in zero output code. In the latter, for
std::unreachable to call std::terminate might be acceptable - but in that
case one might as well call std::terminate directly, since it is noreturn
noexcept. If you want to throw an exception, just throw logic_error
directly.
Clearly it should be permissible for the implementation to throw an
exception or terminate the program if a call to std::unreachable is
encountered. But this must not be mandated.
--
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/CAJnLdObQp01eKXzkPTg2PDH_VKwLxTRmzwd0wNsw-3Ms%2BUp9Kg%40mail.gmail.com.
--001a11417bc2c82e800560d7c9ec
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Dec 21, 2017 at 10:19 AM, Jake Arkinstall <span dir=3D"ltr"><=
;<a href=3D"mailto:jake.arkinstall@gmail.com" target=3D"_blank">jake.arkins=
tall@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"auto"><div class=3D"gmail_extra" dir=3D"auto"><div class=3D"gmail_q=
uote">On 21 Dec 2017 02:55, "Myriachan" <<a href=3D"mailto:myr=
iachan@gmail.com" target=3D"_blank">myriachan@gmail.com</a>> wrote:<br t=
ype=3D"attribution"><blockquote class=3D"m_-7500113243957293740quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"m_-7500113243957293740quoted-text">I'm kind of c=
onfused at this point.=C2=A0 Wouldn't a compiler inserting std::unreach=
able automatically like that be equivalent to the status quo?=C2=A0 The eff=
ect of std::unreachable is undefined behavior.Having std::unreachable() the=
re is equivalent to the current way things are done if you don't have a=
return at all.</div></div></blockquote></div></div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">Hmm, no that wasn't my intended result of using =
some std::unreachable. My intended use is to throw a runtime error (whilst =
also claiming to return the correct type, hence the template, so that in ev=
ery function that uses this properly there is <i>always</i> a returning pat=
h, even if the use of std::unreachable terminates the program), not to welc=
ome undefined behaviour by eliminating that branch - that would make more s=
ense as an [[unreachable]] attribute, as a guide to the compiler. I'm t=
hinking of a standardised approach to escape UB.</div></div></blockquote><d=
iv><br></div><div>That would not be acceptable in a high-performance or no-=
exceptions environment. In the former, a call to std::unreachable must be n=
egative-overhead; it must result in zero output code. In the latter, for st=
d::unreachable to call std::terminate might be acceptable - but in that cas=
e one might as well call std::terminate directly, since it is noreturn noex=
cept. If you want to throw an exception, just throw logic_error directly.</=
div><div><br></div><div>Clearly it should be permissible for the implementa=
tion to throw an exception or terminate the program if a call to std::unrea=
chable is encountered. But this must not be mandated.</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/CAJnLdObQp01eKXzkPTg2PDH_VKwLxTRmzwd0=
wNsw-3Ms%2BUp9Kg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObQp01eKX=
zkPTg2PDH_VKwLxTRmzwd0wNsw-3Ms%2BUp9Kg%40mail.gmail.com</a>.<br />
--001a11417bc2c82e800560d7c9ec--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Thu, 21 Dec 2017 12:18:35 +0100
Raw View
--f403045c48667602310560d7dcd5
Content-Type: text/plain; charset="UTF-8"
>> and not true in this particular case, because, for example, MSVC, when
given int foo() {}, produces a hard error.
> That's non-conformant. There is no latitude for an implementation to
terminate translation of that function.
Conformant or not, it rather gives the lie to the claim that there is a
"massive body of code" that would suddenly fail to compile if
non-compilation became mandated in such a circumstance.
We all write our code to be as portable as possible, don't we?
Clearly, the only code that would need to be revisited would be
platform-specific code that was taking advantage of (flaunting?) UB
techniques.
Code that's doing that really ought to be annotated as such.
On 21 December 2017 at 11:58, 'Edward Catmur' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:
>
>
> On Thu, Dec 21, 2017 at 9:55 AM, Viacheslav Usov <via.usov@gmail.com>
> wrote:
>
>> On Wed, Dec 20, 2017 at 7:41 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>>
>> > So perhaps we have a different idea of what "depending on UB" means. UB
>> only happens when you encounter it* at runtime*. It is not a
>> compile-time concept; it is runtime behavior.
>>
>> That is not true in general, because the standard does not define UB as a
>> runtime concept,
>>
>
> An implementation is permitted to diagnose certain kinds of UB (typically
> "ill-formed NDR") at translation time; it is however not required to (hence
> NDR) and so the runtime behavior of such a program is undefined. In all
> cases of UB dependent on a runtime condition, the program is required to be
> translated and it is the runtime behavior that is undefined.
>
>
>> and not true in this particular case, because, for example, MSVC, when
>> given int foo() {}, produces a hard error.
>>
>
> That's non-conformant. There is no latitude for an implementation to
> terminate translation of that function.
>
>
>> Cheers,
>> V.
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit https://groups.google.com/a/is
>> ocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/is
>> ocpp.org/d/msgid/std-proposals/CAA7YVg087TchKJdacOr5TrWMqLpu
>> q%2BabPtmCCrs7PUjQkC%2BH6Q%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg087TchKJdacOr5TrWMqLpuq%2BabPtmCCrs7PUjQkC%2BH6Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
> --
> 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/CAJnLdOYYY6HY%
> 3DMs3U4nBh88pvxf8jgh0O_Wtjnkz_3-rCeTZtQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYYY6HY%3DMs3U4nBh88pvxf8jgh0O_Wtjnkz_3-rCeTZtQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CALvx3hYt%2Bzxa%2Ba-uGPc5ZtBNVLfVRG2vPd%3DV-bQV55_%2BoDoJ%2Bw%40mail.gmail.com.
--f403045c48667602310560d7dcd5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div>>> <span class=3D"gmail-im">and =
not true in this particular case, because, for example, MSVC, when given in=
t foo() {}, produces a hard error.<br><br>> </span>That's non-confor=
mant. There is no latitude for an implementation to terminate translation o=
f that function.<br><br></div>Conformant or not, it rather gives the lie to=
the claim that there is a "massive body of code" that would sudd=
enly fail to compile if non-compilation became mandated in such a circumsta=
nce.<br><br></div>We all write our code to be as portable as possible, don&=
#39;t we?<br><br></div>Clearly, the only code that would need to be revisit=
ed would be platform-specific code that was taking advantage of (flaunting?=
) UB techniques.<br><br></div>Code that's doing that really ought to be=
annotated as such.<br><br><div><br><div><div><div><span class=3D"gmail-im"=
></span></div></div></div></div></div><div class=3D"gmail_extra"><br><div c=
lass=3D"gmail_quote">On 21 December 2017 at 11:58, 'Edward Catmur' =
via ISO C++ Standard - Future Proposals <span dir=3D"ltr"><<a href=3D"ma=
ilto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</=
a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br=
><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span class=3D""=
>On Thu, Dec 21, 2017 at 9:55 AM, Viacheslav Usov <span dir=3D"ltr"><<a =
href=3D"mailto:via.usov@gmail.com" target=3D"_blank">via.usov@gmail.com</a>=
></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote">On Wed, Dec 20, 2017 at 7:=
41 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.=
com" target=3D"_blank">jmckesson@gmail.com</a>></span> wrote:<br><div><b=
r></div><div>> So perhaps we have a different idea of what "dependi=
ng on UB" means. UB only happens when you encounter it<i> at runtime</=
i>. It is not a compile-time concept; it is runtime behavior.</div><div><br=
></div><div>That is not true in general, because the standard does not defi=
ne UB as a runtime concept,</div></div></div></div></blockquote><div><br></=
div></span><div>An implementation is permitted to diagnose certain kinds of=
UB (typically "ill-formed NDR") at translation time; it is howev=
er not required to (hence NDR) and so the runtime behavior of such a progra=
m is undefined. In all cases of UB dependent on a runtime condition, the pr=
ogram is required to be translated and it is the runtime behavior that is u=
ndefined.</div><span class=3D""><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><div> and not true in this particular case, because, for example, MSVC, wh=
en given int foo() {}, produces a hard error.</div></div></div></div></bloc=
kquote><div><br></div></span><div>That's non-conformant. There is no la=
titude for an implementation to terminate translation of that function.</di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><div></div><div>Cheers,<br></=
div><div>V.</div><div><br></div></div></div></div><span>
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/is<wbr>ocpp.org/d/topic/std-proposals<wbr>/U=
u2QViiWh4k/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isoc<wbr>pp.org</a>.<span class=3D""><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></span><spa=
n 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/CAA7YVg087TchKJdacOr5TrWMqLpuq%2BabPt=
mCCrs7PUjQkC%2BH6Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/=
std-proposals<wbr>/CAA7YVg087TchKJdacOr5TrWMqLpu<wbr>q%2BabPtmCCrs7PUjQkC%2=
BH6Q%40m<wbr>ail.gmail.com</a>.<br>
</span></blockquote></div><br></div></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/CAJnLdOYYY6HY%3DMs3U4nBh88pvxf8jgh0O_=
Wtjnkz_3-rCeTZtQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/CAJnLdOYYY6HY%<wbr>3DMs3U4nBh88pvxf8jgh0O_Wtjnkz_<wbr>3-rC=
eTZtQ%40mail.gmail.com</a>.<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/CALvx3hYt%2Bzxa%2Ba-uGPc5ZtBNVLfVRG2v=
Pd%3DV-bQV55_%2BoDoJ%2Bw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3h=
Yt%2Bzxa%2Ba-uGPc5ZtBNVLfVRG2vPd%3DV-bQV55_%2BoDoJ%2Bw%40mail.gmail.com</a>=
..<br />
--f403045c48667602310560d7dcd5--
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Thu, 21 Dec 2017 12:00:38 +0000
Raw View
--f403045e5b8465fdb60560d8734e
Content-Type: text/plain; charset="UTF-8"
On Thu, Dec 21, 2017 at 12:18 PM Richard Hodges <hodges.r@gmail.com> wrote:
> >> and not true in this particular case, because, for example, MSVC, when
> given int foo() {}, produces a hard error.
>
> > That's non-conformant. There is no latitude for an implementation to
> terminate translation of that function.
>
> Conformant or not, it rather gives the lie to the claim that there is a
> "massive body of code" that would suddenly fail to compile if
> non-compilation became mandated in such a circumstance.
>
> We all write our code to be as portable as possible, don't we?
>
No.
We have projects that are specifically *not* targeted at Windows, because
their environment is, very explicitly, Linux.
Please stop making fallacious arguments. If anything, it is MSVC which
should stop breaking compatibility there - at least by default.
>
> Clearly, the only code that would need to be revisited would be
> platform-specific code that was taking advantage of (flaunting?) UB
> techniques.
>
Nonsense again, it's not UB until you've actually executed the invalid code
path, in this case.
>
> Code that's doing that really ought to be annotated as such.
>
>
>
> On 21 December 2017 at 11:58, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>>
>>
>> On Thu, Dec 21, 2017 at 9:55 AM, Viacheslav Usov <via.usov@gmail.com>
>> wrote:
>>
>>> On Wed, Dec 20, 2017 at 7:41 PM, Nicol Bolas <jmckesson@gmail.com>
>>> wrote:
>>>
>>> > So perhaps we have a different idea of what "depending on UB" means.
>>> UB only happens when you encounter it* at runtime*. It is not a
>>> compile-time concept; it is runtime behavior.
>>>
>>> That is not true in general, because the standard does not define UB as
>>> a runtime concept,
>>>
>>
>> An implementation is permitted to diagnose certain kinds of UB (typically
>> "ill-formed NDR") at translation time; it is however not required to (hence
>> NDR) and so the runtime behavior of such a program is undefined. In all
>> cases of UB dependent on a runtime condition, the program is required to be
>> translated and it is the runtime behavior that is undefined.
>>
>>
>>> and not true in this particular case, because, for example, MSVC, when
>>> given int foo() {}, produces a hard error.
>>>
>>
>> That's non-conformant. There is no latitude for an implementation to
>> terminate translation of that function.
>>
>>
>>> Cheers,
>>> V.
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, 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/CAA7YVg087TchKJdacOr5TrWMqLpuq%2BabPtmCCrs7PUjQkC%2BH6Q%40mail.gmail.com
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg087TchKJdacOr5TrWMqLpuq%2BabPtmCCrs7PUjQkC%2BH6Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>> --
>> 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/CAJnLdOYYY6HY%3DMs3U4nBh88pvxf8jgh0O_Wtjnkz_3-rCeTZtQ%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYYY6HY%3DMs3U4nBh88pvxf8jgh0O_Wtjnkz_3-rCeTZtQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
> --
> 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/CALvx3hYt%2Bzxa%2Ba-uGPc5ZtBNVLfVRG2vPd%3DV-bQV55_%2BoDoJ%2Bw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hYt%2Bzxa%2Ba-uGPc5ZtBNVLfVRG2vPd%3DV-bQV55_%2BoDoJ%2Bw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAPCFJdTvQfpL5exQ%2BDVKUZZhSkdocXT-wtCWn-ZTT4k4E94VQA%40mail.gmail.com.
--f403045e5b8465fdb60560d8734e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu=
, Dec 21, 2017 at 12:18 PM Richard Hodges <<a href=3D"mailto:hodges.r@gm=
ail.com">hodges.r@gmail.com</a>> wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div><div><div><div>>> <span class=3D"m_7549=
427974384382514gmail-im">and not true in this particular case, because, for=
example, MSVC, when given int foo() {}, produces a hard error.<br><br>>=
</span>That's non-conformant. There is no latitude for an implementati=
on to terminate translation of that function.<br><br></div></div></div></di=
v></div><div dir=3D"ltr"><div><div><div>Conformant or not, it rather gives =
the lie to the claim that there is a "massive body of code" that =
would suddenly fail to compile if non-compilation became mandated in such a=
circumstance.</div></div></div></div></blockquote><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div><div><div><br></div>We all write our code to b=
e as portable as possible, don't we?<br></div></div></div></blockquote>=
<div><br></div><div>No.</div><div><br></div><div>We have projects that are =
specifically <i>not</i>=C2=A0targeted at Windows, because their environment=
is, very explicitly, Linux.</div><div><br></div><div>Please stop making fa=
llacious arguments. If anything, it is MSVC which should stop breaking comp=
atibility there - at least by default.</div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div><div><br></div>Clearly, the only cod=
e that would need to be revisited would be platform-specific code that was =
taking advantage of (flaunting?) UB techniques.<br></div></div></blockquote=
><div><br></div><div>Nonsense again, it's not UB until you've actua=
lly executed the invalid code path, in this case.</div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div>Code that's=
doing that really ought to be annotated as such.<br><br><div><br><div><div=
><div><span class=3D"m_7549427974384382514gmail-im"></span></div></div></di=
v></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On =
21 December 2017 at 11:58, 'Edward Catmur' via ISO C++ Standard - F=
uture Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@isocp=
p.org" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><br><div class=3D"gmail_quote"><span>On Thu, Dec 21, 2017 at 9:55 AM, V=
iacheslav Usov <span dir=3D"ltr"><<a href=3D"mailto:via.usov@gmail.com" =
target=3D"_blank">via.usov@gmail.com</a>></span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D=
"gmail_quote">On Wed, Dec 20, 2017 at 7:41 PM, Nicol Bolas <span dir=3D"ltr=
"><<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gm=
ail.com</a>></span> wrote:<br><div><br></div><div>> So perhaps we hav=
e a different idea of what "depending on UB" means. UB only happe=
ns when you encounter it<i> at runtime</i>. It is not a compile-time concep=
t; it is runtime behavior.</div><div><br></div><div>That is not true in gen=
eral, because the standard does not define UB as a runtime concept,</div></=
div></div></div></blockquote><div><br></div></span><div>An implementation i=
s permitted to diagnose certain kinds of UB (typically "ill-formed NDR=
") at translation time; it is however not required to (hence NDR) and =
so the runtime behavior of such a program is undefined. In all cases of UB =
dependent on a runtime condition, the program is required to be translated =
and it is the runtime behavior that is undefined.</div><span><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extr=
a"><div class=3D"gmail_quote"><div> and not true in this particular case, b=
ecause, for example, MSVC, when given int foo() {}, produces a hard error.<=
/div></div></div></div></blockquote><div><br></div></span><div>That's n=
on-conformant. There is no latitude for an implementation to terminate tran=
slation of that function.</div><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<div></div><div>Cheers,<br></div><div>V.</div><div><br></div></div></div></=
div><span>
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<span><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></span><spa=
n>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg087TchKJdacOr5TrWMqLpuq%2BabPt=
mCCrs7PUjQkC%2BH6Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CAA7YVg087TchKJdacOr5TrWMqLpuq%2BabPtmCCrs7PUjQkC%2BH6Q%40mail.gma=
il.com</a>.<br>
</span></blockquote></div><br></div></div><span>
<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@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/CAJnLdOYYY6HY%3DMs3U4nBh88pvxf8jgh0O_=
Wtjnkz_3-rCeTZtQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAJnLdOYYY6HY%3DMs3U4nBh88pvxf8jgh0O_Wtjnkz_3-rCeTZtQ%40mail.gmail.c=
om</a>.<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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hYt%2Bzxa%2Ba-uGPc5ZtBNVLfVRG2v=
Pd%3DV-bQV55_%2BoDoJ%2Bw%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid=
/std-proposals/CALvx3hYt%2Bzxa%2Ba-uGPc5ZtBNVLfVRG2vPd%3DV-bQV55_%2BoDoJ%2B=
w%40mail.gmail.com</a>.<br>
</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/CAPCFJdTvQfpL5exQ%2BDVKUZZhSkdocXT-wt=
CWn-ZTT4k4E94VQA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTvQfpL5e=
xQ%2BDVKUZZhSkdocXT-wtCWn-ZTT4k4E94VQA%40mail.gmail.com</a>.<br />
--f403045e5b8465fdb60560d8734e--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Thu, 21 Dec 2017 13:00:59 +0100
Raw View
--94eb2c065dae1c4c350560d874c1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Thu, Dec 21, 2017 at 11:58 AM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> An implementation is permitted to diagnose certain kinds of UB (typically
"ill-formed NDR") at translation time; it is however not required to (hence
NDR) and so the runtime behavior of such a program is undefined. In all
cases of UB dependent on a runtime condition, the program is required to be
translated and it is the runtime behavior that is undefined.
Quoting 3.27:
undefined behavior
behavior for which this International Standard imposes no requirements
[ Note: Undefined behavior may be expected when this International Standard
omits any explicit definition of
behavior or when a program uses an erroneous construct or erroneous data.
Permissible undefined behavior
ranges from ignoring the situation completely with unpredictable results,
to behaving during translation or
program execution in a documented manner characteristic of the environment
(with or without the issuance
of a diagnostic message), to terminating a translation or execution (with
the issuance of a diagnostic message).
Many erroneous program constructs do not engender undefined behavior; they
are required to be diagnosed.
Evaluation of a constant expression never exhibits behavior explicitly
specified as undefined (8.20). =E2=80=94 end
note ]
To emphasise: "terminating a translation or execution (with the issuance of
a diagnostic message)".
While it can be argued in specific cases that UB can only happen at
runtime, in general it is clearly permitted to have translation-time
effects.
Note also that you restricted the circumstances to "UB dependent on a
runtime condition", while the statement that I responded to was "UB only
happens when you encounter it at runtime", which claims that your
restricted situation is the only situation when UB arises, which is clearly
at odds with the definition above.
> That's non-conformant. There is no latitude for an implementation to
terminate translation of that function.
Possible. However, it is a fact. Note that MSVC does this only when there
is no return statement at all, if there are some, then it emits a warning.
Cheers,
V.
--=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/CAA7YVg1T1h1uy9JQqJ7bhPEZwiVU%3DY04ofHMDZu_vbjhs=
1UHdQ%40mail.gmail.com.
--94eb2c065dae1c4c350560d874c1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Dec 21, 2017 at 11:58 AM, 'Edward Catmur' via ISO C++ Standard =
- Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@is=
ocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:<=
/div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"><div>&=
gt; An implementation is permitted to diagnose certain kinds of UB (typical=
ly "ill-formed NDR") at translation time; it is however not requi=
red to (hence NDR) and so the runtime behavior of such a program is undefin=
ed. In all cases of UB dependent on a runtime condition, the program is req=
uired to be translated and it is the runtime behavior that is undefined.</d=
iv><div><br></div><div>Quoting 3.27:</div><div><br></div><div><div>undefine=
d behavior</div><div>behavior for which this International Standard imposes=
no requirements</div><div>[ Note: Undefined behavior may be expected when =
this International Standard omits any explicit definition of</div><div>beha=
vior or when a program uses an erroneous construct or erroneous data. Permi=
ssible undefined behavior</div><div>ranges from ignoring the situation comp=
letely with unpredictable results, to behaving during translation or</div><=
div>program execution in a documented manner characteristic of the environm=
ent (with or without the issuance</div><div>of a diagnostic message), to te=
rminating a translation or execution (with the issuance of a diagnostic mes=
sage).</div><div>Many erroneous program constructs do not engender undefine=
d behavior; they are required to be diagnosed.</div><div>Evaluation of a co=
nstant expression never exhibits behavior explicitly specified as undefined=
(8.20). =E2=80=94 end</div><div>note ]</div></div><div><br></div><div>To e=
mphasise: "terminating a translation or execution (with the issuance o=
f a diagnostic message)".</div><div><br></div><div>While it can be arg=
ued in specific cases that UB can only happen at runtime, in general it is =
clearly permitted to have translation-time effects.</div><div><br></div><di=
v>Note also that you restricted the circumstances to "UB dependent on =
a runtime condition", while the statement that I responded to was &quo=
t;UB only happens when you encounter it at runtime", which claims that=
your restricted situation is the only situation when UB arises, which is c=
learly at odds with the definition above.</div><div><br></div><div>> Tha=
t's non-conformant. There is no latitude for an implementation to termi=
nate translation of that function.<br></div><div><br></div><div>Possible. H=
owever, it is a fact. Note that MSVC does this only when there is no return=
statement at all, if there are some, then it emits a warning.</div><div><b=
r></div><div>Cheers,</div><div>V.</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/CAA7YVg1T1h1uy9JQqJ7bhPEZwiVU%3DY04of=
HMDZu_vbjhs1UHdQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1T1h1uy9=
JQqJ7bhPEZwiVU%3DY04ofHMDZu_vbjhs1UHdQ%40mail.gmail.com</a>.<br />
--94eb2c065dae1c4c350560d874c1--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Thu, 21 Dec 2017 04:16:09 -0800 (PST)
Raw View
------=_Part_5223_948789904.1513858569844
Content-Type: multipart/alternative;
boundary="----=_Part_5224_1899376847.1513858569844"
------=_Part_5224_1899376847.1513858569844
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
>> We all write our code to be as portable as possible, don't we?
> No
Well that, if may say, seems a little unwise, nevertheless moving on...
> We have projects that are specifically *not* targeted at Windows, because=
=20
their environment is, very explicitly, Linux
So do many others, including my firm. Plus projects targeting iOS, OSX,=20
Android and Windows. But the requirements of interacting with these=20
platforms is out of scope of the c++ standard.
Standard c++ is all the other portable expression of logic in the program.=
=20
It is normal (and good) practice to encapsulate the touching of=20
platform-specific interfaces behind trivial facades, is it not?
It is also normal, and good, to seek to express logic portably using=20
standard c++ and idioms.
It seems to me that the c++ standard should in large part target the=20
authors of this kind of code, and let experts us *implementation defined=20
behaviour* when interacting with the OS.
*undefined* behaviour is an unwelcome smell.
=20
=20
On Thursday, 21 December 2017 13:00:52 UTC+1, Micha=C5=82 Dominiak wrote:
>
>
>
> On Thu, Dec 21, 2017 at 12:18 PM Richard Hodges <hodg...@gmail.com=20
> <javascript:>> wrote:
>
>> >> and not true in this particular case, because, for example, MSVC,=20
>> when given int foo() {}, produces a hard error.
>>
>> > That's non-conformant. There is no latitude for an implementation to=
=20
>> terminate translation of that function.
>>
>> Conformant or not, it rather gives the lie to the claim that there is a=
=20
>> "massive body of code" that would suddenly fail to compile if=20
>> non-compilation became mandated in such a circumstance.
>>
>
>> We all write our code to be as portable as possible, don't we?
>>
>
> No.
>
> We have projects that are specifically *not* targeted at Windows, because=
=20
> their environment is, very explicitly, Linux.
>
> Please stop making fallacious arguments. If anything, it is MSVC which=20
> should stop breaking compatibility there - at least by default.
> =20
>
>>
>> Clearly, the only code that would need to be revisited would be=20
>> platform-specific code that was taking advantage of (flaunting?) UB=20
>> techniques.
>>
>
> Nonsense again, it's not UB until you've actually executed the invalid=20
> code path, in this case.
> =20
>
>>
>> Code that's doing that really ought to be annotated as such.
>>
>>
>>
>> On 21 December 2017 at 11:58, 'Edward Catmur' via ISO C++ Standard -=20
>> Future Proposals <std-pr...@isocpp.org <javascript:>> wrote:
>>
>>>
>>>
>>> On Thu, Dec 21, 2017 at 9:55 AM, Viacheslav Usov <via....@gmail.com=20
>>> <javascript:>> wrote:
>>>
>>>> On Wed, Dec 20, 2017 at 7:41 PM, Nicol Bolas <jmck...@gmail.com=20
>>>> <javascript:>> wrote:
>>>>
>>>> > So perhaps we have a different idea of what "depending on UB" means.=
=20
>>>> UB only happens when you encounter it* at runtime*. It is not a=20
>>>> compile-time concept; it is runtime behavior.
>>>>
>>>> That is not true in general, because the standard does not define UB a=
s=20
>>>> a runtime concept,
>>>>
>>>
>>> An implementation is permitted to diagnose certain kinds of UB=20
>>> (typically "ill-formed NDR") at translation time; it is however not=20
>>> required to (hence NDR) and so the runtime behavior of such a program i=
s=20
>>> undefined. In all cases of UB dependent on a runtime condition, the pro=
gram=20
>>> is required to be translated and it is the runtime behavior that is=20
>>> undefined.
>>> =20
>>>
>>>> and not true in this particular case, because, for example, MSVC, when=
=20
>>>> given int foo() {}, produces a hard error.
>>>>
>>>
>>> That's non-conformant. There is no latitude for an implementation to=20
>>> terminate translation of that function.
>>> =20
>>>
>>>> Cheers,
>>>> V.
>>>>
>>>> --=20
>>>> You received this message because you are subscribed to a topic in the=
=20
>>>> Google Groups "ISO C++ Standard - Future Proposals" group.
>>>> To unsubscribe from this topic, visit=20
>>>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/Uu2QViiWh=
4k/unsubscribe
>>>> .
>>>> To unsubscribe from this group and all its topics, send an email to=20
>>>> 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/CAA7YVg08=
7TchKJdacOr5TrWMqLpuq%2BabPtmCCrs7PUjQkC%2BH6Q%40mail.gmail.com=20
>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0=
87TchKJdacOr5TrWMqLpuq%2BabPtmCCrs7PUjQkC%2BH6Q%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
>>>> .
>>>>
>>>
>>> --=20
>>> You received this message because you are subscribed to the Google=20
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>> an 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/CAJnLdOYYY=
6HY%3DMs3U4nBh88pvxf8jgh0O_Wtjnkz_3-rCeTZtQ%40mail.gmail.com=20
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYY=
Y6HY%3DMs3U4nBh88pvxf8jgh0O_Wtjnkz_3-rCeTZtQ%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
>>> .
>>>
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=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/CALvx3hYt%2=
Bzxa%2Ba-uGPc5ZtBNVLfVRG2vPd%3DV-bQV55_%2BoDoJ%2Bw%40mail.gmail.com=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hYt%=
2Bzxa%2Ba-uGPc5ZtBNVLfVRG2vPd%3DV-bQV55_%2BoDoJ%2Bw%40mail.gmail.com?utm_me=
dium=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/569a7504-8308-493a-b1c8-c7d918c0418f%40isocpp.or=
g.
------=_Part_5224_1899376847.1513858569844
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>> We all write our code to be as portable as possib=
le, don't we?<div>> No</div><div><br></div><div>Well that, if may sa=
y, seems a little unwise, nevertheless moving on...</div><div><br></div><di=
v>> We have projects that are specifically=C2=A0<i>not</i>=C2=A0targeted=
at Windows, because their environment is, very explicitly, Linux</div><div=
><br></div><div>So do many others, including my firm. Plus projects targeti=
ng iOS, OSX, Android and Windows. But the requirements of interacting with =
these platforms is out of scope of the c++ standard.</div><div><br></div><d=
iv>Standard c++ is all the other portable expression of logic in the progra=
m. It is normal (and good) practice to encapsulate the touching of platform=
-specific interfaces behind trivial facades, is it not?</div><div><br></div=
><div>It is also normal, and good, to seek to express logic portably using =
standard c++ and idioms.</div><div><br></div><div>It seems to me that the c=
++ standard should in large part target the authors of this kind of code, a=
nd let experts us <i><b>implementation</b> defined behaviour</i> when inter=
acting with the OS.</div><div><br></div><div><i>undefined</i> behaviour is =
an unwelcome smell.</div><div>=C2=A0</div><div><br></div><div>=C2=A0</div><=
div><br></div><div><br></div><div><br><br>On Thursday, 21 December 2017 13:=
00:52 UTC+1, Micha=C5=82 Dominiak wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"=
ltr">On Thu, Dec 21, 2017 at 12:18 PM Richard Hodges <<a href=3D"javascr=
ipt:" target=3D"_blank" gdf-obfuscated-mailto=3D"Zy7kLi8GBwAJ" rel=3D"nofol=
low" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">hodg...@gmail.com</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><di=
v><div><div>>> <span>and not true in this particular case, because, f=
or example, MSVC, when given int foo() {}, produces a hard error.<br><br>&g=
t; </span>That's non-conformant. There is no latitude for an implementa=
tion to terminate translation of that function.<br><br></div></div></div></=
div></div><div dir=3D"ltr"><div><div><div>Conformant or not, it rather give=
s the lie to the claim that there is a "massive body of code" tha=
t would suddenly fail to compile if non-compilation became mandated in such=
a circumstance.</div></div></div></div></blockquote><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div><div><div><br></div>We all write our code to=
be as portable as possible, don't we?<br></div></div></div></blockquot=
e><div><br></div><div>No.</div><div><br></div><div>We have projects that ar=
e specifically <i>not</i>=C2=A0targeted at Windows, because their environme=
nt is, very explicitly, Linux.</div><div><br></div><div>Please stop making =
fallacious arguments. If anything, it is MSVC which should stop breaking co=
mpatibility there - at least by default.</div><div>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr"><div><div><br></div>Clearly, the only c=
ode that would need to be revisited would be platform-specific code that wa=
s taking advantage of (flaunting?) UB techniques.<br></div></div></blockquo=
te><div><br></div><div>Nonsense again, it's not UB until you've act=
ually executed the invalid code path, in this case.</div><div>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div>Code that'=
;s doing that really ought to be annotated as such.<br><br><div><br><div><d=
iv><div><span></span></div></div></div></div></div><div><br><div class=3D"g=
mail_quote">On 21 December 2017 at 11:58, 'Edward Catmur' via ISO C=
++ Standard - Future Proposals <span dir=3D"ltr"><<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"Zy7kLi8GBwAJ" rel=3D"nofollow"=
onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"=
this.href=3D'javascript:';return true;">std-pr...@isocpp.org</a>>=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div=
><br><div class=3D"gmail_quote"><span>On Thu, Dec 21, 2017 at 9:55 AM, Viac=
heslav Usov <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank"=
gdf-obfuscated-mailto=3D"Zy7kLi8GBwAJ" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D'javascript:';return true;" onclick=3D"this.href=3D'ja=
vascript:';return true;">via....@gmail.com</a>></span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote=
">On Wed, Dec 20, 2017 at 7:41 PM, Nicol Bolas <span dir=3D"ltr"><<a hre=
f=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Zy7kLi8GBwAJ" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return tr=
ue;" onclick=3D"this.href=3D'javascript:';return true;">jmck...@gma=
il.com</a>></span> wrote:<br><div><br></div><div>> So perhaps we have=
a different idea of what "depending on UB" means. UB only happen=
s when you encounter it<i> at runtime</i>. It is not a compile-time concept=
; it is runtime behavior.</div><div><br></div><div>That is not true in gene=
ral, because the standard does not define UB as a runtime concept,</div></d=
iv></div></div></blockquote><div><br></div></span><div>An implementation is=
permitted to diagnose certain kinds of UB (typically "ill-formed NDR&=
quot;) at translation time; it is however not required to (hence NDR) and s=
o the runtime behavior of such a program is undefined. In all cases of UB d=
ependent on a runtime condition, the program is required to be translated a=
nd it is the runtime behavior that is undefined.</div><span><div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_=
quote"><div> and not true in this particular case, because, for example, MS=
VC, when given int foo() {}, produces a hard error.</div></div></div></div>=
</blockquote><div><br></div></span><div>That's non-conformant. There is=
no latitude for an implementation to terminate translation of that functio=
n.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv><div class=3D"gmail_quote"><div></div><div>Cheers,<br></div><div>V.</div=
><div><br></div></div></div></div><span>
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.c=
om/a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe';return t=
rue;" onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/=
topic/std-proposals/Uu2QViiWh4k/unsubscribe';return true;">https://grou=
ps.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/Uu2QViiWh4k/<wbr=
>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Zy7kLi8GBwAJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return tru=
e;" onclick=3D"this.href=3D'javascript:';return true;">std-proposal=
....@<wbr>isocpp.org</a>.<span><br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"Zy7kLi8GBwAJ" 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></span></span>=
<span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg087TchKJdacOr5TrWMqLpuq%2BabPt=
mCCrs7PUjQkC%2BH6Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg087TchKJda=
cOr5TrWMqLpuq%2BabPtmCCrs7PUjQkC%2BH6Q%40mail.gmail.com?utm_medium\x3demail=
\x26utm_source\x3dfooter';return true;" onclick=3D"this.href=3D'htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg087TchKJda=
cOr5TrWMqLpuq%2BabPtmCCrs7PUjQkC%2BH6Q%40mail.gmail.com?utm_medium\x3demail=
\x26utm_source\x3dfooter';return true;">https://groups.google.com/a/<wb=
r>isocpp.org/d/msgid/std-<wbr>proposals/<wbr>CAA7YVg087TchKJdacOr5TrWMqLpuq=
<wbr>%2BabPtmCCrs7PUjQkC%2BH6Q%<wbr>40mail.gmail.com</a>.<br>
</span></blockquote></div><br></div></div><span>
<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"=
Zy7kLi8GBwAJ" 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"Zy7kLi8GBwAJ" 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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYYY6HY%3DMs3U4nBh88pvxf8jgh0O_=
Wtjnkz_3-rCeTZtQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https=
://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYYY6HY%3DMs3=
U4nBh88pvxf8jgh0O_Wtjnkz_3-rCeTZtQ%40mail.gmail.com?utm_medium\x3demail\x26=
utm_source\x3dfooter';return true;" onclick=3D"this.href=3D'https:/=
/groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYYY6HY%3DMs3U4=
nBh88pvxf8jgh0O_Wtjnkz_3-rCeTZtQ%40mail.gmail.com?utm_medium\x3demail\x26ut=
m_source\x3dfooter';return true;">https://groups.google.com/a/<wbr>isoc=
pp.org/d/msgid/std-<wbr>proposals/CAJnLdOYYY6HY%<wbr>3DMs3U4nBh88pvxf8jgh0O=
_Wtjnkz_<wbr>3-rCeTZtQ%40mail.gmail.com</a>.<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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
Zy7kLi8GBwAJ" 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"Zy7kLi8GBwAJ" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hYt%2Bzxa%2Ba-uGPc5ZtBNVLfVRG2v=
Pd%3DV-bQV55_%2BoDoJ%2Bw%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hYt%2=
Bzxa%2Ba-uGPc5ZtBNVLfVRG2vPd%3DV-bQV55_%2BoDoJ%2Bw%40mail.gmail.com?utm_med=
ium\x3demail\x26utm_source\x3dfooter';return true;" onclick=3D"this.hre=
f=3D'https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx=
3hYt%2Bzxa%2Ba-uGPc5ZtBNVLfVRG2vPd%3DV-bQV55_%2BoDoJ%2Bw%40mail.gmail.com?u=
tm_medium\x3demail\x26utm_source\x3dfooter';return true;">https://group=
s.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/CALvx3hYt%2Bzxa%2=
Ba-<wbr>uGPc5ZtBNVLfVRG2vPd%3DV-bQV55_<wbr>%2BoDoJ%2Bw%40mail.gmail.com</a>=
..<br>
</blockquote></div></div>
</blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/569a7504-8308-493a-b1c8-c7d918c0418f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/569a7504-8308-493a-b1c8-c7d918c0418f=
%40isocpp.org</a>.<br />
------=_Part_5224_1899376847.1513858569844--
------=_Part_5223_948789904.1513858569844--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 21 Dec 2017 10:25:04 -0200
Raw View
On quinta-feira, 21 de dezembro de 2017 09:13:22 -02 'Edward Catmur' via ISO C
++ Standard - Future Proposals wrote:
> Clearly it should be permissible for the implementation to throw an
> exception or terminate the program if a call to std::unreachable is
> encountered. But this must not be mandated.
I wouldn't call that acceptable behaviour. It is UB to reach
std::unreachable(), so anything could happen, but I would not expect an
exception.
std::terminate, yes.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/27035861.40YdkragEV%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 21 Dec 2017 10:26:14 -0200
Raw View
On quinta-feira, 21 de dezembro de 2017 04:14:00 -02 Nicol Bolas wrote:
> And despite such careful consideration, there is even some pushback on
> recent removals of things that are clear duplicates of much better stuff
> <http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0845r0.html>. All
> based on the fact that some code just doesn't get updated, but we still
> need to be able to use it.
To say nothing of trigraphs??!
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/13399646.7nQpdtJgyO%40tjmaciei-mobl1.
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Thu, 21 Dec 2017 12:31:57 +0000
Raw View
--94eb2c14c7d6642d990560d8e3bf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Okay, this is my last mail in this thread, because this is all useless. I
invite you to write a paper so I can help trash it in EWG.
This whole discussion is so riddled with logical fallacies you've used,
that I wouldn't even know how to start pointing them out. And also you
consistently avoid answering my actual arguments, only replying to parts of
my messages that are less substantial, because that's easier to contend...
So no, I'm now - after this email - taking my own advice and calling
Dunning-Kruger - and moving on.
On Thu, Dec 21, 2017 at 1:16 PM Richard Hodges <hodges.r@gmail.com> wrote:
> >> We all write our code to be as portable as possible, don't we?
> > No
>
> Well that, if may say, seems a little unwise, nevertheless moving on...
>
Nice attempt at discrediting whoever you are conducting a discussion with..=
..
>
> > We have projects that are specifically *not* targeted at Windows,
> because their environment is, very explicitly, Linux
>
> So do many others, including my firm. Plus projects targeting iOS, OSX,
> Android and Windows. But the requirements of interacting with these
> platforms is out of scope of the c++ standard.
>
> Standard c++ is all the other portable expression of logic in the program=
..
> It is normal (and good) practice to encapsulate the touching of
> platform-specific interfaces behind trivial facades, is it not?
>
> It is also normal, and good, to seek to express logic portably using
> standard c++ and idioms.
>
That is exactly what we do - it's MSVC that breaks compat here, not our
code.
>
> It seems to me that the c++ standard should in large part target the
> authors of this kind of code, and let experts us *implementation defined
> behaviour* when interacting with the OS.
>
> *undefined* behaviour is an unwelcome smell.
>
Says you.
Care about this issue? Write a paper. Care about being able to decide on
it? Come to a meeting.
Just be warned of one thing: as others have pointed out, it is not our duty
to convince you that the status quo is correct, when you bring a proposal.
It's YOUR duty to convince US that both of the following are true: the
status quo is wrong; the cost of fixing the status quo is not a deal
breaker.
You may well find people that agree with the first part.
I doubt you'll find enough people that will agree with the second.
Cheers.
>
>
>
>
>
>
> On Thursday, 21 December 2017 13:00:52 UTC+1, Micha=C5=82 Dominiak wrote:
>>
>>
>>
>> On Thu, Dec 21, 2017 at 12:18 PM Richard Hodges <hodg...@gmail.com>
>> wrote:
>>
>>> >> and not true in this particular case, because, for example, MSVC,
>>> when given int foo() {}, produces a hard error.
>>>
>>> > That's non-conformant. There is no latitude for an implementation to
>>> terminate translation of that function.
>>>
>>> Conformant or not, it rather gives the lie to the claim that there is a
>>> "massive body of code" that would suddenly fail to compile if
>>> non-compilation became mandated in such a circumstance.
>>>
>>
>>> We all write our code to be as portable as possible, don't we?
>>>
>>
>> No.
>>
>> We have projects that are specifically *not* targeted at Windows,
>> because their environment is, very explicitly, Linux.
>>
>> Please stop making fallacious arguments. If anything, it is MSVC which
>> should stop breaking compatibility there - at least by default.
>>
>>
>>>
>>> Clearly, the only code that would need to be revisited would be
>>> platform-specific code that was taking advantage of (flaunting?) UB
>>> techniques.
>>>
>>
>> Nonsense again, it's not UB until you've actually executed the invalid
>> code path, in this case.
>>
>>
>
>>> Code that's doing that really ought to be annotated as such.
>>>
>>>
>>>
>>> On 21 December 2017 at 11:58, 'Edward Catmur' via ISO C++ Standard -
>>> Future Proposals <std-pr...@isocpp.org> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Dec 21, 2017 at 9:55 AM, Viacheslav Usov <via....@gmail.com>
>>>> wrote:
>>>>
>>>
>>>> On Wed, Dec 20, 2017 at 7:41 PM, Nicol Bolas <jmck...@gmail.com> wrote=
:
>>>>>
>>>>> > So perhaps we have a different idea of what "depending on UB" means=
..
>>>>> UB only happens when you encounter it* at runtime*. It is not a
>>>>> compile-time concept; it is runtime behavior.
>>>>>
>>>>> That is not true in general, because the standard does not define UB
>>>>> as a runtime concept,
>>>>>
>>>>
>>>> An implementation is permitted to diagnose certain kinds of UB
>>>> (typically "ill-formed NDR") at translation time; it is however not
>>>> required to (hence NDR) and so the runtime behavior of such a program =
is
>>>> undefined. In all cases of UB dependent on a runtime condition, the pr=
ogram
>>>> is required to be translated and it is the runtime behavior that is
>>>> undefined.
>>>>
>>>>
>>>>> and not true in this particular case, because, for example, MSVC, whe=
n
>>>>> given int foo() {}, produces a hard error.
>>>>>
>>>>
>>>> That's non-conformant. There is no latitude for an implementation to
>>>> terminate translation of that function.
>>>>
>>>>
>>> Cheers,
>>>>> V.
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to a topic in th=
e
>>>>> Google Groups "ISO C++ Standard - Future Proposals" group.
>>>>> To unsubscribe from this topic, visit
>>>>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/Uu2QViiW=
h4k/unsubscribe
>>>>> .
>>>>>
>>>> To unsubscribe from this group and all its topics, send an 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/isocpp.org/d/msgid/std-proposals/CAA7YVg0=
87TchKJdacOr5TrWMqLpuq%2BabPtmCCrs7PUjQkC%2BH6Q%40mail.gmail.com
>>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg=
087TchKJdacOr5TrWMqLpuq%2BabPtmCCrs7PUjQkC%2BH6Q%40mail.gmail.com?utm_mediu=
m=3Demail&utm_source=3Dfooter>
>>>>> .
>>>>>
>>>> --
>>>> 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-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/isocpp.org/d/msgid/std-proposals/CAJnLdOYY=
Y6HY%3DMs3U4nBh88pvxf8jgh0O_Wtjnkz_3-rCeTZtQ%40mail.gmail.com
>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOY=
YY6HY%3DMs3U4nBh88pvxf8jgh0O_Wtjnkz_3-rCeTZtQ%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
>>>> .
>>>>
>>> --
>>> 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 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/isocpp.org/d/msgid/std-proposals/CALvx3hYt%=
2Bzxa%2Ba-uGPc5ZtBNVLfVRG2vPd%3DV-bQV55_%2BoDoJ%2Bw%40mail.gmail.com
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hYt=
%2Bzxa%2Ba-uGPc5ZtBNVLfVRG2vPd%3DV-bQV55_%2BoDoJ%2Bw%40mail.gmail.com?utm_m=
edium=3Demail&utm_source=3Dfooter>
>>> .
>>>
>> --
> 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/569a7504-830=
8-493a-b1c8-c7d918c0418f%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/569a7504-83=
08-493a-b1c8-c7d918c0418f%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/CAPCFJdQwCfHceTZ6hYcyxoGvpRCxgGqQ8k%3Dz2FpCYSOUM=
LpvTg%40mail.gmail.com.
--94eb2c14c7d6642d990560d8e3bf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Okay, this is my last mail in this thread, because this is=
all useless. I invite you to write a paper so I can help trash it in EWG.<=
div><br></div><div>This whole discussion is so riddled with logical fallaci=
es you've used, that I wouldn't even know how to start pointing the=
m out. And also you consistently avoid answering my actual arguments, only =
replying to parts of my messages that are less substantial, because that=
9;s easier to contend... So no, I'm now - after this email - taking my =
own advice and calling Dunning-Kruger - and moving on.<br><br><div class=3D=
"gmail_quote"><div dir=3D"ltr">On Thu, Dec 21, 2017 at 1:16 PM Richard Hodg=
es <<a href=3D"mailto:hodges.r@gmail.com">hodges.r@gmail.com</a>> wro=
te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">>> We al=
l write our code to be as portable as possible, don't we?<div>> No</=
div><div><br></div></div><div dir=3D"ltr"><div>Well that, if may say, seems=
a little unwise, nevertheless moving on...</div></div></blockquote><div><b=
r></div><div>Nice attempt at discrediting whoever you are conducting a disc=
ussion with...</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div><br></div><div>> We have projects that are specifically=
=C2=A0<i>not</i>=C2=A0targeted at Windows, because their environment is, ve=
ry explicitly, Linux</div><div><br></div></div><div dir=3D"ltr"><div>So do =
many others, including my firm. Plus projects targeting iOS, OSX, Android a=
nd Windows. But the requirements of interacting with these platforms is out=
of scope of the c++ standard.</div><div><br></div><div>Standard c++ is all=
the other portable expression of logic in the program. It is normal (and g=
ood) practice to encapsulate the touching of platform-specific interfaces b=
ehind trivial facades, is it not?=C2=A0</div></div></blockquote><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>It is also normal,=
and good, to seek to express logic portably using standard c++ and idioms.=
</div></div></blockquote><div><br></div><div>That is exactly what we do - i=
t's MSVC that breaks compat here, not our code.</div><div>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>It seems=
to me that the c++ standard should in large part target the authors of thi=
s kind of code, and let experts us <i><b>implementation</b> defined behavio=
ur</i> when interacting with the OS.</div><div><br></div><div><i>undefined<=
/i> behaviour is an unwelcome smell.</div></div></blockquote><div><br></div=
><div>Says you.</div><div><br></div><div>Care about this issue? Write a pap=
er. Care about being able to decide on it? Come to a meeting.</div><div><br=
></div><div>Just be warned of one thing: as others have pointed out, it is =
not our duty to convince you that the status quo is correct, when you bring=
a proposal. It's YOUR duty to convince US that both of the following a=
re true: the status quo is wrong; the cost of fixing the status quo is not =
a deal breaker.</div><div><br></div><div>You may well find people that agre=
e with the first part.</div><div><br></div><div>I doubt you'll find eno=
ugh people that will agree with the second.</div><div>=C2=A0</div><div>Chee=
rs.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v>=C2=A0</div><div><br></div><div>=C2=A0</div><div><br></div><div><br></div=
><div><br><br>On Thursday, 21 December 2017 13:00:52 UTC+1, Micha=C5=82 Dom=
iniak 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"><br><=
br><div class=3D"gmail_quote"></div></div></blockquote></div></div><div dir=
=3D"ltr"><div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Dec 21, 2017 at 12:18 PM Ri=
chard Hodges <<a rel=3D"nofollow">hodg...@gmail.com</a>> wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div><div>>=
;> <span>and not true in this particular case, because, for example, MSV=
C, when given int foo() {}, produces a hard error.<br><br>> </span>That&=
#39;s non-conformant. There is no latitude for an implementation to termina=
te translation of that function.<br><br></div></div></div></div></div><div =
dir=3D"ltr"><div><div><div>Conformant or not, it rather gives the lie to th=
e claim that there is a "massive body of code" that would suddenl=
y fail to compile if non-compilation became mandated in such a circumstance=
..</div></div></div></div></blockquote><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div><div><div><br></div>We all write our code to be as portable=
as possible, don't we?<br></div></div></div></blockquote><div><br></di=
v><div>No.</div><div><br></div><div>We have projects that are specifically =
<i>not</i>=C2=A0targeted at Windows, because their environment is, very exp=
licitly, Linux.</div><div><br></div><div>Please stop making fallacious argu=
ments. If anything, it is MSVC which should stop breaking compatibility the=
re - at least by default.</div><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div><div><br></div>Clearly, the only code that would =
need to be revisited would be platform-specific code that was taking advant=
age of (flaunting?) UB techniques.<br></div></div></blockquote><div><br></d=
iv><div>Nonsense again, it's not UB until you've actually executed =
the invalid code path, in this case.</div><div>=C2=A0</div></div></div></bl=
ockquote></div></div><div dir=3D"ltr"><div><blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div><br></div>Code that's doing that really o=
ught to be annotated as such.<br><br><div><br><div><div><div><span></span><=
/div></div></div></div></div></blockquote></div></div></blockquote></div></=
div><div dir=3D"ltr"><div><blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br=
><div class=3D"gmail_quote">On 21 December 2017 at 11:58, 'Edward Catmu=
r' via ISO C++ Standard - Future Proposals <span dir=3D"ltr"><<a rel=
=3D"nofollow">std-pr...@isocpp.org</a>></span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><br><div><br><div class=3D"gmail_quote"><s=
pan>On Thu, Dec 21, 2017 at 9:55 AM, Viacheslav Usov <span dir=3D"ltr"><=
<a rel=3D"nofollow">via....@gmail.com</a>></span> wrote:</span></div></d=
iv></div></blockquote></div></div></blockquote></div></div></blockquote></d=
iv></div><div dir=3D"ltr"><div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div><div class=3D"gmail_quote"><span><br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><div><div class=3D"gmail_quote">On Wed, Dec 20, 2017 at 7:4=
1 PM, Nicol Bolas <span dir=3D"ltr"><<a rel=3D"nofollow">jmck...@gmail.c=
om</a>></span> wrote:<br><div><br></div><div>> So perhaps we have a d=
ifferent idea of what "depending on UB" means. UB only happens wh=
en you encounter it<i> at runtime</i>. It is not a compile-time concept; it=
is runtime behavior.</div><div><br></div><div>That is not true in general,=
because the standard does not define UB as a runtime concept,</div></div><=
/div></div></blockquote><div><br></div></span></div></div></div></blockquot=
e></div></div></blockquote></div></div></blockquote></div></div><div dir=3D=
"ltr"><div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:=
0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"gmail=
_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"=
gmail_quote"><div>An implementation is permitted to diagnose certain kinds =
of UB (typically "ill-formed NDR") at translation time; it is how=
ever not required to (hence NDR) and so the runtime behavior of such a prog=
ram is undefined. In all cases of UB dependent on a runtime condition, the =
program is required to be translated and it is the runtime behavior that is=
undefined.</div><span><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr"><div><div class=3D"gmail_quote"><div> and not true in this par=
ticular case, because, for example, MSVC, when given int foo() {}, produces=
a hard error.</div></div></div></div></blockquote><div><br></div></span><d=
iv>That's non-conformant. There is no latitude for an implementation to=
terminate translation of that function.</div><div>=C2=A0</div></div></div>=
</div></blockquote></div></div></blockquote></div></div></blockquote></div>=
</div><div dir=3D"ltr"><div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div><div class=3D"gmail_quote"><div></div><div>Cheers,<br></div><div>V.=
</div><div><br></div></div></div></div><span></span></blockquote></div></di=
v></div></blockquote></div></div></blockquote></div></div></blockquote></di=
v></div><div dir=3D"ltr"><div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" rel=3D"nofollow=
" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-prop=
osals/Uu2QViiWh4k/unsubscribe</a>.<br></span></blockquote></div></div></div=
></blockquote></div></div></blockquote></div></div></blockquote></div></div=
><div dir=3D"ltr"><div><blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
To unsubscribe from this group and all its topics, send an email to <a rel=
=3D"nofollow">std-proposal...@isocpp.org</a>.<span><br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br></span></span></blockquote></div></div></div></blockquote></div>=
</div></blockquote></div></div></blockquote></div></div><div dir=3D"ltr"><d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_qu=
ote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg087TchKJdacOr5TrWMqLpuq%2BabPt=
mCCrs7PUjQkC%2BH6Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" rel=3D"nofollow" target=3D"_blank">https://groups.google.com/a/isocpp.=
org/d/msgid/std-proposals/CAA7YVg087TchKJdacOr5TrWMqLpuq%2BabPtmCCrs7PUjQkC=
%2BH6Q%40mail.gmail.com</a>.<br>
</span></blockquote></div></div></div></blockquote></div></div></blockquote=
></div></div></blockquote></div></div><div dir=3D"ltr"><div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><span>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></span></blockquot=
e></div></div></blockquote></div></div></blockquote></div></div><div dir=3D=
"ltr"><div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:=
0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"gmail=
_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><span>
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></span></blockquote></div></div></blockquote></div></div></block=
quote></div></div><div dir=3D"ltr"><div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYYY6HY%3DMs3U4nBh88pvxf8jgh0O_=
Wtjnkz_3-rCeTZtQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" rel=3D"nofollow" target=3D"_blank">https://groups.google.com/a/isocpp.or=
g/d/msgid/std-proposals/CAJnLdOYYY6HY%3DMs3U4nBh88pvxf8jgh0O_Wtjnkz_3-rCeTZ=
tQ%40mail.gmail.com</a>.<br>
</blockquote></div></div></blockquote></div></div></blockquote></div></div>=
<div dir=3D"ltr"><div><blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></blockquote></div=
></div></blockquote></div></div><div dir=3D"ltr"><div><blockquote class=3D"=
gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">
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>.</blockquote></div></div></blockquote></div></div><div dir=3D"ltr"><=
div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"=
gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hYt%2Bzxa%2Ba-uGPc5ZtBNVLfVRG2v=
Pd%3DV-bQV55_%2BoDoJ%2Bw%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter" rel=3D"nofollow" target=3D"_blank">https://groups.google.com/a/i=
socpp.org/d/msgid/std-proposals/CALvx3hYt%2Bzxa%2Ba-uGPc5ZtBNVLfVRG2vPd%3DV=
-bQV55_%2BoDoJ%2Bw%40mail.gmail.com</a>.<br>
</blockquote></div></div></blockquote></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/569a7504-8308-493a-b1c8-c7d918c0418f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/569a7504-8308-=
493a-b1c8-c7d918c0418f%40isocpp.org</a>.<br>
</blockquote></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAPCFJdQwCfHceTZ6hYcyxoGvpRCxgGqQ8k%3=
Dz2FpCYSOUMLpvTg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdQwCfHceT=
Z6hYcyxoGvpRCxgGqQ8k%3Dz2FpCYSOUMLpvTg%40mail.gmail.com</a>.<br />
--94eb2c14c7d6642d990560d8e3bf--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Thu, 21 Dec 2017 12:58:52 +0000
Raw View
--001a114cc6c42daa7a0560d9433d
Content-Type: text/plain; charset="UTF-8"
On 21 Dec 2017 11:18, "Richard Hodges" <hodges.r@gmail.com> wrote:
>> and not true in this particular case, because, for example, MSVC, when
given int foo() {}, produces a hard error.
> That's non-conformant. There is no latitude for an implementation to
terminate translation of that function.
Conformant or not, it rather gives the lie to the claim that there is a
"massive body of code" that would suddenly fail to compile if
non-compilation became mandated in such a circumstance.
All that means is that code targeted to be portable to MSVC cannot contain
functions all of whose code paths fall off the end. You are forgetting that
much code does not target MSVC and even code that targets MSVC may contain
functions some of whose code paths fall off the end.
We all write our code to be as portable as possible, don't we?
Clearly, the only code that would need to be revisited would be
platform-specific code that was taking advantage of (flaunting?) UB
techniques.
Code that's doing that really ought to be annotated as such.
On 21 December 2017 at 11:58, 'Edward Catmur' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:
>
>
> On Thu, Dec 21, 2017 at 9:55 AM, Viacheslav Usov <via.usov@gmail.com>
> wrote:
>
>> On Wed, Dec 20, 2017 at 7:41 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>>
>> > So perhaps we have a different idea of what "depending on UB" means. UB
>> only happens when you encounter it* at runtime*. It is not a
>> compile-time concept; it is runtime behavior.
>>
>> That is not true in general, because the standard does not define UB as a
>> runtime concept,
>>
>
> An implementation is permitted to diagnose certain kinds of UB (typically
> "ill-formed NDR") at translation time; it is however not required to (hence
> NDR) and so the runtime behavior of such a program is undefined. In all
> cases of UB dependent on a runtime condition, the program is required to be
> translated and it is the runtime behavior that is undefined.
>
>
>> and not true in this particular case, because, for example, MSVC, when
>> given int foo() {}, produces a hard error.
>>
>
> That's non-conformant. There is no latitude for an implementation to
> terminate translation of that function.
>
>
>> Cheers,
>> V.
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit https://groups.google.com/a/is
>> ocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/is
>> ocpp.org/d/msgid/std-proposals/CAA7YVg087TchKJdacOr5TrWMqLpu
>> q%2BabPtmCCrs7PUjQkC%2BH6Q%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg087TchKJdacOr5TrWMqLpuq%2BabPtmCCrs7PUjQkC%2BH6Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
> --
> 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/is
> ocpp.org/d/msgid/std-proposals/CAJnLdOYYY6HY%3DMs3U4nBh88pvx
> f8jgh0O_Wtjnkz_3-rCeTZtQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYYY6HY%3DMs3U4nBh88pvxf8jgh0O_Wtjnkz_3-rCeTZtQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to a topic in the
Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/
isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
To unsubscribe from this group and all its topics, 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/CALvx3hYt%2Bzxa%2Ba-
uGPc5ZtBNVLfVRG2vPd%3DV-bQV55_%2BoDoJ%2Bw%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hYt%2Bzxa%2Ba-uGPc5ZtBNVLfVRG2vPd%3DV-bQV55_%2BoDoJ%2Bw%40mail.gmail.com?utm_medium=email&utm_source=footer>
..
--
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/CAJnLdOZyKSziPBjzX8G6gsZr5Qg%2B23AR0DazBVHPXh-FJHSPcQ%40mail.gmail.com.
--001a114cc6c42daa7a0560d9433d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On 21 Dec 2017 11:18, "Richard Hodges" <<a href=3D"m=
ailto:hodges.r@gmail.com">hodges.r@gmail.com</a>> wrote:<br type=3D"attr=
ibution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div><div clas=
s=3D"quoted-text"><div>>> <span class=3D"m_6062728813192794342gmail-i=
m">and not true in this particular case, because, for example, MSVC, when g=
iven int foo() {}, produces a hard error.<br><br>> </span>That's non=
-conformant. There is no latitude for an implementation to terminate transl=
ation of that function.<br><br></div></div>Conformant or not, it rather giv=
es the lie to the claim that there is a "massive body of code" th=
at would suddenly fail to compile if non-compilation became mandated in suc=
h a circumstance.<br></div></div></div></div></blockquote></div></div></div=
><div dir=3D"auto"><br></div><div dir=3D"auto">All that means is that code =
targeted to be portable to MSVC cannot contain functions all of whose code =
paths fall off the end. You are forgetting that much code does not target M=
SVC and even code that targets MSVC may contain functions some of whose cod=
e paths fall off the end.=C2=A0</div><div dir=3D"auto"><br></div><div dir=
=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote=
class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div><div><div><br></div>We all write our co=
de to be as portable as possible, don't we?<br><br></div>Clearly, the o=
nly code that would need to be revisited would be platform-specific code th=
at was taking advantage of (flaunting?) UB techniques.<br><br></div>Code th=
at's doing that really ought to be annotated as such.<br><br><div><br><=
div><div><div><span class=3D"m_6062728813192794342gmail-im"></span></div></=
div></div></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_qu=
ote"><div class=3D"elided-text">On 21 December 2017 at 11:58, 'Edward C=
atmur' via ISO C++ Standard - Future Proposals <span dir=3D"ltr"><<a=
href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@i=
socpp.org</a>></span> wrote:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v class=3D"elided-text"><div dir=3D"ltr"><br><div class=3D"gmail_extra"><br=
><div class=3D"gmail_quote"><span>On Thu, Dec 21, 2017 at 9:55 AM, Viachesl=
av Usov <span dir=3D"ltr"><<a href=3D"mailto:via.usov@gmail.com" target=
=3D"_blank">via.usov@gmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gma=
il_quote">On Wed, Dec 20, 2017 at 7:41 PM, Nicol Bolas <span dir=3D"ltr">&l=
t;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.=
com</a>></span> wrote:<br><div><br></div><div>> So perhaps we have a =
different idea of what "depending on UB" means. UB only happens w=
hen you encounter it<i> at runtime</i>. It is not a compile-time concept; i=
t is runtime behavior.</div><div><br></div><div>That is not true in general=
, because the standard does not define UB as a runtime concept,</div></div>=
</div></div></blockquote><div><br></div></span><div>An implementation is pe=
rmitted to diagnose certain kinds of UB (typically "ill-formed NDR&quo=
t;) at translation time; it is however not required to (hence NDR) and so t=
he runtime behavior of such a program is undefined. In all cases of UB depe=
ndent on a runtime condition, the program is required to be translated and =
it is the runtime behavior that is undefined.</div><span><div>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><=
div class=3D"gmail_quote"><div> and not true in this particular case, becau=
se, for example, MSVC, when given int foo() {}, produces a hard error.</div=
></div></div></div></blockquote><div><br></div></span><div>That's non-c=
onformant. There is no latitude for an implementation to terminate translat=
ion of that function.</div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
></div><div>Cheers,<br></div><div>V.</div><div><br></div></div></div></div>=
<span>
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/is<wbr>ocpp.org/d/topic/std-proposals<wbr>/U=
u2QViiWh4k/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isoc<wbr>pp.org</a>.<span><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></span><spa=
n>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg087TchKJdacOr5TrWMqLpuq%2BabPt=
mCCrs7PUjQkC%2BH6Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/=
std-proposals<wbr>/CAA7YVg087TchKJdacOr5TrWMqLpu<wbr>q%2BabPtmCCrs7PUjQkC%2=
BH6Q%40m<wbr>ail.gmail.com</a>.<br>
</span></blockquote></div><br></div></div></div><span>
<p></p>
-- <br><div class=3D"quoted-text">
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></div>
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@isoc<wbr>pp.org</a>.<div class=3D"quoted-t=
ext"><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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYYY6HY%3DMs3U4nBh88pvxf8jgh0O_=
Wtjnkz_3-rCeTZtQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/st=
d-proposals<wbr>/CAJnLdOYYY6HY%3DMs3U4nBh88pvx<wbr>f8jgh0O_Wtjnkz_3-rCeTZtQ=
%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div><br></div><div class=3D"quoted-text">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/U=
u2QViiWh4k/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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/CALvx3hYt%2Bzxa%2Ba-uGPc5ZtBNVLfVRG2v=
Pd%3DV-bQV55_%2BoDoJ%2Bw%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/=
msgid/std-<wbr>proposals/CALvx3hYt%2Bzxa%2Ba-<wbr>uGPc5ZtBNVLfVRG2vPd%3DV-b=
QV55_<wbr>%2BoDoJ%2Bw%40mail.gmail.com</a>.<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/CAJnLdOZyKSziPBjzX8G6gsZr5Qg%2B23AR0D=
azBVHPXh-FJHSPcQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZyKSziPB=
jzX8G6gsZr5Qg%2B23AR0DazBVHPXh-FJHSPcQ%40mail.gmail.com</a>.<br />
--001a114cc6c42daa7a0560d9433d--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Thu, 21 Dec 2017 12:58:52 +0000
Raw View
--001a1148e9fc3b311c0560d943a5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On 21 Dec 2017 12:01, "Viacheslav Usov" <via.usov@gmail.com> wrote:
On Thu, Dec 21, 2017 at 11:58 AM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> An implementation is permitted to diagnose certain kinds of UB (typically
"ill-formed NDR") at translation time; it is however not required to (hence
NDR) and so the runtime behavior of such a program is undefined. In all
cases of UB dependent on a runtime condition, the program is required to be
translated and it is the runtime behavior that is undefined.
Quoting 3.27:
undefined behavior
behavior for which this International Standard imposes no requirements
[ Note: Undefined behavior may be expected when this International Standard
omits any explicit definition of
behavior or when a program uses an erroneous construct or erroneous data.
Permissible undefined behavior
ranges from ignoring the situation completely with unpredictable results,
to behaving during translation or
program execution in a documented manner characteristic of the environment
(with or without the issuance
of a diagnostic message), to terminating a translation or execution (with
the issuance of a diagnostic message).
Many erroneous program constructs do not engender undefined behavior; they
are required to be diagnosed.
Evaluation of a constant expression never exhibits behavior explicitly
specified as undefined (8.20). =E2=80=94 end
note ]
To emphasise: "terminating a translation or execution (with the issuance of
a diagnostic message)".
While it can be argued in specific cases that UB can only happen at
runtime, in general it is clearly permitted to have translation-time
effects.
Note also that you restricted the circumstances to "UB dependent on a
runtime condition", while the statement that I responded to was "UB only
happens when you encounter it at runtime", which claims that your
restricted situation is the only situation when UB arises, which is clearly
at odds with the definition above.
I'm not disagreeing with you. In any case, this is irrelevant to the
discussion.
> That's non-conformant. There is no latitude for an implementation to
terminate translation of that function.
Possible. However, it is a fact. Note that MSVC does this only when there
is no return statement at all, if there are some, then it emits a warning.
Quite. Microsoft could have made the latter an error, since they are
already non conformant. However, they did not. Why?
Cheers,
V.
--=20
You received this message because you are subscribed to a topic in the
Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/
isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAA7YVg1T1h1uy9JQqJ7bhPEZwiVU%
3DY04ofHMDZu_vbjhs1UHdQ%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1T1h1u=
y9JQqJ7bhPEZwiVU%3DY04ofHMDZu_vbjhs1UHdQ%40mail.gmail.com?utm_medium=3Demai=
l&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/CAJnLdOatMtLn-B-D3HRWm8cfG_-9WJ8gsa1L1ZQJgpuD4gX=
gmA%40mail.gmail.com.
--001a1148e9fc3b311c0560d943a5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On 21 Dec 2017 12:01, "Viacheslav Usov" <<a href=3D"=
mailto:via.usov@gmail.com">via.usov@gmail.com</a>> wrote:<br type=3D"att=
ribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ext=
ra"><div class=3D"quoted-text"><div class=3D"gmail_quote">On Thu, Dec 21, 2=
017 at 11:58 AM, 'Edward Catmur' via ISO C++ Standard - Future Prop=
osals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@isocpp.org" tar=
get=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:</div><div cla=
ss=3D"gmail_quote"><br></div></div><div class=3D"gmail_quote"><div class=3D=
"quoted-text"><div>> An implementation is permitted to diagnose certain =
kinds of UB (typically "ill-formed NDR") at translation time; it =
is however not required to (hence NDR) and so the runtime behavior of such =
a program is undefined. In all cases of UB dependent on a runtime condition=
, the program is required to be translated and it is the runtime behavior t=
hat is undefined.</div><div><br></div></div><div>Quoting 3.27:</div><div><b=
r></div><div><div>undefined behavior</div><div>behavior for which this Inte=
rnational Standard imposes no requirements</div><div>[ Note: Undefined beha=
vior may be expected when this International Standard omits any explicit de=
finition of</div><div>behavior or when a program uses an erroneous construc=
t or erroneous data. Permissible undefined behavior</div><div>ranges from i=
gnoring the situation completely with unpredictable results, to behaving du=
ring translation or</div><div>program execution in a documented manner char=
acteristic of the environment (with or without the issuance</div><div>of a =
diagnostic message), to terminating a translation or execution (with the is=
suance of a diagnostic message).</div><div>Many erroneous program construct=
s do not engender undefined behavior; they are required to be diagnosed.</d=
iv><div>Evaluation of a constant expression never exhibits behavior explici=
tly specified as undefined (8.20). =E2=80=94 end</div><div>note ]</div></di=
v><div><br></div><div>To emphasise: "terminating a translation or exec=
ution (with the issuance of a diagnostic message)".</div><div><br></di=
v><div>While it can be argued in specific cases that UB can only happen at =
runtime, in general it is clearly permitted to have translation-time effect=
s.</div><div><br></div><div>Note also that you restricted the circumstances=
to "UB dependent on a runtime condition", while the statement th=
at I responded to was "UB only happens when you encounter it at runtim=
e", which claims that your restricted situation is the only situation =
when UB arises, which is clearly at odds with the definition above.</div><d=
iv class=3D"quoted-text"><div></div></div></div></div></div></blockquote></=
div></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">I'm not d=
isagreeing with you. In any case, this is irrelevant to the discussion.=C2=
=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_=
extra"><div class=3D"gmail_quote"><blockquote class=3D"quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"quoted=
-text"><div><br></div><div>> That's non-conformant. There is no lati=
tude for an implementation to terminate translation of that function.<br></=
div><div><br></div></div><div>Possible. However, it is a fact. Note that MS=
VC does this only when there is no return statement at all, if there are so=
me, then it emits a warning.</div><div></div></div></div></div></blockquote=
></div></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">Quite. Mic=
rosoft could have made the latter an error, since they are already non conf=
ormant. However, they did not. Why?=C2=A0</div><div dir=3D"auto"><br></div>=
<div dir=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><bl=
ockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote"><div><br></div><div>Cheers,</div><div>V.</div></div></div=
></div><div class=3D"quoted-text">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/U=
u2QViiWh4k/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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/CAA7YVg1T1h1uy9JQqJ7bhPEZwiVU%3DY04of=
HMDZu_vbjhs1UHdQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/<wbr>CAA7YVg1T1h1uy9JQqJ7bhPEZwiVU%<wbr>3DY04ofHMDZu_vbjhs=
1UHdQ%<wbr>40mail.gmail.com</a>.<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/CAJnLdOatMtLn-B-D3HRWm8cfG_-9WJ8gsa1L=
1ZQJgpuD4gXgmA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOatMtLn-B-D=
3HRWm8cfG_-9WJ8gsa1L1ZQJgpuD4gXgmA%40mail.gmail.com</a>.<br />
--001a1148e9fc3b311c0560d943a5--
.
Author: Ricardo Fabiano de Andrade <ricardofabianodeandrade@gmail.com>
Date: Thu, 21 Dec 2017 08:00:52 -0600
Raw View
--f403045cf78adefe420560da204f
Content-Type: text/plain; charset="UTF-8"
What form of overhead are we talking about here? Longer compile times?
On Wed, Dec 20, 2017 at 5:06 PM 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
>
>
> On 20 Dec 2017 9:29 pm, "Jake Arkinstall" <jake.arkinstall@gmail.com>
> wrote:
>
> Whilst I'm not decided on this (I'm more confused about *some* of the
> moot arguments against it, which is why I am continuing to reply), can we
> please stop imagining that this is halting-problem related? If something
> isn't obvious to the compiler, it (NOT the programmer) can simply add a
> command to the very end.
>
>
> This is what happens currently; the compiler tags those code paths
> unreachable. Unless you're talking about adding overhead, in which case
> this is what happens if you enable the return sanitizer.
>
>
>
> On 20 Dec 2017 21:09, "Myriachan" <myriachan@gmail.com> wrote:
>
> Here's another example:
>
> int meow(unsigned x)
> {
> switch (x % 3)
> {
> case 0:
> return 1;
> case 1:
> case 2:
> return 4;
> }
> }
>
> Would std::unreachable be required somewhere here? A sufficiently-smart
> compiler could deduce that x % 3 can only produce one of three values, but
> in general, this degenerates into the halting problem.
>
>
> int meow(unsigned x)
> {
> switch (x % 3)
> {
> case 0:
> return 1;
> case 1:
> case 2:
> return 4;
> }
> return std::unreachable<int>(); // or whatever it should be. Inserted
> by the compiler.
> }
>
> The last line never gets reached for a well-formed function. In every case
> of a function that does return properly, but there are possibilities
> allowed by the underlying type that have a non-returning path, nothing is
> broken. Whatsoever. Even if this is applied in every function, even one
> with a return on the last line, there is no effect until UB comes into
> play. The halting problem is NOTHING to do with this, because the compiler
> doesn't need to solve it. That argument is complete and utter nonsense.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
>
>
> To post to this group, send email to std-proposals@isocpp.org.
>
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAC%2B0CCNi7-DB%3D3%
> 3DK17EiqhFrVKK6MWdYmb3i4YD3TzazOpAkWA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNi7-DB%3D3%3DK17EiqhFrVKK6MWdYmb3i4YD3TzazOpAkWA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> --
> 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/CAJnLdOa%3DSRR-LNb%
> 2BuHxQAyUZs4nXPiARB68uM8dQ8trrq7JyJQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOa%3DSRR-LNb%2BuHxQAyUZs4nXPiARB68uM8dQ8trrq7JyJQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CA%2BfGSbP4J7Nn5qGcw%3DwzbpZ260p4rX-Dq7b7%3Depy14pNvVnN%2BA%40mail.gmail.com.
--f403045cf78adefe420560da204f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"auto">What form of overhead are we talking abo=
ut here? Longer compile times?</div><div><br><div class=3D"gmail_quote"><di=
v>On Wed, Dec 20, 2017 at 5:06 PM 'Edward Catmur' via ISO C++ Stand=
ard - Future Proposals <<a href=3D"mailto:std-proposals@isocpp.org" targ=
et=3D"_blank">std-proposals@isocpp.org</a>> wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"auto"><div><br><div class=3D"gmail_extra"><b=
r><div class=3D"gmail_quote">On 20 Dec 2017 9:29 pm, "Jake Arkinstall&=
quot; <<a href=3D"mailto:jake.arkinstall@gmail.com" target=3D"_blank">ja=
ke.arkinstall@gmail.com</a>> wrote:<br type=3D"attribution"><blockquote =
class=3D"m_-2483598494274877678m_6173068744702195821quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto">W=
hilst I'm not decided on this (I'm more confused about <i>some</i> =
of the moot arguments against it, which is why I am continuing to reply), c=
an we please stop imagining that this is halting-problem related? If someth=
ing isn't obvious to the compiler, it (NOT the programmer) can simply a=
dd a command to the very end.<div class=3D"m_-2483598494274877678m_61730687=
44702195821quoted-text"></div></div></blockquote></div></div></div><div dir=
=3D"auto"><br></div></div><div dir=3D"auto"><div dir=3D"auto">This is what =
happens currently; the compiler tags those code paths unreachable.=C2=A0 Un=
less you're talking about adding overhead, in which case this is what h=
appens if you enable the return sanitizer.=C2=A0</div><div dir=3D"auto"><br=
></div><div dir=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_quo=
te"><blockquote class=3D"m_-2483598494274877678m_6173068744702195821quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></b=
lockquote></div></div></div></div><div dir=3D"auto"><div dir=3D"auto"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"m_-24=
83598494274877678m_6173068744702195821quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div class=3D"m=
_-2483598494274877678m_6173068744702195821quoted-text"><br><div class=3D"gm=
ail_extra" dir=3D"auto"><br><div class=3D"gmail_quote">On 20 Dec 2017 21:09=
, "Myriachan" <<a href=3D"mailto:myriachan@gmail.com" target=
=3D"_blank">myriachan@gmail.com</a>> wrote:<br type=3D"attribution"><blo=
ckquote class=3D"m_-2483598494274877678m_6173068744702195821m_8553995229919=
921623quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div><div class=3D"m_-2483598494274877678m_6173068744702195821m_8=
553995229919921623quoted-text">Here's another example:</div><div><br></=
div><div>int meow(unsigned x)<br>{</div><div>=C2=A0=C2=A0=C2=A0 switch (x %=
3)</div><div>=C2=A0=C2=A0=C2=A0 {</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 case 0:</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 return 1;</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 case 1:</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 c=
ase 2:</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 return 4;<br></div><div>=C2=A0=C2=A0=C2=A0 }<br></div><div>}</div=
><div><br></div><div>Would std::unreachable be required somewhere here?=C2=
=A0 A sufficiently-smart compiler could deduce that x % 3 can only produce =
one of three values, but in general, this degenerates into the halting prob=
lem.</div></div></blockquote></div></div><div dir=3D"auto"><br></div></div>=
<div dir=3D"auto"><div class=3D"m_-2483598494274877678m_6173068744702195821=
quoted-text"><div style=3D"font-family:sans-serif" dir=3D"auto">int meow(un=
signed x)<br>{</div><div style=3D"font-family:sans-serif" dir=3D"auto">=C2=
=A0=C2=A0=C2=A0 switch (x % 3)</div><div style=3D"font-family:sans-serif" d=
ir=3D"auto">=C2=A0=C2=A0=C2=A0 {</div><div style=3D"font-family:sans-serif"=
dir=3D"auto">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 0:</div><div =
style=3D"font-family:sans-serif" dir=3D"auto">=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return 1;</div><div style=3D"font-f=
amily:sans-serif" dir=3D"auto">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 c=
ase 1:</div><div style=3D"font-family:sans-serif" dir=3D"auto">=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 2:</div><div style=3D"font-family:sans-=
serif" dir=3D"auto">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 return 4;<br></div><div style=3D"font-family:sans-serif" dir=
=3D"auto">=C2=A0 =C2=A0 }<br></div></div><div style=3D"font-family:sans-ser=
if" dir=3D"auto">=C2=A0 =C2=A0 return std::unreachable<int>(); // or =
whatever it should be. Inserted by the compiler.</div><div style=3D"font-fa=
mily:sans-serif" dir=3D"auto">}</div><div style=3D"font-family:sans-serif" =
dir=3D"auto"><br></div><div style=3D"font-family:sans-serif" dir=3D"auto">T=
he last line never gets reached for a well-formed function. In every case o=
f a function that does return properly, but there are possibilities allowed=
by the underlying type that have a non-returning path, nothing is broken. =
Whatsoever. Even if this is applied in every function, even one with a retu=
rn on the last line, there is no effect until UB comes into play. The halti=
ng problem is NOTHING to do with this, because the compiler doesn't nee=
d to solve it. That argument is complete and utter nonsense.</div></div></d=
iv></blockquote></div></div></div></div><div dir=3D"auto"><div dir=3D"auto"=
><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D=
"m_-2483598494274877678m_6173068744702195821quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"m_-2483598494=
274877678m_6173068744702195821quoted-text">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/U=
u2QViiWh4k/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@<wbr>isocpp.org</a>.</div></blockquote></div></div></div>=
</div><div dir=3D"auto"><div dir=3D"auto"><div class=3D"gmail_extra"><div c=
lass=3D"gmail_quote"><blockquote class=3D"m_-2483598494274877678m_617306874=
4702195821quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div class=3D"m_-2483598494274877678m_6173068744702195821quot=
ed-text"><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></blockquote=
></div></div></div></div><div dir=3D"auto"><div dir=3D"auto"><div class=3D"=
gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"m_-24835984942=
74877678m_6173068744702195821quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNi7-DB%3D3%3DK17EiqhFrVKK6MW=
dYmb3i4YD3TzazOpAkWA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgi=
d/std-<wbr>proposals/CAC%2B0CCNi7-DB%3D3%<wbr>3DK17EiqhFrVKK6MWdYmb3i4YD3Tz=
a<wbr>zOpAkWA%40mail.gmail.com</a>.<br>
</blockquote></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" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdOa%3DSRR-LNb%2BuHxQAyUZs4nXPiAR=
B68uM8dQ8trrq7JyJQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/=
std-<wbr>proposals/CAJnLdOa%3DSRR-LNb%<wbr>2BuHxQAyUZs4nXPiARB68uM8dQ8trr<w=
br>q7JyJQ%40mail.gmail.com</a>.<br>
</blockquote></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CA%2BfGSbP4J7Nn5qGcw%3DwzbpZ260p4rX-D=
q7b7%3Depy14pNvVnN%2BA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSb=
P4J7Nn5qGcw%3DwzbpZ260p4rX-Dq7b7%3Depy14pNvVnN%2BA%40mail.gmail.com</a>.<br=
/>
--f403045cf78adefe420560da204f--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Thu, 21 Dec 2017 14:36:22 +0000
Raw View
--f403045e6d8ec9f07c0560da9f36
Content-Type: text/plain; charset="UTF-8"
On 21 Dec 2017 14:00, "Ricardo Fabiano de Andrade" <
ricardofabianodeandrade@gmail.com> wrote:
What form of overhead are we talking about here? Longer compile times?
Runtime overhead, primarily. Increased binary size. Instruction cache
pressure. Branch predictor pressure. Pipeline slots. A branch not taken has
a cost. Also impediment to optimization as succeeding calculations may not
be hoist or inlined as effectively but must be speculatively executed;
admittedly, a sufficiently smart compiler that understands noreturn will be
able to deal with this.
Now, in many cases the cost of a branch to ud2 or int 3 is so tiny as to be
worth it. But not in every case. And the heavier the action taken (call
terminate, throw an exception) the fewer places the increased safety
justifies the cost.
On Wed, Dec 20, 2017 at 5:06 PM 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
>
>
> On 20 Dec 2017 9:29 pm, "Jake Arkinstall" <jake.arkinstall@gmail.com>
> wrote:
>
> Whilst I'm not decided on this (I'm more confused about *some* of the
> moot arguments against it, which is why I am continuing to reply), can we
> please stop imagining that this is halting-problem related? If something
> isn't obvious to the compiler, it (NOT the programmer) can simply add a
> command to the very end.
>
>
> This is what happens currently; the compiler tags those code paths
> unreachable. Unless you're talking about adding overhead, in which case
> this is what happens if you enable the return sanitizer.
>
>
>
> On 20 Dec 2017 21:09, "Myriachan" <myriachan@gmail.com> wrote:
>
> Here's another example:
>
> int meow(unsigned x)
> {
> switch (x % 3)
> {
> case 0:
> return 1;
> case 1:
> case 2:
> return 4;
> }
> }
>
> Would std::unreachable be required somewhere here? A sufficiently-smart
> compiler could deduce that x % 3 can only produce one of three values, but
> in general, this degenerates into the halting problem.
>
>
> int meow(unsigned x)
> {
> switch (x % 3)
> {
> case 0:
> return 1;
> case 1:
> case 2:
> return 4;
> }
> return std::unreachable<int>(); // or whatever it should be. Inserted
> by the compiler.
> }
>
> The last line never gets reached for a well-formed function. In every case
> of a function that does return properly, but there are possibilities
> allowed by the underlying type that have a non-returning path, nothing is
> broken. Whatsoever. Even if this is applied in every function, even one
> with a return on the last line, there is no effect until UB comes into
> play. The halting problem is NOTHING to do with this, because the compiler
> doesn't need to solve it. That argument is complete and utter nonsense.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/is
> ocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
> To unsubscribe from this group and all its topics, 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/is
> ocpp.org/d/msgid/std-proposals/CAC%2B0CCNi7-DB%3D3%3DK17Eiqh
> FrVKK6MWdYmb3i4YD3TzazOpAkWA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNi7-DB%3D3%3DK17EiqhFrVKK6MWdYmb3i4YD3TzazOpAkWA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> --
> 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/is
> ocpp.org/d/msgid/std-proposals/CAJnLdOa%3DSRR-LNb%2BuHxQAyUZ
> s4nXPiARB68uM8dQ8trrq7JyJQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOa%3DSRR-LNb%2BuHxQAyUZs4nXPiARB68uM8dQ8trrq7JyJQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to a topic in the
Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/
isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
To unsubscribe from this group and all its topics, 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/CA%2BfGSbP4J7Nn5qGcw%3DwzbpZ260p4rX-Dq7b7%
3Depy14pNvVnN%2BA%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbP4J7Nn5qGcw%3DwzbpZ260p4rX-Dq7b7%3Depy14pNvVnN%2BA%40mail.gmail.com?utm_medium=email&utm_source=footer>
..
--
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/CAJnLdOa2cxOr9ydwV4twrTTq8cMN%3DLdr5Lz2W7C1rvOn_2X%3DCQ%40mail.gmail.com.
--f403045e6d8ec9f07c0560da9f36
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On 21 Dec 2017 14:00, "Ricardo Fabiano de Andrade" <=
<a href=3D"mailto:ricardofabianodeandrade@gmail.com">ricardofabianodeandrad=
e@gmail.com</a>> wrote:<br type=3D"attribution"><blockquote class=3D"quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div dir=3D"auto">What form of overhead are we talking ab=
out here? Longer compile times?</div><div></div></div></blockquote></div></=
div></div><div dir=3D"auto"><br></div><div dir=3D"auto">Runtime overhead, p=
rimarily. Increased binary size. Instruction cache pressure. Branch predict=
or pressure. Pipeline slots. A branch not taken has a cost. Also impediment=
to optimization as succeeding calculations may not be hoist or inlined as =
effectively but must be speculatively executed; admittedly, a sufficiently =
smart compiler that understands noreturn will be able to deal with this.=C2=
=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">Now, in many cases t=
he cost of a branch to ud2 or int 3 is so tiny as to be worth it. But not i=
n every case. And the heavier the action taken (call terminate, throw an ex=
ception) the fewer places the increased safety justifies the cost.=C2=A0</d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_extra"=
><div class=3D"gmail_quote"><blockquote class=3D"quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=
<br><div class=3D"gmail_quote"><div>On Wed, Dec 20, 2017 at 5:06 PM 'Ed=
ward Catmur' via ISO C++ Standard - Future Proposals <<a href=3D"mai=
lto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a=
>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div=
><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 20 Dec 20=
17 9:29 pm, "Jake Arkinstall" <<a href=3D"mailto:jake.arkinsta=
ll@gmail.com" target=3D"_blank">jake.arkinstall@gmail.com</a>> wrote:<br=
type=3D"attribution"><blockquote class=3D"m_-4559152544975171001m_-2483598=
494274877678m_6173068744702195821quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"auto">Whilst I'm not d=
ecided on this (I'm more confused about <i>some</i> of the moot argumen=
ts against it, which is why I am continuing to reply), can we please stop i=
magining that this is halting-problem related? If something isn't obvio=
us to the compiler, it (NOT the programmer) can simply add a command to the=
very end.<div class=3D"m_-4559152544975171001m_-2483598494274877678m_61730=
68744702195821quoted-text"></div></div></blockquote></div></div></div><div =
dir=3D"auto"><br></div></div><div dir=3D"auto"><div dir=3D"auto">This is wh=
at happens currently; the compiler tags those code paths unreachable.=C2=A0=
Unless you're talking about adding overhead, in which case this is wha=
t happens if you enable the return sanitizer.=C2=A0</div><div dir=3D"auto">=
<br></div><div dir=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_=
quote"><blockquote class=3D"m_-4559152544975171001m_-2483598494274877678m_6=
173068744702195821quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"></blockquote></div></div></div></div><div dir=3D"auto=
"><div dir=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><=
blockquote class=3D"m_-4559152544975171001m_-2483598494274877678m_617306874=
4702195821quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"auto"><div class=3D"m_-4559152544975171001m_-2483=
598494274877678m_6173068744702195821quoted-text"><br><div class=3D"gmail_ex=
tra" dir=3D"auto"><br><div class=3D"gmail_quote">On 20 Dec 2017 21:09, &quo=
t;Myriachan" <<a href=3D"mailto:myriachan@gmail.com" target=3D"_bla=
nk">myriachan@gmail.com</a>> wrote:<br type=3D"attribution"><blockquote =
class=3D"m_-4559152544975171001m_-2483598494274877678m_6173068744702195821m=
_8553995229919921623quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div><div class=3D"m_-4559152544975171001m_-2483598=
494274877678m_6173068744702195821m_8553995229919921623quoted-text">Here'=
;s another example:</div><div><br></div><div>int meow(unsigned x)<br>{</div=
><div>=C2=A0=C2=A0=C2=A0 switch (x % 3)</div><div>=C2=A0=C2=A0=C2=A0 {</div=
><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 0:</div><div>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return 1;</div=
><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 1:</div><div>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 2:</div><div>=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return 4;<br></div><div>=
=C2=A0=C2=A0=C2=A0 }<br></div><div>}</div><div><br></div><div>Would std::un=
reachable be required somewhere here?=C2=A0 A sufficiently-smart compiler c=
ould deduce that x % 3 can only produce one of three values, but in general=
, this degenerates into the halting problem.</div></div></blockquote></div>=
</div><div dir=3D"auto"><br></div></div><div dir=3D"auto"><div class=3D"m_-=
4559152544975171001m_-2483598494274877678m_6173068744702195821quoted-text">=
<div style=3D"font-family:sans-serif" dir=3D"auto">int meow(unsigned x)<br>=
{</div><div style=3D"font-family:sans-serif" dir=3D"auto">=C2=A0=C2=A0=C2=
=A0 switch (x % 3)</div><div style=3D"font-family:sans-serif" dir=3D"auto">=
=C2=A0=C2=A0=C2=A0 {</div><div style=3D"font-family:sans-serif" dir=3D"auto=
">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 0:</div><div style=3D"fon=
t-family:sans-serif" dir=3D"auto">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 return 1;</div><div style=3D"font-family:sans-s=
erif" dir=3D"auto">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 1:</div>=
<div style=3D"font-family:sans-serif" dir=3D"auto">=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 case 2:</div><div style=3D"font-family:sans-serif" dir=
=3D"auto">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 return 4;<br></div><div style=3D"font-family:sans-serif" dir=3D"auto">=
=C2=A0 =C2=A0 }<br></div></div><div style=3D"font-family:sans-serif" dir=3D=
"auto">=C2=A0 =C2=A0 return std::unreachable<int>(); // or whatever i=
t should be. Inserted by the compiler.</div><div style=3D"font-family:sans-=
serif" dir=3D"auto">}</div><div style=3D"font-family:sans-serif" dir=3D"aut=
o"><br></div><div style=3D"font-family:sans-serif" dir=3D"auto">The last li=
ne never gets reached for a well-formed function. In every case of a functi=
on that does return properly, but there are possibilities allowed by the un=
derlying type that have a non-returning path, nothing is broken. Whatsoever=
.. Even if this is applied in every function, even one with a return on the =
last line, there is no effect until UB comes into play. The halting problem=
is NOTHING to do with this, because the compiler doesn't need to solve=
it. That argument is complete and utter nonsense.</div></div></div></block=
quote></div></div></div></div><div class=3D"quoted-text"><div dir=3D"auto">=
<div dir=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><bl=
ockquote class=3D"m_-4559152544975171001m_-2483598494274877678m_61730687447=
02195821quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div class=3D"m_-4559152544975171001m_-2483598494274877678m_617=
3068744702195821quoted-text">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/is<wbr>ocpp.org/d/topic/std-proposals<wbr>/U=
u2QViiWh4k/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isoc<wbr>pp.org</a>.</div></blockquote></div></div></div>=
</div><div dir=3D"auto"><div dir=3D"auto"><div class=3D"gmail_extra"><div c=
lass=3D"gmail_quote"><blockquote class=3D"m_-4559152544975171001m_-24835984=
94274877678m_6173068744702195821quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div class=3D"m_-4559152544975171001m_-=
2483598494274877678m_6173068744702195821quoted-text"><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></blockquote=
></div></div></div></div></div><div dir=3D"auto"><div dir=3D"auto"><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"m_-45591=
52544975171001m_-2483598494274877678m_6173068744702195821quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNi7-DB%3D3%3DK17EiqhFrVKK6MW=
dYmb3i4YD3TzazOpAkWA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgi=
d/std-proposals<wbr>/CAC%2B0CCNi7-DB%3D3%3DK17Eiqh<wbr>FrVKK6MWdYmb3i4YD3Tz=
azOpAkWA%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div></div></div></div><div class=3D"quoted-text">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></div>
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@isoc<wbr>pp.org</a>.<div class=3D"quoted-t=
ext"><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/CAJnLdOa%3DSRR-LNb%2BuHxQAyUZs4nXPiAR=
B68uM8dQ8trrq7JyJQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/=
std-proposals<wbr>/CAJnLdOa%3DSRR-LNb%2BuHxQAyUZ<wbr>s4nXPiARB68uM8dQ8trrq7=
JyJQ%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div></div></div><div class=3D"quoted-text">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/U=
u2QViiWh4k/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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/CA%2BfGSbP4J7Nn5qGcw%3DwzbpZ260p4rX-D=
q7b7%3Depy14pNvVnN%2BA%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/=
msgid/std-<wbr>proposals/CA%<wbr>2BfGSbP4J7Nn5qGcw%<wbr>3DwzbpZ260p4rX-Dq7b=
7%<wbr>3Depy14pNvVnN%2BA%40mail.<wbr>gmail.com</a>.<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/CAJnLdOa2cxOr9ydwV4twrTTq8cMN%3DLdr5L=
z2W7C1rvOn_2X%3DCQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOa2cxOr=
9ydwV4twrTTq8cMN%3DLdr5Lz2W7C1rvOn_2X%3DCQ%40mail.gmail.com</a>.<br />
--f403045e6d8ec9f07c0560da9f36--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Thu, 21 Dec 2017 10:51:37 -0500
Raw View
--f403045f4c8019fabc0560dbae36
Content-Type: text/plain; charset="UTF-8"
On Thu, Dec 21, 2017 at 5:43 AM, Viacheslav Usov <via.usov@gmail.com> wrote:
>
> In my book of the back-stabbingest incompatible changes ever made, the
> implicit noexcept for destructors holds one of the top lines.
>
Nothing is as bad as the change to make narrowing conversions illegal:
char c[] = { 0x01, 0x02, 0xFF };
Compile with clang++ -std=c++03, complete silence.
Compile with clang++ -std=c++11,
1:26: error: constant expression evaluates to 255 which cannot be narrowed
to type 'char' [-Wc++11-narrowing]
char c[] = { 0x01, 0x02, 0xFF };
^~~~
1:26: note: insert an explicit cast to silence this issue
char c[] = { 0x01, 0x02, 0xFF };
^~~~
static_cast<char>( )
1 error generated.
Because that's what I really want to do to my arrays of initialized data
(some generated automatically) - stick casts everywhere into them.
Or undo the messes caused by the helpful souls who see this error and
decide to make the array unsigned char without following through to all
the places that assumed that members of the array could be negative.
How can anyone say with a straight face that backwards compatibility is
a priority of the committee given this?
--
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/CAHSYqdY7jkGMf%3DR7ptu_nq57vE9cdANeSumHofXbCG7bM1fm0Q%40mail.gmail.com.
--f403045f4c8019fabc0560dbae36
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Dec 21, 2017 at 5:43 AM, Viacheslav Usov <span dir=3D"ltr"><<a href=
=3D"mailto:via.usov@gmail.com" target=3D"_blank">via.usov@gmail.com</a>>=
</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D=
"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><div><span=
style=3D"font-size:12.8px">In my book of the back-stabbingest incompatible=
changes ever made, the implicit noexcept for destructors holds one of the =
top lines.</span></div></div></div></div></div></blockquote><div><br>Nothin=
g is as bad as the change to make narrowing conversions illegal:<br><br><fo=
nt face=3D"monospace, monospace">=C2=A0 =C2=A0 char c[] =3D { 0x01, 0x02, 0=
xFF };</font><br><br>Compile with clang++ -std=3Dc++03, complete silence.<b=
r>Compile with clang++ -std=3Dc++11,<br><div><br></div><div><font face=3D"m=
onospace, monospace">1:26: error: constant expression evaluates to 255 whic=
h cannot be narrowed to type 'char' [-Wc++11-narrowing]</font></div=
><div><font face=3D"monospace, monospace">char c[] =3D { 0x01, 0x02, 0xFF }=
;</font></div><div><font face=3D"monospace, monospace">=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^~~~<=
/font></div><div><font face=3D"monospace, monospace">1:26: note: insert an =
explicit cast to silence this issue</font></div><div><font face=3D"monospac=
e, monospace">char c[] =3D { 0x01, 0x02, 0xFF };</font></div><div><font fac=
e=3D"monospace, monospace">=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^~~~</font></div><div><font face=
=3D"monospace, monospace">=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=A0static_cast<char>( )</font><=
/div><div><font face=3D"monospace, monospace">1 error generated.</font><br>=
<br><font face=3D"arial, helvetica, sans-serif">Because that's what I r=
eally want to do to my arrays of initialized data<br>(some generated automa=
tically) - stick casts everywhere into them.</font></div><div><font face=3D=
"arial, helvetica, sans-serif"><br>Or undo the messes caused by the helpful=
souls who see this error and<br>decide to make the array </font><font face=
=3D"monospace, monospace">unsigned char</font><font face=3D"arial, helvetic=
a, sans-serif"> without following through to all<br>the places that assumed=
that members of the array could be negative.<br><br>How can anyone say wit=
h a straight face that backwards compatibility is<br>a priority of the comm=
ittee given this?</font></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/CAHSYqdY7jkGMf%3DR7ptu_nq57vE9cdANeSu=
mHofXbCG7bM1fm0Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdY7jkGMf%=
3DR7ptu_nq57vE9cdANeSumHofXbCG7bM1fm0Q%40mail.gmail.com</a>.<br />
--f403045f4c8019fabc0560dbae36--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 21 Dec 2017 08:13:09 -0800 (PST)
Raw View
------=_Part_5755_1029229523.1513872789654
Content-Type: multipart/alternative;
boundary="----=_Part_5756_2108439305.1513872789654"
------=_Part_5756_2108439305.1513872789654
Content-Type: text/plain; charset="UTF-8"
On Thursday, December 21, 2017 at 10:52:01 AM UTC-5, Hyman Rosen wrote:
>
> How can anyone say with a straight face that backwards compatibility is
> a priority of the committee given this?
>
Because there have been two releases of C++ since then, with no similar
incompatible changes. The pain caused by such changes no doubt influences
the committee to not do that again, much like what happens if you stick
your arm into a wasp nest.
Personally, I defend the `noexcept` change, since there is simply no useful
and correct means to communicate exceptions through destructors.
--
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/e6a828ef-cef4-4c17-9e6a-95d27e4bdf96%40isocpp.org.
------=_Part_5756_2108439305.1513872789654
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, December 21, 2017 at 10:52:01 AM UTC-5, Hyman=
Rosen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote"><div><div><font face=3D"arial, helvetica, s=
ans-serif">How can anyone say with a straight face that backwards compatibi=
lity is<br>a priority of the committee given this?</font></div></div></div>=
</div></div></blockquote><div><br></div><div>Because there have been two re=
leases of C++ since then, with no similar incompatible changes. The pain ca=
used by such changes no doubt influences the committee to not do that again=
, much like what happens if you stick your arm into a wasp nest.</div><div>=
<br></div><div>Personally, I defend the `noexcept` change, since there is s=
imply no useful and correct means to communicate exceptions through destruc=
tors.</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/e6a828ef-cef4-4c17-9e6a-95d27e4bdf96%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e6a828ef-cef4-4c17-9e6a-95d27e4bdf96=
%40isocpp.org</a>.<br />
------=_Part_5756_2108439305.1513872789654--
------=_Part_5755_1029229523.1513872789654--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Thu, 21 Dec 2017 17:28:14 +0100
Raw View
--f4030436096ee3f1130560dc2f22
Content-Type: text/plain; charset="UTF-8"
On Thu, Dec 21, 2017 at 5:13 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> Personally, I defend the `noexcept` change, since there is simply no
useful and correct means to communicate exceptions through destructors.
I am also all for it, yet it is still something that broke things in a very
nasty way. Compared to this, Richard's proposed breakage seems rather mild.
Cheers,
V.
--
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/CAA7YVg0p2cag%3DuZsbgWdiYR5aZutAF-ZSMKrxPGAn1J-%2B5uuQA%40mail.gmail.com.
--f4030436096ee3f1130560dc2f22
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Dec 21, 2017 at 5:13 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></s=
pan> wrote:<br><div><br></div><div>> Personally, I defend the `noexcept`=
change, since there is simply no useful and correct means to communicate e=
xceptions through destructors.</div><div><br></div><div>I am also all for i=
t, yet it is still something that broke things in a very nasty way. Compare=
d to this, Richard's proposed breakage seems rather mild.</div><div><br=
></div><div>Cheers,</div><div>V.</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/CAA7YVg0p2cag%3DuZsbgWdiYR5aZutAF-ZSM=
KrxPGAn1J-%2B5uuQA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0p2cag=
%3DuZsbgWdiYR5aZutAF-ZSMKrxPGAn1J-%2B5uuQA%40mail.gmail.com</a>.<br />
--f4030436096ee3f1130560dc2f22--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Thu, 21 Dec 2017 18:52:22 +0000
Raw View
--001a1147c1384f3eb70560de333c
Content-Type: text/plain; charset="UTF-8"
On 21 Dec 2017 4:28 pm, "Viacheslav Usov" <via.usov@gmail.com> wrote:
On Thu, Dec 21, 2017 at 5:13 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> Personally, I defend the `noexcept` change, since there is simply no
useful and correct means to communicate exceptions through destructors.
I am also all for it, yet it is still something that broke things in a very
nasty way. Compared to this, Richard's proposed breakage seems rather mild.
In my opinion, the rejection of previously valid programs without even a
deprecation step is more likely to hinder the adoption of the new version
of the standard than a behavior change that fails safe and only affects a
tiny fraction of highly specialized uses.
Cheers,
V.
--
You received this message because you are subscribed to a topic in the
Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/
isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAA7YVg0p2cag%3DuZsbgWdiYR5aZutAF-
ZSMKrxPGAn1J-%2B5uuQA%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0p2cag%3DuZsbgWdiYR5aZutAF-ZSMKrxPGAn1J-%2B5uuQA%40mail.gmail.com?utm_medium=email&utm_source=footer>
..
--
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/CAJnLdObJzvE%3DQjkfT5Hz9MO6%3DcT_fbBMQ3_ranx%3D%3Dgo3nUz-Cg%40mail.gmail.com.
--001a1147c1384f3eb70560de333c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On 21 Dec 2017 4:28 pm, "Viacheslav Usov" <<a href=
=3D"mailto:via.usov@gmail.com">via.usov@gmail.com</a>> wrote:<br type=3D=
"attribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail=
_extra"><div class=3D"gmail_quote"><div class=3D"quoted-text">On Thu, Dec 2=
1, 2017 at 5:13 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmc=
kesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></span> wrot=
e:<br><div><br></div><div>> Personally, I defend the `noexcept` change, =
since there is simply no useful and correct means to communicate exceptions=
through destructors.</div><div><br></div></div><div>I am also all for it, =
yet it is still something that broke things in a very nasty way. Compared t=
o this, Richard's proposed breakage seems rather mild.</div><div></div>=
</div></div></div></blockquote></div></div></div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">In my opinion, the rejection of previously valid progra=
ms without even a deprecation step is more likely to hinder the adoption of=
the new version of the standard than a behavior change that fails safe and=
only affects a tiny fraction of highly specialized uses.=C2=A0</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"=
gmail_extra"><div class=3D"gmail_quote"><div><br></div><div>Cheers,</div><d=
iv>V.</div></div></div></div><div class=3D"quoted-text">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/U=
u2QViiWh4k/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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/CAA7YVg0p2cag%3DuZsbgWdiYR5aZutAF-ZSM=
KrxPGAn1J-%2B5uuQA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/=
std-<wbr>proposals/CAA7YVg0p2cag%<wbr>3DuZsbgWdiYR5aZutAF-<wbr>ZSMKrxPGAn1J=
-%2B5uuQA%40mail.<wbr>gmail.com</a>.<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/CAJnLdObJzvE%3DQjkfT5Hz9MO6%3DcT_fbBM=
Q3_ranx%3D%3Dgo3nUz-Cg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObJ=
zvE%3DQjkfT5Hz9MO6%3DcT_fbBMQ3_ranx%3D%3Dgo3nUz-Cg%40mail.gmail.com</a>.<br=
/>
--001a1147c1384f3eb70560de333c--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 21 Dec 2017 18:12:41 -0200
Raw View
On quinta-feira, 21 de dezembro de 2017 14:28:14 -02 Viacheslav Usov wrote:
> On Thu, Dec 21, 2017 at 5:13 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> > Personally, I defend the `noexcept` change, since there is simply no
>
> useful and correct means to communicate exceptions through destructors.
>
> I am also all for it, yet it is still something that broke things in a very
> nasty way. Compared to this, Richard's proposed breakage seems rather mild.
I beg to differ.
Fixing the narrowing, register, auto, digraphs, etc. all had C++03 solutions.
You could convert your codebase to C++11 years before C++11 became supported
in your compiler and you could retain a the same codebase compiling with old
and new compilers.
This one doesn't. If you applied the fix, your code would stop compiling with
older compilers; if you didn't, it would not work with the new ones.
As I said, let's add std::unreachable() and revisit this in 10 years. It may
be acceptable to make the progrm ill-formed then.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/4562564.WoYzNyQr7X%40tjmaciei-mobl1.
.
Author: Erich Keane <erich.keane@verizon.net>
Date: Thu, 21 Dec 2017 14:39:38 -0800 (PST)
Raw View
------=_Part_6510_182566221.1513895979010
Content-Type: multipart/alternative;
boundary="----=_Part_6511_1482229857.1513895979010"
------=_Part_6511_1482229857.1513895979010
Content-Type: text/plain; charset="UTF-8"
Check out -Wno-c++11-narrowing (or -Wno-narrowing if GCC), which explicitly
disable that message. In Clang, it is implemented as a 'warning set as
Werror by default'.
On Thursday, December 21, 2017 at 7:52:01 AM UTC-8, Hyman Rosen wrote:
>
> On Thu, Dec 21, 2017 at 5:43 AM, Viacheslav Usov <via....@gmail.com
> <javascript:>> wrote:
>>
>> In my book of the back-stabbingest incompatible changes ever made, the
>> implicit noexcept for destructors holds one of the top lines.
>>
>
> Nothing is as bad as the change to make narrowing conversions illegal:
>
> char c[] = { 0x01, 0x02, 0xFF };
>
> Compile with clang++ -std=c++03, complete silence.
> Compile with clang++ -std=c++11,
>
> 1:26: error: constant expression evaluates to 255 which cannot be narrowed
> to type 'char' [-Wc++11-narrowing]
> char c[] = { 0x01, 0x02, 0xFF };
> ^~~~
> 1:26: note: insert an explicit cast to silence this issue
> char c[] = { 0x01, 0x02, 0xFF };
> ^~~~
> static_cast<char>( )
> 1 error generated.
>
> Because that's what I really want to do to my arrays of initialized data
> (some generated automatically) - stick casts everywhere into them.
>
> Or undo the messes caused by the helpful souls who see this error and
> decide to make the array unsigned char without following through to all
> the places that assumed that members of the array could be negative.
>
> How can anyone say with a straight face that backwards compatibility is
> a priority of the committee given this?
>
--
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/549cec86-6393-4e9c-ae8d-b86839a7b921%40isocpp.org.
------=_Part_6511_1482229857.1513895979010
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Check out -Wno-c++11-narrowing (or -Wno-narrowing if GCC),=
which explicitly disable that message.=C2=A0 In Clang, it is implemented a=
s a 'warning set as Werror=C2=A0 by default'.<br><br>On Thursday, D=
ecember 21, 2017 at 7:52:01 AM UTC-8, Hyman Rosen wrote:<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"><div><div class=3D"gmail_quote=
">On Thu, Dec 21, 2017 at 5:43 AM, Viacheslav Usov <span dir=3D"ltr"><<a=
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"1U21WcwSBw=
AJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';retur=
n true;" onclick=3D"this.href=3D'javascript:';return true;">via....=
@gmail.com</a>></span> wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div><div><span sty=
le=3D"font-size:12.8px">In my book of the back-stabbingest incompatible cha=
nges ever made, the implicit noexcept for destructors holds one of the top =
lines.</span></div></div></div></div></div></blockquote><div><br>Nothing is=
as bad as the change to make narrowing conversions illegal:<br><br><font f=
ace=3D"monospace, monospace">=C2=A0 =C2=A0 char c[] =3D { 0x01, 0x02, 0xFF =
};</font><br><br>Compile with clang++ -std=3Dc++03, complete silence.<br>Co=
mpile with clang++ -std=3Dc++11,<br><div><br></div><div><font face=3D"monos=
pace, monospace">1:26: error: constant expression evaluates to 255 which ca=
nnot be narrowed to type 'char' [-Wc++11-narrowing]</font></div><di=
v><font face=3D"monospace, monospace">char c[] =3D { 0x01, 0x02, 0xFF };</f=
ont></div><div><font face=3D"monospace, monospace">=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^~~~</fon=
t></div><div><font face=3D"monospace, monospace">1:26: note: insert an expl=
icit cast to silence this issue</font></div><div><font face=3D"monospace, m=
onospace">char c[] =3D { 0x01, 0x02, 0xFF };</font></div><div><font face=3D=
"monospace, monospace">=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^~~~</font></div><div><font face=3D"m=
onospace, monospace">=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=A0static_cast<char>( )</font></di=
v><div><font face=3D"monospace, monospace">1 error generated.</font><br><br=
><font face=3D"arial, helvetica, sans-serif">Because that's what I real=
ly want to do to my arrays of initialized data<br>(some generated automatic=
ally) - stick casts everywhere into them.</font></div><div><font face=3D"ar=
ial, helvetica, sans-serif"><br>Or undo the messes caused by the helpful so=
uls who see this error and<br>decide to make the array </font><font face=3D=
"monospace, monospace">unsigned char</font><font face=3D"arial, helvetica, =
sans-serif"> without following through to all<br>the places that assumed th=
at members of the array could be negative.<br><br>How can anyone say with a=
straight face that backwards compatibility is<br>a priority of the committ=
ee given this?</font></div></div></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/549cec86-6393-4e9c-ae8d-b86839a7b921%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/549cec86-6393-4e9c-ae8d-b86839a7b921=
%40isocpp.org</a>.<br />
------=_Part_6511_1482229857.1513895979010--
------=_Part_6510_182566221.1513895979010--
.
Author: gmisocpp@gmail.com
Date: Thu, 21 Dec 2017 15:15:04 -0800 (PST)
Raw View
------=_Part_6888_982452565.1513898105037
Content-Type: multipart/alternative;
boundary="----=_Part_6889_1532131444.1513898105037"
------=_Part_6889_1532131444.1513898105037
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I'm trying to follow this whole conversation.
It seems to me you are saying at the very least, lets make the code=20
below illegal code. i.e. there is no return statement yet there is a=20
return type.
int foo() {}=20
But apparently, It seems you (Richard) don't have support to make even this=
=20
code above invalid.
Is that really the case?
Can someone (i'll start with you Nicol, but really anyone) clarify if you=
=20
are saying we can't even make this code illegal at a minimum.
I find this hard to believe or appreciate.
If there are things beyond that which get tricky fine, but surely we can=20
acknowledge that Richard has a point that *something* can be improved here.
Because the way I'm reading things it appears people are saying nothing can=
=20
be done which I would imagine would be pretty frustrating for Richard to be=
=20
reading as it is for me.
On Wednesday, December 20, 2017 at 6:52:06 AM UTC+13, Richard Hodges wrote:
> > It ALREADY does return or throw.
>
> I don't think you've been listening.
>
> int foo() {}=20
>
> neither returns anything (of meaning) nor throws. Neither does it inform=
=20
> the compiler that the UB is intended. It is never, ever, ever going to be=
=20
> part of a meaningful program. Any program which calls this function and=
=20
> uses the return value is doomed. It is a non-program. It has become a noi=
se=20
> generator.
>
> Allowing this is like saying, "we're going to allow landmines under the=
=20
> living room carpet, because it optimises the case where we would want to=
=20
> run across the living room not knowing whether we were going to have our=
=20
> legs blown off."
>
> No-one ever wants that.
>
> So let's prevent home-furnishers from inadvertently leaving landmines=20
> under carpets for the sake of finishing the job 10 seconds early...
>
>
>
> On 19 December 2017 at 18:43, Thiago Macieira <thi...@macieira.org=20
> <javascript:>> wrote:
>
>> On ter=C3=A7a-feira, 19 de dezembro de 2017 06:18:45 PST Richard Hodges =
wrote:
>> > So simply make it so from c++20 that a function shall return or throw.=
=20
>> i.e.
>> > programmers shall be honest or their programs shall not compile.
>>
>> It ALREADY does return or throw.
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> Software Architect - Intel Open Source Technology Center
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=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/4561860.0Qv=
KHTRbXI%40tjmaciei-mobl1
>> .
>>
>
>
--=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/d420a677-ae2f-469f-9305-4a9c19d807ef%40isocpp.or=
g.
------=_Part_6889_1532131444.1513898105037
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><br></div><div>I'm trying to follow this whole co=
nversation.</div><div><br></div><div>It seems to me you are saying at the v=
ery least, lets make the code below=C2=A0illegal code. i.e. there is no ret=
urn statement yet there is a return=C2=A0type.</div><div><span style=3D"fon=
t-size: 12.8px;"><font face=3D"monospace, monospace">int foo() {}</font>=C2=
=A0</span></div><p><br></p><div>But apparently, It seems you (Richard) don&=
#39;t=C2=A0have support to make even this code above invalid.</div><div><br=
></div><div>Is that really the case?</div><div>Can=C2=A0someone (i'll s=
tart with you Nicol, but really anyone) clarify if you are saying we can=
9;t even=C2=A0make this code illegal at a minimum.</div><div>I find this ha=
rd to believe or appreciate.</div><div><br></div><div>If there are things b=
eyond that which get tricky fine, but surely we can acknowledge that Richar=
d has a point that *something* can be improved here.</div><div>Because the =
way I'm reading things it appears people are saying nothing can be done=
which I would imagine would be pretty frustrating for Richard to be readin=
g as it is for me.</div><div><br></div><div><br><br>On Wednesday, December =
20, 2017 at 6:52:06 AM UTC+13, Richard Hodges wrote:</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;"><div dir=3D"ltr">>=C2=A0<span style=3D"font-size: 12.8px;">I=
t ALREADY does return or throw.</span><br style=3D"font-size: 12.8px;"><div=
><span style=3D"font-size: 12.8px;"><br></span></div><div><span style=3D"fo=
nt-size: 12.8px;">I don't think you've been listening.</span></div>=
<div><span style=3D"font-size: 12.8px;"><br></span></div><div><span style=
=3D"font-size: 12.8px;"><font face=3D"monospace, monospace">int foo() {}</f=
ont>=C2=A0</span></div><div><span style=3D"font-size: 12.8px;"><br></span><=
/div><div><span style=3D"font-size: 12.8px;">neither returns anything (of m=
eaning) nor throws. Neither does it inform the compiler that the UB is inte=
nded. It is never, ever, ever going to be part of a meaningful program. Any=
program which calls this function and uses the return value is doomed. It =
is a non-program. It has become a noise generator.</span></div><div><span s=
tyle=3D"font-size: 12.8px;"><br></span></div><div><span style=3D"font-size:=
12.8px;">Allowing this is like saying, "we're going to allow land=
mines under the living room carpet, because it optimises the case where we =
would want to run across the living room not knowing whether we were going =
to have our legs blown off."</span></div><div><span style=3D"font-size=
: 12.8px;"><br></span></div><div><span style=3D"font-size: 12.8px;">No-one =
ever wants that.</span></div><div><span style=3D"font-size: 12.8px;"><br></=
span></div><div><span style=3D"font-size: 12.8px;">So let's prevent hom=
e-furnishers from inadvertently leaving landmines under carpets for the sak=
e of finishing the job 10 seconds early...</span></div><div><span style=3D"=
font-size: 12.8px;"><br></span></div><div><span style=3D"font-size: 12.8px;=
"><br></span></div></div><div><br><div class=3D"gmail_quote">On 19 December=
2017 at 18:43, Thiago Macieira <span dir=3D"ltr"><<a onmousedown=3D"thi=
s.href=3D'javascript:';return true;" onclick=3D"this.href=3D'ja=
vascript:';return true;" href=3D"javascript:" target=3D"_blank" rel=3D"=
nofollow" gdf-obfuscated-mailto=3D"R-3xVh9tAgAJ">thi...@macieira.org</a>>=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;"><span>On ter=C3=A7a-feira, =
19 de dezembro de 2017 06:18:45 PST Richard Hodges wrote:<br>
> So simply make it so from c++20 that a function shall return or throw.=
i.e.<br>
> programmers shall be honest or their programs shall not compile.<br>
<br>
</span>It ALREADY does return or throw.<br>
<br>
--<br>
Thiago Macieira - thiago (AT) <a onmousedown=3D"this.href=3D'http://www=
..google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26=
usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"thi=
s.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26=
sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';retu=
rn true;" href=3D"http://macieira.info" target=3D"_blank" rel=3D"nofollow">=
macieira.info</a> - thiago (AT) <a onmousedown=3D"this.href=3D'http://w=
ww.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x2=
6sntz\x3d1\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" =
href=3D"http://kde.org" target=3D"_blank" rel=3D"nofollow">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<span><br>
--<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 onmousedown=3D"this.href=3D'javascript:';return true;" o=
nclick=3D"this.href=3D'javascript:';return true;" href=3D"javascrip=
t:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"R-3xVh9tAgA=
J">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a onmousedown=3D"this.href=3D'jav=
ascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obf=
uscated-mailto=3D"R-3xVh9tAgAJ">std-pr...@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a onmousedown=3D"this.href=
=3D'https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/456186=
0.0QvKHTRbXI%40tjmaciei-mobl1';return true;" onclick=3D"this.href=3D=
9;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4561860.0QvK=
HTRbXI%40tjmaciei-mobl1';return true;" href=3D"https://groups.google.co=
m/a/isocpp.org/d/msgid/std-proposals/4561860.0QvKHTRbXI%40tjmaciei-mobl1" t=
arget=3D"_blank" rel=3D"nofollow">https://groups.google.com/a/<wbr>isocpp.o=
rg/d/msgid/std-<wbr>proposals/4561860.0QvKHTRbXI%<wbr>40tjmaciei-mobl1</a>.=
<br>
</blockquote></div><br></div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/d420a677-ae2f-469f-9305-4a9c19d807ef%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d420a677-ae2f-469f-9305-4a9c19d807ef=
%40isocpp.org</a>.<br />
------=_Part_6889_1532131444.1513898105037--
------=_Part_6888_982452565.1513898105037--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Fri, 22 Dec 2017 01:19:44 +0000
Raw View
--001a11417bc29eb6760560e39c26
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On 21 Dec 2017 11:15 pm, <gmisocpp@gmail.com> wrote:
I'm trying to follow this whole conversation.
It seems to me you are saying at the very least, lets make the code
below illegal code. i.e. there is no return statement yet there is a
return type.
int foo() {}
This code is useful because it can be used in fusion metaprogramming. A
bare declaration would be less useful as it cannot be odr-used and thus can
only be used in pure metaprogramming. It may also arise naturally from
template or macro programming, in which case whether it is valid or not
would depend on the details of the task.
Once we have a way to tag code paths as unreachable we can consider making
that code invalid. But this will take multiple cycles of standard releases.
But apparently, It seems you (Richard) don't have support to make even this
code above invalid.
Is that really the case?
Can someone (i'll start with you Nicol, but really anyone) clarify if you
are saying we can't even make this code illegal at a minimum.
I find this hard to believe or appreciate.
If there are things beyond that which get tricky fine, but surely we can
acknowledge that Richard has a point that *something* can be improved here.
Because the way I'm reading things it appears people are saying nothing can
be done which I would imagine would be pretty frustrating for Richard to be
reading as it is for me.
On Wednesday, December 20, 2017 at 6:52:06 AM UTC+13, Richard Hodges wrote:
> > It ALREADY does return or throw.
>
> I don't think you've been listening.
>
> int foo() {}
>
> neither returns anything (of meaning) nor throws. Neither does it inform
> the compiler that the UB is intended. It is never, ever, ever going to be
> part of a meaningful program. Any program which calls this function and
> uses the return value is doomed. It is a non-program. It has become a noi=
se
> generator.
>
> Allowing this is like saying, "we're going to allow landmines under the
> living room carpet, because it optimises the case where we would want to
> run across the living room not knowing whether we were going to have our
> legs blown off."
>
> No-one ever wants that.
>
> So let's prevent home-furnishers from inadvertently leaving landmines
> under carpets for the sake of finishing the job 10 seconds early...
>
>
>
> On 19 December 2017 at 18:43, Thiago Macieira <thi...@macieira.org> wrote=
:
>
>> On ter=C3=A7a-feira, 19 de dezembro de 2017 06:18:45 PST Richard Hodges =
wrote:
>> > So simply make it so from c++20 that a function shall return or throw.
>> i.e.
>> > programmers shall be honest or their programs shall not compile.
>>
>> It ALREADY does return or throw.
>>
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> Software Architect - Intel Open Source Technology Center
>>
>> --
>>
>> 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/4561860.0QvKHTRbXI%40tjmaciei-mobl1.
>>
>
> --
You received this message because you are subscribed to a topic in the
Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/
isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
To unsubscribe from this group and all its topics, 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/d420a677-ae2f-469f-
9305-4a9c19d807ef%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d420a677-ae2f=
-469f-9305-4a9c19d807ef%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/CAJnLdOYxjOrFt3PNxnhMaEHqDc6Kzg9d9M%2Bv3rhDqXi9z=
f0xmA%40mail.gmail.com.
--001a11417bc29eb6760560e39c26
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On 21 Dec 2017 11:15 pm, <<a href=3D"mailto:gmisocpp@gmail.co=
m">gmisocpp@gmail.com</a>> wrote:<br type=3D"attribution"><blockquote cl=
ass=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div><br></div><div>I'm trying to follow th=
is whole conversation.</div><div><br></div><div>It seems to me you are sayi=
ng at the very least, lets make the code below=C2=A0illegal code. i.e. ther=
e is no return statement yet there is a return=C2=A0type.</div><div><span s=
tyle=3D"font-size:12.8px"><font face=3D"monospace, monospace">int foo() {}<=
/font>=C2=A0</span></div><p></p></div></blockquote></div></div></div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">This code is useful because it can =
be used in fusion metaprogramming. A bare declaration would be less useful =
as it cannot be odr-used and thus can only be used in pure metaprogramming.=
It may also arise naturally from template or macro programming, in which c=
ase whether it is valid or not would depend on the details of the task.=C2=
=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">Once we have a way t=
o tag code paths as unreachable we can consider making that code invalid. B=
ut this will take multiple cycles of standard releases.=C2=A0</div><div dir=
=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><p><br></p><div>=
But apparently, It seems you (Richard) don't=C2=A0have support to make =
even this code above invalid.</div><div><br></div><div>Is that really the c=
ase?</div><div>Can=C2=A0someone (i'll start with you Nicol, but really =
anyone) clarify if you are saying we can't even=C2=A0make this code ill=
egal at a minimum.</div><div>I find this hard to believe or appreciate.</di=
v><div><br></div><div>If there are things beyond that which get tricky fine=
, but surely we can acknowledge that Richard has a point that *something* c=
an be improved here.</div><div>Because the way I'm reading things it ap=
pears people are saying nothing can be done which I would imagine would be =
pretty frustrating for Richard to be reading as it is for me.</div><div><br=
></div><div><br><br>On Wednesday, December 20, 2017 at 6:52:06 AM UTC+13, R=
ichard Hodges wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);bord=
er-left-width:1px;border-left-style:solid"><div dir=3D"ltr">>=C2=A0<span=
style=3D"font-size:12.8px">It ALREADY does return or throw.</span><br styl=
e=3D"font-size:12.8px"><div><span style=3D"font-size:12.8px"><br></span></d=
iv><div><span style=3D"font-size:12.8px">I don't think you've been =
listening.</span></div><div><span style=3D"font-size:12.8px"><br></span></d=
iv><div><span style=3D"font-size:12.8px"><font face=3D"monospace, monospace=
">int foo() {}</font>=C2=A0</span></div><div><span style=3D"font-size:12.8p=
x"><br></span></div><div><span style=3D"font-size:12.8px">neither returns a=
nything (of meaning) nor throws. Neither does it inform the compiler that t=
he UB is intended. It is never, ever, ever going to be part of a meaningful=
program. Any program which calls this function and uses the return value i=
s doomed. It is a non-program. It has become a noise generator.</span></div=
><div><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D=
"font-size:12.8px">Allowing this is like saying, "we're going to a=
llow landmines under the living room carpet, because it optimises the case =
where we would want to run across the living room not knowing whether we we=
re going to have our legs blown off."</span></div><div><span style=3D"=
font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">No=
-one ever wants that.</span></div><div><span style=3D"font-size:12.8px"><br=
></span></div><div><span style=3D"font-size:12.8px">So let's prevent ho=
me-furnishers from inadvertently leaving landmines under carpets for the sa=
ke of finishing the job 10 seconds early...</span></div><div><span style=3D=
"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px"><=
br></span></div></div><div><br><div class=3D"gmail_quote">On 19 December 20=
17 at 18:43, Thiago Macieira <span dir=3D"ltr"><<a rel=3D"nofollow">thi.=
...@macieira.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(20=
4,204,204);border-left-width:1px;border-left-style:solid"><span>On ter=C3=
=A7a-feira, 19 de dezembro de 2017 06:18:45 PST Richard Hodges wrote:<br>
> So simply make it so from c++20 that a function shall return or throw.=
i.e.<br>
> programmers shall be honest or their programs shall not compile.<br>
<br>
</span>It ALREADY does return or throw.<div class=3D"quoted-text"><br>
<br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"nofol=
low" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kd=
e.org" rel=3D"nofollow" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
</div><span><br>
--<div class=3D"quoted-text"><br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/4561860.0QvKHTRbXI%40tjmaciei-=
mobl1" rel=3D"nofollow" target=3D"_blank">https://groups.google.com/a/is<wb=
r>ocpp.org/d/msgid/std-proposals<wbr>/4561860.0QvKHTRbXI%40tjmaciei<wbr>-mo=
bl1</a>.<br>
</blockquote></div><br></div>
</blockquote></div><div class=3D"quoted-text">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/U=
u2QViiWh4k/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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/d420a677-ae2f-469f-9305-4a9c19d807ef%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/d420=
a677-ae2f-469f-<wbr>9305-4a9c19d807ef%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/CAJnLdOYxjOrFt3PNxnhMaEHqDc6Kzg9d9M%2=
Bv3rhDqXi9zf0xmA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYxjOrFt3=
PNxnhMaEHqDc6Kzg9d9M%2Bv3rhDqXi9zf0xmA%40mail.gmail.com</a>.<br />
--001a11417bc29eb6760560e39c26--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Fri, 22 Dec 2017 07:40:09 +0100
Raw View
--001a113fbc088706a30560e8168d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
> This code is useful because it can be used in fusion metaprogramming.
Are you able to provide an example in fusion metaprogramming where this is
useful?
I am of course sceptical but also interested, since it won't compile on
MSVC as we have seen. Wouldn't it need to be some kind of gcc-only fusion
metaprogramming?
Forgive me, but this does not seem like something we are likely to
encounter often.
An example would clarify greatly.
R
On 22 Dec 2017 2:19 am, "'Edward Catmur' via ISO C++ Standard - Future
Proposals" <std-proposals@isocpp.org> wrote:
>
>
> On 21 Dec 2017 11:15 pm, <gmisocpp@gmail.com> wrote:
>
>
> I'm trying to follow this whole conversation.
>
> It seems to me you are saying at the very least, lets make the code
> below illegal code. i.e. there is no return statement yet there is a
> return type.
> int foo() {}
>
>
> This code is useful because it can be used in fusion metaprogramming. A
> bare declaration would be less useful as it cannot be odr-used and thus c=
an
> only be used in pure metaprogramming. It may also arise naturally from
> template or macro programming, in which case whether it is valid or not
> would depend on the details of the task.
>
> Once we have a way to tag code paths as unreachable we can consider makin=
g
> that code invalid. But this will take multiple cycles of standard release=
s.
>
>
> But apparently, It seems you (Richard) don't have support to make even
> this code above invalid.
>
> Is that really the case?
> Can someone (i'll start with you Nicol, but really anyone) clarify if you
> are saying we can't even make this code illegal at a minimum.
> I find this hard to believe or appreciate.
>
> If there are things beyond that which get tricky fine, but surely we can
> acknowledge that Richard has a point that *something* can be improved her=
e.
> Because the way I'm reading things it appears people are saying nothing
> can be done which I would imagine would be pretty frustrating for Richard
> to be reading as it is for me.
>
>
>
> On Wednesday, December 20, 2017 at 6:52:06 AM UTC+13, Richard Hodges wrot=
e:
>
>> > It ALREADY does return or throw.
>>
>> I don't think you've been listening.
>>
>> int foo() {}
>>
>> neither returns anything (of meaning) nor throws. Neither does it inform
>> the compiler that the UB is intended. It is never, ever, ever going to b=
e
>> part of a meaningful program. Any program which calls this function and
>> uses the return value is doomed. It is a non-program. It has become a no=
ise
>> generator.
>>
>> Allowing this is like saying, "we're going to allow landmines under the
>> living room carpet, because it optimises the case where we would want to
>> run across the living room not knowing whether we were going to have our
>> legs blown off."
>>
>> No-one ever wants that.
>>
>> So let's prevent home-furnishers from inadvertently leaving landmines
>> under carpets for the sake of finishing the job 10 seconds early...
>>
>>
>>
>> On 19 December 2017 at 18:43, Thiago Macieira <thi...@macieira.org>
>> wrote:
>>
>>> On ter=C3=A7a-feira, 19 de dezembro de 2017 06:18:45 PST Richard Hodges=
wrote:
>>> > So simply make it so from c++20 that a function shall return or throw=
..
>>> i.e.
>>> > programmers shall be honest or their programs shall not compile.
>>>
>>> It ALREADY does return or throw.
>>>
>>>
>>> --
>>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>> Software Architect - Intel Open Source Technology Center
>>>
>>> --
>>>
>>> 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-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/4561860.0QvKHTRbXI%40tjmaciei-mobl1.
>>>
>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/is
> ocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
> To unsubscribe from this group and all its topics, 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/is
> ocpp.org/d/msgid/std-proposals/d420a677-ae2f-469f-9305-
> 4a9c19d807ef%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d420a677-ae=
2f-469f-9305-4a9c19d807ef%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
>
> --
> 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/CAJnLdOYxjOrFt3PNxnhMaEHqDc6Kz
> g9d9M%2Bv3rhDqXi9zf0xmA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYxjO=
rFt3PNxnhMaEHqDc6Kzg9d9M%2Bv3rhDqXi9zf0xmA%40mail.gmail.com?utm_medium=3Dem=
ail&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/CALvx3havVfO4jtuhUpLmG3r%2BpjcuXPyGFNaGMr4dQ0fxu=
y3rPA%40mail.gmail.com.
--001a113fbc088706a30560e8168d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">>=C2=A0<span style=3D"font-family:sans-serif;font-size=
:12.8px">This code is useful because it can be used in fusion metaprogrammi=
ng.</span><div dir=3D"auto"><span style=3D"font-family:sans-serif;font-size=
:12.8px"><br></span></div><div dir=3D"auto"><span style=3D"font-family:sans=
-serif;font-size:12.8px">Are you able to provide an example in fusion metap=
rogramming where this is useful?</span></div><div dir=3D"auto"><span style=
=3D"font-family:sans-serif;font-size:12.8px"><br></span></div><div dir=3D"a=
uto"><span style=3D"font-family:sans-serif;font-size:12.8px">I am of course=
sceptical but also interested, since it won't compile on MSVC as we ha=
ve seen. Wouldn't it need to be some kind of gcc-only fusion metaprogra=
mming?</span></div><div dir=3D"auto"><span style=3D"font-family:sans-serif;=
font-size:12.8px"><br></span></div><div dir=3D"auto"><span style=3D"font-fa=
mily:sans-serif;font-size:12.8px">Forgive me, but this does not seem like s=
omething we are likely to encounter often.=C2=A0</span></div><div dir=3D"au=
to"><span style=3D"font-family:sans-serif;font-size:12.8px"><br></span></di=
v><div dir=3D"auto"><span style=3D"font-family:sans-serif;font-size:12.8px"=
>An example would clarify greatly.</span></div><div dir=3D"auto"><span styl=
e=3D"font-family:sans-serif;font-size:12.8px"><br></span></div><div dir=3D"=
auto"><span style=3D"font-family:sans-serif;font-size:12.8px">R</span></div=
></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 22 Dec =
2017 2:19 am, "'Edward Catmur' via ISO C++ Standard - Future P=
roposals" <<a href=3D"mailto:std-proposals@isocpp.org">std-proposal=
s@isocpp.org</a>> wrote:<br type=3D"attribution"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div clas=
s=3D"gmail_quote">On 21 Dec 2017 11:15 pm, <<a href=3D"mailto:gmisocpp@=
gmail.com" target=3D"_blank">gmisocpp@gmail.com</a>> wrote:<br type=3D"a=
ttribution"><blockquote class=3D"m_40130494947718652quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv><br></div><div>I'm trying to follow this whole conversation.</div><d=
iv><br></div><div>It seems to me you are saying at the very least, lets mak=
e the code below=C2=A0illegal code. i.e. there is no return statement yet t=
here is a return=C2=A0type.</div><div><span style=3D"font-size:12.8px"><fon=
t face=3D"monospace, monospace">int foo() {}</font>=C2=A0</span></div><p></=
p></div></blockquote></div></div></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">This code is useful because it can be used in fusion metaprogramm=
ing. A bare declaration would be less useful as it cannot be odr-used and t=
hus can only be used in pure metaprogramming. It may also arise naturally f=
rom template or macro programming, in which case whether it is valid or not=
would depend on the details of the task.=C2=A0</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">Once we have a way to tag code paths as unreachable=
we can consider making that code invalid. But this will take multiple cycl=
es of standard releases.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D=
"auto"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote cl=
ass=3D"m_40130494947718652quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><p><br></p><div>But apparent=
ly, It seems you (Richard) don't=C2=A0have support to make even this co=
de above invalid.</div><div><br></div><div>Is that really the case?</div><d=
iv>Can=C2=A0someone (i'll start with you Nicol, but really anyone) clar=
ify if you are saying we can't even=C2=A0make this code illegal at a mi=
nimum.</div><div>I find this hard to believe or appreciate.</div><div><br><=
/div><div>If there are things beyond that which get tricky fine, but surely=
we can acknowledge that Richard has a point that *something* can be improv=
ed here.</div><div>Because the way I'm reading things it appears people=
are saying nothing can be done which I would imagine would be pretty frust=
rating for Richard to be reading as it is for me.</div><div><br></div><div>=
<br><br>On Wednesday, December 20, 2017 at 6:52:06 AM UTC+13, Richard Hodge=
s wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-widt=
h:1px;border-left-style:solid"><div dir=3D"ltr">>=C2=A0<span style=3D"fo=
nt-size:12.8px">It ALREADY does return or throw.</span><br style=3D"font-si=
ze:12.8px"><div><span style=3D"font-size:12.8px"><br></span></div><div><spa=
n style=3D"font-size:12.8px">I don't think you've been listening.</=
span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><spa=
n style=3D"font-size:12.8px"><font face=3D"monospace, monospace">int foo() =
{}</font>=C2=A0</span></div><div><span style=3D"font-size:12.8px"><br></spa=
n></div><div><span style=3D"font-size:12.8px">neither returns anything (of =
meaning) nor throws. Neither does it inform the compiler that the UB is int=
ended. It is never, ever, ever going to be part of a meaningful program. An=
y program which calls this function and uses the return value is doomed. It=
is a non-program. It has become a noise generator.</span></div><div><span =
style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:1=
2.8px">Allowing this is like saying, "we're going to allow landmin=
es under the living room carpet, because it optimises the case where we wou=
ld want to run across the living room not knowing whether we were going to =
have our legs blown off."</span></div><div><span style=3D"font-size:12=
..8px"><br></span></div><div><span style=3D"font-size:12.8px">No-one ever wa=
nts that.</span></div><div><span style=3D"font-size:12.8px"><br></span></di=
v><div><span style=3D"font-size:12.8px">So let's prevent home-furnisher=
s from inadvertently leaving landmines under carpets for the sake of finish=
ing the job 10 seconds early...</span></div><div><span style=3D"font-size:1=
2.8px"><br></span></div><div><span style=3D"font-size:12.8px"><br></span></=
div></div><div><br><div class=3D"gmail_quote">On 19 December 2017 at 18:43,=
Thiago Macieira <span dir=3D"ltr"><<a rel=3D"nofollow">thi...@macieira.=
org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);b=
order-left-width:1px;border-left-style:solid"><span>On ter=C3=A7a-feira, 19=
de dezembro de 2017 06:18:45 PST Richard Hodges wrote:<br>
> So simply make it so from c++20 that a function shall return or throw.=
i.e.<br>
> programmers shall be honest or their programs shall not compile.<br>
<br>
</span>It ALREADY does return or throw.<div class=3D"m_40130494947718652quo=
ted-text"><br>
<br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"nofol=
low" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kd=
e.org" rel=3D"nofollow" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
</div><span><br>
--<div class=3D"m_40130494947718652quoted-text"><br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/4561860.0QvKHTRbXI%40tjmaciei-=
mobl1" rel=3D"nofollow" target=3D"_blank">https://groups.google.com/a/is<wb=
r>ocpp.org/d/msgid/std-proposals<wbr>/4561860.0QvKHTRbXI%40tjmaciei<wbr>-mo=
bl1</a>.<br>
</blockquote></div><br></div>
</blockquote></div><div class=3D"m_40130494947718652quoted-text">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/is<wbr>ocpp.org/d/topic/std-proposals<wbr>/U=
u2QViiWh4k/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isoc<wbr>pp.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/d420a677-ae2f-469f-9305-4a9c19d807ef%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/d420=
a677-ae2f-469f-9305-<wbr>4a9c19d807ef%40isocpp.org</a>.<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" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYxjOrFt3PNxnhMaEHqDc6Kzg9d9M%2=
Bv3rhDqXi9zf0xmA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/<wbr>CAJnLdOYxjOrFt3PNxnhMaEHqDc6Kz<wbr>g9d9M%2Bv3rhDqXi9z=
f0xmA%<wbr>40mail.gmail.com</a>.<br>
</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/CALvx3havVfO4jtuhUpLmG3r%2BpjcuXPyGFN=
aGMr4dQ0fxuy3rPA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3havVfO4jt=
uhUpLmG3r%2BpjcuXPyGFNaGMr4dQ0fxuy3rPA%40mail.gmail.com</a>.<br />
--001a113fbc088706a30560e8168d--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Fri, 22 Dec 2017 10:59:57 +0100
Raw View
--94eb2c065dae13b5370560eae137
Content-Type: text/plain; charset="UTF-8"
On Thu, Dec 21, 2017 at 7:52 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> In my opinion, the rejection of previously valid programs without even a
deprecation step is more likely to hinder the adoption of the new version
of the standard
Did destructors' defaulting to noexcept follow a deprecation step?
> than a behavior change that fails safe and only affects a tiny fraction
of highly specialized uses
"Fails safe" is not how I describe a situation when a program formerly
perfectly able to handle a particular condition crashes in the same
condition after being recompiled. And even after fixing that here, there
and over there, I am unsure whether my entire codebase (including third
party libraries) has more dormant problems of the same kind.
Cheers,
V.
--
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/CAA7YVg03VhHCz_cFPe7Sx6JF0m_jT-Da-59pyF7SJt63r9cM8Q%40mail.gmail.com.
--94eb2c065dae13b5370560eae137
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Dec 21, 2017 at 7:52 PM, 'Edward Catmur' via ISO C++ Standard -=
Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@iso=
cpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:</=
div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">> In=
my opinion, the rejection of previously valid programs without even a depr=
ecation step is more likely to hinder the adoption of the new version of th=
e standard</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_qu=
ote">Did destructors' defaulting to noexcept follow a deprecation step?=
</div><div class=3D"gmail_quote">=C2=A0</div><div class=3D"gmail_quote">>=
; than a behavior change that fails safe and only affects a tiny fraction o=
f highly specialized uses</div><div class=3D"gmail_quote"><br></div><div cl=
ass=3D"gmail_quote">"Fails safe" is not how I describe a situatio=
n when a program formerly perfectly able to handle a particular condition c=
rashes in the same condition after being recompiled. And even after fixing =
that here, there and over there, I am unsure whether my entire codebase (in=
cluding third party libraries) has more dormant problems of the same kind.=
=C2=A0</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"=
>Cheers,</div><div class=3D"gmail_quote">V.</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/CAA7YVg03VhHCz_cFPe7Sx6JF0m_jT-Da-59p=
yF7SJt63r9cM8Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg03VhHCz_cF=
Pe7Sx6JF0m_jT-Da-59pyF7SJt63r9cM8Q%40mail.gmail.com</a>.<br />
--94eb2c065dae13b5370560eae137--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Fri, 22 Dec 2017 11:59:16 +0100
Raw View
--94eb2c065dae3bc1b90560ebb523
Content-Type: text/plain; charset="UTF-8"
On Thu, Dec 21, 2017 at 9:12 PM, Thiago Macieira <thiago@macieira.org>
wrote:
> Fixing the narrowing, register, auto, digraphs, etc. all had C++03
solutions.
> You could convert your codebase to C++11 years before C++11 became
supported in your compiler and you could retain a the same codebase
compiling with old and new compilers.
With respect to destructors' defaulting to noexcept, I am unsure whether my
codebase has been converted to C++11 years *after* C++11 became supported
by my compiler. I *hope* that it has, but my hope is based on some static
analysis runs, that are known to be theoretically unable to answer that
question (halting problem equivalent), and crash statistics. And source
code grepping and eyeballing, for sure, but we all know here how reliable
that is.
Now contrast that with the situation when my source code cannot be compiled
with a new compiler. That is highly unpleasant for sure, but I still have
my old version, and I can do some maintenance using the old compiler, while
fixing broken compilation in the main branch. Or I can create a new branch
just for the purpose of the switchover, and keep using main for regular
development. Either way, my task has a well defined structure, I need to
fix the code that fails to compile, so it is easy to identify, I need to
test the new code, again easy to identify, review the new code (ditto),
repeat if needed, done. I do not have to search for something with
indefinite criteria (halting problem) and ultimately resort to *hoping*.
I am not sure whether you truly understood my intent, it is to show that
the standard has been through horribly incompatible changes, so the
argument "it is horribly backward incompatible, so it won't fly", *alone*,
is not enough to dismiss any proposal.
Cheers,
V.
--
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/CAA7YVg2qdgBTHCCCz%3Dh3wzXUkyWHzcfrdn44pH3QLT%2BHf%3DxKCQ%40mail.gmail.com.
--94eb2c065dae3bc1b90560ebb523
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Dec 21, 2017 at 9:12 PM, Thiago Macieira <span dir=3D"ltr"><<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gm=
ail_quote">> Fixing the narrowing, register, auto, digraphs, etc. all ha=
d C++03 solutions.</div><div class=3D"gmail_quote">> You could convert y=
our codebase to C++11 years before C++11 became supported in your compiler =
and you could retain a the same codebase compiling with old and new compile=
rs.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Wi=
th respect to destructors' defaulting to noexcept, I am unsure whether =
my codebase has been converted to C++11 years <i>after</i>=C2=A0C++11 becam=
e supported by my compiler. I <i>hope</i>=C2=A0that it has, but my hope is =
based on=C2=A0some static analysis runs, that are known to be theoretically=
unable to answer that question (halting problem equivalent), and crash sta=
tistics. And source code grepping and eyeballing, for sure, but we all know=
here how reliable that is.</div><div class=3D"gmail_quote"><br></div><div =
class=3D"gmail_quote">Now contrast that with the situation when my source c=
ode cannot be compiled with a new compiler. That is highly unpleasant for s=
ure, but I still have my old version, and I can do some maintenance using t=
he old compiler, while fixing broken compilation in the main branch. Or I c=
an create a new branch just for the purpose of the switchover, and keep usi=
ng main for regular development. Either way, my task has a well defined str=
ucture, I need to fix the code that fails to compile, so it is easy to iden=
tify, I need to test the new code, again easy to identify, review the new c=
ode (ditto), repeat if needed, done. I do not have to search for something =
with indefinite criteria (halting problem) and ultimately resort to <i>hopi=
ng</i>.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote=
">I am not sure whether you truly understood my intent, it is to show that =
the standard has been through horribly incompatible changes, so the argumen=
t "it is horribly backward incompatible, so it won't fly", <i=
>alone</i>, is not enough to dismiss any proposal.</div><div class=3D"gmail=
_quote"><br></div><div class=3D"gmail_quote">Cheers,</div><div class=3D"gma=
il_quote">V.</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/CAA7YVg2qdgBTHCCCz%3Dh3wzXUkyWHzcfrdn=
44pH3QLT%2BHf%3DxKCQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2qdg=
BTHCCCz%3Dh3wzXUkyWHzcfrdn44pH3QLT%2BHf%3DxKCQ%40mail.gmail.com</a>.<br />
--94eb2c065dae3bc1b90560ebb523--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Fri, 22 Dec 2017 19:50:06 +0000
Raw View
--94eb2c1b54449687c80560f31f8d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Fri, Dec 22, 2017 at 6:40 AM, Richard Hodges <hodges.r@gmail.com> wrote:
> > This code is useful because it can be used in fusion metaprogramming.
>
> Are you able to provide an example in fusion metaprogramming where this i=
s
> useful?
>
For example, one could use such a function template as a type index, prior
to std::type_index being available.
Another case I encountered today was using a pre-C++17 compiler which did
not support if constexpr: in some restricted generic code I needed to take
a particular action only for types satisfying a particular concept:
template<class T>
auto MyClass::foo(T const& value)
{
// .. some code
if (satisfies_predicate<T>::value) // TODO: use if constexpr once we
upgrade to C++17
{
auto const& prop =3D get_property(value);
if (meow(prop) =3D=3D AA)
{
// more code
return some_result;
}
}
// more code
return another_result;
}
Now, get_property must be declared and defined for all T for which
MyClass::foo is instantiated, even though it is only called for those T for
which satisfies_predicate is true. A natural definition for the non-called
overloads of get_property is:
template<class T>
std::enable_if_t<!satisfies_predicate<T>::value, X> get_property(T const&)
{ /* unreachable */ }
where X is a minimal type satisfying the constraints of meow.
Once we have std::unreachable, /* unreachable */ can be fleshed out; but
currently, there is nothing obvious to put there: std::terminate is
overkill, and a throw is unsatisfactory.
> I am of course sceptical but also interested, since it won't compile on
> MSVC as we have seen. Wouldn't it need to be some kind of gcc-only fusion
> metaprogramming?
>
Plenty code only targets gcc or possibly gcc plus clang. Remember that most
code is written for use within an organization, on a single platform, and
never published.
Forgive me, but this does not seem like something we are likely to
> encounter often.
>
> An example would clarify greatly.
>
> R
>
> On 22 Dec 2017 2:19 am, "'Edward Catmur' via ISO C++ Standard - Future
> Proposals" <std-proposals@isocpp.org> wrote:
>
>>
>>
>> On 21 Dec 2017 11:15 pm, <gmisocpp@gmail.com> wrote:
>>
>>
>> I'm trying to follow this whole conversation.
>>
>> It seems to me you are saying at the very least, lets make the code
>> below illegal code. i.e. there is no return statement yet there is a
>> return type.
>> int foo() {}
>>
>>
>> This code is useful because it can be used in fusion metaprogramming. A
>> bare declaration would be less useful as it cannot be odr-used and thus =
can
>> only be used in pure metaprogramming. It may also arise naturally from
>> template or macro programming, in which case whether it is valid or not
>> would depend on the details of the task.
>>
>> Once we have a way to tag code paths as unreachable we can consider
>> making that code invalid. But this will take multiple cycles of standard
>> releases.
>>
>>
>> But apparently, It seems you (Richard) don't have support to make even
>> this code above invalid.
>>
>> Is that really the case?
>> Can someone (i'll start with you Nicol, but really anyone) clarify if yo=
u
>> are saying we can't even make this code illegal at a minimum.
>> I find this hard to believe or appreciate.
>>
>> If there are things beyond that which get tricky fine, but surely we can
>> acknowledge that Richard has a point that *something* can be improved he=
re.
>> Because the way I'm reading things it appears people are saying nothing
>> can be done which I would imagine would be pretty frustrating for Richar=
d
>> to be reading as it is for me.
>>
>>
>>
>> On Wednesday, December 20, 2017 at 6:52:06 AM UTC+13, Richard Hodges
>> wrote:
>>
>>> > It ALREADY does return or throw.
>>>
>>> I don't think you've been listening.
>>>
>>> int foo() {}
>>>
>>> neither returns anything (of meaning) nor throws. Neither does it infor=
m
>>> the compiler that the UB is intended. It is never, ever, ever going to =
be
>>> part of a meaningful program. Any program which calls this function and
>>> uses the return value is doomed. It is a non-program. It has become a n=
oise
>>> generator.
>>>
>>> Allowing this is like saying, "we're going to allow landmines under the
>>> living room carpet, because it optimises the case where we would want t=
o
>>> run across the living room not knowing whether we were going to have ou=
r
>>> legs blown off."
>>>
>>> No-one ever wants that.
>>>
>>> So let's prevent home-furnishers from inadvertently leaving landmines
>>> under carpets for the sake of finishing the job 10 seconds early...
>>>
>>>
>>>
>>> On 19 December 2017 at 18:43, Thiago Macieira <thi...@macieira.org>
>>> wrote:
>>>
>>>> On ter=C3=A7a-feira, 19 de dezembro de 2017 06:18:45 PST Richard Hodge=
s
>>>> wrote:
>>>> > So simply make it so from c++20 that a function shall return or
>>>> throw. i.e.
>>>> > programmers shall be honest or their programs shall not compile.
>>>>
>>>> It ALREADY does return or throw.
>>>>
>>>>
>>>> --
>>>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>>> Software Architect - Intel Open Source Technology Center
>>>>
>>>> --
>>>>
>>>> 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-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/i=
s
>>>> ocpp.org/d/msgid/std-proposals/4561860.0QvKHTRbXI%40tjmaciei-mobl1.
>>>>
>>>
>>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit https://groups.google.com/a/is
>> ocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/is
>> ocpp.org/d/msgid/std-proposals/d420a677-ae2f-469f-9305-4a9c1
>> 9d807ef%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d420a677-a=
e2f-469f-9305-4a9c19d807ef%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>>
>> --
>> 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-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/is
>> ocpp.org/d/msgid/std-proposals/CAJnLdOYxjOrFt3PNxnhMaEHqDc6K
>> zg9d9M%2Bv3rhDqXi9zf0xmA%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYxj=
OrFt3PNxnhMaEHqDc6Kzg9d9M%2Bv3rhDqXi9zf0xmA%40mail.gmail.com?utm_medium=3De=
mail&utm_source=3Dfooter>
>> .
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CALvx3havVfO4jtuhUpLmG3r%
> 2BpjcuXPyGFNaGMr4dQ0fxuy3rPA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3havVf=
O4jtuhUpLmG3r%2BpjcuXPyGFNaGMr4dQ0fxuy3rPA%40mail.gmail.com?utm_medium=3Dem=
ail&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/CAJnLdOYjnq1%3DUO7Quh8tSz%2BDHYxhZ3sKVd8kp0Ax7Fc=
kQyceTg%40mail.gmail.com.
--94eb2c1b54449687c80560f31f8d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Dec 22, 2017 at 6:40 AM, Richard Hodges <span dir=3D"ltr"><<a href=
=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a>>=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div di=
r=3D"auto"><span class=3D"gmail-">>=C2=A0<span style=3D"font-family:sans=
-serif;font-size:12.8px">This code is useful because it can be used in fusi=
on metaprogramming.</span><div dir=3D"auto"><span style=3D"font-family:sans=
-serif;font-size:12.8px"><br></span></div></span><div dir=3D"auto"><span st=
yle=3D"font-family:sans-serif;font-size:12.8px">Are you able to provide an =
example in fusion metaprogramming where this is useful?</span></div></div><=
/blockquote><div><br></div><div>For example, one could use such a function =
template as a type index, prior to std::type_index being available.</div><d=
iv><br></div><div>Another case I encountered today was using a pre-C++17 co=
mpiler which did not support if constexpr: in some restricted generic code =
I needed to take a particular action only for types satisfying a particular=
concept:</div><div><br></div><div><font face=3D"monospace, monospace">temp=
late<class T></font></div><div><font face=3D"monospace, monospace">au=
to MyClass::foo(T const& value)</font></div><div><font face=3D"monospac=
e, monospace">{</font></div><div><font face=3D"monospace, monospace">=C2=A0=
=C2=A0 // .. some code</font></div><div><font face=3D"monospace, monospace=
">=C2=A0 =C2=A0 if (satisfies_predicate<T>::value)=C2=A0 // TODO: use=
if constexpr once we upgrade to C++17</font></div><div><font face=3D"monos=
pace, monospace">=C2=A0 =C2=A0 {</font></div><div><font face=3D"monospace, =
monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto const& prop =3D get_propert=
y(value);</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 if (meow(prop) =3D=3D AA)</font></div><div><font face=3D"=
monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 {</font></div><div><font =
face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // =
more code</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return some_result;</font></div><div><font =
face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 }</font></div><di=
v><font face=3D"monospace, monospace">=C2=A0 =C2=A0 }</font></div><div><fon=
t face=3D"monospace, monospace">=C2=A0 =C2=A0 // more code</font></div><div=
><font face=3D"monospace, monospace">=C2=A0 =C2=A0 return another_result;</=
font></div><div><font face=3D"monospace, monospace">}</font></div><div><br>=
</div><div>Now, get_property must be declared and defined for all T for whi=
ch MyClass::foo is instantiated, even though it is only called for those T =
for which satisfies_predicate is true. A natural definition for the non-cal=
led overloads of get_property is:</div><div><br></div><div><font face=3D"mo=
nospace, monospace">template<class T></font></div><div><font face=3D"=
monospace, monospace">std::enable_if_t<!satisfies_predicate<T>::va=
lue, X> get_property(T const&) { /* unreachable */ }</font></div><di=
v><br></div><div>where X is a minimal type satisfying the constraints of me=
ow.</div><div><br></div><div>Once we have std::unreachable, /* unreachable =
*/ can be fleshed out; but currently, there is nothing obvious to put there=
: std::terminate is overkill, and a throw is unsatisfactory.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"auto=
"><div dir=3D"auto"><span style=3D"font-family:sans-serif;font-size:12.8px"=
></span></div><div dir=3D"auto"><span style=3D"font-family:sans-serif;font-=
size:12.8px">I am of course sceptical but also interested, since it won'=
;t compile on MSVC as we have seen. Wouldn't it need to be some kind of=
gcc-only fusion metaprogramming?</span></div></div></blockquote><div><br><=
/div><div>Plenty code only targets gcc or possibly gcc plus clang. Remember=
that most code is written for use within an organization, on a single plat=
form, and never published.</div><div><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto"><span style=3D"fo=
nt-family:sans-serif;font-size:12.8px"></span></div><div dir=3D"auto"><span=
style=3D"font-family:sans-serif;font-size:12.8px">Forgive me, but this doe=
s not seem like something we are likely to encounter often.=C2=A0</span></d=
iv><div dir=3D"auto"><span style=3D"font-family:sans-serif;font-size:12.8px=
"><br></span></div><div dir=3D"auto"><span style=3D"font-family:sans-serif;=
font-size:12.8px">An example would clarify greatly.</span></div><div dir=3D=
"auto"><span style=3D"font-family:sans-serif;font-size:12.8px"><br></span><=
/div><div dir=3D"auto"><span style=3D"font-family:sans-serif;font-size:12.8=
px">R</span></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_=
quote"><div><div class=3D"gmail-h5">On 22 Dec 2017 2:19 am, "'Edwa=
rd Catmur' via ISO C++ Standard - Future Proposals" <<a href=3D=
"mailto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.or=
g</a>> wrote:<br type=3D"attribution"></div></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex"><div><div class=3D"gmail-h5"><div dir=3D"auto">=
<div><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 21 De=
c 2017 11:15 pm, <<a href=3D"mailto:gmisocpp@gmail.com" target=3D"_blan=
k">gmisocpp@gmail.com</a>> wrote:<br type=3D"attribution"><blockquote cl=
ass=3D"gmail-m_894891227491049220m_40130494947718652quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr"><div><br></div><div>I'm trying to follow this whole co=
nversation.</div><div><br></div><div>It seems to me you are saying at the v=
ery least, lets make the code below=C2=A0illegal code. i.e. there is no ret=
urn statement yet there is a return=C2=A0type.</div><div><span style=3D"fon=
t-size:12.8px"><font face=3D"monospace, monospace">int foo() {}</font>=C2=
=A0</span></div><p></p></div></blockquote></div></div></div><div dir=3D"aut=
o"><br></div><div dir=3D"auto">This code is useful because it can be used i=
n fusion metaprogramming. A bare declaration would be less useful as it can=
not be odr-used and thus can only be used in pure metaprogramming. It may a=
lso arise naturally from template or macro programming, in which case wheth=
er it is valid or not would depend on the details of the task.=C2=A0</div><=
div dir=3D"auto"><br></div><div dir=3D"auto">Once we have a way to tag code=
paths as unreachable we can consider making that code invalid. But this wi=
ll take multiple cycles of standard releases.=C2=A0</div><div dir=3D"auto">=
<br></div><div dir=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_=
quote"><blockquote class=3D"gmail-m_894891227491049220m_40130494947718652qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><div dir=3D"ltr"><p><br></p><div>But apparently, It se=
ems you (Richard) don't=C2=A0have support to make even this code above =
invalid.</div><div><br></div><div>Is that really the case?</div><div>Can=C2=
=A0someone (i'll start with you Nicol, but really anyone) clarify if yo=
u are saying we can't even=C2=A0make this code illegal at a minimum.</d=
iv><div>I find this hard to believe or appreciate.</div><div><br></div><div=
>If there are things beyond that which get tricky fine, but surely we can a=
cknowledge that Richard has a point that *something* can be improved here.<=
/div><div>Because the way I'm reading things it appears people are sayi=
ng nothing can be done which I would imagine would be pretty frustrating fo=
r Richard to be reading as it is for me.</div><div><br></div><div><br><br>O=
n Wednesday, December 20, 2017 at 6:52:06 AM UTC+13, Richard Hodges wrote:<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;pa=
dding-left:1ex;border-left:1px solid rgb(204,204,204)"><div dir=3D"ltr">>=
;=C2=A0<span style=3D"font-size:12.8px">It ALREADY does return or throw.</s=
pan><br style=3D"font-size:12.8px"><div><span style=3D"font-size:12.8px"><b=
r></span></div><div><span style=3D"font-size:12.8px">I don't think you&=
#39;ve been listening.</span></div><div><span style=3D"font-size:12.8px"><b=
r></span></div><div><span style=3D"font-size:12.8px"><font face=3D"monospac=
e, monospace">int foo() {}</font>=C2=A0</span></div><div><span style=3D"fon=
t-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">neith=
er returns anything (of meaning) nor throws. Neither does it inform the com=
piler that the UB is intended. It is never, ever, ever going to be part of =
a meaningful program. Any program which calls this function and uses the re=
turn value is doomed. It is a non-program. It has become a noise generator.=
</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><s=
pan style=3D"font-size:12.8px">Allowing this is like saying, "we'r=
e going to allow landmines under the living room carpet, because it optimis=
es the case where we would want to run across the living room not knowing w=
hether we were going to have our legs blown off."</span></div><div><sp=
an style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-siz=
e:12.8px">No-one ever wants that.</span></div><div><span style=3D"font-size=
:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">So let'=
s prevent home-furnishers from inadvertently leaving landmines under carpet=
s for the sake of finishing the job 10 seconds early...</span></div><div><s=
pan style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-si=
ze:12.8px"><br></span></div></div><div><br><div class=3D"gmail_quote">On 19=
December 2017 at 18:43, Thiago Macieira <span dir=3D"ltr"><<a rel=3D"no=
follow">thi...@macieira.org</a>></span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left:=
1px solid rgb(204,204,204)"><span>On ter=C3=A7a-feira, 19 de dezembro de 20=
17 06:18:45 PST Richard Hodges wrote:<br>
> So simply make it so from c++20 that a function shall return or throw.=
i.e.<br>
> programmers shall be honest or their programs shall not compile.<br>
<br>
</span>It ALREADY does return or throw.<div class=3D"gmail-m_89489122749104=
9220m_40130494947718652quoted-text"><br>
<br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"nofol=
low" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kd=
e.org" rel=3D"nofollow" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
</div><span><br>
--<div class=3D"gmail-m_894891227491049220m_40130494947718652quoted-text"><=
br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/4561860.0QvKHTRbXI%40tjmaciei-=
mobl1" rel=3D"nofollow" target=3D"_blank">https://groups.google.com/a/is<wb=
r>ocpp.org/d/msgid/std-proposals<wbr>/4561860.0QvKHTRbXI%40tjmaciei<wbr>-mo=
bl1</a>.<br>
</blockquote></div><br></div>
</blockquote></div><div class=3D"gmail-m_894891227491049220m_40130494947718=
652quoted-text">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/is<wbr>ocpp.org/d/topic/std-proposals<wbr>/U=
u2QViiWh4k/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isoc<wbr>pp.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/d420a677-ae2f-469f-9305-4a9c19d807ef%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/d420=
a677-ae2f-469f-9305-4a9c1<wbr>9d807ef%40isocpp.org</a>.<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></div></div>
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@isoc<wbr>pp.org</a>.<span class=3D"gmail-"=
><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/CAJnLdOYxjOrFt3PNxnhMaEHqDc6Kzg9d9M%2=
Bv3rhDqXi9zf0xmA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/st=
d-proposals<wbr>/CAJnLdOYxjOrFt3PNxnhMaEHqDc6K<wbr>zg9d9M%2Bv3rhDqXi9zf0xmA=
%40mai<wbr>l.gmail.com</a>.<br>
</blockquote></div></div><span class=3D"gmail-">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/U=
u2QViiWh4k/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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/CALvx3havVfO4jtuhUpLmG3r%2BpjcuXPyGFN=
aGMr4dQ0fxuy3rPA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/<wbr>CALvx3havVfO4jtuhUpLmG3r%<wbr>2BpjcuXPyGFNaGMr4dQ0fxu=
y3rPA%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAJnLdOYjnq1%3DUO7Quh8tSz%2BDHYxhZ3sK=
Vd8kp0Ax7FckQyceTg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYjnq1%=
3DUO7Quh8tSz%2BDHYxhZ3sKVd8kp0Ax7FckQyceTg%40mail.gmail.com</a>.<br />
--94eb2c1b54449687c80560f31f8d--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 22 Dec 2017 12:14:37 -0800 (PST)
Raw View
------=_Part_8854_803961615.1513973677282
Content-Type: multipart/alternative;
boundary="----=_Part_8855_1522670749.1513973677283"
------=_Part_8855_1522670749.1513973677283
Content-Type: text/plain; charset="UTF-8"
On Friday, December 22, 2017 at 5:00:01 AM UTC-5, Viacheslav Usov wrote:
>
> On Thu, Dec 21, 2017 at 7:52 PM, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals <std-pr...@isocpp.org <javascript:>> wrote:
>
> > In my opinion, the rejection of previously valid programs without even a
> deprecation step is more likely to hinder the adoption of the new version
> of the standard
>
> Did destructors' defaulting to noexcept follow a deprecation step?
>
That was not a "rejection of previously valid programs". That was silently
and subtly changing its behavior.
I'm not saying that it's not without consequence. But it is a different
ballpark.
> than a behavior change that fails safe and only affects a tiny fraction
> of highly specialized uses
>
> "Fails safe" is not how I describe a situation when a program formerly
> perfectly able to handle a particular condition crashes in the same
> condition after being recompiled. And even after fixing that here, there
> and over there, I am unsure whether my entire codebase (including third
> party libraries) has more dormant problems of the same kind.
>
If you're unsure of that, then it seems likely that you're unsure of
whether your codebase has the problems that precipitated this change in the
first place. Remember: this was added because you usually* cannot*
reasonably throw exceptions from destructors. Doing so can easily lead to
exception clashes. And therefore, you should only allow destructor
exceptions when you have made sure that clashes can't happen.
If you don't know if you're throwing from destructors, then you probably
don't know if clashes can't happen due to destructor throwing.
>
--
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/a232e555-8ae4-46ec-a083-a66808ef4775%40isocpp.org.
------=_Part_8855_1522670749.1513973677283
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, December 22, 2017 at 5:00:01 AM UTC-5, Viachesl=
av Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div><div class=3D"gmail_quote">On Thu, Dec 21, 2017 at 7:52 PM, 'Edwa=
rd Catmur' via ISO C++ Standard - Future Proposals <span dir=3D"ltr">&l=
t;<a onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;" href=3D"javascript:" ta=
rget=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"ttagxStOBwAJ">std=
-pr...@isocpp.org</a>></span> wrote:</div><div class=3D"gmail_quote"><br=
></div><div class=3D"gmail_quote">> In my opinion, the rejection of prev=
iously valid programs without even a deprecation step is more likely to hin=
der the adoption of the new version of the standard</div><div class=3D"gmai=
l_quote"><br></div><div class=3D"gmail_quote">Did destructors' defaulti=
ng to noexcept follow a deprecation step?</div></div></div></blockquote><di=
v><br></div><div>That was not a "rejection of previously valid program=
s". That was silently and subtly changing its behavior.</div><div><br>=
</div><div>I'm not saying that it's not without consequence. But it=
is a different ballpark.</div><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote">> than =
a behavior change that fails safe and only affects a tiny fraction of highl=
y specialized uses</div><div class=3D"gmail_quote"><br></div><div class=3D"=
gmail_quote">"Fails safe" is not how I describe a situation when =
a program formerly perfectly able to handle a particular condition crashes =
in the same condition after being recompiled. And even after fixing that he=
re, there and over there, I am unsure whether my entire codebase (including=
third party libraries) has more dormant problems of the same kind.=C2=A0</=
div></div></div></blockquote><div><br></div><div>If you're unsure of th=
at, then it seems likely that you're unsure of whether your codebase ha=
s the problems that precipitated this change in the first place. Remember: =
this was added because you usually<i> cannot</i> reasonably throw exception=
s from destructors. Doing so can easily lead to exception clashes. And ther=
efore, you should only allow destructor exceptions when you have made sure =
that clashes can't happen.</div><div><br></div><div>If you don't kn=
ow if you're throwing from destructors, then you probably don't kno=
w if clashes can't happen due to destructor throwing.</div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;">
</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/a232e555-8ae4-46ec-a083-a66808ef4775%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a232e555-8ae4-46ec-a083-a66808ef4775=
%40isocpp.org</a>.<br />
------=_Part_8855_1522670749.1513973677283--
------=_Part_8854_803961615.1513973677282--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Fri, 22 Dec 2017 20:14:42 +0000
Raw View
--001a114b31869b86d20560f3774e
Content-Type: text/plain; charset="UTF-8"
On Fri, Dec 22, 2017 at 10:59 AM, Viacheslav Usov <via.usov@gmail.com>
wrote:
> On Thu, Dec 21, 2017 at 9:12 PM, Thiago Macieira <thiago@macieira.org>
> wrote:
>
> > Fixing the narrowing, register, auto, digraphs, etc. all had C++03
> solutions.
> > You could convert your codebase to C++11 years before C++11 became
> supported in your compiler and you could retain a the same codebase
> compiling with old and new compilers.
>
> With respect to destructors' defaulting to noexcept, I am unsure whether
> my codebase has been converted to C++11 years *after* C++11 became
> supported by my compiler. I *hope* that it has, but my hope is based
> on some static analysis runs, that are known to be theoretically unable to
> answer that question (halting problem equivalent), and crash statistics.
> And source code grepping and eyeballing, for sure, but we all know here how
> reliable that is.
>
> Now contrast that with the situation when my source code cannot be
> compiled with a new compiler. That is highly unpleasant for sure, but I
> still have my old version, and I can do some maintenance using the old
> compiler, while fixing broken compilation in the main branch. Or I can
> create a new branch just for the purpose of the switchover, and keep using
> main for regular development. Either way, my task has a well defined
> structure, I need to fix the code that fails to compile, so it is easy to
> identify, I need to test the new code, again easy to identify, review the
> new code (ditto), repeat if needed, done. I do not have to search for
> something with indefinite criteria (halting problem) and ultimately resort
> to *hoping*.
>
> I am not sure whether you truly understood my intent, it is to show that
> the standard has been through horribly incompatible changes, so the
> argument "it is horribly backward incompatible, so it won't fly", *alone*,
> is not enough to dismiss any proposal.
>
Yes, I understand your position. I hope that you are aware that it is
relatively uncommon to be able to branch for a new compiler and fix
compilation errors, while worrying about crashes introduced by a corner
change to language semantics. Most projects when faced by a sea of errors
from a new compiler will simply refuse to upgrade, meaning that they are
stuck on the old version either of the language or of the compiler and
thereby hold up adoption of the new version of the standard and the
compiler. If they are worrying about behavior changes, it is as likely to
be in undefined behavior which they are (intentionally or otherwise)
relying on, making any compiler upgrade a worry whether or not the language
itself changes semantics.
When assessing the horribleness of a backwards incompatible change, the
overriding criterion is the extent to which the pain it causes will hinder
adoption of the version of standard within which it is introduced, not
whether the pain is justified by the benefit to those who upgrade. There is
no point in creating a marvellous new version of the language if the
community as a whole fails to make the hurdle of upgrading to it.
> Cheers,
> V.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CAA7YVg2qdgBTHCCCz%
> 3Dh3wzXUkyWHzcfrdn44pH3QLT%2BHf%3DxKCQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2qdgBTHCCCz%3Dh3wzXUkyWHzcfrdn44pH3QLT%2BHf%3DxKCQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAJnLdOaws6vpTF6AMatae0toqap-cypBAvasJtUCCTtONfSA%3Dg%40mail.gmail.com.
--001a114b31869b86d20560f3774e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Dec 22, 2017 at 10:59 AM, Viacheslav Usov <span dir=3D"ltr"><=
;<a href=3D"mailto:via.usov@gmail.com" target=3D"_blank">via.usov@gmail.com=
</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><=
div class=3D"gmail_extra"><span class=3D""><div class=3D"gmail_quote">On Th=
u, Dec 21, 2017 at 9:12 PM, Thiago Macieira <span dir=3D"ltr"><<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gm=
ail_quote">> Fixing the narrowing, register, auto, digraphs, etc. all ha=
d C++03 solutions.</div><div class=3D"gmail_quote">> You could convert y=
our codebase to C++11 years before C++11 became supported in your compiler =
and you could retain a the same codebase compiling with old and new compile=
rs.</div><div class=3D"gmail_quote"><br></div></span><div class=3D"gmail_qu=
ote">With respect to destructors' defaulting to noexcept, I am unsure w=
hether my codebase has been converted to C++11 years <i>after</i>=C2=A0C++1=
1 became supported by my compiler. I <i>hope</i>=C2=A0that it has, but my h=
ope is based on=C2=A0some static analysis runs, that are known to be theore=
tically unable to answer that question (halting problem equivalent), and cr=
ash statistics. And source code grepping and eyeballing, for sure, but we a=
ll know here how reliable that is.</div><div class=3D"gmail_quote"><br></di=
v><div class=3D"gmail_quote">Now contrast that with the situation when my s=
ource code cannot be compiled with a new compiler. That is highly unpleasan=
t for sure, but I still have my old version, and I can do some maintenance =
using the old compiler, while fixing broken compilation in the main branch.=
Or I can create a new branch just for the purpose of the switchover, and k=
eep using main for regular development. Either way, my task has a well defi=
ned structure, I need to fix the code that fails to compile, so it is easy =
to identify, I need to test the new code, again easy to identify, review th=
e new code (ditto), repeat if needed, done. I do not have to search for som=
ething with indefinite criteria (halting problem) and ultimately resort to =
<i>hoping</i>.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmai=
l_quote">I am not sure whether you truly understood my intent, it is to sho=
w that the standard has been through horribly incompatible changes, so the =
argument "it is horribly backward incompatible, so it won't fly&qu=
ot;, <i>alone</i>, is not enough to dismiss any proposal.</div></div></div>=
</blockquote><div><br></div><div>Yes, I understand your position. I hope th=
at you are aware that it is relatively uncommon to be able to branch for a =
new compiler and fix compilation errors, while worrying about crashes intro=
duced by a corner change to language semantics. Most projects when faced by=
a sea of errors from a new compiler will simply refuse to upgrade, meaning=
that they are stuck on the old version either of the language or of the co=
mpiler and thereby hold up adoption of the new version of the standard and =
the compiler. If they are worrying about behavior changes, it is as likely =
to be in undefined behavior which they are (intentionally or otherwise) rel=
ying on, making any compiler upgrade a worry whether or not the language it=
self changes semantics.</div><div><br></div><div>When assessing the horribl=
eness of a backwards incompatible change, the overriding criterion is the e=
xtent to which the pain it causes will hinder adoption of the version of st=
andard within which it is introduced, not whether the pain is justified by =
the benefit to those who upgrade. There is no point in creating a marvellou=
s new version of the language if the community as a whole fails to make the=
hurdle of upgrading to it.=C2=A0</div><div><br></div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div=
class=3D"gmail_quote"></div><div class=3D"gmail_quote">Cheers,</div><div c=
lass=3D"gmail_quote">V.</div></div></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/U=
u2QViiWh4k/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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/CAA7YVg2qdgBTHCCCz%3Dh3wzXUkyWHzcfrdn=
44pH3QLT%2BHf%3DxKCQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgi=
d/std-<wbr>proposals/CAA7YVg2qdgBTHCCCz%<wbr>3Dh3wzXUkyWHzcfrdn44pH3QLT%<wb=
r>2BHf%3DxKCQ%40mail.gmail.com</a>.<br>
</blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAJnLdOaws6vpTF6AMatae0toqap-cypBAvas=
JtUCCTtONfSA%3Dg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOaws6vpTF=
6AMatae0toqap-cypBAvasJtUCCTtONfSA%3Dg%40mail.gmail.com</a>.<br />
--001a114b31869b86d20560f3774e--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 22 Dec 2017 12:18:05 -0800 (PST)
Raw View
------=_Part_8941_249635762.1513973885837
Content-Type: multipart/alternative;
boundary="----=_Part_8942_569162276.1513973885837"
------=_Part_8942_569162276.1513973885837
Content-Type: text/plain; charset="UTF-8"
On Friday, December 22, 2017 at 5:59:20 AM UTC-5, Viacheslav Usov wrote:
>
> On Thu, Dec 21, 2017 at 9:12 PM, Thiago Macieira <thi...@macieira.org
> <javascript:>> wrote:
>
> > Fixing the narrowing, register, auto, digraphs, etc. all had C++03
> solutions.
> > You could convert your codebase to C++11 years before C++11 became
> supported in your compiler and you could retain a the same codebase
> compiling with old and new compilers.
>
> With respect to destructors' defaulting to noexcept, I am unsure whether
> my codebase has been converted to C++11 years *after* C++11 became
> supported by my compiler. I *hope* that it has, but my hope is based
> on some static analysis runs, that are known to be theoretically unable to
> answer that question (halting problem equivalent), and crash statistics.
> And source code grepping and eyeballing, for sure, but we all know here how
> reliable that is.
>
But if your code compiles as C++11, then it has been converted to C++11
(modulo compiler bugs). It may not quite have the same meaning as you
expect, but it is still the right language.
The feature under discussion here makes it so that your code either
compiles as C++17 or as C++20, but not both.
>
--
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/4cdb7a4a-cec0-4667-a8e7-9436e9d21bff%40isocpp.org.
------=_Part_8942_569162276.1513973885837
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, December 22, 2017 at 5:59:20 AM UTC-5, =
Viacheslav Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote">On Thu, Dec 21, 2017 at 9:12 PM, T=
hiago Macieira <span dir=3D"ltr"><<a onmousedown=3D"this.href=3D'jav=
ascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obf=
uscated-mailto=3D"xi5lYGhRBwAJ">thi...@macieira.org</a>></span> wrote:</=
div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">> Fi=
xing the narrowing, register, auto, digraphs, etc. all had C++03 solutions.=
</div><div class=3D"gmail_quote">> You could convert your codebase to C+=
+11 years before C++11 became supported in your compiler and you could reta=
in a the same codebase compiling with old and new compilers.</div><div clas=
s=3D"gmail_quote"><br></div><div class=3D"gmail_quote">With respect to dest=
ructors' defaulting to noexcept, I am unsure whether my codebase has be=
en converted to C++11 years <i>after</i>=C2=A0C++11 became supported by my =
compiler. I <i>hope</i>=C2=A0that it has, but my hope is based on=C2=A0some=
static analysis runs, that are known to be theoretically unable to answer =
that question (halting problem equivalent), and crash statistics. And sourc=
e code grepping and eyeballing, for sure, but we all know here how reliable=
that is.</div></div></div></blockquote><div><br></div><div>But if your cod=
e compiles as C++11, then it has been converted to C++11 (modulo compiler b=
ugs). It may not quite have the same meaning as you expect, but it is still=
the right language.</div><div><br></div><div>The feature under discussion =
here makes it so that your code either compiles as C++17 or as C++20, but n=
ot both.</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
</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/4cdb7a4a-cec0-4667-a8e7-9436e9d21bff%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4cdb7a4a-cec0-4667-a8e7-9436e9d21bff=
%40isocpp.org</a>.<br />
------=_Part_8942_569162276.1513973885837--
------=_Part_8941_249635762.1513973885837--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Fri, 22 Dec 2017 23:49:34 +0100
Raw View
--001a1143e71e70167b0560f5a169
Content-Type: text/plain; charset="UTF-8"
> The feature under discussion here makes it so that your code either
compiles as C++17 or as C++20, but not both.
Correction: The feature under discussion here makes it so that your code
either compiles as C++17 on gcc and clang but not MSVC or as C++20 on
everything.
i.e. it makes compiler behaviour more portable and more predictable.
Edward:
The example is pre-c++17 but we are now post-c++17 so there is not need for
hacks such as these anymore.
Can you provide an example where int foo() {} is required to compile in
c++17 and there is no other workaround?
On 22 December 2017 at 21:18, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Friday, December 22, 2017 at 5:59:20 AM UTC-5, Viacheslav Usov wrote:
>>
>> On Thu, Dec 21, 2017 at 9:12 PM, Thiago Macieira <thi...@macieira.org>
>> wrote:
>>
>> > Fixing the narrowing, register, auto, digraphs, etc. all had C++03
>> solutions.
>> > You could convert your codebase to C++11 years before C++11 became
>> supported in your compiler and you could retain a the same codebase
>> compiling with old and new compilers.
>>
>> With respect to destructors' defaulting to noexcept, I am unsure whether
>> my codebase has been converted to C++11 years *after* C++11 became
>> supported by my compiler. I *hope* that it has, but my hope is based
>> on some static analysis runs, that are known to be theoretically unable to
>> answer that question (halting problem equivalent), and crash statistics.
>> And source code grepping and eyeballing, for sure, but we all know here how
>> reliable that is.
>>
>
> But if your code compiles as C++11, then it has been converted to C++11
> (modulo compiler bugs). It may not quite have the same meaning as you
> expect, but it is still the right language.
>
> The feature under discussion here makes it so that your code either
> compiles as C++17 or as C++20, but not both.
>
>> --
> 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/4cdb7a4a-cec0-4667-
> a8e7-9436e9d21bff%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4cdb7a4a-cec0-4667-a8e7-9436e9d21bff%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CALvx3hb2kHKB%3Dr2ZHrKDw6o7r17gOCXLQhrQBNi-YMqW0nB_%2Bg%40mail.gmail.com.
--001a1143e71e70167b0560f5a169
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">The feature und=
er discussion here makes it so that your code either compiles as C++17 or a=
s C++20, but not both.</span><div><span style=3D"font-size:12.8px"><br></sp=
an></div><div><span style=3D"font-size:12.8px">Correction:=C2=A0</span><spa=
n style=3D"font-size:12.8px">The feature under discussion here makes it so =
that your code either compiles as C++17 on gcc and clang but not MSVC or as=
C++20 on everything.</span></div><div><span style=3D"font-size:12.8px"><br=
></span></div><div><span style=3D"font-size:12.8px">i.e. it makes compiler =
behaviour more portable and more predictable.</span></div><div><span style=
=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px=
">Edward:</span></div><div><span style=3D"font-size:12.8px"><br></span></di=
v><div><span style=3D"font-size:12.8px">The example is pre-c++17 but we are=
now post-c++17 so there is not need for hacks such as these anymore.</span=
></div><div><span style=3D"font-size:12.8px"><br></span></div><div><span st=
yle=3D"font-size:12.8px">Can you provide an example where <font face=3D"mon=
ospace, monospace">int foo() {}</font> is required to compile in c++17 and =
there is no other workaround?</span></div><div><span style=3D"font-size:12.=
8px"><br></span></div><div><span style=3D"font-size:12.8px"><br></span></di=
v><div><span style=3D"font-size:12.8px"><br></span></div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On 22 December 2017 at 21:1=
8, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com"=
target=3D"_blank">jmckesson@gmail.com</a>></span> wrote:<br><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><br><br>On Friday, December 22, 2017 a=
t 5:59:20 AM UTC-5, Viacheslav Usov wrote:<span class=3D""><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On=
Thu, Dec 21, 2017 at 9:12 PM, Thiago Macieira <span dir=3D"ltr"><<a rel=
=3D"nofollow">thi...@macieira.org</a>></span> wrote:</div><div class=3D"=
gmail_quote"><br></div><div class=3D"gmail_quote">> Fixing the narrowing=
, register, auto, digraphs, etc. all had C++03 solutions.</div><div class=
=3D"gmail_quote">> You could convert your codebase to C++11 years before=
C++11 became supported in your compiler and you could retain a the same co=
debase compiling with old and new compilers.</div><div class=3D"gmail_quote=
"><br></div><div class=3D"gmail_quote">With respect to destructors' def=
aulting to noexcept, I am unsure whether my codebase has been converted to =
C++11 years <i>after</i>=C2=A0C++11 became supported by my compiler. I <i>h=
ope</i>=C2=A0that it has, but my hope is based on=C2=A0some static analysis=
runs, that are known to be theoretically unable to answer that question (h=
alting problem equivalent), and crash statistics. And source code grepping =
and eyeballing, for sure, but we all know here how reliable that is.</div><=
/div></div></blockquote><div><br></div></span><div>But if your code compile=
s as C++11, then it has been converted to C++11 (modulo compiler bugs). It =
may not quite have the same meaning as you expect, but it is still the righ=
t language.</div><div><br></div><div>The feature under discussion here make=
s it so that your code either compiles as C++17 or as C++20, but not both.<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex">
</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/4cdb7a4a-cec0-4667-a8e7-9436e9d21bff%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/4cdb=
7a4a-cec0-4667-<wbr>a8e7-9436e9d21bff%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/CALvx3hb2kHKB%3Dr2ZHrKDw6o7r17gOCXLQh=
rQBNi-YMqW0nB_%2Bg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hb2kHKB=
%3Dr2ZHrKDw6o7r17gOCXLQhrQBNi-YMqW0nB_%2Bg%40mail.gmail.com</a>.<br />
--001a1143e71e70167b0560f5a169--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Fri, 22 Dec 2017 23:51:15 +0100
Raw View
--001a114aad786f16220560f5a7e8
Content-Type: text/plain; charset="UTF-8"
Edward:
and in fact this function can be expressed another way, by simply deferring
to another template function or function object.
On 22 December 2017 at 23:49, Richard Hodges <hodges.r@gmail.com> wrote:
> > The feature under discussion here makes it so that your code either
> compiles as C++17 or as C++20, but not both.
>
> Correction: The feature under discussion here makes it so that your code
> either compiles as C++17 on gcc and clang but not MSVC or as C++20 on
> everything.
>
> i.e. it makes compiler behaviour more portable and more predictable.
>
> Edward:
>
> The example is pre-c++17 but we are now post-c++17 so there is not need
> for hacks such as these anymore.
>
> Can you provide an example where int foo() {} is required to compile in
> c++17 and there is no other workaround?
>
>
>
>
> On 22 December 2017 at 21:18, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>>
>>
>> On Friday, December 22, 2017 at 5:59:20 AM UTC-5, Viacheslav Usov wrote:
>>>
>>> On Thu, Dec 21, 2017 at 9:12 PM, Thiago Macieira <thi...@macieira.org>
>>> wrote:
>>>
>>> > Fixing the narrowing, register, auto, digraphs, etc. all had C++03
>>> solutions.
>>> > You could convert your codebase to C++11 years before C++11 became
>>> supported in your compiler and you could retain a the same codebase
>>> compiling with old and new compilers.
>>>
>>> With respect to destructors' defaulting to noexcept, I am unsure whether
>>> my codebase has been converted to C++11 years *after* C++11 became
>>> supported by my compiler. I *hope* that it has, but my hope is based
>>> on some static analysis runs, that are known to be theoretically unable to
>>> answer that question (halting problem equivalent), and crash statistics.
>>> And source code grepping and eyeballing, for sure, but we all know here how
>>> reliable that is.
>>>
>>
>> But if your code compiles as C++11, then it has been converted to C++11
>> (modulo compiler bugs). It may not quite have the same meaning as you
>> expect, but it is still the right language.
>>
>> The feature under discussion here makes it so that your code either
>> compiles as C++17 or as C++20, but not both.
>>
>>> --
>> 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/is
>> ocpp.org/d/msgid/std-proposals/4cdb7a4a-cec0-4667-a8e7-
>> 9436e9d21bff%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4cdb7a4a-cec0-4667-a8e7-9436e9d21bff%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
>
--
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/CALvx3hYynssh8KzRqG8oMmd_8TSikoU-vvpxaBs-C3KMMwBSkA%40mail.gmail.com.
--001a114aad786f16220560f5a7e8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Edward:<div><br></div><div>and in fact this function can b=
e expressed another way, by simply deferring to another template function o=
r function object.</div></div><div class=3D"gmail_extra"><br><div class=3D"=
gmail_quote">On 22 December 2017 at 23:49, Richard Hodges <span dir=3D"ltr"=
><<a href=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail=
..com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><span class=3D"">>=C2=A0<span style=3D"font-size:12.8px">The feature =
under discussion here makes it so that your code either compiles as C++17 o=
r as C++20, but not both.</span><div><span style=3D"font-size:12.8px"><br><=
/span></div></span><div><span style=3D"font-size:12.8px">Correction:=C2=A0<=
/span><span style=3D"font-size:12.8px">The feature under discussion here ma=
kes it so that your code either compiles as C++17 on gcc and clang but not =
MSVC or as C++20 on everything.</span></div><div><span style=3D"font-size:1=
2.8px"><br></span></div><div><span style=3D"font-size:12.8px">i.e. it makes=
compiler behaviour more portable and more predictable.</span></div><div><s=
pan style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-si=
ze:12.8px">Edward:</span></div><div><span style=3D"font-size:12.8px"><br></=
span></div><div><span style=3D"font-size:12.8px">The example is pre-c++17 b=
ut we are now post-c++17 so there is not need for hacks such as these anymo=
re.</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div=
><span style=3D"font-size:12.8px">Can you provide an example where <font fa=
ce=3D"monospace, monospace">int foo() {}</font> is required to compile in c=
++17 and there is no other workaround?</span></div><div><span style=3D"font=
-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px"><br></=
span></div><div><span style=3D"font-size:12.8px"><br></span></div></div><di=
v class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><br><div cl=
ass=3D"gmail_quote">On 22 December 2017 at 21:18, Nicol Bolas <span dir=3D"=
ltr"><<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson=
@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><br><br>On Friday, December 22, 2017 at 5:59:20 AM UTC-5, Viachesl=
av Usov wrote:<span><blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div><div class=3D"gmail_quote">On Thu, Dec 21, 2017 at 9:12 PM, Thiago M=
acieira <span dir=3D"ltr"><<a rel=3D"nofollow">thi...@macieira.org</a>&g=
t;</span> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gm=
ail_quote">> Fixing the narrowing, register, auto, digraphs, etc. all ha=
d C++03 solutions.</div><div class=3D"gmail_quote">> You could convert y=
our codebase to C++11 years before C++11 became supported in your compiler =
and you could retain a the same codebase compiling with old and new compile=
rs.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Wi=
th respect to destructors' defaulting to noexcept, I am unsure whether =
my codebase has been converted to C++11 years <i>after</i>=C2=A0C++11 becam=
e supported by my compiler. I <i>hope</i>=C2=A0that it has, but my hope is =
based on=C2=A0some static analysis runs, that are known to be theoretically=
unable to answer that question (halting problem equivalent), and crash sta=
tistics. And source code grepping and eyeballing, for sure, but we all know=
here how reliable that is.</div></div></div></blockquote><div><br></div></=
span><div>But if your code compiles as C++11, then it has been converted to=
C++11 (modulo compiler bugs). It may not quite have the same meaning as yo=
u expect, but it is still the right language.</div><div><br></div><div>The =
feature under discussion here makes it so that your code either compiles as=
C++17 or as C++20, but not both.</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex">
</blockquote></div><span>
<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@isoc<wbr>pp.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/4cdb7a4a-cec0-4667-a8e7-9436e9d21bff%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/4cdb=
7a4a-cec0-4667-a8e7-<wbr>9436e9d21bff%40isocpp.org</a>.<br>
</blockquote></div><br></div>
</div></div></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/CALvx3hYynssh8KzRqG8oMmd_8TSikoU-vvpx=
aBs-C3KMMwBSkA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hYynssh8KzR=
qG8oMmd_8TSikoU-vvpxaBs-C3KMMwBSkA%40mail.gmail.com</a>.<br />
--001a114aad786f16220560f5a7e8--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Fri, 22 Dec 2017 23:32:32 +0000
Raw View
--089e082f832c1dbe110560f63b4f
Content-Type: text/plain; charset="UTF-8"
On Fri, Dec 22, 2017 at 10:51 PM, Richard Hodges <hodges.r@gmail.com> wrote:
> Edward:
>
> and in fact this function can be expressed another way, by simply
> deferring to another template function or function object.
>
That's irrelevant; the question was whether such a function arises
naturally, not whether its use can be avoided via a rewrite.
> On 22 December 2017 at 23:49, Richard Hodges <hodges.r@gmail.com> wrote:
>
>> > The feature under discussion here makes it so that your code either
>> compiles as C++17 or as C++20, but not both.
>>
>> Correction: The feature under discussion here makes it so that your code
>> either compiles as C++17 on gcc and clang but not MSVC or as C++20 on
>> everything.
>>
>> i.e. it makes compiler behaviour more portable and more predictable.
>>
>
Am I to understand from this that you are restricting your proposal to the
case where all code paths fall off the end of the function? That seems
rather unambitious; it would exclude almost any use of a user-defined type,
since very few user-defined operations are marked noexcept.
> Edward:
>>
>> The example is pre-c++17 but we are now post-c++17 so there is not need
>> for hacks such as these anymore.
>>
>
True. However, such code is likely to remain even once C++14 support has
been dropped, which will be not for some time especially for public
software. Most of boost still supports C++03.
>
>> Can you provide an example where int foo() {} is required to compile in
>> c++17 and there is no other workaround?
>>
>
What an odd question. There is always a workaround.
>
>>
>>
>> On 22 December 2017 at 21:18, Nicol Bolas <jmckesson@gmail.com> wrote:
>>
>>>
>>>
>>> On Friday, December 22, 2017 at 5:59:20 AM UTC-5, Viacheslav Usov wrote:
>>>>
>>>> On Thu, Dec 21, 2017 at 9:12 PM, Thiago Macieira <thi...@macieira.org>
>>>> wrote:
>>>>
>>>> > Fixing the narrowing, register, auto, digraphs, etc. all had C++03
>>>> solutions.
>>>> > You could convert your codebase to C++11 years before C++11 became
>>>> supported in your compiler and you could retain a the same codebase
>>>> compiling with old and new compilers.
>>>>
>>>> With respect to destructors' defaulting to noexcept, I am unsure
>>>> whether my codebase has been converted to C++11 years *after* C++11
>>>> became supported by my compiler. I *hope* that it has, but my hope is
>>>> based on some static analysis runs, that are known to be theoretically
>>>> unable to answer that question (halting problem equivalent), and crash
>>>> statistics. And source code grepping and eyeballing, for sure, but we all
>>>> know here how reliable that is.
>>>>
>>>
>>> But if your code compiles as C++11, then it has been converted to C++11
>>> (modulo compiler bugs). It may not quite have the same meaning as you
>>> expect, but it is still the right language.
>>>
>>> The feature under discussion here makes it so that your code either
>>> compiles as C++17 or as C++20, but not both.
>>>
>>>> --
>>> 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/is
>>> ocpp.org/d/msgid/std-proposals/4cdb7a4a-cec0-4667-a8e7-9436e
>>> 9d21bff%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4cdb7a4a-cec0-4667-a8e7-9436e9d21bff%40isocpp.org?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CALvx3hYynssh8KzRqG8oMmd_
> 8TSikoU-vvpxaBs-C3KMMwBSkA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hYynssh8KzRqG8oMmd_8TSikoU-vvpxaBs-C3KMMwBSkA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAJnLdOY1kUvtVM2YZ1_EMR88dmOjXBw9vmnzZojV6_CkAjVJrg%40mail.gmail.com.
--089e082f832c1dbe110560f63b4f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Dec 22, 2017 at 10:51 PM, Richard Hodges <span dir=3D"ltr"><=
<a href=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com<=
/a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Ed=
ward:<div><br></div><div>and in fact this function can be expressed another=
way, by simply deferring to another template function or function object.<=
/div></div></blockquote><div><br></div><div>That's irrelevant; the ques=
tion was whether such a function arises naturally, not whether its use can =
be avoided via a rewrite.</div><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div><div class=3D"h5"><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote">On 22 December 2017 at 23:49, Richard Hodges <span dir=3D"ltr"><<a=
href=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a=
>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><spa=
n>>=C2=A0<span style=3D"font-size:12.8px">The feature under discussion h=
ere makes it so that your code either compiles as C++17 or as C++20, but no=
t both.</span><div><span style=3D"font-size:12.8px"><br></span></div></span=
><div><span style=3D"font-size:12.8px">Correction:=C2=A0</span><span style=
=3D"font-size:12.8px">The feature under discussion here makes it so that yo=
ur code either compiles as C++17 on gcc and clang but not MSVC or as C++20 =
on everything.</span></div><div><span style=3D"font-size:12.8px"><br></span=
></div><div><span style=3D"font-size:12.8px">i.e. it makes compiler behavio=
ur more portable and more predictable.</span></div></div></blockquote></div=
></div></div></div></blockquote><div><br></div><div>Am I to understand from=
this that you are restricting your proposal to the case where all code pat=
hs fall off the end of the function? That seems rather unambitious; it woul=
d exclude almost any use of a user-defined type, since very few user-define=
d operations are marked noexcept.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div><div class=3D"h5"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><span=
style=3D"font-size:12.8px">Edward:</span></div><div><span style=3D"font-si=
ze:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">The examp=
le is pre-c++17 but we are now post-c++17 so there is not need for hacks su=
ch as these anymore.</span></div></div></blockquote></div></div></div></div=
></blockquote><div><br></div><div>True. However, such code is likely to rem=
ain even once C++14 support has been dropped, which will be not for some ti=
me especially for public software. Most of boost still supports C++03.</div=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><di=
v class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div><span style=3D"font-size:12.8px"><br></span></=
div><div><span style=3D"font-size:12.8px">Can you provide an example where =
<font face=3D"monospace, monospace">int foo() {}</font> is required to comp=
ile in c++17 and there is no other workaround?</span></div></div></blockquo=
te></div></div></div></div></blockquote><div><br></div><div>What an odd que=
stion. There is always a workaround.</div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div><div class=3D"h5"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><span=
style=3D"font-size:12.8px"></span></div><div><span style=3D"font-size:12.8=
px"><br></span></div><div><span style=3D"font-size:12.8px"><br></span></div=
></div><div class=3D"m_-1257588038292399970HOEnZb"><div class=3D"m_-1257588=
038292399970h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">O=
n 22 December 2017 at 21:18, Nicol Bolas <span dir=3D"ltr"><<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On F=
riday, December 22, 2017 at 5:59:20 AM UTC-5, Viacheslav Usov wrote:<span><=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"=
gmail_quote">On Thu, Dec 21, 2017 at 9:12 PM, Thiago Macieira <span dir=3D"=
ltr"><<a rel=3D"nofollow">thi...@macieira.org</a>></span> wrote:</div=
><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">> Fixin=
g the narrowing, register, auto, digraphs, etc. all had C++03 solutions.</d=
iv><div class=3D"gmail_quote">> You could convert your codebase to C++11=
years before C++11 became supported in your compiler and you could retain =
a the same codebase compiling with old and new compilers.</div><div class=
=3D"gmail_quote"><br></div><div class=3D"gmail_quote">With respect to destr=
uctors' defaulting to noexcept, I am unsure whether my codebase has bee=
n converted to C++11 years <i>after</i>=C2=A0C++11 became supported by my c=
ompiler. I <i>hope</i>=C2=A0that it has, but my hope is based on=C2=A0some =
static analysis runs, that are known to be theoretically unable to answer t=
hat question (halting problem equivalent), and crash statistics. And source=
code grepping and eyeballing, for sure, but we all know here how reliable =
that is.</div></div></div></blockquote><div><br></div></span><div>But if yo=
ur code compiles as C++11, then it has been converted to C++11 (modulo comp=
iler bugs). It may not quite have the same meaning as you expect, but it is=
still the right language.</div><div><br></div><div>The feature under discu=
ssion here makes it so that your code either compiles as C++17 or as C++20,=
but not both.</div><blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div><span>
<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@isoc<wbr>pp.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/4cdb7a4a-cec0-4667-a8e7-9436e9d21bff%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/4cdb=
7a4a-cec0-4667-a8e7-9436e<wbr>9d21bff%40isocpp.org</a>.<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/U=
u2QViiWh4k/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hYynssh8KzRqG8oMmd_8TSikoU-vvpx=
aBs-C3KMMwBSkA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-=
<wbr>proposals/<wbr>CALvx3hYynssh8KzRqG8oMmd_<wbr>8TSikoU-vvpxaBs-C3KMMwBSk=
A%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAJnLdOY1kUvtVM2YZ1_EMR88dmOjXBw9vmnz=
ZojV6_CkAjVJrg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOY1kUvtVM2Y=
Z1_EMR88dmOjXBw9vmnzZojV6_CkAjVJrg%40mail.gmail.com</a>.<br />
--089e082f832c1dbe110560f63b4f--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 22 Dec 2017 16:26:00 -0800 (PST)
Raw View
------=_Part_9236_1468387511.1513988760261
Content-Type: multipart/alternative;
boundary="----=_Part_9237_1509770736.1513988760261"
------=_Part_9237_1509770736.1513988760261
Content-Type: text/plain; charset="UTF-8"
On Friday, December 22, 2017 at 5:49:37 PM UTC-5, Richard Hodges wrote:
>
> > The feature under discussion here makes it so that your code either
> compiles as C++17 or as C++20, but not both.
>
> Correction: The feature under discussion here makes it so that your code
> either compiles as C++17 on gcc and clang but not MSVC or as C++20 on
> everything.
>
> i.e. it makes compiler behaviour more portable and more predictable.
>
How do you figure?
From the OP and the title of the thread, the feature is essentially "make
programs fail to compile if they do not statically return, throw, call a
`[[noreturn]]` function, or invoke 'unreachable'." That's the feature* as
you defined it*.
This feature has nothing to do with portability. If MSVC is not compiling
legal C++17, then that's its fault, not the standard's.
>
--
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/99066c40-1e2d-490c-b2e4-c7b37e5a3a8f%40isocpp.org.
------=_Part_9237_1509770736.1513988760261
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, December 22, 2017 at 5:49:37 PM UTC-5, Richard =
Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
>=C2=A0<span style=3D"font-size:12.8px">The feature under discussion her=
e makes it so that your code either compiles as C++17 or as C++20, but not =
both.</span><div><span style=3D"font-size:12.8px"><br></span></div><div><sp=
an style=3D"font-size:12.8px">Correction:=C2=A0</span><span style=3D"font-s=
ize:12.8px">The feature under discussion here makes it so that your code ei=
ther compiles as C++17 on gcc and clang but not MSVC or as C++20 on everyth=
ing.</span></div><div><span style=3D"font-size:12.8px"><br></span></div><di=
v><span style=3D"font-size:12.8px">i.e. it makes compiler behaviour more po=
rtable and more predictable.</span></div></div></blockquote><div><br></div>=
<div>How do you figure?</div><div><br></div><div>From the OP and the title =
of the thread, the feature is essentially "make programs fail to compi=
le if they do not statically return, throw, call a `[[noreturn]]` function,=
or invoke 'unreachable'." That's the feature<i> as you de=
fined it</i>.</div><div><br></div><div>This feature has nothing to do with =
portability. If MSVC is not compiling legal C++17, then that's its faul=
t, not the standard's.<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">
</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/99066c40-1e2d-490c-b2e4-c7b37e5a3a8f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/99066c40-1e2d-490c-b2e4-c7b37e5a3a8f=
%40isocpp.org</a>.<br />
------=_Part_9237_1509770736.1513988760261--
------=_Part_9236_1468387511.1513988760261--
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Sat, 23 Dec 2017 00:36:03 +0000
Raw View
--001a113ccab847b5700560f71e0e
Content-Type: text/plain; charset="UTF-8"
Yeah, and that proposal is well and truly down the drain from what I've
seen of this thread.
Are we:
A) in agreement that a std::unreachable is a good evolution of the proposal?
B) if (A), in agreement about the behaviour of std::unreachable - whether
it should cause an abort, branch removal, or it undefined to allow anything
from to branch removal?
C) whether it should have the possibility of a pseudo return type to allow
devs to "return" in all branches from the context of the function alone?
E.g.
T neverUsed(){
return std::unreachable<T>(); //technically returns a T.
}
On 23 Dec 2017 00:26, "Nicol Bolas" <jmckesson@gmail.com> wrote:
> On Friday, December 22, 2017 at 5:49:37 PM UTC-5, Richard Hodges wrote:
>>
>> > The feature under discussion here makes it so that your code either
>> compiles as C++17 or as C++20, but not both.
>>
>> Correction: The feature under discussion here makes it so that your code
>> either compiles as C++17 on gcc and clang but not MSVC or as C++20 on
>> everything.
>>
>> i.e. it makes compiler behaviour more portable and more predictable.
>>
>
> How do you figure?
>
> From the OP and the title of the thread, the feature is essentially "make
> programs fail to compile if they do not statically return, throw, call a
> `[[noreturn]]` function, or invoke 'unreachable'." That's the feature* as
> you defined it*.
>
> This feature has nothing to do with portability. If MSVC is not compiling
> legal C++17, then that's its fault, not the standard's.
>
>> --
> 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/99066c40-1e2d-490c-
> b2e4-c7b37e5a3a8f%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/99066c40-1e2d-490c-b2e4-c7b37e5a3a8f%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNqTNJGRBavNoe6w6-W8CZS%3D%3DPt807Twg6TLS8OvPTouQ%40mail.gmail.com.
--001a113ccab847b5700560f71e0e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">Yeah, and that proposal is well and truly down the drain =
from what I've seen of this thread.<div dir=3D"auto"><br></div><div dir=
=3D"auto">Are we:</div><div dir=3D"auto"><br><div dir=3D"auto">A) in agreem=
ent that a std::unreachable is a good evolution of the proposal?</div><div =
dir=3D"auto"><br></div><div dir=3D"auto">B) if (A), in agreement about the =
behaviour of std::unreachable - whether it should cause an abort, branch re=
moval, or it undefined to allow anything from to branch removal?</div><div =
dir=3D"auto"><br></div><div dir=3D"auto">C) whether it should have the poss=
ibility of a pseudo return type to allow devs to "return" in all =
branches from the context of the function alone? E.g.</div><div dir=3D"auto=
"><br></div><div dir=3D"auto">T neverUsed(){</div><div dir=3D"auto">=C2=A0 =
=C2=A0 return std::unreachable<T>(); //technically returns a T.</div>=
<div dir=3D"auto">}</div></div></div><div class=3D"gmail_extra"><br><div cl=
ass=3D"gmail_quote">On 23 Dec 2017 00:26, "Nicol Bolas" <<a hr=
ef=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>> wrote:<br typ=
e=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Friday=
, December 22, 2017 at 5:49:37 PM UTC-5, Richard Hodges wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr">>=C2=A0<span style=3D"font-s=
ize:12.8px">The feature under discussion here makes it so that your code ei=
ther compiles as C++17 or as C++20, but not both.</span><div><span style=3D=
"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">C=
orrection:=C2=A0</span><span style=3D"font-size:12.8px">The feature under d=
iscussion here makes it so that your code either compiles as C++17 on gcc a=
nd clang but not MSVC or as C++20 on everything.</span></div><div><span sty=
le=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8=
px">i.e. it makes compiler behaviour more portable and more predictable.</s=
pan></div></div></blockquote><div><br></div><div>How do you figure?</div><d=
iv><br></div><div>From the OP and the title of the thread, the feature is e=
ssentially "make programs fail to compile if they do not statically re=
turn, throw, call a `[[noreturn]]` function, or invoke 'unreachable'=
;." That's the feature<i> as you defined it</i>.</div><div><br></d=
iv><div>This feature has nothing to do with portability. If MSVC is not com=
piling legal C++17, then that's its fault, not the standard's.<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex">
</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" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/99066c40-1e2d-490c-b2e4-c7b37e5a3a8f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/9906=
6c40-1e2d-490c-<wbr>b2e4-c7b37e5a3a8f%40isocpp.org</a><wbr>.<br>
</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/CAC%2B0CCNqTNJGRBavNoe6w6-W8CZS%3D%3D=
Pt807Twg6TLS8OvPTouQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNq=
TNJGRBavNoe6w6-W8CZS%3D%3DPt807Twg6TLS8OvPTouQ%40mail.gmail.com</a>.<br />
--001a113ccab847b5700560f71e0e--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 22 Dec 2017 23:14:05 -0200
Raw View
On sexta-feira, 22 de dezembro de 2017 07:59:57 -02 Viacheslav Usov wrote:
> Did destructors' defaulting to noexcept follow a deprecation step?
Kinda.
Throwing from a destructor while unwinding was already a no-go, so throwing
from destructors was practically deprecated.
In any case, there was no other deprecation step to be taken, since there's no
noexcept(maybe).
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/7044484.vyLHDBfxLV%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 22 Dec 2017 23:15:38 -0200
Raw View
On sexta-feira, 22 de dezembro de 2017 08:59:16 -02 Viacheslav Usov wrote:
> I am not sure whether you truly understood my intent, it is to show that
> the standard has been through horribly incompatible changes, so the
> argument "it is horribly backward incompatible, so it won't fly", *alone*,
> is not enough to dismiss any proposal.
I understand your argument, but having failed once is not a reason to accept
failure again. You are completely right when it comes to silent breakage and
that we should avoid it and should have avoided it in cases where we did, if
possible.
But see other email: I'm not sure there was anything we could do.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/5630885.K5WDNVBW87%40tjmaciei-mobl1.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 19 Dec 2017 11:48:36 -0500
Raw View
On 2017-12-19 11:15, Ren Industries wrote:
>> This is nonsense. I have provided a proposal on expressing the intent to
>> not provide a return statement. You would have the same optimisation
>> opportunities that you enjoy today.
>
> Right, which I now need to transform hundreds to thousands of lines of code
> to use. No.
If you compile your code with -Wreturn-type, does that warning pop up
hundreds to thousands of times? If not, then no, you would not need to
transform large amounts of code.
(If yes, I would be deeply concerned to use your code, frankly...)
>> No-one is arguing that you have to have any throw logic.
>
> It was mentioned several times in this thread. I don't exactly see how else
> you are going to enforce these constraints at runtime otherwise.
Who said anything about *enforcing*? If you want the compiler to trust
you that execution will never fall off the end of a function, you stick
`[[unreachable]]` at the end to tell it to do so. If execution ever does
get there, you're back in UB land, as today.
Throwing is one of the three ways to avoid falling off the end of a
function. It's been mentioned in *that* context several times.
--
Matthew
--
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/p1bgu9%24qkj%241%40blaine.gmane.org.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 19 Dec 2017 11:23:13 -0500
Raw View
On 2017-12-19 08:48, Nicol Bolas wrote:
> On Tuesday, December 19, 2017 at 8:44:32 AM UTC-5, Richard Hodges wrote:
>> On Tuesday, 19 December 2017 14:41:33 UTC+1, Nicol Bolas wrote:
>>> So, what do you return in return statements that will* never be reached*?
>>> If the return type is not default-constructible, what can you return?
>>
>> I've already covered this. You don't return anything, but you tell the
>> compiler to trust you.
>
> How? With what? You can't use an attribute, as an attribute cannot make an
> ill-formed program well-formed.
At some level, I think this should be considered QoI. However, it would
indeed be nice if the standard would change to make this ill-formed;
mostly because such a change might finally convince compiler vendors
that they shouldn't be lenient about this mistake.
How do you cover this for "hard" cases? Like this:
T foo(...)
{
// code that will "always" return but the compiler can't tell
[[unreachable]] std::abort();
}
With the proposed change, this code is still well-formed. As a QoI,
compilers should be allowed to elide the call to std::abort given the
annotation that execution will never reach it. (This negates the
argument that the change necessarily "pessimizes" code.) It also forces
coders to express these sorts of situations in a way that is clear to a
reader of the code.
Critically, however, it makes *this* code ill-formed:
T bar(...)
{
// some code, and oops, I forgot the 'return'
}
....which compilers *already detect*, but which vendors refuse to make an
error by default.
(And, yes, I compile pretty much all C++ code I build with
-Werror=return-type. I have yet to experience a false positive. Given
that this catches egregious but easy to make mistakes, it is a travesty
that it is not the *default* behavior.)
--
Matthew
--
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/p1be9n%24oa2%241%40blaine.gmane.org.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 19 Dec 2017 11:24:33 -0500
Raw View
On 2017-12-19 09:18, Richard Hodges wrote:
> Back to attributes...
>
> What are they really? They're new keywords that the c++ committee felt too
> timid to enforce on compiler writers.
They're also new keywords that are *forwards compatible*. I can write:
switch (...)
{
...
[[fallthrough]]
...
}
....and a C++11 compiler will happily compile it, despite that I used a
"new keyword" that does not exist until C++17.
That said, I think there is some merit to the argument for allowing
[[unreachable]] to be required to make a program well-formed as of C++X,
since it would only be ill-formed due to a change that was also
introduced in C++X. If the compiler does not implement C++X, then it
doesn't matter that it doesn't implement [[unreachable]] with this new
ability, because it also doesn't implement ill-formedness due to a
function that falls off the end without returning.
(I would expect 'C++X' here means C++20; the point is more that all this
is happening in a single revision of the standard, whatever revision
that happens to be.)
Besides, it's not the end of the world if a compiler just doesn't
implement any of this. It would still compile conforming programs just
fine, it just loses the chance to diagnose broken programs. Compilers
have a long history of compiling non-conforming programs, and folks
generally do not complain about it.
> So simply make it so from c++20 that a function shall return or
> throw.
....or shall call a [[noreturn]] function. (Which, incidentally, is
another way in which an attribute would influence well-formedness...)
--
Matthew
--
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/p1bec6%24oa2%242%40blaine.gmane.org.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 19 Dec 2017 11:41:35 -0500
Raw View
On 2017-12-19 09:39, Nicol Bolas wrote:
> This is what we call a breaking change. So named because it breaks people's
> perfectly functioning code.
Really?
Such code has Undefined Behavior.
As you'll recall, we used to compile code like `if (x > x + 1)` to do
what people thought it "ought" to do. But we were perfectly content to
leverage the fact that that is UB to "break" such code.
Why should this change be any different?
It's not like it's hard to "repair" code that fails to compile due to
this change... just stick `[[unreachable]]` at the end of the function
and pray it really is. Worst case, your code continues to have UB.
> Breaking people's code is not good. It's doubly not good to do so without
> fair warning. It's triply not good to do so for so little *genuine* gain.
I will happily argue that having compilers actually prevent people from
writing broken code in the form of functions which are supposed to
return and don't, of which I've seen a handful, constitutes genuine gain.
We're not talking about breaking *good* code. We're talking about
refusing to compile code that is most definitely bad.
(Note: if we make a change, I would recommend that it be 'ill formed,
NDR'. As QoI, compilers should only squawk if they are "confident" the
code falls off the end of the function. This puts the onus on compiler
vendors to work out with their customers a reasonable balance of
squawking at "definitely bad" code vs. "possibly good" code. If the
compiler can't decide, it can compile the code anyway, exactly as they
would today, as a non-conforming extension.)
....and saying we don't have "fair warning" seems disingenuous;
-Wreturn-type has been around for some time.
> This will not make anyone's code one iota faster or easier to write.
No, but it *will* stop people from writing broken code.
This is *not* hypothetical. I've seen real, non-"toy" code, on more than
one occasion, that was broken because someone forgot a `return`. (I'm
pretty sure I've even written such code, although, because I *always*
compile with -Werror=return-type, I've caught the times *I* made such
mistakes before anything got committed.)
--
Matthew
--
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/p1bfc4%24u5e%241%40blaine.gmane.org.
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Thu, 21 Dec 2017 13:17:51 +0000
Raw View
--089e08280284fb69b00560d98659
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Thu, Dec 21, 2017 at 12:16 PM, Richard Hodges <hodges.r@gmail.com> wrote=
:
> >> We all write our code to be as portable as possible, don't we?
> > No
>
> Well that, if may say, seems a little unwise, nevertheless moving on...
>
> > We have projects that are specifically *not* targeted at Windows,
> because their environment is, very explicitly, Linux
>
> So do many others, including my firm. Plus projects targeting iOS, OSX,
> Android and Windows. But the requirements of interacting with these
> platforms is out of scope of the c++ standard.
>
> Standard c++ is all the other portable expression of logic in the program=
..
> It is normal (and good) practice to encapsulate the touching of
> platform-specific interfaces behind trivial facades, is it not?
>
> It is also normal, and good, to seek to express logic portably using
> standard c++ and idioms.
>
> It seems to me that the c++ standard should in large part target the
> authors of this kind of code, and let experts us *implementation defined
> behaviour* when interacting with the OS.
>
> *undefined* behaviour is an unwelcome smell.
>
>
Undefined behavior is a corollary of writing narrow contracts. If all
behavior is defined, that is a wide contract.
> On Thursday, 21 December 2017 13:00:52 UTC+1, Micha=C5=82 Dominiak wrote=
:
>
>>
>>
>> On Thu, Dec 21, 2017 at 12:18 PM Richard Hodges <hodg...@gmail.com>
>> wrote:
>>
>>> >> and not true in this particular case, because, for example, MSVC,
>>> when given int foo() {}, produces a hard error.
>>>
>>> > That's non-conformant. There is no latitude for an implementation to
>>> terminate translation of that function.
>>>
>>> Conformant or not, it rather gives the lie to the claim that there is a
>>> "massive body of code" that would suddenly fail to compile if
>>> non-compilation became mandated in such a circumstance.
>>>
>>
>>> We all write our code to be as portable as possible, don't we?
>>>
>>
>> No.
>>
>> We have projects that are specifically *not* targeted at Windows,
>> because their environment is, very explicitly, Linux.
>>
>> Please stop making fallacious arguments. If anything, it is MSVC which
>> should stop breaking compatibility there - at least by default.
>>
>>
>>>
>>> Clearly, the only code that would need to be revisited would be
>>> platform-specific code that was taking advantage of (flaunting?) UB
>>> techniques.
>>>
>>
>> Nonsense again, it's not UB until you've actually executed the invalid
>> code path, in this case.
>>
>>
>>>
>>> Code that's doing that really ought to be annotated as such.
>>>
>>>
>>>
>>> On 21 December 2017 at 11:58, 'Edward Catmur' via ISO C++ Standard -
>>> Future Proposals <std-pr...@isocpp.org> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Dec 21, 2017 at 9:55 AM, Viacheslav Usov <via....@gmail.com>
>>>> wrote:
>>>>
>>>>> On Wed, Dec 20, 2017 at 7:41 PM, Nicol Bolas <jmck...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> > So perhaps we have a different idea of what "depending on UB" means=
..
>>>>> UB only happens when you encounter it* at runtime*. It is not a
>>>>> compile-time concept; it is runtime behavior.
>>>>>
>>>>> That is not true in general, because the standard does not define UB
>>>>> as a runtime concept,
>>>>>
>>>>
>>>> An implementation is permitted to diagnose certain kinds of UB
>>>> (typically "ill-formed NDR") at translation time; it is however not
>>>> required to (hence NDR) and so the runtime behavior of such a program =
is
>>>> undefined. In all cases of UB dependent on a runtime condition, the pr=
ogram
>>>> is required to be translated and it is the runtime behavior that is
>>>> undefined.
>>>>
>>>>
>>>>> and not true in this particular case, because, for example, MSVC, whe=
n
>>>>> given int foo() {}, produces a hard error.
>>>>>
>>>>
>>>> That's non-conformant. There is no latitude for an implementation to
>>>> terminate translation of that function.
>>>>
>>>>
>>>>> Cheers,
>>>>> V.
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to a topic in th=
e
>>>>> Google Groups "ISO C++ Standard - Future Proposals" group.
>>>>> To unsubscribe from this topic, visit https://groups.google.com/a/is
>>>>> ocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
>>>>> To unsubscribe from this group and all its topics, send an 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/isocpp.org/d/msgid/std-proposals
>>>>> /CAA7YVg087TchKJdacOr5TrWMqLpuq%2BabPtmCCrs7PUjQkC%2BH6Q%40m
>>>>> ail.gmail.com
>>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg=
087TchKJdacOr5TrWMqLpuq%2BabPtmCCrs7PUjQkC%2BH6Q%40mail.gmail.com?utm_mediu=
m=3Demail&utm_source=3Dfooter>
>>>>> .
>>>>>
>>>>
>>>> --
>>>> 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-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/i=
s
>>>> ocpp.org/d/msgid/std-proposals/CAJnLdOYYY6HY%3DMs3U4nBh88pvx
>>>> f8jgh0O_Wtjnkz_3-rCeTZtQ%40mail.gmail.com
>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOY=
YY6HY%3DMs3U4nBh88pvxf8jgh0O_Wtjnkz_3-rCeTZtQ%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
>>>> .
>>>>
>>>
>>> --
>>> 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-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/CALvx3hYt%2Bzxa%2Ba-uGPc5ZtBN
>>> VLfVRG2vPd%3DV-bQV55_%2BoDoJ%2Bw%40mail.gmail.com
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hYt=
%2Bzxa%2Ba-uGPc5ZtBNVLfVRG2vPd%3DV-bQV55_%2BoDoJ%2Bw%40mail.gmail.com?utm_m=
edium=3Demail&utm_source=3Dfooter>
>>> .
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
> To unsubscribe from this group and all its topics, 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/569a7504-8308-493a-
> b1c8-c7d918c0418f%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/569a7504-83=
08-493a-b1c8-c7d918c0418f%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/CAJnLdOZ---e%3DGjg_QLcHLHDC6foNWYDEiJoZaTkA3U47A=
N1vHw%40mail.gmail.com.
--089e08280284fb69b00560d98659
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Dec 21, 2017 at 12:16 PM, Richard Hodges <span dir=3D"ltr"><=
<a href=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com<=
/a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><s=
pan class=3D"">>> We all write our code to be as portable as possible=
, don't we?<div>> No</div><div><br></div></span><div>Well that, if m=
ay say, seems a little unwise, nevertheless moving on...</div><span class=
=3D""><div><br></div><div>> We have projects that are specifically=C2=A0=
<i>not</i>=C2=A0targeted at Windows, because their environment is, very exp=
licitly, Linux</div><div><br></div></span><div>So do many others, including=
my firm. Plus projects targeting iOS, OSX, Android and Windows. But the re=
quirements of interacting with these platforms is out of scope of the c++ s=
tandard.</div><div><br></div><div>Standard c++ is all the other portable ex=
pression of logic in the program. It is normal (and good) practice to encap=
sulate the touching of platform-specific interfaces behind trivial facades,=
is it not?</div><div><br></div><div>It is also normal, and good, to seek t=
o express logic portably using standard c++ and idioms.</div><div><br></div=
><div>It seems to me that the c++ standard should in large part target the =
authors of this kind of code, and let experts us <i><b>implementation</b> d=
efined behaviour</i> when interacting with the OS.</div><div><br></div><div=
><i>undefined</i> behaviour is an unwelcome smell.</div><div>=C2=A0</div></=
div></blockquote><div><br></div><div>Undefined behavior is a corollary of w=
riting narrow contracts. If all behavior is defined, that is a wide contrac=
t.</div><div><br></div><div><br></div><div>=C2=A0<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div></div><div>=C2=A0On Thursday, 21 Decem=
ber 2017 13:00:52 UTC+1, Micha=C5=82 Dominiak wrote:</div><div><blockquote=
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br><div class=3D"gmail_q=
uote"><span class=3D""><div dir=3D"ltr">On Thu, Dec 21, 2017 at 12:18 PM Ri=
chard Hodges <<a rel=3D"nofollow">hodg...@gmail.com</a>> wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div><div>>=
;> <span>and not true in this particular case, because, for example, MSV=
C, when given int foo() {}, produces a hard error.<br><br>> </span>That&=
#39;s non-conformant. There is no latitude for an implementation to termina=
te translation of that function.<br><br></div></div></div></div></div><div =
dir=3D"ltr"><div><div><div>Conformant or not, it rather gives the lie to th=
e claim that there is a "massive body of code" that would suddenl=
y fail to compile if non-compilation became mandated in such a circumstance=
..</div></div></div></div></blockquote><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div><div><div><br></div>We all write our code to be as portable=
as possible, don't we?<br></div></div></div></blockquote><div><br></di=
v><div>No.</div><div><br></div><div>We have projects that are specifically =
<i>not</i>=C2=A0targeted at Windows, because their environment is, very exp=
licitly, Linux.</div><div><br></div><div>Please stop making fallacious argu=
ments. If anything, it is MSVC which should stop breaking compatibility the=
re - at least by default.</div><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div><div><br></div>Clearly, the only code that would =
need to be revisited would be platform-specific code that was taking advant=
age of (flaunting?) UB techniques.<br></div></div></blockquote><div><br></d=
iv><div>Nonsense again, it's not UB until you've actually executed =
the invalid code path, in this case.</div><div>=C2=A0</div></span><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><span class=3D""><div dir=3D"ltr"><div><br></div>Code=
that's doing that really ought to be annotated as such.<br><br><div><b=
r><div><div><div><span></span></div></div></div></div></div></span><div><br=
><div class=3D"gmail_quote">On 21 December 2017 at 11:58, 'Edward Catmu=
r' via ISO C++ Standard - Future Proposals <span dir=3D"ltr"><<a rel=
=3D"nofollow">std-pr...@isocpp.org</a>></span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><br><div><br><div class=3D"gmail_quote"><s=
pan>On Thu, Dec 21, 2017 at 9:55 AM, Viacheslav Usov <span dir=3D"ltr"><=
<a rel=3D"nofollow">via....@gmail.com</a>></span> wrote:<span class=3D""=
><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gma=
il_quote">On Wed, Dec 20, 2017 at 7:41 PM, Nicol Bolas <span dir=3D"ltr">&l=
t;<a rel=3D"nofollow">jmck...@gmail.com</a>></span> wrote:<br><div><br><=
/div><div>> So perhaps we have a different idea of what "depending =
on UB" means. UB only happens when you encounter it<i> at runtime</i>.=
It is not a compile-time concept; it is runtime behavior.</div><div><br></=
div><div>That is not true in general, because the standard does not define =
UB as a runtime concept,</div></div></div></div></blockquote><div><br></div=
></span></span><span class=3D""><div>An implementation is permitted to diag=
nose certain kinds of UB (typically "ill-formed NDR") at translat=
ion time; it is however not required to (hence NDR) and so the runtime beha=
vior of such a program is undefined. In all cases of UB dependent on a runt=
ime condition, the program is required to be translated and it is the runti=
me behavior that is undefined.</div><span><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div> and n=
ot true in this particular case, because, for example, MSVC, when given int=
foo() {}, produces a hard error.</div></div></div></div></blockquote><div>=
<br></div></span><div>That's non-conformant. There is no latitude for a=
n implementation to terminate translation of that function.</div><div>=C2=
=A0</div></span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div c=
lass=3D"gmail_quote"><div></div><div>Cheers,<br></div><div>V.</div><div><br=
></div></div></div></div><span><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" rel=3D"nofollow=
" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/topic/std=
-proposals<wbr>/Uu2QViiWh4k/unsubscribe</a>.<br></span>
To unsubscribe from this group and all its topics, send an email to <a rel=
=3D"nofollow">std-proposal...@isocpp.org</a>.<span><br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br></span></span><span class=3D""><span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg087TchKJdacOr5TrWMqLpuq%2BabPt=
mCCrs7PUjQkC%2BH6Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" rel=3D"nofollow" target=3D"_blank">https://groups.google.com/a/is<wbr>=
ocpp.org/d/msgid/std-proposals<wbr>/CAA7YVg087TchKJdacOr5TrWMqLpu<wbr>q%2Ba=
bPtmCCrs7PUjQkC%2BH6Q%40m<wbr>ail.gmail.com</a>.<br>
</span></span></blockquote></div><br></div></div><span><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></span>
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></span><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/CAJnLdOYYY6HY%3DMs3U4nBh88pvxf8jgh0O_=
Wtjnkz_3-rCeTZtQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" rel=3D"nofollow" target=3D"_blank">https://groups.google.com/a/is<wbr>oc=
pp.org/d/msgid/std-proposals<wbr>/CAJnLdOYYY6HY%3DMs3U4nBh88pvx<wbr>f8jgh0O=
_Wtjnkz_3-rCeTZtQ%<wbr>40mail.gmail.com</a>.<br>
</span></blockquote></div><br></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></span>
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>.<span class=3D""><br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hYt%2Bzxa%2Ba-uGPc5ZtBNVLfVRG2v=
Pd%3DV-bQV55_%2BoDoJ%2Bw%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter" rel=3D"nofollow" target=3D"_blank">https://groups.google.com/a/i=
s<wbr>ocpp.org/d/msgid/std-proposals<wbr>/CALvx3hYt%2Bzxa%2Ba-uGPc5ZtBN<wbr=
>VLfVRG2vPd%3DV-bQV55_%2BoDoJ%<wbr>2Bw%40mail.gmail.com</a>.<br>
</span></blockquote></div></div>
</blockquote></div></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/U=
u2QViiWh4k/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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/569a7504-8308-493a-b1c8-c7d918c0418f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/569a=
7504-8308-493a-<wbr>b1c8-c7d918c0418f%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAJnLdOZ---e%3DGjg_QLcHLHDC6foNWYDEiJ=
oZaTkA3U47AN1vHw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZ---e%3D=
Gjg_QLcHLHDC6foNWYDEiJoZaTkA3U47AN1vHw%40mail.gmail.com</a>.<br />
--089e08280284fb69b00560d98659--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 19 Dec 2017 12:58:45 -0500
Raw View
On 2017-12-19 11:02, Edward Catmur wrote:
> The reason that -Wreturn-type is part of -Wextra and not -Wall is that
> there is far too much existing code that would trigger the warning.
Citation needed.
I've been using -Werror=return-type with just about all C++ code I
compile for some years, and have yet to see a false positive. (Genuine
bugs, on the other hand...)
This statement directly contradicts my own real-world observations, and
thus, I must consider it inadmissible without substantiation.
--
Matthew
--
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/p1bjsq%24omk%241%40blaine.gmane.org.
.
Author: Ren Industries <renindustries@gmail.com>
Date: Fri, 22 Dec 2017 21:43:43 -0500
Raw View
--94eb2c195c1ed1d7aa0560f8e6db
Content-Type: text/plain; charset="UTF-8"
> On 2017-12-19 11:15, Ren Industries wrote:
> >> This is nonsense. I have provided a proposal on expressing the intent to
> >> not provide a return statement. You would have the same optimisation
> >> opportunities that you enjoy today.
> >
> > Right, which I now need to transform hundreds to thousands of lines of
> code
> > to use. No.
>
> If you compile your code with -Wreturn-type, does that warning pop up
> hundreds to thousands of times? If not, then no, you would not need to
> transform large amounts of code.
>
> (If yes, I would be deeply concerned to use your code, frankly...)
>
Yes, I mentioned how many it would be. The reason is quite obvious: we have
many simple state machines that need to be inlinable.
>
> >> No-one is arguing that you have to have any throw logic.
> >
> > It was mentioned several times in this thread. I don't exactly see how
> else
> > you are going to enforce these constraints at runtime otherwise.
>
> Who said anything about *enforcing*? If you want the compiler to trust
> you that execution will never fall off the end of a function, you stick
> `[[unreachable]]` at the end to tell it to do so. If execution ever does
> get there, you're back in UB land, as today.
>
Again, demanding currently completely valid code to be altered for no
reason is a non-starter.
The code is NOT UB; it COULD POSSIBLY be UB, but is not until an actual
invalid value is given.
Which it never is if you obey the narrow contract of the function
>
> Throwing is one of the three ways to avoid falling off the end of a
> function. It's been mentioned in *that* context several times.
>
>
Throwing is a a bad idea in high performance code, especially game
development.
Especially if it's implicitly added, so it can't even be accurately
documented.
--
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/CAMD6iD_xn9bcbie871_di%3D%3DJX4SduNEYQkLX2zOSvjeAJCZ1Vg%40mail.gmail.com.
--94eb2c195c1ed1d7aa0560f8e6db
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On 2017-12-19 11:15, Ren Industries wrote:<b=
r>
>> This is nonsense. I have provided a proposal on expressing the int=
ent to<br>
>> not provide a return statement. You would have the same optimisati=
on<br>
>> opportunities that you enjoy today.<br>
><br>
> Right, which I now need to transform hundreds to thousands of lines of=
code<br>
> to use. No.<br>
<br>
If you compile your code with -Wreturn-type, does that warning pop up<br>
hundreds to thousands of times? If not, then no, you would not need to<br>
transform large amounts of code.<br>
<br>
(If yes, I would be deeply concerned to use your code, frankly...)<br></blo=
ckquote><div><br></div><div>Yes, I mentioned how many it would be. The reas=
on is quite obvious: we have many simple state machines that need to be inl=
inable.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
>> No-one is arguing that you have to have any throw logic.<br>
><br>
> It was mentioned several times in this thread. I don't exactly see=
how else<br>
> you are going to enforce these constraints at runtime otherwise.<br>
<br>
Who said anything about *enforcing*? If you want the compiler to trust<br>
you that execution will never fall off the end of a function, you stick<br>
`[[unreachable]]` at the end to tell it to do so. If execution ever does<br=
>
get there, you're back in UB land, as today.<br></blockquote><div><br><=
/div><div>Again, demanding currently completely valid code to be altered fo=
r no reason is a non-starter.</div><div>The code is NOT UB; it COULD POSSIB=
LY be UB, but is not until an actual invalid value is given.</div><div>Whic=
h it never is if you obey the narrow contract of the function</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">
<br>
Throwing is one of the three ways to avoid falling off the end of a<br>
function. It's been mentioned in *that* context several times.<br>
<span class=3D""><br></span></blockquote><div><br></div><div>Throwing is a =
a bad idea in high performance code, especially game development.</div><div=
>Especially if it's implicitly added, so it can't even be accuratel=
y documented.</div><div>=C2=A0</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/CAMD6iD_xn9bcbie871_di%3D%3DJX4SduNEY=
QkLX2zOSvjeAJCZ1Vg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD_xn9bc=
bie871_di%3D%3DJX4SduNEYQkLX2zOSvjeAJCZ1Vg%40mail.gmail.com</a>.<br />
--94eb2c195c1ed1d7aa0560f8e6db--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 22 Dec 2017 20:20:35 -0800 (PST)
Raw View
------=_Part_2164_648259231.1514002835195
Content-Type: multipart/alternative;
boundary="----=_Part_2165_809118110.1514002835196"
------=_Part_2165_809118110.1514002835196
Content-Type: text/plain; charset="UTF-8"
On Friday, December 22, 2017 at 9:05:42 PM UTC-5, Matthew Woehlke wrote:
>
> On 2017-12-19 09:39, Nicol Bolas wrote:
> > This is what we call a breaking change. So named because it breaks
> people's
> > perfectly functioning code.
>
> Really?
>
> Such code has Undefined Behavior.
>
No, it does not. Undefined behavior is not a static construct; it is a
runtime construct. Therefore, outside of the simplest of cases, you cannot*
know* that a function that doesn't have all control paths return/throw "has
Undefined Behavior".
Ill-formed is a static property of the code. The OP wants to turn any code
that* theoretically* might exhibit UB into ill-formed code.
As you'll recall, we used to compile code like `if (x > x + 1)` to do
> what people thought it "ought" to do. But we were perfectly content to
> leverage the fact that that is UB to "break" such code.
>
> Why should this change be any different?
>
Because that code was already broken. While it may have been very
surprising to people, that's only because those people had never read the
actual rules for the language. Every version of C and C++ made that
abundantly clear that you cannot detect overflow that way.
By contrast, the code below is perfectly valid; you want to *redefine it*
as invalid, despite literally decades of C and C++ versions that say it's
valid.
It's not like it's hard to "repair" code that fails to compile due to
> this change... just stick `[[unreachable]]` at the end of the function
> and pray it really is.
Well at present, the thinking for designating "unreachable" code is to use
a standard library function, not an attribute.
One advantage of using real syntax (whether a function call or a keyword)
is that it provides a path for us to* eventually* outlaw not identifying
non-returning branches. You can't do it yet for compatibility reasons, but
after many years of having `std::unreachable()` around (with increasingly
more insistent compiler warnings), we can then decide that anyone who
hasn't upgraded clearly doesn't intend to.
> Worst case, your code continues to have UB.
>
See below. Such cases have no more UB than `int foo(int *ptr) {return
*ptr;}`. Should we be statically required to check* every* pointer we get
to see if it's NULL?
>
> > Breaking people's code is not good. It's doubly not good to do so
> without
> > fair warning. It's triply not good to do so for so little *genuine*
> gain.
>
> I will happily argue that having compilers actually prevent people from
> writing broken code in the form of functions which are supposed to
> return and don't, of which I've seen a handful, constitutes genuine gain.
>
> We're not talking about breaking *good* code. We're talking about
> refusing to compile code that is most definitely bad.
>
No, we're not. We're talking about making this code not compile:
std::string get_enum_name(SomeEnumeration e)
{
switch(e)
{
case SomeEnumeration::Enum1: return "Enum1";
case ...;
}
}
It has no final `return` statement. But this does exactly what the
programmer wanted. There's no reason why this code should not be legal.
Now, it would certainly be* better* if there was some explicit statement
that the writer intends there to be UB beyond the end of the `switch`. But
there's no reason to force that on the user.
(Note: if we make a change, I would recommend that it be 'ill formed,
> NDR'. As QoI, compilers should only squawk if they are "confident" the
> code falls off the end of the function.
That is self-contradictory. If code is ill-formed, then you as a programmer
cannot and should not reasonably rely on its execution. If we declare that
the static possibility of falling off the end of a function is ill-formed,
then that means every program that has such a construct is *semantic
nonsense*.
The behavior of an ill-formed program is not defined. Period.
By contrast, the behavior of a program that* might* exhibit UB is perfectly
valid... so long as it doesn't *actually* do things that exhibit UB.
"Ill formed, NDR" is typically used for cases where compilers have a hard
time diagnosing a problem (ODR violations). But it's clear that, if the
condition happens, it is *most certainly* a problem and the compiler can
guarantee nothing about the result. That's not the case here; if the
compiler can't tell if the function can walk off the bottom, the compiler
doesn't know if it is certainly a problem.
The other major category of uses of "ill-formed, NDR" is for identifier
issues. That is, using identifiers reserved to the implementation.
> This will not make anyone's code one iota faster or easier to write.
> No, but it *will* stop people from writing broken code.
>
While simultaneously forcing people to make an ultimately meaningless
change to their perfectly functioning code. A change that notably is not
backwards compatible. So your code either compiles as C++17 or it compiles
as C++20; not both.
Stopping people from writing broken code is a laudable goal. But the costs
of this change outweigh its benefits.
I don't understand what's so bad about just having the `unreachable`
syntax, however it is that this gets spelled.
--
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/bf486ea5-4b29-4d7e-abac-dadb7c1622a2%40isocpp.org.
------=_Part_2165_809118110.1514002835196
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, December 22, 2017 at 9:05:42 PM UTC-5, Matthew =
Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2017-12-19 09=
:39, Nicol Bolas wrote:
<br>> This is what we call a breaking change. So named because it breaks=
people's=20
<br>> perfectly functioning code.
<br>
<br>Really?
<br>
<br>Such code has Undefined Behavior.
<br></blockquote><div><br></div><div>No, it does not. Undefined behavior is=
not a static construct; it is a runtime construct. Therefore, outside of t=
he simplest of cases, you cannot<i> know</i> that a function that doesn'=
;t have all control paths return/throw "has Undefined Behavior".<=
/div><div><br></div><div>Ill-formed is a static property of the code. The O=
P wants to turn any code that<i> theoretically</i> might exhibit UB into il=
l-formed code.</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">As you'll recall, we used to compile code like `if (x > x + 1)=
` to do
<br>what people thought it "ought" to do. But we were perfectly c=
ontent to
<br>leverage the fact that that is UB to "break" such code.
<br>
<br>Why should this change be any different?<br></blockquote><div><br></div=
><div>Because that code was already broken. While it may have been very sur=
prising to people, that's only because those people had never read the =
actual rules for the language. E<span style=3D"display: inline !important; =
float: none; background-color: transparent; color: rgb(34, 34, 34); font-fa=
mily: "Arial","Helvetica",sans-serif; font-size: 13px; =
font-style: normal; font-variant: normal; font-weight: 400; letter-spacing:=
normal; orphans: 2; text-align: left; text-decoration: none; text-indent: =
0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: nor=
mal; word-spacing: 0px;">very version of C and C++ made that abundantly cle=
ar that you cannot detect overflow that way.</span></div><div><span style=
=3D"display: inline !important; float: none; background-color: transparent;=
color: rgb(34, 34, 34); font-family: "Arial","Helvetica&quo=
t;,sans-serif; font-size: 13px; font-style: normal; font-variant: normal; f=
ont-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text=
-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-str=
oke-width: 0px; white-space: normal; word-spacing: 0px;"></span><b><br></b>=
</div><div>By contrast, the code below is perfectly valid; you want to <i>r=
edefine it</i> as invalid, despite literally decades of C and C++ versions =
that say it's valid.</div><div><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;">It's not like it's hard to "repair" code t=
hat fails to compile due to
<br>this change... just stick `[[unreachable]]` at the end of the function
<br>and pray it really is.</blockquote><div><br></div><div>Well at present,=
the thinking for designating "unreachable" code is to use a stan=
dard library function, not an attribute.</div><div><br></div><div>One advan=
tage of using real syntax (whether a function call or a keyword) is that it=
provides a path for us to<i> eventually</i> outlaw not identifying non-ret=
urning branches. You can't do it yet for compatibility reasons, but aft=
er many years of having `std::unreachable()` around (with increasingly more=
insistent compiler warnings), we can then decide that anyone who hasn'=
t upgraded clearly doesn't intend to.</div><div><i></i>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">Worst case, your code continues to=
have UB.<br></blockquote><div><br></div><div>See below. Such cases have no=
more UB than `int foo(int *ptr) {return *ptr;}`. Should we be statically r=
equired to check<i> every</i> pointer we get to see if it's NULL?</div>=
<div><i></i>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>> Breaking people's code is not good. It's doubly not good t=
o do so without=20
<br>> fair warning. It's triply not good to do so for so little *gen=
uine* gain.
<br>
<br>I will happily argue that having compilers actually prevent people from
<br>writing broken code in the form of functions which are supposed to
<br>return and don't, of which I've seen a handful, constitutes gen=
uine gain.
<br>
<br>We're not talking about breaking *good* code. We're talking abo=
ut
<br>refusing to compile code that is most definitely bad.<br></blockquote><=
div><br></div><div>No, we're not. We're talking about making this c=
ode not compile:</div><div><br></div><div class=3D"prettyprint" style=3D"bo=
rder: 1px solid rgb(187, 187, 187); word-wrap: break-word; background-color=
: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyp=
rint"><span class=3D"styled-by-prettify" style=3D"color: #000;">std</span><=
span class=3D"styled-by-prettify" style=3D"color: #660;">::</span><span cla=
ss=3D"styled-by-prettify" style=3D"color: #008;">string</span><span class=
=3D"styled-by-prettify" style=3D"color: #000;"> get_enum_name</span><span c=
lass=3D"styled-by-prettify" style=3D"color: #660;">(</span><span class=3D"s=
tyled-by-prettify" style=3D"color: #606;">SomeEnumeration</span><span class=
=3D"styled-by-prettify" style=3D"color: #000;"> e</span><span class=3D"styl=
ed-by-prettify" style=3D"color: #660;">)</span><span class=3D"styled-by-pre=
ttify" style=3D"color: #000;"><br></span><span class=3D"styled-by-prettify"=
style=3D"color: #660;">{</span><span class=3D"styled-by-prettify" style=3D=
"color: #000;"><br>=C2=A0 </span><span class=3D"styled-by-prettify" style=
=3D"color: #008;">switch</span><span class=3D"styled-by-prettify" style=3D"=
color: #660;">(</span><span class=3D"styled-by-prettify" style=3D"color: #0=
00;">e</span><span class=3D"styled-by-prettify" style=3D"color: #660;">)</s=
pan><span class=3D"styled-by-prettify" style=3D"color: #000;"><br>=C2=A0 </=
span><span class=3D"styled-by-prettify" style=3D"color: #660;">{</span><spa=
n class=3D"styled-by-prettify" style=3D"color: #000;"><br>=C2=A0 </span><sp=
an class=3D"styled-by-prettify" style=3D"color: #008;">case</span><span cla=
ss=3D"styled-by-prettify" style=3D"color: #000;"> </span><span class=3D"sty=
led-by-prettify" style=3D"color: #606;">SomeEnumeration</span><span class=
=3D"styled-by-prettify" style=3D"color: #660;">::</span><span class=3D"styl=
ed-by-prettify" style=3D"color: #606;">Enum1</span><span class=3D"styled-by=
-prettify" style=3D"color: #660;">:</span><span class=3D"styled-by-prettify=
" style=3D"color: #000;"> </span><span class=3D"styled-by-prettify" style=
=3D"color: #008;">return</span><span class=3D"styled-by-prettify" style=3D"=
color: #000;"> </span><span class=3D"styled-by-prettify" style=3D"color: #0=
80;">"Enum1"</span><span class=3D"styled-by-prettify" style=3D"co=
lor: #660;">;</span><span class=3D"styled-by-prettify" style=3D"color: #000=
;"><br>=C2=A0 </span><span class=3D"styled-by-prettify" style=3D"color: #00=
8;">case</span><span class=3D"styled-by-prettify" style=3D"color: #000;"> <=
/span><span class=3D"styled-by-prettify" style=3D"color: #660;">...;</span>=
<span class=3D"styled-by-prettify" style=3D"color: #000;"><br>=C2=A0 </span=
><span class=3D"styled-by-prettify" style=3D"color: #660;">}</span><span cl=
ass=3D"styled-by-prettify" style=3D"color: #000;"><br></span><span class=3D=
"styled-by-prettify" style=3D"color: #660;">}</span></div></code></div><div=
><br></div><div>It has no final `return` statement. But this does exactly w=
hat the programmer wanted. There's no reason why this code should not b=
e legal.</div><div><br></div><div>Now, it would certainly be<i> better</i> =
if there was some explicit statement that the writer intends there to be UB=
beyond the end of the `switch`. But there's no reason to force that on=
the user.<br></div><div><i><br></i></div><blockquote class=3D"gmail_quote"=
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;">(Note: if we make a change, I would recommend that it be 'i=
ll formed,
<br>NDR'. As QoI, compilers should only squawk if they are "confid=
ent" the
<br>code falls off the end of the function.</blockquote><div><br></div><div=
>That is self-contradictory. If code is ill-formed, then you as a programme=
r cannot and should not reasonably rely on its execution. If we declare tha=
t the static possibility of falling off the end of a function is ill-formed=
, then that means every program that has such a construct is <i>semantic no=
nsense</i>.</div><div><br></div><div>The behavior of an ill-formed program =
is not defined. Period.</div><div><br></div><div>By contrast, the behavior =
of a program that<i> might</i> exhibit UB is perfectly valid... so long as =
it doesn't <i>actually</i> do things that exhibit UB.</div><div><i><br>=
</i></div><div><span style=3D"display: inline !important; float: none; back=
ground-color: transparent; color: rgb(34, 34, 34); font-family: "Arial=
","Helvetica",sans-serif; font-size: 13px; font-style: norma=
l; font-variant: normal; font-weight: 400; letter-spacing: normal; orphans:=
2; text-align: left; text-decoration: none; text-indent: 0px; text-transfo=
rm: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing=
: 0px;">"Ill formed, NDR" is typically used for cases where compi=
lers have a hard time diagnosing a problem (ODR violations). But it's c=
lear that, if the condition happens, it is <i>most certainly</i> a problem =
and the compiler can guarantee nothing about the result. That's not the=
case here; if the compiler can't tell if the function can walk off the=
bottom, the compiler doesn't know if it is certainly a problem.</span>=
</div><div><span style=3D"display: inline !important; float: none; backgrou=
nd-color: transparent; color: rgb(34, 34, 34); font-family: "Arial&quo=
t;,"Helvetica",sans-serif; font-size: 13px; font-style: normal; f=
ont-variant: normal; font-weight: 400; letter-spacing: normal; orphans: 2; =
text-align: left; text-decoration: none; text-indent: 0px; text-transform: =
none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0p=
x;"><br></span></div><div><span style=3D"display: inline !important; float:=
none; background-color: transparent; color: rgb(34, 34, 34); font-family: =
"Arial","Helvetica",sans-serif; font-size: 13px; font-s=
tyle: normal; font-variant: normal; font-weight: 400; letter-spacing: norma=
l; orphans: 2; text-align: left; text-decoration: none; text-indent: 0px; t=
ext-transform: none; -webkit-text-stroke-width: 0px; white-space: normal; w=
ord-spacing: 0px;">The other major category of uses of "ill-formed, ND=
R" is for identifier issues. That is, using identifiers reserved to th=
e implementation.</span></div><div><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;">> This will not make anyone's code one iota faster or=
easier to write.
<br>No, but it *will* stop people from writing broken code.<br></blockquote=
><div><br></div><div>While simultaneously forcing people to make an ultimat=
ely meaningless change to their perfectly functioning code. A change that n=
otably is not backwards compatible. So your code either compiles as C++17 o=
r it compiles as C++20; not both.</div><div><br></div><div>Stopping people =
from writing broken code is a laudable goal. But the costs of this change o=
utweigh its benefits.</div><div><br></div><div>I don't understand what&=
#39;s so bad about just having the `unreachable` syntax, however it is that=
this gets spelled.<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/bf486ea5-4b29-4d7e-abac-dadb7c1622a2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bf486ea5-4b29-4d7e-abac-dadb7c1622a2=
%40isocpp.org</a>.<br />
------=_Part_2165_809118110.1514002835196--
------=_Part_2164_648259231.1514002835195--
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Sat, 23 Dec 2017 04:43:34 +0000
Raw View
--001a113e3d167e00560560fa93b8
Content-Type: text/plain; charset="UTF-8"
On 23 Dec 2017 02:05, "'Edward Catmur' via ISO C++ Standard - Future
Proposals" <std-proposals@isocpp.org> wrote:
Undefined behavior is a corollary of writing narrow contracts. If all
behavior is defined, that is a wide contract.
Not necessarily. It's a corollary of writing *optimal* narrow contracts *in
current C++.* A narrow contract that makes assertations or otherwise has
every branch returning is still a narrow contract, it's just a little
smarter. The issue here is the trade-off between swapping foolproof code
for optimised code.
This thread has had me thinking about this problem. Narrow contracts are
useful, but they utilise UB because they are non-enforceable without
validating on every call. Do we have a mechanism by which we can describe
*some* narrow contracts*, such that the contract is understood at compile
time, even if some value is from external input (but filtered and validated
as all external input should be, unless we want an interrupted data feed,
corrupted file or a user's typo to actually go through a wrong branch and
into our main processing.) Essentially, we *enforce* a subset of the
underlying type through some rules and become able to utilise that subset
at compile time with no ambiguity.
* not all narrow contracts can be enforced this way. If your input must be
some solution to some hard problem, you know it to be so as it is passed
from the solver directly to the function, then there's no chance. But for
many cases, it could be useful.
Benefits:
- Changing the contract at a later date would then give you warnings about
impossible conditions (e.g. a switch case of a value that can't exist any
more), about non-returning branches (if your select cases are no longer
exhaustive), useful warnings like that. In this sense the contract is no
longer just existent in some docs and the dev's mind, but is actually
enforced where it matters - in the code.
- Contract validation need only happen once for each input, rather than for
each call. Your micro-function remains optimised and it knows exactly what
to expect, as no other values are even possible inputs to it any more.
- UB is no longer a concern for the narrow contracts that can be expressed.
Although this isn't what I have in mind, one *can* get an idea of this with
a class, as I have given an example of below. The non-returning branch is
warned about (though from this code in isolation you can see that is not
going to be an issue). It's also a bad approach, as a child could be
created that sets an invalid value. Is there a better approach regarding
narrow contracts that has been already proposed/in the standard that I'm
not aware of? Is there any interest in having such a thing? What I'm
initially thinking of is some template, such as bounded<T,min,max>, and
some explicit sets of values.
#include <iostream>
template<int min, int max>class CustomBoundedInt{protected:
int value;public:
CustomBoundedInt(int value)
:
value(value)
{
if(value <= min || value >= max){
throw std::domain_error("Invalid value");
}
}
int get() const{
return value;
}};
std::string narrow_contract_function(CustomBoundedInt<1,5> input){
switch(input.get()){
case 1:
return "One";
case 2:
return "Two";
case 3:
return "Three";
case 4:
return "Four";
case 5:
return "Five";
}}
int main(){
int input = 2;
CustomBoundedInt<1,5> a(input);
// if we reach this point, input must be valid.
// we know this at compile time.
// The compiler does not. Thus although the switch is exhaustive,
// the compiler still thinks there is a non-returning branch.
std::cout << narrow_contract_function(a) << "\n";
return 0;}
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMye6aSaLR1Eh8H2Yhh%2BQs3_0C1K%3Dmx53cQpXS7vXJN4w%40mail.gmail.com.
--001a113e3d167e00560560fa93b8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><br><div class=3D"gmail_extra" dir=3D"auto"><br><div clas=
s=3D"gmail_quote">On 23 Dec 2017 02:05, "'Edward Catmur' via I=
SO C++ Standard - Future Proposals" <<a href=3D"mailto:std-proposal=
s@isocpp.org">std-proposals@isocpp.org</a>> wrote:<br type=3D"attributio=
n"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote"><div class=3D"quoted-text">=C2=A0Undefined behavior=
is a corollary of writing narrow contracts. If all behavior is defined, th=
at is a wide contract.</div></div></div></div></blockquote></div></div><div=
dir=3D"auto"><br></div><div dir=3D"auto">Not necessarily. It's a corol=
lary of writing <i><u>optimal</u></i> narrow contracts <i>in current C++.</=
i>=C2=A0A narrow contract that makes assertations or otherwise has every br=
anch returning is still a narrow contract, it's just a little smarter. =
The issue here is the trade-off between swapping foolproof code for optimis=
ed code.</div><div dir=3D"auto"><br></div><div dir=3D"auto">This thread has=
had me thinking about this problem. Narrow contracts are useful, but they =
utilise UB because they are non-enforceable without validating on every cal=
l. Do we have a mechanism by which we can describe <i>some</i> narrow contr=
acts*, such that the contract is understood at compile time, even if some v=
alue is from external input (but filtered and validated as all external inp=
ut should be, unless we want an interrupted data feed, corrupted file or a =
user's typo to actually go through a wrong branch and into our main pro=
cessing.) Essentially, we <i>enforce</i> a subset of the underlying type th=
rough some rules and become able to utilise that subset at compile time wit=
h no ambiguity.</div><div dir=3D"auto"><br></div><div dir=3D"auto">* not al=
l narrow contracts can be enforced this way. If your input must be some sol=
ution to some hard problem, you know it to be so as it is passed from the s=
olver directly to the function, then there's no chance. But for many ca=
ses, it could be useful.</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>Benefits:</div><div dir=3D"auto"><br></div><div dir=3D"auto">- Changing th=
e contract at a later date would then give you warnings about impossible co=
nditions (e.g. a switch case of a value that can't exist any more), abo=
ut non-returning branches (if your select cases are no longer exhaustive), =
useful warnings like that. In this sense the contract is no longer just exi=
stent in some docs and the dev's mind, but is actually enforced where i=
t matters - in the code.</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>- Contract validation need only happen once for each input, rather than fo=
r each call. Your micro-function remains optimised and it knows exactly wha=
t to expect, as no other values are even possible inputs to it any more.</d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto">- UB is no longer a concer=
n for the narrow contracts that can be expressed.</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">Although this isn't what I have in mind, one =
<i>can</i> get an idea of this with a class, as I have given an example of =
below. The non-returning branch is warned about (though from this code in i=
solation you can see that is not going to be an issue). It's also a bad=
approach, as a child could be created that sets an invalid value. Is there=
a better approach regarding narrow contracts that has been already propose=
d/in the standard that I'm not aware of? Is there any interest in havin=
g such a thing? What I'm initially thinking of is some template, such a=
s bounded<T,min,max>, and some explicit sets of values.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto"><pre style=3D"background:rgb(255,255,=
255)"><pre style=3D"background-image:initial;background-position:initial;ba=
ckground-size:initial;background-repeat:initial;background-origin:initial;b=
ackground-clip:initial"><span style=3D"color:rgb(0,74,67)">#</span><span st=
yle=3D"color:rgb(0,74,67)">include </span><span style=3D"color:rgb(128,0,0)=
"><</span><span style=3D"color:rgb(64,1,90)">iostream</span><span style=
=3D"color:rgb(128,0,0)">></span>
<span style=3D"color:rgb(128,0,0);font-weight:bold">template</span><span st=
yle=3D"color:rgb(128,0,128)"><</span><span style=3D"color:rgb(128,0,0);f=
ont-weight:bold">int</span> <span style=3D"color:rgb(96,48,0)">min</span><s=
pan style=3D"color:rgb(128,128,48)">,</span> <span style=3D"color:rgb(128,0=
,0);font-weight:bold">int</span> <span style=3D"color:rgb(96,48,0)">max</sp=
an><span style=3D"color:rgb(128,0,128)">></span>
<span style=3D"color:rgb(128,0,0);font-weight:bold">class</span> CustomBoun=
dedInt<span style=3D"color:rgb(128,0,128)">{</span>
<span style=3D"color:rgb(128,0,0);font-weight:bold">protected</span><span s=
tyle=3D"color:rgb(227,74,220)">:</span>
<span style=3D"color:rgb(128,0,0);font-weight:bold">int</span> value<sp=
an style=3D"color:rgb(128,0,128)">;</span>
<span style=3D"color:rgb(128,0,0);font-weight:bold">public</span><span styl=
e=3D"color:rgb(227,74,220)">:</span>
CustomBoundedInt<span style=3D"color:rgb(128,128,48)">(</span><span sty=
le=3D"color:rgb(128,0,0);font-weight:bold">int</span> value<span style=3D"c=
olor:rgb(128,128,48)">)</span>
<span style=3D"color:rgb(128,0,128)">:</span>
value<span style=3D"color:rgb(128,128,48)">(</span>value<span style=
=3D"color:rgb(128,128,48)">)</span>
<span style=3D"color:rgb(128,0,128)">{</span>
<span style=3D"color:rgb(128,0,0);font-weight:bold">if</span><span =
style=3D"color:rgb(128,128,48)">(</span>value <span style=3D"color:rgb(128,=
128,48)"><</span><span style=3D"color:rgb(128,128,48)">=3D</span> <span =
style=3D"color:rgb(96,48,0)">min</span> <span style=3D"color:rgb(128,128,48=
)">|</span><span style=3D"color:rgb(128,128,48)">|</span> value <span style=
=3D"color:rgb(128,128,48)">></span><span style=3D"color:rgb(128,128,48)"=
>=3D</span> <span style=3D"color:rgb(96,48,0)">max</span><span style=3D"col=
or:rgb(128,128,48)">)</span><span style=3D"color:rgb(128,0,128)">{</span>
<span style=3D"color:rgb(128,0,0);font-weight:bold">throw</span> <=
span style=3D"color:rgb(102,102,22)">std</span><span style=3D"color:rgb(128=
,0,128)">::</span><span style=3D"color:rgb(96,48,0)">domain_error</span><sp=
an style=3D"color:rgb(128,128,48)">(</span><span style=3D"color:rgb(128,0,0=
)">"</span><span style=3D"color:rgb(0,0,230)">Invalid value</span><spa=
n style=3D"color:rgb(128,0,0)">"</span><span style=3D"color:rgb(128,12=
8,48)">)</span><span style=3D"color:rgb(128,0,128)">;</span>
<span style=3D"color:rgb(128,0,128)">}</span>
<span style=3D"color:rgb(128,0,128)">}</span>
<span style=3D"color:rgb(128,0,0);font-weight:bold">int</span> get<span=
style=3D"color:rgb(128,128,48)">(</span><span style=3D"color:rgb(128,128,4=
8)">)</span> <span style=3D"color:rgb(128,0,0);font-weight:bold">const</spa=
n><span style=3D"color:rgb(128,0,128)">{</span>
<span style=3D"color:rgb(128,0,0);font-weight:bold">return</span> v=
alue<span style=3D"color:rgb(128,0,128)">;</span>
<span style=3D"color:rgb(128,0,128)">}</span>
<span style=3D"color:rgb(128,0,128)">}</span><span style=3D"color:rgb(128,0=
,128)">;</span>
<span style=3D"color:rgb(102,102,22)">std</span><span style=3D"color:rgb(12=
8,0,128)">::</span><span style=3D"color:rgb(96,48,0)">string</span> narrow_=
contract_function<span style=3D"color:rgb(128,128,48)">(</span>CustomBounde=
dInt<span style=3D"color:rgb(128,0,128)"><</span><span style=3D"color:rg=
b(0,140,0)">1</span><span style=3D"color:rgb(128,128,48)">,</span><span sty=
le=3D"color:rgb(0,140,0)">5</span><span style=3D"color:rgb(128,0,128)">>=
</span> input<span style=3D"color:rgb(128,128,48)">)</span><span style=3D"c=
olor:rgb(128,0,128)">{</span>
<span style=3D"color:rgb(128,0,0);font-weight:bold">switch</span><span =
style=3D"color:rgb(128,128,48)">(</span>input<span style=3D"color:rgb(128,1=
28,48)">.</span>get<span style=3D"color:rgb(128,128,48)">(</span><span styl=
e=3D"color:rgb(128,128,48)">)</span><span style=3D"color:rgb(128,128,48)">)=
</span><span style=3D"color:rgb(128,0,128)">{</span>
<span style=3D"color:rgb(128,0,0);font-weight:bold">case </span><span sty=
le=3D"color:rgb(0,140,0)">1</span><span style=3D"color:rgb(227,74,220)">:</=
span>
<span style=3D"color:rgb(128,0,0);font-weight:bold">return</span> <sp=
an style=3D"color:rgb(128,0,0)">"</span><span style=3D"color:rgb(0,0,2=
30)">One</span><span style=3D"color:rgb(128,0,0)">"</span><span style=
=3D"color:rgb(128,0,128)">;</span>
<span style=3D"color:rgb(128,0,0);font-weight:bold">case </span><span sty=
le=3D"color:rgb(0,140,0)">2</span><span style=3D"color:rgb(227,74,220)">:</=
span>
<span style=3D"color:rgb(128,0,0);font-weight:bold">return</span> <sp=
an style=3D"color:rgb(128,0,0)">"</span><span style=3D"color:rgb(0,0,2=
30)">Two</span><span style=3D"color:rgb(128,0,0)">"</span><span style=
=3D"color:rgb(128,0,128)">;</span>
<span style=3D"color:rgb(128,0,0);font-weight:bold">case </span><span sty=
le=3D"color:rgb(0,140,0)">3</span><span style=3D"color:rgb(227,74,220)">:</=
span>
<span style=3D"color:rgb(128,0,0);font-weight:bold">return</span> <sp=
an style=3D"color:rgb(128,0,0)">"</span><span style=3D"color:rgb(0,0,2=
30)">Three</span><span style=3D"color:rgb(128,0,0)">"</span><span styl=
e=3D"color:rgb(128,0,128)">;</span>
<span style=3D"color:rgb(128,0,0);font-weight:bold">case </span><span sty=
le=3D"color:rgb(0,140,0)">4</span><span style=3D"color:rgb(227,74,220)">:</=
span>
<span style=3D"color:rgb(128,0,0);font-weight:bold">return</span> <sp=
an style=3D"color:rgb(128,0,0)">"</span><span style=3D"color:rgb(0,0,2=
30)">Four</span><span style=3D"color:rgb(128,0,0)">"</span><span style=
=3D"color:rgb(128,0,128)">;</span>
<span style=3D"color:rgb(128,0,0);font-weight:bold">case </span><span sty=
le=3D"color:rgb(0,140,0)">5</span><span style=3D"color:rgb(227,74,220)">:</=
span>
<span style=3D"color:rgb(128,0,0);font-weight:bold">return</span> <sp=
an style=3D"color:rgb(128,0,0)">"</span><span style=3D"color:rgb(0,0,2=
30)">Five</span><span style=3D"color:rgb(128,0,0)">"</span><span style=
=3D"color:rgb(128,0,128)">;</span>
<span style=3D"color:rgb(128,0,128)">}</span>
<span style=3D"color:rgb(128,0,128)">}</span>
<span style=3D"color:rgb(128,0,0);font-weight:bold">int</span> <span style=
=3D"color:rgb(64,0,0)">main</span><span style=3D"color:rgb(128,128,48)">(</=
span><span style=3D"color:rgb(128,128,48)">)</span><span style=3D"color:rgb=
(128,0,128)">{</span>
<span style=3D"color:rgb(128,0,0);font-weight:bold">int</span> input <s=
pan style=3D"color:rgb(128,128,48)">=3D</span> <span style=3D"color:rgb(0,1=
40,0)">2</span><span style=3D"color:rgb(128,0,128)">;</span>
CustomBoundedInt<span style=3D"color:rgb(128,0,128)"><</span><span s=
tyle=3D"color:rgb(0,140,0)">1</span><span style=3D"color:rgb(128,128,48)">,=
</span><span style=3D"color:rgb(0,140,0)">5</span><span style=3D"color:rgb(=
128,0,128)">></span> a<span style=3D"color:rgb(128,128,48)">(</span>inpu=
t<span style=3D"color:rgb(128,128,48)">)</span><span style=3D"color:rgb(128=
,0,128)">;</span>
<span style=3D"color:rgb(105,105,105)">// if we reach this point, input=
must be valid.</span>
<span style=3D"color:rgb(105,105,105)">// we know this at compile time.=
</span>
<span style=3D"color:rgb(105,105,105)">// The compiler does not. Thus a=
lthough the switch is exhaustive,</span>
<span style=3D"color:rgb(105,105,105)">// the compiler still thinks the=
re is a non-returning branch.</span>
<span style=3D"color:rgb(102,102,22)">std</span><span style=3D"color:rg=
b(128,0,128)">::</span><span style=3D"color:rgb(96,48,0)">cout</span> <span=
style=3D"color:rgb(128,128,48)"><</span><span style=3D"color:rgb(128,12=
8,48)"><</span> narrow_contract_function<span style=3D"color:rgb(128,128=
,48)">(</span>a<span style=3D"color:rgb(128,128,48)">)</span> <span style=
=3D"color:rgb(128,128,48)"><</span><span style=3D"color:rgb(128,128,48)"=
><</span> <span style=3D"color:rgb(128,0,0)">"</span><span style=3D=
"color:rgb(15,105,255)">\n</span><span style=3D"color:rgb(128,0,0)">"<=
/span><span style=3D"color:rgb(128,0,128)">;</span>
<span style=3D"color:rgb(128,0,0);font-weight:bold">return</span> <span=
style=3D"color:rgb(0,140,0)">0</span><span style=3D"color:rgb(128,0,128)">=
;</span>
<span style=3D"color:rgb(128,0,128)">}</span></pre></pre></div><div class=
=3D"gmail_extra" dir=3D"auto"></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMye6aSaLR1Eh8H2Yhh%2BQs3_0C1=
K%3Dmx53cQpXS7vXJN4w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMy=
e6aSaLR1Eh8H2Yhh%2BQs3_0C1K%3Dmx53cQpXS7vXJN4w%40mail.gmail.com</a>.<br />
--001a113e3d167e00560560fa93b8--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 22 Dec 2017 23:03:31 -0800 (PST)
Raw View
------=_Part_9947_693039573.1514012611580
Content-Type: multipart/alternative;
boundary="----=_Part_9948_146538776.1514012611581"
------=_Part_9948_146538776.1514012611581
Content-Type: text/plain; charset="UTF-8"
On Friday, December 22, 2017 at 11:43:38 PM UTC-5, Jake Arkinstall wrote:
>
> On 23 Dec 2017 02:05, "'Edward Catmur' via ISO C++ Standard - Future
> Proposals" <std-pr...@isocpp.org <javascript:>> wrote:
>
> Undefined behavior is a corollary of writing narrow contracts. If all
> behavior is defined, that is a wide contract.
>
>
> Not necessarily. It's a corollary of writing *optimal* narrow contracts *in
> current C++.* A narrow contract that makes assertations or otherwise has
> every branch returning is still a narrow contract, it's just a little
> smarter.
>
One that makes assertions is narrow. But one that returns in every branch
is not a narrow contract. Returning a value means defining what it means
when the inputs are not what you expect. That makes such a return value*
part* of the contract; you are saying that it's OK to be beyond the
expectations.
Here's a hint about how contracts work: if your function has well-defined
behavior in the event of passing that value, then that value is a
legitimate part of the function's contract.
The issue here is the trade-off between swapping foolproof code for
> optimised code.
>
> This thread has had me thinking about this problem. Narrow contracts are
> useful, but they utilise UB because they are non-enforceable without
> validating on every call. Do we have a mechanism by which we can describe
> *some* narrow contracts*, such that the contract is understood at compile
> time, even if some value is from external input (but filtered and validated
> as all external input should be, unless we want an interrupted data feed,
> corrupted file or a user's typo to actually go through a wrong branch and
> into our main processing.)
>
Isn't this what the whole contracts proposal is all about? Allowing you to
explicitly state contract requirements?
The point of a contract in the language is not to "validate" input; the
point of the contract in the code is to let the compiler know what the
contract is, and therefore that it may freely assume that the input values
will never be anything other than that. Validation* can be* done, but that
would only be as a purely debugging step; the function would still have UB
if the contract is violated.
Essentially, we *enforce* a subset of the underlying type through some
> rules and become able to utilise that subset at compile time with no
> ambiguity.
>
> * not all narrow contracts can be enforced this way. If your input must be
> some solution to some hard problem, you know it to be so as it is passed
> from the solver directly to the function, then there's no chance. But for
> many cases, it could be useful.
>
> Benefits:
>
> - Changing the contract at a later date would then give you warnings about
> impossible conditions (e.g. a switch case of a value that can't exist any
> more), about non-returning branches (if your select cases are no longer
> exhaustive), useful warnings like that. In this sense the contract is no
> longer just existent in some docs and the dev's mind, but is actually
> enforced where it matters - in the code.
>
> - Contract validation need only happen once for each input, rather than
> for each call.
>
That makes no sense. If it's a runtime value, and does runtime validation,
how can the compiler possibly know that it's being called with the same
value?
> Your micro-function remains optimised and it knows exactly what to expect,
> as no other values are even possible inputs to it any more.
>
> - UB is no longer a concern for the narrow contracts that can be expressed.
>
> Although this isn't what I have in mind, one *can* get an idea of this
> with a class, as I have given an example of below. The non-returning branch
> is warned about (though from this code in isolation you can see that is not
> going to be an issue). It's also a bad approach, as a child could be
> created that sets an invalid value. Is there a better approach regarding
> narrow contracts that has been already proposed/in the standard that I'm
> not aware of? Is there any interest in having such a thing? What I'm
> initially thinking of is some template, such as bounded<T,min,max>, and
> some explicit sets of values.
>
The problem with type-based contracts (well, one problem of many
<https://softwareengineering.stackexchange.com/a/311145/28374>) is that
they don't compose well. That doesn't mean that they aren't a useful idea,
but they have strong limitations.
Also this means that the contract leaks. It has to be part of the interface
types of a function or somesuch, which puts contract details in the
function prototype.
--
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/23bfd0f4-16a3-478f-8116-8e8a21d257d4%40isocpp.org.
------=_Part_9948_146538776.1514012611581
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, December 22, 2017 at 11:43:38 PM UTC-5, Jake Ar=
kinstall wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"aut=
o"><div dir=3D"auto"><div class=3D"gmail_quote">On 23 Dec 2017 02:05, "=
;'Edward Catmur' via ISO C++ Standard - Future Proposals" <=
<a onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;" href=3D"javascript:" ta=
rget=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"2qOUT3yLBwAJ">std=
-pr...@isocpp.org</a>> wrote:<br type=3D"attribution"><blockquote style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote"><div>=C2=A0Undefined behavior is a=
corollary of writing narrow contracts. If all behavior is defined, that is=
a wide contract.</div></div></div></div></blockquote></div></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">Not necessarily. It's a corollary=
of writing <i><u>optimal</u></i> narrow contracts <i>in current C++.</i>=
=C2=A0A narrow contract that makes assertations or otherwise has every bran=
ch returning is still a narrow contract, it's just a little smarter.</d=
iv></div></blockquote><div><br></div><div>One that makes assertions is narr=
ow. But one that returns in every branch is not a narrow contract. Returnin=
g a value means defining what it means when the inputs are not what you exp=
ect. That makes such a return value<i> part</i> of the contract; you are sa=
ying that it's OK to be beyond the expectations.</div><div><br></div><d=
iv>Here's a hint about how contracts work: if your function has well-de=
fined behavior in the event of passing that value, then that value is a leg=
itimate part of the function's contract.</div><div><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"auto"><div dir=3D"auto">The =
issue here is the trade-off between swapping foolproof code for optimised c=
ode.</div><div dir=3D"auto"><br></div><div dir=3D"auto">This thread has had=
me thinking about this problem. Narrow contracts are useful, but they util=
ise UB because they are non-enforceable without validating on every call. D=
o we have a mechanism by which we can describe <i>some</i> narrow contracts=
*, such that the contract is understood at compile time, even if some value=
is from external input (but filtered and validated as all external input s=
hould be, unless we want an interrupted data feed, corrupted file or a user=
's typo to actually go through a wrong branch and into our main process=
ing.)</div></div></blockquote><div><br></div><div>Isn't this what the w=
hole contracts proposal is all about? Allowing you to explicitly state cont=
ract requirements?</div><div><br></div><div>The point of a contract in the =
language is not to "validate" input; the point of the contract in=
the code is to let the compiler know what the contract is, and therefore t=
hat it may freely assume that the input values will never be anything other=
than that. Validation<i> can be</i> done, but that would only be as a pure=
ly debugging step; the function would still have UB if the contract is viol=
ated.</div><div><i><br></i></div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div dir=3D"auto"><div dir=3D"auto">Essentially, we <i>enforce</i> a sub=
set of the underlying type through some rules and become able to utilise th=
at subset at compile time with no ambiguity.</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">* not all narrow contracts can be enforced this way. I=
f your input must be some solution to some hard problem, you know it to be =
so as it is passed from the solver directly to the function, then there'=
;s no chance. But for many cases, it could be useful.</div><div dir=3D"auto=
"><br></div><div dir=3D"auto">Benefits:</div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">- Changing the contract at a later date would then give you=
warnings about impossible conditions (e.g. a switch case of a value that c=
an't exist any more), about non-returning branches (if your select case=
s are no longer exhaustive), useful warnings like that. In this sense the c=
ontract is no longer just existent in some docs and the dev's mind, but=
is actually enforced where it matters - in the code.</div><div dir=3D"auto=
"><br></div><div dir=3D"auto">- Contract validation need only happen once f=
or each input, rather than for each call.</div></div></blockquote><div><br>=
</div><div>That makes no sense. If it's a runtime value, and does runti=
me validation, how can the compiler possibly know that it's being calle=
d with the same value?</div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"auto"><div dir=3D"auto">Your micro-function rema=
ins optimised and it knows exactly what to expect, as no other values are e=
ven possible inputs to it any more.</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">- UB is no longer a concern for the narrow contracts that can b=
e expressed.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Although th=
is isn't what I have in mind, one <i>can</i> get an idea of this with a=
class, as I have given an example of below. The non-returning branch is wa=
rned about (though from this code in isolation you can see that is not goin=
g to be an issue). It's also a bad approach, as a child could be create=
d that sets an invalid value. Is there a better approach regarding narrow c=
ontracts that has been already proposed/in the standard that I'm not aw=
are of? Is there any interest in having such a thing? What I'm initiall=
y thinking of is some template, such as bounded<T,min,max>, and some =
explicit sets of values.</div></div></blockquote><div><br></div><div>The pr=
oblem with type-based contracts (well, <a href=3D"https://softwareengineeri=
ng.stackexchange.com/a/311145/28374">one problem of many</a>) is that they =
don't compose well. That doesn't mean that they aren't a useful=
idea, but they have strong limitations.</div><div><br></div><div>Also this=
means that the contract leaks. It has to be part of the interface types of=
a function or somesuch, which puts contract details in the function protot=
ype.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"auto"><div dir=3D"auto"></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/23bfd0f4-16a3-478f-8116-8e8a21d257d4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/23bfd0f4-16a3-478f-8116-8e8a21d257d4=
%40isocpp.org</a>.<br />
------=_Part_9948_146538776.1514012611581--
------=_Part_9947_693039573.1514012611580--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Sat, 23 Dec 2017 10:02:45 +0100
Raw View
--001a114075a26356670560fe325f
Content-Type: text/plain; charset="UTF-8"
On Fri, Dec 22, 2017 at 9:14 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> If you don't know if you're throwing from destructors, then you probably
don't know if clashes can't happen due to destructor throwing.
In this thread, we have seen advocacy of permitting functions to contain
statically possible UB, because the programmer is smart enough to ensure
that it won't happen at runtime. The same argument would work here. The
programmer who wrote an exception throwing destruction (potentially
indirectly) could have ensured that would never happen when unwinding. Why
am I unsure now? Because that clever guy is no longer with us.
The above is a fact of life. We inherit code and have to assume it is
correct without knowing all the details. A silent change forces us to stop
assuming that and embark on a costly review of the details and runtime
behaviours. That is, if we are smart enough to understand there is such a
change to begin with, which is not granted. The compiler's statement "I
reject this piece of code" assumes much less.
Cheers,
V.
--
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/CAA7YVg3tyjYdkEH8bL%3Dk0-E2QV-4vCRQ6MVnLKy1Ut6ZZ2dOSA%40mail.gmail.com.
--001a114075a26356670560fe325f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Dec 22, 2017 at 9:14 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></s=
pan> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_q=
uote">> If you don't know if you're throwing from destructors, t=
hen you probably don't know if clashes can't happen due to destruct=
or throwing.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_=
quote">In this thread, we have seen advocacy of permitting functions to con=
tain statically possible UB, because the programmer is smart enough to ensu=
re that it won't happen at runtime. The same argument would work here. =
The programmer who wrote an exception throwing destruction (potentially ind=
irectly) could have ensured that would never happen when unwinding. Why am =
I unsure now? Because that clever guy is no longer with us.</div><div class=
=3D"gmail_quote"><br></div><div class=3D"gmail_quote">The above is a fact o=
f life. We inherit code and have to assume it is correct without knowing al=
l the details. A silent change forces us to stop assuming that and embark o=
n a costly review of the details and runtime behaviours. That is, if we are=
smart enough to understand there is such a change to begin with, which is =
not granted. The compiler's statement "I reject this piece of code=
" assumes much less.</div><div class=3D"gmail_quote">=C2=A0<br></div><=
div class=3D"gmail_quote">Cheers,</div><div class=3D"gmail_quote">V.</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/CAA7YVg3tyjYdkEH8bL%3Dk0-E2QV-4vCRQ6M=
VnLKy1Ut6ZZ2dOSA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3tyjYdkE=
H8bL%3Dk0-E2QV-4vCRQ6MVnLKy1Ut6ZZ2dOSA%40mail.gmail.com</a>.<br />
--001a114075a26356670560fe325f--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Sat, 23 Dec 2017 10:17:53 +0100
Raw View
--f403045fc1ac77dc560560fe685f
Content-Type: text/plain; charset="UTF-8"
On Fri, Dec 22, 2017 at 9:14 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> I hope that you are aware that it is relatively uncommon to be able to
branch for a new compiler and fix compilation errors, while worrying about
crashes introduced by a corner change to language semantics.
It was not "while" but "versus" in my argument.
> Most projects when faced by a sea of errors from a new compiler will
simply refuse to upgrade, meaning that they are stuck on the old version
either of the language or of the compiler and thereby hold up adoption of
the new version of the standard and the compiler.
That is exactly what I said. They will have to hold on till the sea of
errors dries up, which is easily observable.
Cheers,
V.
--
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/CAA7YVg0wjgLvdNqL-0OdtGhhRQcHaXTwJ2wbejxuptT5dRYZnw%40mail.gmail.com.
--f403045fc1ac77dc560560fe685f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Dec 22, 2017 at 9:14 PM, 'Edward Catmur' via ISO C++ Standard -=
Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@iso=
cpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:<b=
r><div><br></div><div>> I hope that you are aware that it is relatively =
uncommon to be able to branch for a new compiler and fix compilation errors=
, while worrying about crashes introduced by a corner change to language se=
mantics.</div><div><br></div><div>It was not "while" but "ve=
rsus" in my argument.</div><div><br></div><div>> Most projects when=
faced by a sea of errors from a new compiler will simply refuse to upgrade=
, meaning that they are stuck on the old version either of the language or =
of the compiler and thereby hold up adoption of the new version of the stan=
dard and the compiler.</div><div><br></div><div>That is exactly what I said=
.. They will have to hold on till the sea of errors dries up, which is easil=
y observable.</div><div><br></div><div>Cheers,</div><div>V.</div></div></di=
v></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/CAA7YVg0wjgLvdNqL-0OdtGhhRQcHaXTwJ2wb=
ejxuptT5dRYZnw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0wjgLvdNqL=
-0OdtGhhRQcHaXTwJ2wbejxuptT5dRYZnw%40mail.gmail.com</a>.<br />
--f403045fc1ac77dc560560fe685f--
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Sat, 23 Dec 2017 13:24:25 +0000
Raw View
--001a1135253a23e830056101da13
Content-Type: text/plain; charset="UTF-8"
On 23 Dec 2017 07:03, "Nicol Bolas" <jmckesson@gmail.com> wrote:
The point of a contract in the language is not to "validate" input; the
point of the contract in the code is to let the compiler know what the
contract is, and therefore that it may freely assume that the input values
will never be anything other than that. Validation* can be* done, but that
would only be as a purely debugging step; the function would still have UB
if the contract is violated.
I'm suggesting something different. Something that *enforces* the contract
*before* a value is ever passed to a function which expects the contract to
be fulfilled. Rather than it simply expecting the contract to be fulfilled,
I'm going a step further and suggesting that it would be useful to have a
mechanism by which it *must* be fulfilled for it to be passed.
That makes no sense. If it's a runtime value, and does runtime validation,
how can the compiler possibly know that it's being called with the same
value?
That only applies if you take your above version of what I'm suggesting,
rather than what I'm actually suggesting. I'm talking about a type, to
which input is cast, which cannot take a value which doesn't satisfy the
contract. If you cast something to such a type, that type is understood at
compile time, not runtime. You then pass a value of that *type* to some
function for which we expect this contract and undefined behaviour *cannot*
occur within the function.
An example is if you have a variable A, say a long, which you cast to an
unsigned int B after some checks. From here the compiler is fully aware
that B is an int without voodoo. You can cast a negative long into an
unsigned int which doesn't represent the input, and here we end up with the
same issue that a branch is taken which doesn't reflect the value of A. I'm
thinking of a type for B, as a subtype of A's type, which cannot be cast to
in such a way, and that has well-defined behaviour when A is not a valid B
- something is thrown, an assertation is made, whatever as long as B cannot
be used.
You can see exactly what I mean with my example code. A programmer, by
inspection, can see that no branch in the function is non-returning because
it is not possible for any value other than 1-5 to be passed to it due to
the restrictions imposed in the constructor. The problem is that the
compiler does not do such inspection, because it is ill-equipped to do so.
It has no way of understanding the contract. I'd like something that allows
the compiler to understand the contract.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPq1ZjgF4OtM8AQaUMzjEbW9S9J%2BAR7w0pDuKdJtA1vNQ%40mail.gmail.com.
--001a1135253a23e830056101da13
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div class=3D"gmail_extra" dir=3D"auto"><div class=3D"gma=
il_quote">On 23 Dec 2017 07:03, "Nicol Bolas" <<a href=3D"mail=
to:jmckesson@gmail.com">jmckesson@gmail.com</a>> wrote:<br type=3D"attri=
bution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>The point of a contr=
act in the language is not to "validate" input; the point of the =
contract in the code is to let the compiler know what the contract is, and =
therefore that it may freely assume that the input values will never be any=
thing other than that. Validation<i> can be</i> done, but that would only b=
e as a purely debugging step; the function would still have UB if the contr=
act is violated.</div></div></blockquote></div></div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">I'm suggesting something different. Something t=
hat <b>enforces</b>=C2=A0the contract <i>before</i>=C2=A0a value is ever pa=
ssed to a function which expects the contract to be fulfilled. Rather than =
it simply expecting the contract to be fulfilled, I'm going a step furt=
her and suggesting that it would be useful to have a mechanism by which it =
<i>must</i>=C2=A0be fulfilled for it to be passed.</div><div class=3D"gmail=
_extra" dir=3D"auto"></div><div dir=3D"auto"><br></div><div class=3D"gmail_=
extra" dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div>That makes no sense. If it's a runtime value, and do=
es runtime validation, how can the compiler possibly know that it's bei=
ng called with the same value?</div></div></blockquote></div></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">That only applies if you take your ab=
ove version of what I'm suggesting, rather than what I'm actually s=
uggesting. I'm talking about a type, to which input is cast, which cann=
ot take a value which doesn't satisfy the contract. If you cast somethi=
ng to such a type, that type is understood at compile time, not runtime. Yo=
u then pass a value of that <i>type</i> to some function for which we expec=
t this contract and undefined behaviour <i>cannot</i> occur within the func=
tion.</div><div dir=3D"auto"><br></div><div dir=3D"auto">An example is if y=
ou have a variable A, say a long, which you cast to an unsigned int B after=
some checks. From here the compiler is fully aware that B is an int withou=
t voodoo. You can cast a negative long into an unsigned int which doesn'=
;t represent the input, and here we end up with the same issue that a branc=
h is taken which doesn't reflect the value of A. I'm thinking of a =
type for B, as a subtype of A's type, which cannot be cast to in such a=
way, and that has well-defined behaviour when A is not a valid B - somethi=
ng is thrown, an assertation is made, whatever as long as B cannot be used.=
</div><div dir=3D"auto"><br></div><div dir=3D"auto">You can see exactly wha=
t I mean with my example code. A programmer, by inspection, can see that no=
branch in the function is non-returning because it is not possible for any=
value other than 1-5 to be passed to it due to the restrictions imposed in=
the constructor. The problem is that the compiler does not do such inspect=
ion, because it is ill-equipped to do so. It has no way of understanding th=
e contract. I'd like something that allows the compiler to understand t=
he contract.</div><div class=3D"gmail_extra" dir=3D"auto"></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPq1ZjgF4OtM8AQaUMzjEbW9S9J%2=
BAR7w0pDuKdJtA1vNQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPq1Z=
jgF4OtM8AQaUMzjEbW9S9J%2BAR7w0pDuKdJtA1vNQ%40mail.gmail.com</a>.<br />
--001a1135253a23e830056101da13--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 23 Dec 2017 07:55:27 -0800 (PST)
Raw View
------=_Part_10481_626086929.1514044527224
Content-Type: multipart/alternative;
boundary="----=_Part_10482_1200237171.1514044527224"
------=_Part_10482_1200237171.1514044527224
Content-Type: text/plain; charset="UTF-8"
On Saturday, December 23, 2017 at 4:02:50 AM UTC-5, Viacheslav Usov wrote:
>
> On Fri, Dec 22, 2017 at 9:14 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
> > If you don't know if you're throwing from destructors, then you probably
> don't know if clashes can't happen due to destructor throwing.
>
> In this thread, we have seen advocacy of permitting functions to contain
> statically possible UB, because the programmer is smart enough to ensure
> that it won't happen at runtime. The same argument would work here. The
> programmer who wrote an exception throwing destruction (potentially
> indirectly) could have ensured that would never happen when unwinding. Why
> am I unsure now? Because that clever guy is no longer with us.
>
Which goes back to my point. The programmer you lost would have to have
known which types throw from their destructors. And therefore, which
switching to C++11, he would have known which types needed to use
`noexcept(false)` in their destructors.
Let's not forget that it's* really important* for you to rebuild that lost
domain knowledge. Because as it currently stands, you could have broken
code and not know it (whether C++03 or C++11). This is something you need
to do for the health of your codebase.
The above is a fact of life. We inherit code and have to assume it is
> correct without knowing all the details. A silent change forces us to stop
> assuming that and embark on a costly review of the details and runtime
> behaviours. That is, if we are smart enough to understand there is such a
> change to begin with, which is not granted. The compiler's statement "I
> reject this piece of code" assumes much less.
>
And a noisy change makes it impossible for you to cross-compile across
versions. That too is a fact of life.
>
--
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/21fec149-204a-4f53-bdf0-fbd19af78291%40isocpp.org.
------=_Part_10482_1200237171.1514044527224
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, December 23, 2017 at 4:02:50 AM UTC-5, Viache=
slav Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div><div class=3D"gmail_quote">On Fri, Dec 22, 2017 at 9:14 PM, Nicol B=
olas <span dir=3D"ltr"><<a onmousedown=3D"this.href=3D'javascript:&#=
39;;return true;" onclick=3D"this.href=3D'javascript:';return true;=
" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-ma=
ilto=3D"JxnQhaGZBwAJ">jmck...@gmail.com</a>></span> wrote:</div><div cla=
ss=3D"gmail_quote"><br></div><div class=3D"gmail_quote">> If you don'=
;t know if you're throwing from destructors, then you probably don'=
t know if clashes can't happen due to destructor throwing.</div><div cl=
ass=3D"gmail_quote"><br></div><div class=3D"gmail_quote">In this thread, we=
have seen advocacy of permitting functions to contain statically possible =
UB, because the programmer is smart enough to ensure that it won't happ=
en at runtime. The same argument would work here. The programmer who wrote =
an exception throwing destruction (potentially indirectly) could have ensur=
ed that would never happen when unwinding. Why am I unsure now? Because tha=
t clever guy is no longer with us.</div></div></div></blockquote><div><br><=
/div><div>Which goes back to my point. The programmer you lost would have t=
o have known which types throw from their destructors. And therefore, which=
switching to C++11, he would have known which types needed to use `noexcep=
t(false)` in their destructors.</div><div><br></div><div>Let's not forg=
et that it's<i> really important</i> for you to rebuild that lost domai=
n knowledge. Because as it currently stands, you could have broken code and=
not know it (whether C++03 or C++11). This is something you need to do for=
the health of your codebase.</div><div><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote">The ab=
ove is a fact of life. We inherit code and have to assume it is correct wit=
hout knowing all the details. A silent change forces us to stop assuming th=
at and embark on a costly review of the details and runtime behaviours. Tha=
t is, if we are smart enough to understand there is such a change to begin =
with, which is not granted. The compiler's statement "I reject thi=
s piece of code" assumes much less.</div></div></div></blockquote><div=
><br></div><div>And a noisy change makes it impossible for you to cross-com=
pile across versions. That too is a fact of life.</div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;">
</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/21fec149-204a-4f53-bdf0-fbd19af78291%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/21fec149-204a-4f53-bdf0-fbd19af78291=
%40isocpp.org</a>.<br />
------=_Part_10482_1200237171.1514044527224--
------=_Part_10481_626086929.1514044527224--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 23 Dec 2017 08:00:09 -0800 (PST)
Raw View
------=_Part_10596_284752746.1514044809470
Content-Type: multipart/alternative;
boundary="----=_Part_10597_470136001.1514044809470"
------=_Part_10597_470136001.1514044809470
Content-Type: text/plain; charset="UTF-8"
On Saturday, December 23, 2017 at 8:24:28 AM UTC-5, Jake Arkinstall wrote:
>
> On 23 Dec 2017 07:03, "Nicol Bolas" <jmck...@gmail.com <javascript:>>
> wrote:
>
> The point of a contract in the language is not to "validate" input; the
> point of the contract in the code is to let the compiler know what the
> contract is, and therefore that it may freely assume that the input values
> will never be anything other than that. Validation* can be* done, but
> that would only be as a purely debugging step; the function would still
> have UB if the contract is violated.
>
>
> I'm suggesting something different. Something that *enforces* the
> contract *before* a value is ever passed to a function which expects the
> contract to be fulfilled. Rather than it simply expecting the contract to
> be fulfilled, I'm going a step further and suggesting that it would be
> useful to have a mechanism by which it *must* be fulfilled for it to be
> passed.
>
I understand what you want, but that doesn't change the fact that what you
describe is* not a contract*. If you validate your inputs, whether it's the
function doing it or something outside of the function that is an
inexorable part of its interface, then that's not a part of your function's
contract.
My point is that you're using the words incorrectly. You're not specifying
a contract; you're creating a type requirement on your function.
The state of inputs given to a function can be one of the following:
1) Values which result in a well-defined, positive result.
2) Values which result in a well-defined, erroneous condition (ie: error
codes, throwing, unexpected, etc)
3) Values which result in undefined behavior.
Contracts deal with case #3. If you use a type which prevents your function
from ever doing #3, then your function has a wide contract. It can take any
value; it may error out on some values, but it does so in a well-defined
manor.
Yes, we want compilers to understand contracts, but* not like this*. Not by
putting contracts in the function's interface and so forth. That's why the
actual contracts proposal sticks them inside the function itself, where the
compiler can see it but where the outside world cannot.
If you want to bind requirements in types and have them fail in
well-defined ways, that's fine for you. But that's not what contracts are
all about; such functions do not have narrow contracts.
At this point, the discussion clearly seems to be a matter of coding style:
people who believe that narrow contracts represent broken code vs. people
who disagree.
C++ should not define coding style.
>
--
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/ff4ff8af-2d6b-4dc1-bba0-7b1438add4ac%40isocpp.org.
------=_Part_10597_470136001.1514044809470
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, December 23, 2017 at 8:24:28 AM UTC-5, Jake A=
rkinstall wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"au=
to"><div dir=3D"auto"><div class=3D"gmail_quote">On 23 Dec 2017 07:03, &quo=
t;Nicol Bolas" <<a onmousedown=3D"this.href=3D'javascript:'=
;return true;" onclick=3D"this.href=3D'javascript:';return true;" h=
ref=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailt=
o=3D"BR4qOOinBwAJ">jmck...@gmail.com</a>> wrote:<br type=3D"attribution"=
><blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div>The point of a contract in the language is =
not to "validate" input; the point of the contract in the code is=
to let the compiler know what the contract is, and therefore that it may f=
reely assume that the input values will never be anything other than that. =
Validation<i> can be</i> done, but that would only be as a purely debugging=
step; the function would still have UB if the contract is violated.</div><=
/div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>I'm suggesting something different. Something that <b>enforces</b>=C2=
=A0the contract <i>before</i>=C2=A0a value is ever passed to a function whi=
ch expects the contract to be fulfilled. Rather than it simply expecting th=
e contract to be fulfilled, I'm going a step further and suggesting tha=
t it would be useful to have a mechanism by which it <i>must</i>=C2=A0be fu=
lfilled for it to be passed.</div></div></blockquote><div><br></div><div>I =
understand what you want, but that doesn't change the fact that what yo=
u describe is<i> not a contract</i>. If you validate your inputs, whether i=
t's the function doing it or something outside of the function that is =
an inexorable part of its interface, then that's not a part of your fun=
ction's contract.</div><div><br></div><div>My point is that you're =
using the words incorrectly. You're not specifying a contract; you'=
re creating a type requirement on your function.</div><div><br></div><div>T=
he state of inputs given to a function can be one of the following:</div><d=
iv><br></div><div>1) Values which result in a well-defined, positive result=
..</div><div>2) Values which result in a well-defined, erroneous condition (=
ie: error codes, throwing, unexpected, etc)</div><div>3) Values which resul=
t in undefined behavior.</div><div><br></div><div>Contracts deal with case =
#3. If you use a type which prevents your function from ever doing #3, then=
your function has a wide contract. It can take any value; it may error out=
on some values, but it does so in a well-defined manor.</div><div><br></di=
v><div>Yes, we want compilers to understand contracts, but<i> not like this=
</i>. Not by putting contracts in the function's interface and so forth=
.. That's why the actual contracts proposal sticks them inside the funct=
ion itself, where the compiler can see it but where the outside world canno=
t.</div><div><br></div><div>If you want to bind requirements in types and h=
ave them fail in well-defined ways, that's fine for you. But that's=
not what contracts are all about; such functions do not have narrow contra=
cts.</div><div><br></div><div>At this point, the discussion clearly seems t=
o be a matter of coding style: people who believe that narrow contracts rep=
resent broken code vs. people who disagree.</div><div><br></div><div>C++ sh=
ould not define coding style.</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">
</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/ff4ff8af-2d6b-4dc1-bba0-7b1438add4ac%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ff4ff8af-2d6b-4dc1-bba0-7b1438add4ac=
%40isocpp.org</a>.<br />
------=_Part_10597_470136001.1514044809470--
------=_Part_10596_284752746.1514044809470--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 23 Dec 2017 18:19:46 +0200
Raw View
On 23 December 2017 at 18:00, Nicol Bolas <jmckesson@gmail.com> wrote:
> Yes, we want compilers to understand contracts, but not like this. Not by
> putting contracts in the function's interface and so forth. That's why the
> actual contracts proposal sticks them inside the function itself, where the
> compiler can see it but where the outside world cannot.
The actual contracts proposal supports both contract asserts inside
function definitions
and contract attributes on function declarations. The latter are very
much in the interface.
--
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/CAFk2RUa6M%2BQAuwhca-p8WEVqk7j8k%2B5SQRTwQpE0snHUGC10Ow%40mail.gmail.com.
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Sat, 23 Dec 2017 17:34:36 +0100
Raw View
--94eb2c0dbf164e9b120561048273
Content-Type: text/plain; charset="UTF-8"
On Sat, Dec 23, 2017 at 4:55 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> Which goes back to my point. The programmer you lost would have to have
known which types throw from their destructors. And therefore, which
switching to C++11, he would have known which types needed to use
`noexcept(false)` in their destructors.
The "lost programmer" was a simplification for the purpose of the argument.
I could just say "lost knowledge", something was done, found adequate, and
details then forgotten. And even if not fully forgotten, then not recalled
until too late. This is how human brains really work.
> Let's not forget that it's* really important* for you to rebuild that
lost domain knowledge.
Great advice, given infinite time and no other priorities.
> Because as it currently stands, you could have broken code and not know
it (whether C++03 or C++11).
A trivial statement that can be said of any real-life code base,
> And a noisy change makes it impossible for you to cross-compile across
versions. That too is a fact of life.
It takes an effort, but the effort is not huge. If there are really massive
compilation errors of the same nature, I could even spend a day to develop
a tool that patches my code base just to get rid of those messages in some
simple way. In this thread's context, that would be inserting return {}; at
the end of each function flagged as problematic. That would probably not
fix every error, but if that again left a class of similar errors, I would
adjust the patch accordingly. Then, of course I would still have to spend
time to review whether those simple patches were really good, but that
would be another problem.
Cheers,
V.
--
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/CAA7YVg3O9aujRo40BAXB2DGprD77URsfPQ5s%3DR5KVVTOMEkkzQ%40mail.gmail.com.
--94eb2c0dbf164e9b120561048273
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Dec 23, 2017 at 4:55 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></s=
pan> wrote:<br><div><br></div><div>>=C2=A0 Which goes back to my point. =
The programmer you lost would have to have known which types throw from the=
ir destructors. And therefore, which switching to C++11, he would have know=
n which types needed to use `noexcept(false)` in their destructors.</div><d=
iv><br></div><div>The "lost programmer" was a simplification for =
the purpose of the argument. I could just say "lost knowledge", s=
omething was done, found adequate, and details then forgotten. And even if =
not fully forgotten, then not recalled until too late. This is how human br=
ains really work.</div><div><br></div><div>> Let's not forget that i=
t's<i> really important</i> for you to rebuild that lost domain knowled=
ge.</div><div><br></div><div>Great advice, given infinite time and no other=
priorities.</div><div><br></div><div>> Because as it currently stands, =
you could have broken code and not know it (whether C++03 or C++11).</div><=
div><br></div><div>A trivial statement that can be said of any real-life co=
de base,</div><div><br></div><div>>=C2=A0 And a noisy change makes it im=
possible for you to cross-compile across versions. That too is a fact of li=
fe.</div><div><br></div><div>It takes an effort, but the effort is not huge=
.. If there are really massive compilation errors of the same nature, I coul=
d even spend a day to develop a tool that patches my code base just to get =
rid of those messages in some simple way. In this thread's context, tha=
t would be inserting return {}; at the end of each function flagged as prob=
lematic. That would probably not fix every error, but if that again left a =
class of similar errors, I would adjust the patch accordingly. Then, of cou=
rse I would still have to spend time to review whether those simple patches=
were really good, but that would be another problem.</div><div><br></div><=
div>Cheers,</div><div>V.</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/CAA7YVg3O9aujRo40BAXB2DGprD77URsfPQ5s=
%3DR5KVVTOMEkkzQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3O9aujRo=
40BAXB2DGprD77URsfPQ5s%3DR5KVVTOMEkkzQ%40mail.gmail.com</a>.<br />
--94eb2c0dbf164e9b120561048273--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Sat, 23 Dec 2017 16:42:29 +0000
Raw View
--089e082802847e84e00561049efd
Content-Type: text/plain; charset="UTF-8"
On 23 Dec 2017 12:36 am, "Jake Arkinstall" <jake.arkinstall@gmail.com>
wrote:
Yeah, and that proposal is well and truly down the drain from what I've
seen of this thread.
Are we:
A) in agreement that a std::unreachable is a good evolution of the proposal?
I am very much in favor of this form.
B) if (A), in agreement about the behaviour of std::unreachable - whether
it should cause an abort, branch removal, or it undefined to allow anything
from to branch removal?
Definitely undefined, as this gives implementors maximum latitude to favor
safety, debuggability, or performance.
C) whether it should have the possibility of a pseudo return type to allow
devs to "return" in all branches from the context of the function alone?
E.g.
T neverUsed(){
return std::unreachable<T>(); //technically returns a T.
}
I'm not sure. I think vendors' input would be valuable here, as that would
only be necessary if they cannot commit to disable return warnings/errors
on paths that pass through std::unreachable except by giving it a return
type. On the other hand it may be useful and more clear to some users. It
would have the advantage that it could be used within an expression - as a
ternary conditional branch, say. A downside might be that this would allow
its misuse as a substitute for std::declval. In any case it should be
possible to use std::unreachable without supplying a template parameter, so
T should default to void.
On 23 Dec 2017 00:26, "Nicol Bolas" <jmckesson@gmail.com> wrote:
> On Friday, December 22, 2017 at 5:49:37 PM UTC-5, Richard Hodges wrote:
>>
>> > The feature under discussion here makes it so that your code either
>> compiles as C++17 or as C++20, but not both.
>>
>> Correction: The feature under discussion here makes it so that your code
>> either compiles as C++17 on gcc and clang but not MSVC or as C++20 on
>> everything.
>>
>> i.e. it makes compiler behaviour more portable and more predictable.
>>
>
> How do you figure?
>
> From the OP and the title of the thread, the feature is essentially "make
> programs fail to compile if they do not statically return, throw, call a
> `[[noreturn]]` function, or invoke 'unreachable'." That's the feature* as
> you defined it*.
>
> This feature has nothing to do with portability. If MSVC is not compiling
> legal C++17, then that's its fault, not the standard's.
>
>> --
> 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/is
> ocpp.org/d/msgid/std-proposals/99066c40-1e2d-490c-b2e4-
> c7b37e5a3a8f%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/99066c40-1e2d-490c-b2e4-c7b37e5a3a8f%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to a topic in the
Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/
isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/
isocpp.org/d/msgid/std-proposals/CAC%2B0CCNqTNJGRBavNoe6w6-W8CZS%
3D%3DPt807Twg6TLS8OvPTouQ%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNqTNJGRBavNoe6w6-W8CZS%3D%3DPt807Twg6TLS8OvPTouQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
..
--
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/CAJnLdObdvg%2BrpgkK6WXEUhB6P88%3DYSuDS%3DxRduTsjCovBoDyxQ%40mail.gmail.com.
--089e082802847e84e00561049efd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On 23 Dec 2017 12:36 am, "Jake Arkinstall" <<a href=
=3D"mailto:jake.arkinstall@gmail.com">jake.arkinstall@gmail.com</a>> wro=
te:<br type=3D"attribution"><blockquote class=3D"quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto">Yeah=
, and that proposal is well and truly down the drain from what I've see=
n of this thread.<div dir=3D"auto"><br></div><div dir=3D"auto">Are we:</div=
><div dir=3D"auto"><br><div dir=3D"auto">A) in agreement that a std::unreac=
hable is a good evolution of the proposal?</div><div dir=3D"auto"></div></d=
iv></div></blockquote></div></div></div><div dir=3D"auto"><br></div><div di=
r=3D"auto">I am very much in favor of this form.=C2=A0</div><div dir=3D"aut=
o"><br></div><div dir=3D"auto"><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto"><div=
dir=3D"auto">B) if (A), in agreement about the behaviour of std::unreachab=
le - whether it should cause an abort, branch removal, or it undefined to a=
llow anything from to branch removal?</div><div dir=3D"auto"></div></div></=
div></blockquote></div></div></div><div dir=3D"auto"><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote"><blockquote class=3D"quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto">=
<div dir=3D"auto"><div dir=3D"auto"></div></div></div></blockquote></div></=
div></div><div dir=3D"auto"><br></div><div dir=3D"auto">Definitely undefine=
d, as this gives implementors maximum latitude to favor safety, debuggabili=
ty, or performance.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto=
"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=
=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"auto"><div dir=3D"auto"><div dir=3D"auto"><br></div><di=
v dir=3D"auto">C) whether it should have the possibility of a pseudo return=
type to allow devs to "return" in all branches from the context =
of the function alone? E.g.</div><div dir=3D"auto"><br></div><div dir=3D"au=
to">T neverUsed(){</div><div dir=3D"auto">=C2=A0 =C2=A0 return std::unreach=
able<T>(); //technically returns a T.</div><div dir=3D"auto">}</div><=
/div></div><div class=3D"gmail_extra"></div></blockquote></div></div></div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">I'm not sure. I think ven=
dors' input would be valuable here, as that would only be necessary if =
they cannot commit to disable return warnings/errors on paths that pass thr=
ough std::unreachable except by giving it a return type. On the other hand =
it may be useful and more clear to some users. It would have the advantage =
that it could be used within an expression - as a ternary conditional branc=
h, say. A downside might be that this would allow its misuse as a substitut=
e for std::declval. In any case it should be possible to use std::unreachab=
le without supplying a template parameter, so T should default to void.=C2=
=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_=
extra"><div class=3D"gmail_quote"><blockquote class=3D"quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote"><div class=3D"quoted-text">On 23 =
Dec 2017 00:26, "Nicol Bolas" <<a href=3D"mailto:jmckesson@gma=
il.com" target=3D"_blank">jmckesson@gmail.com</a>> wrote:<br type=3D"att=
ribution"></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"quoted-text"><=
div dir=3D"ltr">On Friday, December 22, 2017 at 5:49:37 PM UTC-5, Richard H=
odges wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">>=
=C2=A0<span style=3D"font-size:12.8px">The feature under discussion here ma=
kes it so that your code either compiles as C++17 or as C++20, but not both=
..</span><div><span style=3D"font-size:12.8px"><br></span></div><div><span s=
tyle=3D"font-size:12.8px">Correction:=C2=A0</span><span style=3D"font-size:=
12.8px">The feature under discussion here makes it so that your code either=
compiles as C++17 on gcc and clang but not MSVC or as C++20 on everything.=
</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><s=
pan style=3D"font-size:12.8px">i.e. it makes compiler behaviour more portab=
le and more predictable.</span></div></div></blockquote><div><br></div><div=
>How do you figure?</div><div><br></div><div>From the OP and the title of t=
he thread, the feature is essentially "make programs fail to compile i=
f they do not statically return, throw, call a `[[noreturn]]` function, or =
invoke 'unreachable'." That's the feature<i> as you define=
d it</i>.</div><div><br></div><div>This feature has nothing to do with port=
ability. If MSVC is not compiling legal C++17, then that's its fault, n=
ot the standard's.<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div>
<p></p>
-- <br></div><div class=3D"quoted-text">
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></div>
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@isoc<wbr>pp.org</a>.<div class=3D"quoted-t=
ext"><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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/99066c40-1e2d-490c-b2e4-c7b37e5a3a8f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/9906=
6c40-1e2d-490c-b2e4-<wbr>c7b37e5a3a8f%40isocpp.org</a>.<br>
</div></blockquote></div></div><div class=3D"quoted-text">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/U=
u2QViiWh4k/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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/CAC%2B0CCNqTNJGRBavNoe6w6-W8CZS%3D%3D=
Pt807Twg6TLS8OvPTouQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgi=
d/std-<wbr>proposals/CAC%<wbr>2B0CCNqTNJGRBavNoe6w6-W8CZS%<wbr>3D%3DPt807Tw=
g6TLS8OvPTouQ%<wbr>40mail.gmail.com</a>.<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/CAJnLdObdvg%2BrpgkK6WXEUhB6P88%3DYSuD=
S%3DxRduTsjCovBoDyxQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObdvg=
%2BrpgkK6WXEUhB6P88%3DYSuDS%3DxRduTsjCovBoDyxQ%40mail.gmail.com</a>.<br />
--089e082802847e84e00561049efd--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 23 Dec 2017 08:50:20 -0800 (PST)
Raw View
------=_Part_11148_2129917799.1514047820319
Content-Type: multipart/alternative;
boundary="----=_Part_11149_1381395637.1514047820320"
------=_Part_11149_1381395637.1514047820320
Content-Type: text/plain; charset="UTF-8"
On Saturday, December 23, 2017 at 11:42:32 AM UTC-5, Edward Catmur wrote:
>
>
>
> On 23 Dec 2017 12:36 am, "Jake Arkinstall" <jake.ar...@gmail.com
> <javascript:>> wrote:
>
> Yeah, and that proposal is well and truly down the drain from what I've
> seen of this thread.
>
> Are we:
>
> A) in agreement that a std::unreachable is a good evolution of the
> proposal?
>
>
> I am very much in favor of this form.
>
> B) if (A), in agreement about the behaviour of std::unreachable - whether
> it should cause an abort, branch removal, or it undefined to allow anything
> from to branch removal?
>
>
> Definitely undefined, as this gives implementors maximum latitude to favor
> safety, debuggability, or performance.
>
>
> C) whether it should have the possibility of a pseudo return type to allow
> devs to "return" in all branches from the context of the function alone?
> E.g.
>
> T neverUsed(){
> return std::unreachable<T>(); //technically returns a T.
> }
>
>
> I'm not sure. I think vendors' input would be valuable here, as that would
> only be necessary if they cannot commit to disable return warnings/errors
> on paths that pass through std::unreachable except by giving it a return
> type. On the other hand it may be useful and more clear to some users.
>
Besides the DRY issue around the return type, the other issue here is that
it doesn't help the compiler.
After all, if you called `std::terminate`, that's a [[noreturn]] function.
So the compiler automatically knows that control is never coming back, so
there is no possibility of UB. And this should be true of *any*
[[noreturn]] function; calling one should stop the compiler from warning
about a lack of a `return` statement in that branch. Since the compiler
already needs to be on the lookout for [[noreturn]]s, `std::unreachable`'s
ability to turn off such warnings can simply be due to being declared
[[noreturn]].
That is, the compiler already has to handle this for other cases of calling
a function that never returns here. Just let it handle it for this case too.
Further, the code should not act like it's going to return control to that
location. `unreachable` is not really a function; it doesn't do anything.
It's a marker in the code, so it shouldn't look like it's going to return
something.
By all rights, `unreachable` should be a keyword. And if the committee had
accepted the "soft keywords" idea, it would be.
>
--
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/abc5bd57-ea7b-4ba3-bcac-a6742e893353%40isocpp.org.
------=_Part_11149_1381395637.1514047820320
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, December 23, 2017 at 11:42:32 AM UTC-=
5, Edward Catmur wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"auto"><div><br><div><br><div class=3D"gmail_quote">On 23 Dec 2017 12:3=
6 am, "Jake Arkinstall" <<a onmousedown=3D"this.href=3D'ja=
vascript:';return true;" onclick=3D"this.href=3D'javascript:';r=
eturn true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-ob=
fuscated-mailto=3D"yIR4areyBwAJ">jake.ar...@gmail.com</a>> wrote:<br typ=
e=3D"attribution"><blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"auto">Yeah, and that proposal is wel=
l and truly down the drain from what I've seen of this thread.<div dir=
=3D"auto"><br></div><div dir=3D"auto">Are we:</div><div dir=3D"auto"><br><d=
iv dir=3D"auto">A) in agreement that a std::unreachable is a good evolution=
of the proposal?</div><div dir=3D"auto"></div></div></div></blockquote></d=
iv></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">I am very much=
in favor of this form.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"=
auto"><div><div class=3D"gmail_quote"><blockquote style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div dir=
=3D"auto"><div dir=3D"auto">B) if (A), in agreement about the behaviour of =
std::unreachable - whether it should cause an abort, branch removal, or it =
undefined to allow anything from to branch removal?</div><div dir=3D"auto">=
</div></div></div></blockquote></div></div></div><div dir=3D"auto"><div><di=
v class=3D"gmail_quote"><blockquote style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto"><div d=
ir=3D"auto"></div></div></div></blockquote></div></div></div><div dir=3D"au=
to"><br></div><div dir=3D"auto">Definitely undefined, as this gives impleme=
ntors maximum latitude to favor safety, debuggability, or performance.=C2=
=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div><div class=3D"g=
mail_quote"><blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto"><div dir=3D"auto">=
<br></div><div dir=3D"auto">C) whether it should have the possibility of a =
pseudo return type to allow devs to "return" in all branches from=
the context of the function alone? E.g.</div><div dir=3D"auto"><br></div><=
div dir=3D"auto">T neverUsed(){</div><div dir=3D"auto">=C2=A0 =C2=A0 return=
std::unreachable<T>(); //technically returns a T.</div><div dir=3D"a=
uto">}</div></div></div><div></div></blockquote></div></div></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">I'm not sure. I think vendors'=
; input would be valuable here, as that would only be necessary if they can=
not commit to disable return warnings/errors on paths that pass through std=
::unreachable except by giving it a return type. On the other hand it may b=
e useful and more clear to some users.</div></div></blockquote><div><br></d=
iv><div>Besides the DRY issue around the return type, the other issue here =
is that it doesn't help the compiler.</div><div><br></div><div>After al=
l, if you called `std::terminate`, that's a [[noreturn]] function. So t=
he compiler automatically knows that control is never coming back, so there=
is no possibility of UB. And this should be true of <i>any</i> [[noreturn]=
] function; calling one should stop the compiler from warning about a lack =
of a `return` statement in that branch. Since the compiler already needs to=
be on the lookout for [[noreturn]]s, `std::unreachable`'s ability to t=
urn off such warnings can simply be due to being declared [[noreturn]].</di=
v><div><br></div><div>That is, the compiler already has to handle this for =
other cases of calling a function that never returns here. Just let it hand=
le it for this case too.</div><div><br></div><div>Further, the code should =
not act like it's going to return control to that location. `unreachabl=
e` is not really a function; it doesn't do anything. It's a marker =
in the code, so it shouldn't look like it's going to return somethi=
ng.</div><div><br></div><div>By all rights, `unreachable` should be a keywo=
rd. And if the committee had accepted the "soft keywords" idea, i=
t would be.<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
</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/abc5bd57-ea7b-4ba3-bcac-a6742e893353%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/abc5bd57-ea7b-4ba3-bcac-a6742e893353=
%40isocpp.org</a>.<br />
------=_Part_11149_1381395637.1514047820320--
------=_Part_11148_2129917799.1514047820319--
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Sat, 23 Dec 2017 17:38:40 +0000
Raw View
--001a113f0024740ca40561056716
Content-Type: text/plain; charset="UTF-8"
On 23 Dec 2017 16:00, "Nicol Bolas" <jmckesson@gmail.com> wrote:
I understand what you want, but that doesn't change the fact that what you
describe is* not a contract*. If you validate your inputs, whether it's the
function doing it or something outside of the function that is an
inexorable part of its interface, then that's not a part of your function's
contract.
My point is that you're using the words incorrectly. You're not specifying
a contract; you're creating a type requirement on your function.
Understood. Nevertheless, this does provide an alternative to a contract
that solves the "problem" (subjective. I see it as a problem.) of UB in a
function whilst also getting the full optimisation inside the function.
At this point, the discussion clearly seems to be a matter of coding style:
people who believe that narrow contracts represent broken code vs. people
who disagree.
C++ should not define coding style.
I agree with you. All I'm after here is an optional way of getting the best
of both worlds.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPJJkRhsGsg%3DLrDX7jFFTwm2XSHvOpN1gs%2BFFz9Y8QyCg%40mail.gmail.com.
--001a113f0024740ca40561056716
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><br><div class=3D"gmail_extra" dir=3D"auto"><br><div clas=
s=3D"gmail_quote">On 23 Dec 2017 16:00, "Nicol Bolas" <<a href=
=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>> wrote:<br type=
=3D"attribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"qu=
oted-text"><div>I understand what you want, but that doesn't change the=
fact that what you describe is<i> not a contract</i>. If you validate your=
inputs, whether it's the function doing it or something outside of the=
function that is an inexorable part of its interface, then that's not =
a part of your function's contract.<br></div></div><div><br></div><div>=
My point is that you're using the words incorrectly. You're not spe=
cifying a contract; you're creating a type requirement on your function=
..</div></div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Understood. Nevertheless, this does provide an alternative to a c=
ontract that solves the "problem" (subjective. I see it as a prob=
lem.) of UB in a function whilst also getting the full optimisation inside =
the function.</div><div class=3D"gmail_extra" dir=3D"auto"><div class=3D"gm=
ail_quote"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div></div></blo=
ckquote></div></div><div dir=3D"auto"><br></div><div class=3D"gmail_extra" =
dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div>At this point, the discussion clearly seems to be a matter of=
coding style: people who believe that narrow contracts represent broken co=
de vs. people who disagree.<br></div><div><br></div><div>C++ should not def=
ine coding style.</div></div></blockquote></div></div><div dir=3D"auto"><br=
></div><div dir=3D"auto">I agree with you. All I'm after here is an opt=
ional way of getting the best of both worlds.</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/CAC%2B0CCPJJkRhsGsg%3DLrDX7jFFTwm2XSH=
vOpN1gs%2BFFz9Y8QyCg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPJ=
JkRhsGsg%3DLrDX7jFFTwm2XSHvOpN1gs%2BFFz9Y8QyCg%40mail.gmail.com</a>.<br />
--001a113f0024740ca40561056716--
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Sat, 23 Dec 2017 18:09:41 +0000
Raw View
--001a113ccab85a98e4056105d6ba
Content-Type: text/plain; charset="UTF-8"
On 23 Dec 2017 16:50, "Nicol Bolas" <jmckesson@gmail.com> wrote:
Besides the DRY issue around the return type, the other issue here is that
it doesn't help the compiler.
I also agree here. I mean for it to be optional, and I don't mean for it to
help the compiler. I'm a purist when it comes to types and when it comes to
C++ code in it's written form, which is why I want to be able to have such
a type "returned" in every branch, including ones destined for deletion.
That's no biggie, though, because one can always define a custom template
function that is always unreachable. At least that way the only ugly piece
of code (in my view) is that function:
template<typename T>
function unreachable(){
std::unreachable(); // yuck. But just the once.
}
And we can use this in plenty of other functions that otherwise "return"
from every branch.
unsigned blah(unsigned thing){
if(thing < 5)
return 5 - thing;
return unreachable<unsigned>();
}
std::string bleh(unsigned bar){
switch(bar){
case 0: return "Zero";
case 1: return "One";
case 2: return "Two";
default: return unreachable<std::string>();
}
}
(Which would still do exactly the same thing and exhibits the same UB as
without the fake returning branch, but we still keep purists happy in blah
and bleh)
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCODFyp4AahBODYfXXKpZiBGfHh5wnSDPzKeoH2gBEtP3w%40mail.gmail.com.
--001a113ccab85a98e4056105d6ba
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><br><div class=3D"gmail_extra" dir=3D"auto"><br><div clas=
s=3D"gmail_quote">On 23 Dec 2017 16:50, "Nicol Bolas" <<a href=
=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>> wrote:<blockquo=
te class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div>Besides the DRY issue around the retu=
rn type, the other issue here is that it doesn't help the compiler.</di=
v></div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"au=
to">I also agree here. I mean for it to be optional, and I don't mean f=
or it to help the compiler. I'm a purist when it comes to types and whe=
n it comes to C++ code in it's written form, which is why I want to be =
able to have such a type "returned" in every branch, including on=
es destined for deletion. That's no biggie, though, because one can alw=
ays define a custom template function that is always unreachable. At least =
that way the only ugly piece of code (in my view) is that function:</div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto">template<typename T></div=
><div dir=3D"auto">function unreachable(){</div><div dir=3D"auto">=C2=A0 =
=C2=A0 std::unreachable(); // yuck. But just the once.</div><div dir=3D"aut=
o">}</div><div dir=3D"auto"><br></div><div dir=3D"auto">And we can use this=
in plenty of other functions that otherwise "return" from every =
branch.</div><div dir=3D"auto"><br></div><div dir=3D"auto">unsigned blah(un=
signed thing){</div><div dir=3D"auto">=C2=A0 =C2=A0 if(thing < 5)</div><=
div dir=3D"auto">=C2=A0 =C2=A0 =C2=A0 =C2=A0 return 5 - thing;</div><div di=
r=3D"auto">=C2=A0 =C2=A0 return unreachable<unsigned>();</div><div di=
r=3D"auto">}</div><div dir=3D"auto"><br></div><div dir=3D"auto">std::string=
bleh(unsigned bar){</div><div dir=3D"auto">=C2=A0 =C2=A0 switch(bar){</div=
><div dir=3D"auto">=C2=A0 =C2=A0 =C2=A0 =C2=A0case 0: return "Zero&quo=
t;;</div><div dir=3D"auto">=C2=A0 =C2=A0 =C2=A0 =C2=A0case 1: return "=
One";</div><div dir=3D"auto">=C2=A0 =C2=A0 =C2=A0 =C2=A0case 2: return=
"Two";</div><div dir=3D"auto">=C2=A0 =C2=A0 =C2=A0 =C2=A0default=
: return unreachable<std::string>();</div><div dir=3D"auto">=C2=A0 =
=C2=A0 }</div><div dir=3D"auto">}</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">(Which would still do exactly the same thing and exhibits the sam=
e UB as without the fake returning branch, but we still keep purists happy =
in blah and bleh)</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/CAC%2B0CCODFyp4AahBODYfXXKpZiBGfHh5wn=
SDPzKeoH2gBEtP3w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCODFyp4=
AahBODYfXXKpZiBGfHh5wnSDPzKeoH2gBEtP3w%40mail.gmail.com</a>.<br />
--001a113ccab85a98e4056105d6ba--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Sat, 23 Dec 2017 19:12:26 +0000
Raw View
--001a1148e9fcc2be39056106b699
Content-Type: text/plain; charset="UTF-8"
On 23 Dec 2017 2:05 am, "Matthew Woehlke" <mwoehlke.floss@gmail.com> wrote:
On 2017-12-19 11:02, Edward Catmur wrote:
> The reason that -Wreturn-type is part of -Wextra and not -Wall is that
> there is far too much existing code that would trigger the warning.
Citation needed.
I've been using -Werror=return-type with just about all C++ code I
compile for some years, and have yet to see a false positive. (Genuine
bugs, on the other hand...)
This statement directly contradicts my own real-world observations, and
thus, I must consider it inadmissible without substantiation.
That's fair enough; my position is currently based not on direct experience
but rather on the observation that the major compilers do not enable the
warning by default or even under -Wall. (MSVC does not count, as that
warning only fires if all code paths fail to return.) Once I'm back at
work, I'll see how much of our code base (a mix of open source and
proprietary code) would break with -Werror=return-type enabled.
My concern is that the third party (open source and proprietary) libraries
we use may be leery of accepting patches that refactor code to eliminate
false positives. I reiterate that if and when std::unreachable makes it in,
this would be a lot easier as no changes to logic would be required.
--
Matthew
--
You received this message because you are subscribed to a topic in the
Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/
isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
To unsubscribe from this group and all its topics, 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/p1bjsq%24omk%241%40blaine.gmane.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/CAJnLdOZXiFrOWeUE9Uuz%2Biy5v8n4-kv7LAdzgkvoE3216gjS9w%40mail.gmail.com.
--001a1148e9fcc2be39056106b699
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On 23 Dec 2017 2:05 am, "Matthew Woehlke" <<a href=
=3D"mailto:mwoehlke.floss@gmail.com">mwoehlke.floss@gmail.com</a>> wrote=
:<br type=3D"attribution"><blockquote class=3D"quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">On 2017-12-19 11:02, Edw=
ard Catmur wrote:<br>
> The reason that -Wreturn-type is part of -Wextra and not -Wall is that=
<br>
> there is far too much existing code that would trigger the warning.<br=
>
<br>
Citation needed.<br>
<br>
I've been using -Werror=3Dreturn-type with just about all C++ code I<br=
>
compile for some years, and have yet to see a false positive. (Genuine<br>
bugs, on the other hand...)<br>
<br>
This statement directly contradicts my own real-world observations, and<br>
thus, I must consider it inadmissible without substantiation.<br>
<div class=3D"quoted-text"></div></blockquote></div></div></div><div dir=3D=
"auto"><br></div><div dir=3D"auto">That's fair enough; my position is c=
urrently based not on direct experience but rather on the observation that =
the major compilers do not enable the warning by default or even under -Wal=
l. (MSVC does not count, as that warning only fires if all code paths fail =
to return.)=C2=A0 Once I'm back at work, I'll see how much of our c=
ode base (a mix of open source and proprietary code) would break with -Werr=
or=3Dreturn-type enabled.=C2=A0</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">My concern is that the third party (open source and proprietary) =
libraries we use may be leery of accepting patches that refactor code to el=
iminate false positives. I reiterate that if and when std::unreachable make=
s it in, this would be a lot easier as no changes to logic would be require=
d.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"g=
mail_extra"><div class=3D"gmail_quote"><blockquote class=3D"quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=
=3D"quoted-text"><br>
--<br>
Matthew<br>
<br>
--<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/topic/s=
td-<wbr>proposals/Uu2QViiWh4k/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@<wbr>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>
</div>To view this discussion on the web visit <a href=3D"https://groups.go=
ogle.com/a/isocpp.org/d/msgid/std-proposals/p1bjsq%24omk%241%40blaine.gmane=
..org" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/<wbr=
>isocpp.org/d/msgid/std-<wbr>proposals/p1bjsq%24omk%241%<wbr>40blaine.gmane=
..org</a>.<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/CAJnLdOZXiFrOWeUE9Uuz%2Biy5v8n4-kv7LA=
dzgkvoE3216gjS9w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZXiFrOWe=
UE9Uuz%2Biy5v8n4-kv7LAdzgkvoE3216gjS9w%40mail.gmail.com</a>.<br />
--001a1148e9fcc2be39056106b699--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 23 Dec 2017 11:15:35 -0800 (PST)
Raw View
------=_Part_11220_450379192.1514056535799
Content-Type: multipart/alternative;
boundary="----=_Part_11221_1522901763.1514056535799"
------=_Part_11221_1522901763.1514056535799
Content-Type: text/plain; charset="UTF-8"
On Saturday, December 23, 2017 at 1:09:44 PM UTC-5, Jake Arkinstall wrote:
>
> On 23 Dec 2017 16:50, "Nicol Bolas" <jmck...@gmail.com <javascript:>>
> wrote:
>
> Besides the DRY issue around the return type, the other issue here is that
> it doesn't help the compiler.
>
>
> I also agree here. I mean for it to be optional, and I don't mean for it
> to help the compiler.
>
Then why have the option? If it serves no objectively useful purpose, then
it's purely a matter of coding style. Why standardize it?
If you want to make a function like this:
template<typename T>
[[noreturn]] T unreachable_t() {std::unreachable();}
And then use that where you see fit, that's fine. But there's no reason why
that needs to be standardized.
What we need in the standard is a clear delineation for the compiler that
says, "the program should never get here." We don't need to say "I'm
returning something but no really because it should never get here." That's
just confused.
>
--
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/aac36104-4bce-4111-bde2-2141c5e7be47%40isocpp.org.
------=_Part_11221_1522901763.1514056535799
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, December 23, 2017 at 1:09:44 PM UTC-5, Jake A=
rkinstall wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"au=
to"><div dir=3D"auto"><div class=3D"gmail_quote">On 23 Dec 2017 16:50, &quo=
t;Nicol Bolas" <<a onmousedown=3D"this.href=3D'javascript:'=
;return true;" onclick=3D"this.href=3D'javascript:';return true;" h=
ref=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailt=
o=3D"_R96dHm3BwAJ">jmck...@gmail.com</a>> wrote:<blockquote style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div>Besides the DRY issue around the return type, the other issue here i=
s that it doesn't help the compiler.</div></div></blockquote></div></di=
v><div dir=3D"auto"><br></div><div dir=3D"auto">I also agree here. I mean f=
or it to be optional, and I don't mean for it to help the compiler.</di=
v></div></blockquote><div><br></div><div>Then why have the option? If it se=
rves no objectively useful purpose, then it's purely a matter of coding=
style. Why standardize it?</div><div><br></div><div>If you want to make a =
function like this:</div><div><br></div><div class=3D"prettyprint" style=3D=
"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; background-co=
lor: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subpret=
typrint"><span class=3D"styled-by-prettify" style=3D"color: #008;">template=
</span><span class=3D"styled-by-prettify" style=3D"color: #660;"><</span=
><span class=3D"styled-by-prettify" style=3D"color: #008;">typename</span><=
span class=3D"styled-by-prettify" style=3D"color: #000;"> T</span><span cla=
ss=3D"styled-by-prettify" style=3D"color: #660;">></span><span class=3D"=
styled-by-prettify" style=3D"color: #000;"><br></span><span class=3D"styled=
-by-prettify" style=3D"color: #660;">[[</span><span class=3D"styled-by-pret=
tify" style=3D"color: #000;">noreturn</span><span class=3D"styled-by-pretti=
fy" style=3D"color: #660;">]]</span><span class=3D"styled-by-prettify" styl=
e=3D"color: #000;"> T unreachable_t</span><span class=3D"styled-by-prettify=
" style=3D"color: #660;">()</span><span class=3D"styled-by-prettify" style=
=3D"color: #000;"> </span><span class=3D"styled-by-prettify" style=3D"color=
: #660;">{</span><span class=3D"styled-by-prettify" style=3D"color: #000;">=
std</span><span class=3D"styled-by-prettify" style=3D"color: #660;">::</spa=
n><span class=3D"styled-by-prettify" style=3D"color: #000;">unreachable</sp=
an><span class=3D"styled-by-prettify" style=3D"color: #660;">();}</span></d=
iv></code></div><div><br></div><div>And then use that where you see fit, th=
at's fine. But there's no reason why that needs to be standardized.=
</div><div><br></div><div>What we need in the standard is a clear delineati=
on for the compiler that says, "the program should never get here.&quo=
t; We don't need to say "I'm returning something but no really=
because it should never get here." That's just confused.</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">
</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/aac36104-4bce-4111-bde2-2141c5e7be47%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/aac36104-4bce-4111-bde2-2141c5e7be47=
%40isocpp.org</a>.<br />
------=_Part_11221_1522901763.1514056535799--
------=_Part_11220_450379192.1514056535799--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Sat, 23 Dec 2017 20:45:04 +0000
Raw View
--001a11417bc20c4cc505610802ca
Content-Type: text/plain; charset="UTF-8"
On 23 Dec 2017 09:17, "Viacheslav Usov" <via.usov@gmail.com> wrote:
On Fri, Dec 22, 2017 at 9:14 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> I hope that you are aware that it is relatively uncommon to be able to
branch for a new compiler and fix compilation errors, while worrying about
crashes introduced by a corner change to language semantics.
It was not "while" but "versus" in my argument.
> Most projects when faced by a sea of errors from a new compiler will
simply refuse to upgrade, meaning that they are stuck on the old version
either of the language or of the compiler and thereby hold up adoption of
the new version of the standard and the compiler.
That is exactly what I said. They will have to hold on till the sea of
errors dries up, which is easily observable.
If the errors are in their own code, they will never upgrade. This is a bad
thing, because they will not enjoy the benefits of the newer standard and
because it makes it more difficult for other projects to upgrade. The
benefit in fewer bugs does not justify the cost.
Cheers,
V.
--
You received this message because you are subscribed to a topic in the
Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/
isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAA7YVg0wjgLvdNqL-
0OdtGhhRQcHaXTwJ2wbejxuptT5dRYZnw%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0wjgLvdNqL-0OdtGhhRQcHaXTwJ2wbejxuptT5dRYZnw%40mail.gmail.com?utm_medium=email&utm_source=footer>
..
--
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/CAJnLdOaUrkWX1Hrbi8gcfhgFEwXAUFQWpG-U5qfGp4Lx6x%3D8iw%40mail.gmail.com.
--001a11417bc20c4cc505610802ca
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On 23 Dec 2017 09:17, "Viacheslav Usov" <<a href=3D"=
mailto:via.usov@gmail.com">via.usov@gmail.com</a>> wrote:<br type=3D"att=
ribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><div class=3D"quoted-text">On Fri, Dec 22, 2=
017 at 9:14 PM, 'Edward Catmur' via ISO C++ Standard - Future Propo=
sals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@isocpp.org" targ=
et=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:<br><div><br></=
div><div>> I hope that you are aware that it is relatively uncommon to b=
e able to branch for a new compiler and fix compilation errors, while worry=
ing about crashes introduced by a corner change to language semantics.</div=
><div><br></div></div><div>It was not "while" but "versus&qu=
ot; in my argument.</div><div class=3D"quoted-text"><div><br></div><div>>=
; Most projects when faced by a sea of errors from a new compiler will simp=
ly refuse to upgrade, meaning that they are stuck on the old version either=
of the language or of the compiler and thereby hold up adoption of the new=
version of the standard and the compiler.</div><div><br></div></div><div>T=
hat is exactly what I said. They will have to hold on till the sea of error=
s dries up, which is easily observable.</div><div></div></div></div></div><=
/blockquote></div></div></div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>If the errors are in their own code, they will never upgrade. This is a ba=
d thing, because they will not enjoy the benefits of the newer standard and=
because it makes it more difficult for other projects to upgrade. The bene=
fit in fewer bugs does not justify the cost.=C2=A0</div><div dir=3D"auto"><=
br></div><div dir=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div><br></div><div>Cheers,</div><div>V.</div></=
div></div></div><div class=3D"quoted-text">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/U=
u2QViiWh4k/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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/CAA7YVg0wjgLvdNqL-0OdtGhhRQcHaXTwJ2wb=
ejxuptT5dRYZnw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-=
<wbr>proposals/CAA7YVg0wjgLvdNqL-<wbr>0OdtGhhRQcHaXTwJ2wbejxuptT5dRY<wbr>Zn=
w%40mail.gmail.com</a>.<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/CAJnLdOaUrkWX1Hrbi8gcfhgFEwXAUFQWpG-U=
5qfGp4Lx6x%3D8iw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOaUrkWX1H=
rbi8gcfhgFEwXAUFQWpG-U5qfGp4Lx6x%3D8iw%40mail.gmail.com</a>.<br />
--001a11417bc20c4cc505610802ca--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 24 Dec 2017 00:29:44 -0200
Raw View
On sexta-feira, 22 de dezembro de 2017 22:36:03 -02 Jake Arkinstall wrote:
> Are we:
>
> A) in agreement that a std::unreachable is a good evolution of the proposal?
Yes.
> B) if (A), in agreement about the behaviour of std::unreachable - whether
> it should cause an abort, branch removal, or it undefined to allow anything
> from to branch removal?
Undefined. I *expect* optimising compilers to perform dead-code elimination
backwards in all paths leading to the unreachable code and optimise the code
accordingly. When not optimising, a call to std::terminate would be welcome.
> C) whether it should have the possibility of a pseudo return type to allow
> devs to "return" in all branches from the context of the function alone?
> E.g.
>
> T neverUsed(){
> return std::unreachable<T>(); //technically returns a T.
> }
This makes no sense. Why would you need this and not
T neverUsed() { std::unreachable(); }
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/4429805.HRajz6qbQG%40tjmaciei-mobl1.
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Sun, 24 Dec 2017 07:13:15 +0000
Raw View
--001a114cc6c495423e056110c8a7
Content-Type: text/plain; charset="UTF-8"
On 24 Dec 2017 02:29, "Thiago Macieira" <thiago@macieira.org> wrote:
On sexta-feira, 22 de dezembro de 2017 22:36:03 -02 Jake Arkinstall wrote:
> Are we:
>
> A) in agreement that a std::unreachable is a good evolution of the
proposal?
Yes.
> B) if (A), in agreement about the behaviour of std::unreachable - whether
> it should cause an abort, branch removal, or it undefined to allow
anything
> from to branch removal?
Undefined. I *expect* optimising compilers to perform dead-code elimination
backwards in all paths leading to the unreachable code and optimise the code
accordingly. When not optimising, a call to std::terminate would be welcome.
> C) whether it should have the possibility of a pseudo return type to allow
> devs to "return" in all branches from the context of the function alone?
> E.g.
>
> T neverUsed(){
> return std::unreachable<T>(); //technically returns a T.
> }
This makes no sense. Why would you need this and not
T neverUsed() { std::unreachable(); }
In a sufficiently stupid compiler, that might not be enough to suppress
return warnings - one that does not understand how to use noreturn to
poison code paths.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
You received this message because you are subscribed to a topic in the
Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/
isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
To unsubscribe from this group and all its topics, 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/4429805.HRajz6qbQG%40tjmaciei-mobl1.
--
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/CAJnLdOZ%2BgH13K4xd0ggJZsSufPwYjGGZeEiYs6KkuKNaTXVy7A%40mail.gmail.com.
--001a114cc6c495423e056110c8a7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On 24 Dec 2017 02:29, "Thiago Macieira" <<a href=3D"=
mailto:thiago@macieira.org">thiago@macieira.org</a>> wrote:<br type=3D"a=
ttribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div class=3D"quoted-text">On sexta-fe=
ira, 22 de dezembro de 2017 22:36:03 -02 Jake Arkinstall wrote:<br>
> Are we:<br>
><br>
> A) in agreement that a std::unreachable is a good evolution of the pro=
posal?<br>
<br>
</div>Yes.<br>
<div class=3D"quoted-text"><br>
> B) if (A), in agreement about the behaviour of std::unreachable - whet=
her<br>
> it should cause an abort, branch removal, or it undefined to allow any=
thing<br>
> from to branch removal?<br>
<br>
</div>Undefined. I *expect* optimising compilers to perform dead-code elimi=
nation<br>
backwards in all paths leading to the unreachable code and optimise the cod=
e<br>
accordingly. When not optimising, a call to std::terminate would be welcome=
..<br>
<div class=3D"quoted-text"><br>
> C) whether it should have the possibility of a pseudo return type to a=
llow<br>
> devs to "return" in all branches from the context of the fun=
ction alone?<br>
> E.g.<br>
><br>
> T neverUsed(){<br>
>=C2=A0 =C2=A0 =C2=A0return std::unreachable<T>(); //technically r=
eturns a T.<br>
> }<br>
<br>
</div>This makes no sense. Why would you need this and not<br>
<br>
T neverUsed() { std::unreachable(); }<br>
<div class=3D"quoted-text"></div></blockquote></div></div></div><div dir=3D=
"auto"><br></div><div dir=3D"auto">In a sufficiently stupid compiler, that =
might not be enough to suppress return warnings - one that does not underst=
and how to use noreturn to poison code paths.=C2=A0</div><div dir=3D"auto">=
<br></div><div dir=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_=
quote"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div class=3D"quoted-text"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
</div><div class=3D"quoted-text">--<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/topic/s=
td-<wbr>proposals/Uu2QViiWh4k/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@<wbr>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>
</div>To view this discussion on the web visit <a href=3D"https://groups.go=
ogle.com/a/isocpp.org/d/msgid/std-proposals/4429805.HRajz6qbQG%40tjmaciei-m=
obl1" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/<wbr=
>isocpp.org/d/msgid/std-<wbr>proposals/4429805.HRajz6qbQG%<wbr>40tjmaciei-m=
obl1</a>.<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/CAJnLdOZ%2BgH13K4xd0ggJZsSufPwYjGGZeE=
iYs6KkuKNaTXVy7A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZ%2BgH13=
K4xd0ggJZsSufPwYjGGZeEiYs6KkuKNaTXVy7A%40mail.gmail.com</a>.<br />
--001a114cc6c495423e056110c8a7--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Sun, 24 Dec 2017 09:28:27 +0100
Raw View
--001a1140794090491d056111d590
Content-Type: text/plain; charset="UTF-8"
On Sat, Dec 23, 2017 at 8:12 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> That's fair enough; my position is currently based not on direct
experience but rather on the observation that the major compilers do not
enable the warning by default or even under -Wall. (MSVC does not count, as
that warning only fires if all code paths fail to return.)
False. MSVC produces warning C4715 if there are any code paths that do not
return a value. [1]
If there is no path that returns a value, then it emits warning C4716,
which is automatically promoted to an error by default. [2]
Both are level 1 warnings, on by default, so one would have to disable all
warnings or these two specifically to get warning-free compilation of such
code with MSVC.
Cheers,
V.
[1]
https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4715
[2]
https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4716
--
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/CAA7YVg0KF569LOBQeOCjHB-rA2TvhZ-KjiXmkTK5XaFmppqY4g%40mail.gmail.com.
--001a1140794090491d056111d590
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Dec 23, 2017 at 8:12 PM, 'Edward Catmur' via ISO C++ Standard -=
Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@iso=
cpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:<b=
r><div><br></div><div>> That's fair enough; my position is currently=
based not on direct experience but rather on the observation that the majo=
r compilers do not enable the warning by default or even under -Wall. (MSVC=
does not count, as that warning only fires if all code paths fail to retur=
n.)</div><div><br></div><div>False. MSVC produces warning=C2=A0C4715 if the=
re are any code paths that do not return a value. [1]</div><div><br></div><=
div>If there is no path that returns a value, then it emits warning C4716, =
which is automatically promoted to an error by default. [2]</div><div><br><=
/div><div>Both are level 1 warnings, on by default, so one would have to di=
sable all warnings or these two specifically to get warning-free compilatio=
n of such code with MSVC.</div><div><br></div><div>Cheers,</div><div>V.</di=
v><div><br></div><div>[1]=C2=A0<a href=3D"https://docs.microsoft.com/en-us/=
cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4715">https:=
//docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-wa=
rning-level-1-c4715</a></div><div><br></div><div>[2]=C2=A0<a href=3D"https:=
//docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-wa=
rning-level-1-c4716">https://docs.microsoft.com/en-us/cpp/error-messages/co=
mpiler-warnings/compiler-warning-level-1-c4716</a></div><div><br></div></di=
v></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/CAA7YVg0KF569LOBQeOCjHB-rA2TvhZ-KjiXm=
kTK5XaFmppqY4g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0KF569LOBQ=
eOCjHB-rA2TvhZ-KjiXmkTK5XaFmppqY4g%40mail.gmail.com</a>.<br />
--001a1140794090491d056111d590--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Sun, 24 Dec 2017 09:37:17 +0100
Raw View
--001a113f25983218eb056111f550
Content-Type: text/plain; charset="UTF-8"
On Sat, Dec 23, 2017 at 9:45 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> If the errors are in their own code, they will never upgrade.
Unqualified "most projects" and unqualified "will never upgrade" do not
sound convincing. I can agree with a trivial statement that "while there
are errors, they will not officially upgrade". But this does not imply
"they will not work on those errors in order to upgrade". This lacks any
basis in fact and directly contradicts my own experience.
Cheers,
V.
--
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/CAA7YVg0%2BnAQi8fonMbya6wJiDw5oT46Fmv3SCx2ud9WtrKjBPQ%40mail.gmail.com.
--001a113f25983218eb056111f550
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Dec 23, 2017 at 9:45 PM, 'Edward Catmur' via ISO C++ Standard -=
Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@iso=
cpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:</=
div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">>=C2=
=A0If the errors are in their own code, they will never upgrade.</div><div =
class=3D"gmail_quote"><br><div>Unqualified "most projects" and un=
qualified "will never upgrade" do not sound convincing. I can agr=
ee with a trivial statement that "while there are errors, they will no=
t officially upgrade". But this does not imply "they will not wor=
k on those errors in order to upgrade". This lacks any basis in fact a=
nd directly contradicts my own experience.=C2=A0</div><div><br></div><div>C=
heers,</div><div>V.</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/CAA7YVg0%2BnAQi8fonMbya6wJiDw5oT46Fmv=
3SCx2ud9WtrKjBPQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0%2BnAQi=
8fonMbya6wJiDw5oT46Fmv3SCx2ud9WtrKjBPQ%40mail.gmail.com</a>.<br />
--001a113f25983218eb056111f550--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Sun, 24 Dec 2017 08:37:41 +0000
Raw View
--089e08e57d118bfea7056111f6d1
Content-Type: text/plain; charset="UTF-8"
On 24 Dec 2017 08:28, "Viacheslav Usov" <via.usov@gmail.com> wrote:
On Sat, Dec 23, 2017 at 8:12 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> That's fair enough; my position is currently based not on direct
experience but rather on the observation that the major compilers do not
enable the warning by default or even under -Wall. (MSVC does not count, as
that warning only fires if all code paths fail to return.)
False. MSVC produces warning C4715 if there are any code paths that do not
return a value. [1]
If there is no path that returns a value, then it emits warning C4716,
which is automatically promoted to an error by default. [2]
Both are level 1 warnings, on by default, so one would have to disable all
warnings or these two specifically to get warning-free compilation of such
code with MSVC.
Thanks for the clarification. Unfortunately we don't aim for warning free
compilation on MSVC so I imagine C4715 warnings will have got lost in the
noise.
Cheers,
V.
[1] https://docs.microsoft.com/en-us/cpp/error-messages/
compiler-warnings/compiler-warning-level-1-c4715
[2] https://docs.microsoft.com/en-us/cpp/error-messages/
compiler-warnings/compiler-warning-level-1-c4716
--
You received this message because you are subscribed to a topic in the
Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/
isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAA7YVg0KF569LOBQeOCjHB-
rA2TvhZ-KjiXmkTK5XaFmppqY4g%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0KF569LOBQeOCjHB-rA2TvhZ-KjiXmkTK5XaFmppqY4g%40mail.gmail.com?utm_medium=email&utm_source=footer>
..
--
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/CAJnLdOYn1wVdchcpwHez2Mk47y5zNC%2BCQ%3DN6rACZNu%2BCtAJb1Q%40mail.gmail.com.
--089e08e57d118bfea7056111f6d1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On 24 Dec 2017 08:28, "Viacheslav Usov" <<a href=3D"=
mailto:via.usov@gmail.com">via.usov@gmail.com</a>> wrote:<br type=3D"att=
ribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><div class=3D"quoted-text">On Sat, Dec 23, 2=
017 at 8:12 PM, 'Edward Catmur' via ISO C++ Standard - Future Propo=
sals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@isocpp.org" targ=
et=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:<br><div><br></=
div><div>> That's fair enough; my position is currently based not on=
direct experience but rather on the observation that the major compilers d=
o not enable the warning by default or even under -Wall. (MSVC does not cou=
nt, as that warning only fires if all code paths fail to return.)</div><div=
><br></div></div><div>False. MSVC produces warning=C2=A0C4715 if there are =
any code paths that do not return a value. [1]</div><div><br></div><div>If =
there is no path that returns a value, then it emits warning C4716, which i=
s automatically promoted to an error by default. [2]</div><div><br></div><d=
iv>Both are level 1 warnings, on by default, so one would have to disable a=
ll warnings or these two specifically to get warning-free compilation of su=
ch code with MSVC.</div><div></div></div></div></div></blockquote></div></d=
iv></div><div dir=3D"auto"><br></div><div dir=3D"auto">Thanks for the clari=
fication. Unfortunately we don't aim for warning free compilation on MS=
VC so I imagine=C2=A0<span style=3D"font-family:sans-serif">C4715 warnings =
will have got lost in the noise.=C2=A0</span></div><div dir=3D"auto"><br></=
div><div dir=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div><br></div><div>Cheers,</div><div>V.</div><div><b=
r></div><div>[1]=C2=A0<a href=3D"https://docs.microsoft.com/en-us/cpp/error=
-messages/compiler-warnings/compiler-warning-level-1-c4715" target=3D"_blan=
k">https://docs.microsoft.<wbr>com/en-us/cpp/error-messages/<wbr>compiler-w=
arnings/compiler-<wbr>warning-level-1-c4715</a></div><div><br></div><div>[2=
]=C2=A0<a href=3D"https://docs.microsoft.com/en-us/cpp/error-messages/compi=
ler-warnings/compiler-warning-level-1-c4716" target=3D"_blank">https://docs=
..microsoft.<wbr>com/en-us/cpp/error-messages/<wbr>compiler-warnings/compile=
r-<wbr>warning-level-1-c4716</a></div><div><br></div></div></div></div><div=
class=3D"quoted-text">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/U=
u2QViiWh4k/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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/CAA7YVg0KF569LOBQeOCjHB-rA2TvhZ-KjiXm=
kTK5XaFmppqY4g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-=
<wbr>proposals/<wbr>CAA7YVg0KF569LOBQeOCjHB-<wbr>rA2TvhZ-KjiXmkTK5XaFmppqY4=
g%<wbr>40mail.gmail.com</a>.<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/CAJnLdOYn1wVdchcpwHez2Mk47y5zNC%2BCQ%=
3DN6rACZNu%2BCtAJb1Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYn1w=
VdchcpwHez2Mk47y5zNC%2BCQ%3DN6rACZNu%2BCtAJb1Q%40mail.gmail.com</a>.<br />
--089e08e57d118bfea7056111f6d1--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Sun, 24 Dec 2017 10:25:01 +0000
Raw View
--089e08e57d116415e705611376c9
Content-Type: text/plain; charset="UTF-8"
On 24 Dec 2017 08:37, "Viacheslav Usov" <via.usov@gmail.com> wrote:
On Sat, Dec 23, 2017 at 9:45 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> If the errors are in their own code, they will never upgrade.
Unqualified "most projects" and unqualified "will never upgrade" do not
sound convincing. I can agree with a trivial statement that "while there
are errors, they will not officially upgrade". But this does not imply
"they will not work on those errors in order to upgrade". This lacks any
basis in fact and directly contradicts my own experience.
My concern is that they will not be able to work on those errors, because
the simplest solution - inserting calls to std::unreachable - will prevent
their code working on the previous version. If on the other hand the error
is produced in a version after std::unreachable is introduced, then
projects that aim only for compatibility with the most recent version and
two versions during the transition at least will be able to cope.
Cheers,
V.
--
You received this message because you are subscribed to a topic in the
Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/
isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAA7YVg0%2BnAQi8fonMbya6wJiDw5oT46Fmv3S
Cx2ud9WtrKjBPQ%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0%2BnAQi8fonMbya6wJiDw5oT46Fmv3SCx2ud9WtrKjBPQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
..
--
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/CAJnLdOY5KWX5hy4vimzPco1JE0nce4bbfYxho0XJhX8%2BkoaYcQ%40mail.gmail.com.
--089e08e57d116415e705611376c9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On 24 Dec 2017 08:37, "Viacheslav Usov" <<a href=3D"=
mailto:via.usov@gmail.com">via.usov@gmail.com</a>> wrote:<br type=3D"att=
ribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ext=
ra"><div class=3D"quoted-text"><div class=3D"gmail_quote">On Sat, Dec 23, 2=
017 at 9:45 PM, 'Edward Catmur' via ISO C++ Standard - Future Propo=
sals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@isocpp.org" targ=
et=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:</div><div clas=
s=3D"gmail_quote"><br></div><div class=3D"gmail_quote">>=C2=A0If the err=
ors are in their own code, they will never upgrade.</div></div><div class=
=3D"gmail_quote"><br><div>Unqualified "most projects" and unquali=
fied "will never upgrade" do not sound convincing. I can agree wi=
th a trivial statement that "while there are errors, they will not off=
icially upgrade". But this does not imply "they will not work on =
those errors in order to upgrade". This lacks any basis in fact and di=
rectly contradicts my own experience.=C2=A0</div><div></div></div></div></d=
iv></blockquote></div></div></div><div dir=3D"auto"><br></div><div dir=3D"a=
uto">My concern is that they will not be able to work on those errors, beca=
use the simplest solution - inserting calls to std::unreachable - will prev=
ent their code working on the previous version. If on the other hand the er=
ror is produced in a version after std::unreachable is introduced, then pro=
jects that aim only for compatibility with the most recent version and two =
versions during the transition at least will be able to cope.=C2=A0</div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_extra"><div=
class=3D"gmail_quote"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div><br></div><div>Cheers,</di=
v><div>V.</div></div></div></div><div class=3D"quoted-text">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/U=
u2QViiWh4k/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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/CAA7YVg0%2BnAQi8fonMbya6wJiDw5oT46Fmv=
3SCx2ud9WtrKjBPQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/CAA7YVg0%<wbr>2BnAQi8fonMbya6wJiDw5oT46Fmv3S<wbr>Cx2ud9Wtr=
KjBPQ%40mail.gmail.<wbr>com</a>.<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/CAJnLdOY5KWX5hy4vimzPco1JE0nce4bbfYxh=
o0XJhX8%2BkoaYcQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOY5KWX5hy=
4vimzPco1JE0nce4bbfYxho0XJhX8%2BkoaYcQ%40mail.gmail.com</a>.<br />
--089e08e57d116415e705611376c9--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Sun, 24 Dec 2017 10:37:25 +0000
Raw View
--001a114b3186c288e9056113a211
Content-Type: text/plain; charset="UTF-8"
On 24 Dec 2017 02:29, "Thiago Macieira" <thiago@macieira.org> wrote:
On sexta-feira, 22 de dezembro de 2017 22:36:03 -02 Jake Arkinstall wrote:
> Are we:
>
> A) in agreement that a std::unreachable is a good evolution of the
proposal?
Yes.
> B) if (A), in agreement about the behaviour of std::unreachable - whether
> it should cause an abort, branch removal, or it undefined to allow
anything
> from to branch removal?
Undefined. I *expect* optimising compilers to perform dead-code elimination
backwards in all paths leading to the unreachable code and optimise the code
accordingly. When not optimising, a call to std::terminate would be welcome.
Would a call to std::terminate preclude its being called from a constexpr
function? I suppose there could be some compiler magic to allow it, but I
think std::unreachable should be constexpr if at all possible.
> C) whether it should have the possibility of a pseudo return type to allow
> devs to "return" in all branches from the context of the function alone?
> E.g.
>
> T neverUsed(){
> return std::unreachable<T>(); //technically returns a T.
> }
This makes no sense. Why would you need this and not
T neverUsed() { std::unreachable(); }
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
You received this message because you are subscribed to a topic in the
Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/
isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
To unsubscribe from this group and all its topics, 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/4429805.HRajz6qbQG%40tjmaciei-mobl1.
--
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/CAJnLdOZv9dPrtFSDBMkqtX3mD8LP8P-dgqXyyNEKVqopnP0VBg%40mail.gmail.com.
--001a114b3186c288e9056113a211
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On 24 Dec 2017 02:29, "Thiago Macieira" <<a href=3D"=
mailto:thiago@macieira.org">thiago@macieira.org</a>> wrote:<br type=3D"a=
ttribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div class=3D"quoted-text">On sexta-fe=
ira, 22 de dezembro de 2017 22:36:03 -02 Jake Arkinstall wrote:<br>
> Are we:<br>
><br>
> A) in agreement that a std::unreachable is a good evolution of the pro=
posal?<br>
<br>
</div>Yes.<br>
<div class=3D"quoted-text"><br>
> B) if (A), in agreement about the behaviour of std::unreachable - whet=
her<br>
> it should cause an abort, branch removal, or it undefined to allow any=
thing<br>
> from to branch removal?<br>
<br>
</div>Undefined. I *expect* optimising compilers to perform dead-code elimi=
nation<br>
backwards in all paths leading to the unreachable code and optimise the cod=
e<br>
accordingly. When not optimising, a call to std::terminate would be welcome=
..<br>
<div class=3D"quoted-text"></div></blockquote></div></div></div><div dir=3D=
"auto"><br></div><div dir=3D"auto">Would a call to std::terminate preclude =
its being called from a constexpr function? I suppose there could be some c=
ompiler magic to allow it, but I think std::unreachable should be constexpr=
if at all possible.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"aut=
o"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=
=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div class=3D"quoted-text"><br>
> C) whether it should have the possibility of a pseudo return type to a=
llow<br>
> devs to "return" in all branches from the context of the fun=
ction alone?<br>
> E.g.<br>
><br>
> T neverUsed(){<br>
>=C2=A0 =C2=A0 =C2=A0return std::unreachable<T>(); //technically r=
eturns a T.<br>
> }<br>
<br>
</div>This makes no sense. Why would you need this and not<br>
<br>
T neverUsed() { std::unreachable(); }<br>
<div class=3D"quoted-text"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
</div><div class=3D"quoted-text">--<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/topic/s=
td-<wbr>proposals/Uu2QViiWh4k/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@<wbr>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>
</div>To view this discussion on the web visit <a href=3D"https://groups.go=
ogle.com/a/isocpp.org/d/msgid/std-proposals/4429805.HRajz6qbQG%40tjmaciei-m=
obl1" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/<wbr=
>isocpp.org/d/msgid/std-<wbr>proposals/4429805.HRajz6qbQG%<wbr>40tjmaciei-m=
obl1</a>.<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/CAJnLdOZv9dPrtFSDBMkqtX3mD8LP8P-dgqXy=
yNEKVqopnP0VBg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZv9dPrtFSD=
BMkqtX3mD8LP8P-dgqXyyNEKVqopnP0VBg%40mail.gmail.com</a>.<br />
--001a114b3186c288e9056113a211--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 24 Dec 2017 10:18:44 -0200
Raw View
On domingo, 24 de dezembro de 2017 05:13:15 -02 'Edward Catmur' via ISO C++
Standard - Future Proposals wrote:
> T neverUsed() { std::unreachable(); }
>
>
> In a sufficiently stupid compiler, that might not be enough to suppress
> return warnings - one that does not understand how to use noreturn to
> poison code paths.
As someone else said in this thread yesterday, we should consult compiler
vendors to see if they think we could implement the above or if we need a fake
non-returning return.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/2219526.d0z1aMvSDk%40tjmaciei-mobl1.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 26 Dec 2017 13:13:45 -0500
Raw View
On 2017-12-20 10:55, Ville Voutilainen wrote:
> VV: We could go towards a direction of making the lack of return
> ill-formed. Compilers already diagnose it, by default.
Alas, if only that were true...
--
Matthew
--
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/cabb77bb-1bb9-35ae-1669-d21ec0629686%40gmail.com.
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Wed, 27 Dec 2017 10:25:33 +0100
Raw View
--089e082ce448461cc005614efba2
Content-Type: text/plain; charset="UTF-8"
> If on the other hand the error is produced in a version after
std::unreachable is introduced
noexcept, constexpr, if constexpr et al. are incompatible with previous
versions. This is normally solved with some trivial conditional assembly.
On 24 December 2017 at 11:25, 'Edward Catmur' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:
>
>
> On 24 Dec 2017 08:37, "Viacheslav Usov" <via.usov@gmail.com> wrote:
>
> On Sat, Dec 23, 2017 at 9:45 PM, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
> > If the errors are in their own code, they will never upgrade.
>
> Unqualified "most projects" and unqualified "will never upgrade" do not
> sound convincing. I can agree with a trivial statement that "while there
> are errors, they will not officially upgrade". But this does not imply
> "they will not work on those errors in order to upgrade". This lacks any
> basis in fact and directly contradicts my own experience.
>
>
> My concern is that they will not be able to work on those errors, because
> the simplest solution - inserting calls to std::unreachable - will prevent
> their code working on the previous version. If on the other hand the error
> is produced in a version after std::unreachable is introduced, then
> projects that aim only for compatibility with the most recent version and
> two versions during the transition at least will be able to cope.
>
>
> Cheers,
> V.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/is
> ocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
> To unsubscribe from this group and all its topics, 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/is
> ocpp.org/d/msgid/std-proposals/CAA7YVg0%2BnAQi8fonMbya6wJiDw
> 5oT46Fmv3SCx2ud9WtrKjBPQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0%2BnAQi8fonMbya6wJiDw5oT46Fmv3SCx2ud9WtrKjBPQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
>
> --
> 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/CAJnLdOY5KWX5hy4vimzPco1JE0nce
> 4bbfYxho0XJhX8%2BkoaYcQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOY5KWX5hy4vimzPco1JE0nce4bbfYxho0XJhX8%2BkoaYcQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CALvx3hacknr6pLxcqdNtoPzGveO-nrm_-q0TdwK9kqkj5qCP%3Dw%40mail.gmail.com.
--089e082ce448461cc005614efba2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">If on the other=
hand the error is produced in a version after std::unreachable is introduc=
ed<br><br>noexcept, constexpr, if constexpr et al. are incompatible with pr=
evious versions. This is normally solved with some trivial conditional asse=
mbly.</span></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"=
>On 24 December 2017 at 11:25, 'Edward Catmur' via ISO C++ Standard=
- Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@i=
socpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><span class=3D""><div>=
<br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 24 Dec 201=
7 08:37, "Viacheslav Usov" <<a href=3D"mailto:via.usov@gmail.c=
om" target=3D"_blank">via.usov@gmail.com</a>> wrote:<br type=3D"attribut=
ion"><blockquote class=3D"m_-652367320257834468quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div cl=
ass=3D"gmail_extra"><div class=3D"m_-652367320257834468quoted-text"><div cl=
ass=3D"gmail_quote">On Sat, Dec 23, 2017 at 9:45 PM, 'Edward Catmur'=
; via ISO C++ Standard - Future Proposals <span dir=3D"ltr"><<a href=3D"=
mailto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org=
</a>></span> wrote:</div><div class=3D"gmail_quote"><br></div><div class=
=3D"gmail_quote">>=C2=A0If the errors are in their own code, they will n=
ever upgrade.</div></div><div class=3D"gmail_quote"><br><div>Unqualified &q=
uot;most projects" and unqualified "will never upgrade" do n=
ot sound convincing. I can agree with a trivial statement that "while =
there are errors, they will not officially upgrade". But this does not=
imply "they will not work on those errors in order to upgrade". =
This lacks any basis in fact and directly contradicts my own experience.=C2=
=A0</div><div></div></div></div></div></blockquote></div></div></div><div d=
ir=3D"auto"><br></div></span><div dir=3D"auto">My concern is that they will=
not be able to work on those errors, because the simplest solution - inser=
ting calls to std::unreachable - will prevent their code working on the pre=
vious version. If on the other hand the error is produced in a version afte=
r std::unreachable is introduced, then projects that aim only for compatibi=
lity with the most recent version and two versions during the transition at=
least will be able to cope.=C2=A0</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"m_-652367320257834468quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote"><div><br></div><div>Cheers,</div><div>V.</d=
iv></div></div></div><div class=3D"m_-652367320257834468quoted-text">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/is<wbr>ocpp.org/d/topic/std-proposals<wbr>/U=
u2QViiWh4k/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isoc<wbr>pp.org</a>.<span class=3D""><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></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/CAA7YVg0%2BnAQi8fonMbya6wJiDw5oT46Fmv=
3SCx2ud9WtrKjBPQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/st=
d-proposals<wbr>/CAA7YVg0%2BnAQi8fonMbya6wJiDw<wbr>5oT46Fmv3SCx2ud9WtrKjBPQ=
%<wbr>40mail.gmail.com</a>.<br>
</span></blockquote></div><br></div></div></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/CAJnLdOY5KWX5hy4vimzPco1JE0nce4bbfYxh=
o0XJhX8%2BkoaYcQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/<wbr>CAJnLdOY5KWX5hy4vimzPco1JE0nce<wbr>4bbfYxho0XJhX8%2Bk=
oaYcQ%<wbr>40mail.gmail.com</a>.<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/CALvx3hacknr6pLxcqdNtoPzGveO-nrm_-q0T=
dwK9kqkj5qCP%3Dw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hacknr6pL=
xcqdNtoPzGveO-nrm_-q0TdwK9kqkj5qCP%3Dw%40mail.gmail.com</a>.<br />
--089e082ce448461cc005614efba2--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Wed, 27 Dec 2017 10:27:36 +0100
Raw View
--f403045c4866962d7605614f02f8
Content-Type: text/plain; charset="UTF-8"
> This is normally solved with some trivial conditional assembly.
I of course mean conditional compilation :) Look at me, showing my age...
On 27 December 2017 at 10:25, Richard Hodges <hodges.r@gmail.com> wrote:
> > If on the other hand the error is produced in a version after
> std::unreachable is introduced
>
> noexcept, constexpr, if constexpr et al. are incompatible with previous
> versions. This is normally solved with some trivial conditional assembly.
>
> On 24 December 2017 at 11:25, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>>
>>
>> On 24 Dec 2017 08:37, "Viacheslav Usov" <via.usov@gmail.com> wrote:
>>
>> On Sat, Dec 23, 2017 at 9:45 PM, 'Edward Catmur' via ISO C++ Standard -
>> Future Proposals <std-proposals@isocpp.org> wrote:
>>
>> > If the errors are in their own code, they will never upgrade.
>>
>> Unqualified "most projects" and unqualified "will never upgrade" do not
>> sound convincing. I can agree with a trivial statement that "while there
>> are errors, they will not officially upgrade". But this does not imply
>> "they will not work on those errors in order to upgrade". This lacks any
>> basis in fact and directly contradicts my own experience.
>>
>>
>> My concern is that they will not be able to work on those errors, because
>> the simplest solution - inserting calls to std::unreachable - will prevent
>> their code working on the previous version. If on the other hand the error
>> is produced in a version after std::unreachable is introduced, then
>> projects that aim only for compatibility with the most recent version and
>> two versions during the transition at least will be able to cope.
>>
>>
>> Cheers,
>> V.
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit https://groups.google.com/a/is
>> ocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/is
>> ocpp.org/d/msgid/std-proposals/CAA7YVg0%2BnAQi8fonMbya6wJiDw
>> 5oT46Fmv3SCx2ud9WtrKjBPQ%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0%2BnAQi8fonMbya6wJiDw5oT46Fmv3SCx2ud9WtrKjBPQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>>
>> --
>> 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/is
>> ocpp.org/d/msgid/std-proposals/CAJnLdOY5KWX5hy4vimzPco1JE0nc
>> e4bbfYxho0XJhX8%2BkoaYcQ%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOY5KWX5hy4vimzPco1JE0nce4bbfYxho0XJhX8%2BkoaYcQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>
--
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/CALvx3hZN0X3L5wr-mgwSA7q5ODQqmmav2DaLy-WgZrpQSbUhyQ%40mail.gmail.com.
--f403045c4866962d7605614f02f8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">=C2=A0This is n=
ormally solved with some trivial conditional assembly.<br><br>I of course m=
ean conditional compilation :) Look at me, showing my age...</span><div><sp=
an style=3D"font-size:12.8px"><br></span></div></div><div class=3D"gmail_ex=
tra"><br><div class=3D"gmail_quote">On 27 December 2017 at 10:25, Richard H=
odges <span dir=3D"ltr"><<a href=3D"mailto:hodges.r@gmail.com" target=3D=
"_blank">hodges.r@gmail.com</a>></span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">If on =
the other hand the error is produced in a version after std::unreachable is=
introduced<br><br>noexcept, constexpr, if constexpr et al. are incompatibl=
e with previous versions. This is normally solved with some trivial conditi=
onal assembly.</span></div><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On 24 December 2017 at 11:25, 'Edward Catmur' via ISO C++=
Standard - Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-pr=
oposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><span><div><b=
r><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 24 Dec 2017 =
08:37, "Viacheslav Usov" <<a href=3D"mailto:via.usov@gmail.com=
" target=3D"_blank">via.usov@gmail.com</a>> wrote:<br type=3D"attributio=
n"><blockquote class=3D"m_-295753152284829927m_-652367320257834468quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"m_-295753152284829927m=
_-652367320257834468quoted-text"><div class=3D"gmail_quote">On Sat, Dec 23,=
2017 at 9:45 PM, 'Edward Catmur' via ISO C++ Standard - Future Pro=
posals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@isocpp.org" ta=
rget=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:</div><div cl=
ass=3D"gmail_quote"><br></div><div class=3D"gmail_quote">>=C2=A0If the e=
rrors are in their own code, they will never upgrade.</div></div><div class=
=3D"gmail_quote"><br><div>Unqualified "most projects" and unquali=
fied "will never upgrade" do not sound convincing. I can agree wi=
th a trivial statement that "while there are errors, they will not off=
icially upgrade". But this does not imply "they will not work on =
those errors in order to upgrade". This lacks any basis in fact and di=
rectly contradicts my own experience.=C2=A0</div><div></div></div></div></d=
iv></blockquote></div></div></div><div dir=3D"auto"><br></div></span><div d=
ir=3D"auto">My concern is that they will not be able to work on those error=
s, because the simplest solution - inserting calls to std::unreachable - wi=
ll prevent their code working on the previous version. If on the other hand=
the error is produced in a version after std::unreachable is introduced, t=
hen projects that aim only for compatibility with the most recent version a=
nd two versions during the transition at least will be able to cope.=C2=A0<=
/div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_extr=
a"><div class=3D"gmail_quote"><blockquote class=3D"m_-295753152284829927m_-=
652367320257834468quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote"><div><br></div><div>Cheers,</div><div>V.</div></div></div=
></div><div class=3D"m_-295753152284829927m_-652367320257834468quoted-text"=
>
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/is<wbr>ocpp.org/d/topic/std-proposals<wbr>/U=
u2QViiWh4k/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isoc<wbr>pp.org</a>.<span class=3D""><span><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></span></di=
v><span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0%2BnAQi8fonMbya6wJiDw5oT46Fmv=
3SCx2ud9WtrKjBPQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/st=
d-proposals<wbr>/CAA7YVg0%2BnAQi8fonMbya6wJiDw<wbr>5oT46Fmv3SCx2ud9WtrKjBPQ=
%40mai<wbr>l.gmail.com</a>.<br>
</span></blockquote></div><br></div></div></div><span class=3D""><span>
<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@isoc<wbr>pp.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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdOY5KWX5hy4vimzPco1JE0nce4bbfYxh=
o0XJhX8%2BkoaYcQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/st=
d-proposals<wbr>/CAJnLdOY5KWX5hy4vimzPco1JE0nc<wbr>e4bbfYxho0XJhX8%2BkoaYcQ=
%40mai<wbr>l.gmail.com</a>.<br>
</blockquote></div><br></div>
</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/CALvx3hZN0X3L5wr-mgwSA7q5ODQqmmav2DaL=
y-WgZrpQSbUhyQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZN0X3L5wr-=
mgwSA7q5ODQqmmav2DaLy-WgZrpQSbUhyQ%40mail.gmail.com</a>.<br />
--f403045c4866962d7605614f02f8--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 27 Dec 2017 09:37:18 +0000
Raw View
--f403045e6d8e4c0e8505614f253c
Content-Type: text/plain; charset="UTF-8"
On 27 Dec 2017 09:27, "Richard Hodges" <hodges.r@gmail.com> wrote:
> This is normally solved with some trivial conditional assembly.
I of course mean conditional compilation :) Look at me, showing my age...
Noexcept and constexpr are optional additions to a program; they can easily
be omitted. Your proposed unreachable would require either a minimum of 3
extra lines per function or a preprocessor macro library. This is an
unnecessary imposition.
On 27 December 2017 at 10:25, Richard Hodges <hodges.r@gmail.com> wrote:
> > If on the other hand the error is produced in a version after
> std::unreachable is introduced
>
> noexcept, constexpr, if constexpr et al. are incompatible with previous
> versions. This is normally solved with some trivial conditional assembly.
>
> On 24 December 2017 at 11:25, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>>
>>
>> On 24 Dec 2017 08:37, "Viacheslav Usov" <via.usov@gmail.com> wrote:
>>
>> On Sat, Dec 23, 2017 at 9:45 PM, 'Edward Catmur' via ISO C++ Standard -
>> Future Proposals <std-proposals@isocpp.org> wrote:
>>
>> > If the errors are in their own code, they will never upgrade.
>>
>> Unqualified "most projects" and unqualified "will never upgrade" do not
>> sound convincing. I can agree with a trivial statement that "while there
>> are errors, they will not officially upgrade". But this does not imply
>> "they will not work on those errors in order to upgrade". This lacks any
>> basis in fact and directly contradicts my own experience.
>>
>>
>> My concern is that they will not be able to work on those errors, because
>> the simplest solution - inserting calls to std::unreachable - will prevent
>> their code working on the previous version. If on the other hand the error
>> is produced in a version after std::unreachable is introduced, then
>> projects that aim only for compatibility with the most recent version and
>> two versions during the transition at least will be able to cope.
>>
>>
>> Cheers,
>> V.
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit https://groups.google.com/a/is
>> ocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/is
>> ocpp.org/d/msgid/std-proposals/CAA7YVg0%2BnAQi8fonMbya6wJiDw
>> 5oT46Fmv3SCx2ud9WtrKjBPQ%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0%2BnAQi8fonMbya6wJiDw5oT46Fmv3SCx2ud9WtrKjBPQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>>
>> --
>> 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/is
>> ocpp.org/d/msgid/std-proposals/CAJnLdOY5KWX5hy4vimzPco1JE0nc
>> e4bbfYxho0XJhX8%2BkoaYcQ%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOY5KWX5hy4vimzPco1JE0nce4bbfYxho0XJhX8%2BkoaYcQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>
--
You received this message because you are subscribed to a topic in the
Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/
isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
To unsubscribe from this group and all its topics, 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/CALvx3hZN0X3L5wr-mgwSA7q5ODQqmmav2DaLy-
WgZrpQSbUhyQ%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZN0X3L5wr-mgwSA7q5ODQqmmav2DaLy-WgZrpQSbUhyQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
..
--
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/CAJnLdOaqVNLV-RdGz%3DUokpemFOU8ekf10Sj%2Be%2B%3DSKUg2q9J56w%40mail.gmail.com.
--f403045e6d8e4c0e8505614f253c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On 27 Dec 2017 09:27, "Richard Hodges" <<a href=3D"m=
ailto:hodges.r@gmail.com">hodges.r@gmail.com</a>> wrote:<br type=3D"attr=
ibution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">>=C2=A0<span style=3D=
"font-size:12.8px">=C2=A0This is normally solved with some trivial conditio=
nal assembly.<br><br>I of course mean conditional compilation :) Look at me=
, showing my age...</span><div><span style=3D"font-size:12.8px"></span></di=
v></div></blockquote></div></div></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Noexcept and constexpr are optional additions to a program; they =
can easily be omitted. Your proposed unreachable would require either a min=
imum of 3 extra lines per function or a preprocessor macro library. This is=
an unnecessary imposition.=C2=A0</div><div dir=3D"auto"><br></div><div dir=
=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote=
class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div><span style=3D"font-size:12.8px"><br></=
span></div></div><div class=3D"elided-text"><div class=3D"gmail_extra"><br>=
<div class=3D"gmail_quote">On 27 December 2017 at 10:25, Richard Hodges <sp=
an dir=3D"ltr"><<a href=3D"mailto:hodges.r@gmail.com" target=3D"_blank">=
hodges.r@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">If on the other=
hand the error is produced in a version after std::unreachable is introduc=
ed<br><br>noexcept, constexpr, if constexpr et al. are incompatible with pr=
evious versions. This is normally solved with some trivial conditional asse=
mbly.</span></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"=
>On 24 December 2017 at 11:25, 'Edward Catmur' via ISO C++ Standard=
- Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@i=
socpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><span><div><br><div cl=
ass=3D"gmail_extra"><br><div class=3D"gmail_quote">On 24 Dec 2017 08:37, &q=
uot;Viacheslav Usov" <<a href=3D"mailto:via.usov@gmail.com" target=
=3D"_blank">via.usov@gmail.com</a>> wrote:<br type=3D"attribution"><bloc=
kquote class=3D"m_3151646788672652149m_-295753152284829927m_-65236732025783=
4468quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"m_3151646=
788672652149m_-295753152284829927m_-652367320257834468quoted-text"><div cla=
ss=3D"gmail_quote">On Sat, Dec 23, 2017 at 9:45 PM, 'Edward Catmur'=
via ISO C++ Standard - Future Proposals <span dir=3D"ltr"><<a href=3D"m=
ailto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org<=
/a>></span> wrote:</div><div class=3D"gmail_quote"><br></div><div class=
=3D"gmail_quote">>=C2=A0If the errors are in their own code, they will n=
ever upgrade.</div></div><div class=3D"gmail_quote"><br><div>Unqualified &q=
uot;most projects" and unqualified "will never upgrade" do n=
ot sound convincing. I can agree with a trivial statement that "while =
there are errors, they will not officially upgrade". But this does not=
imply "they will not work on those errors in order to upgrade". =
This lacks any basis in fact and directly contradicts my own experience.=C2=
=A0</div><div></div></div></div></div></blockquote></div></div></div><div d=
ir=3D"auto"><br></div></span><div dir=3D"auto">My concern is that they will=
not be able to work on those errors, because the simplest solution - inser=
ting calls to std::unreachable - will prevent their code working on the pre=
vious version. If on the other hand the error is produced in a version afte=
r std::unreachable is introduced, then projects that aim only for compatibi=
lity with the most recent version and two versions during the transition at=
least will be able to cope.=C2=A0</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"m_3151646788672652149m_-295753152284829927m_-652367320257834468q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><=
div><br></div><div>Cheers,</div><div>V.</div></div></div></div><div class=
=3D"m_3151646788672652149m_-295753152284829927m_-652367320257834468quoted-t=
ext">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/is<wbr>ocpp.org/d/topic/std-proposals<wbr>/U=
u2QViiWh4k/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isoc<wbr>pp.org</a>.<span><span><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></span></di=
v><span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0%2BnAQi8fonMbya6wJiDw5oT46Fmv=
3SCx2ud9WtrKjBPQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/st=
d-proposals<wbr>/CAA7YVg0%2BnAQi8fonMbya6wJiDw<wbr>5oT46Fmv3SCx2ud9WtrKjBPQ=
%40mai<wbr>l.gmail.com</a>.<br>
</span></blockquote></div><br></div></div></div><span><span>
<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@isoc<wbr>pp.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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdOY5KWX5hy4vimzPco1JE0nce4bbfYxh=
o0XJhX8%2BkoaYcQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/st=
d-proposals<wbr>/CAJnLdOY5KWX5hy4vimzPco1JE0nc<wbr>e4bbfYxho0XJhX8%2BkoaYcQ=
%40mai<wbr>l.gmail.com</a>.<br>
</blockquote></div><br></div>
</blockquote></div><br></div>
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/U=
u2QViiWh4k/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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/CALvx3hZN0X3L5wr-mgwSA7q5ODQqmmav2DaL=
y-WgZrpQSbUhyQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-=
<wbr>proposals/CALvx3hZN0X3L5wr-<wbr>mgwSA7q5ODQqmmav2DaLy-<wbr>WgZrpQSbUhy=
Q%40mail.gmail.com</a>.<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/CAJnLdOaqVNLV-RdGz%3DUokpemFOU8ekf10S=
j%2Be%2B%3DSKUg2q9J56w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOaq=
VNLV-RdGz%3DUokpemFOU8ekf10Sj%2Be%2B%3DSKUg2q9J56w%40mail.gmail.com</a>.<br=
/>
--f403045e6d8e4c0e8505614f253c--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Wed, 27 Dec 2017 10:42:31 +0100
Raw View
--001a113fbc08ebd4a305614f37f9
Content-Type: text/plain; charset="UTF-8"
> This is an unnecessary imposition.
None of any of it is 'necessary'. We can just limp along, remembering to
plaster over the broken bits of the language and remembering to dodge the
landmines inherent in the language if we want.
Or we can find a way to take this much-loved but deeply flawed language and
turn it into something beautiful and perfect.
Wouldn't you prefer that?
On 27 December 2017 at 10:37, 'Edward Catmur' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:
>
>
> On 27 Dec 2017 09:27, "Richard Hodges" <hodges.r@gmail.com> wrote:
>
> > This is normally solved with some trivial conditional assembly.
>
> I of course mean conditional compilation :) Look at me, showing my age...
>
>
> Noexcept and constexpr are optional additions to a program; they can
> easily be omitted. Your proposed unreachable would require either a minimum
> of 3 extra lines per function or a preprocessor macro library. This is an
> unnecessary imposition.
>
>
>
> On 27 December 2017 at 10:25, Richard Hodges <hodges.r@gmail.com> wrote:
>
>> > If on the other hand the error is produced in a version after
>> std::unreachable is introduced
>>
>> noexcept, constexpr, if constexpr et al. are incompatible with previous
>> versions. This is normally solved with some trivial conditional assembly.
>>
>> On 24 December 2017 at 11:25, 'Edward Catmur' via ISO C++ Standard -
>> Future Proposals <std-proposals@isocpp.org> wrote:
>>
>>>
>>>
>>> On 24 Dec 2017 08:37, "Viacheslav Usov" <via.usov@gmail.com> wrote:
>>>
>>> On Sat, Dec 23, 2017 at 9:45 PM, 'Edward Catmur' via ISO C++ Standard -
>>> Future Proposals <std-proposals@isocpp.org> wrote:
>>>
>>> > If the errors are in their own code, they will never upgrade.
>>>
>>> Unqualified "most projects" and unqualified "will never upgrade" do not
>>> sound convincing. I can agree with a trivial statement that "while there
>>> are errors, they will not officially upgrade". But this does not imply
>>> "they will not work on those errors in order to upgrade". This lacks any
>>> basis in fact and directly contradicts my own experience.
>>>
>>>
>>> My concern is that they will not be able to work on those errors,
>>> because the simplest solution - inserting calls to std::unreachable - will
>>> prevent their code working on the previous version. If on the other hand
>>> the error is produced in a version after std::unreachable is introduced,
>>> then projects that aim only for compatibility with the most recent version
>>> and two versions during the transition at least will be able to cope.
>>>
>>>
>>> Cheers,
>>> V.
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this topic, visit https://groups.google.com/a/is
>>> ocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
>>> To unsubscribe from this group and all its topics, 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/is
>>> ocpp.org/d/msgid/std-proposals/CAA7YVg0%2BnAQi8fonMbya6wJiDw
>>> 5oT46Fmv3SCx2ud9WtrKjBPQ%40mail.gmail.com
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0%2BnAQi8fonMbya6wJiDw5oT46Fmv3SCx2ud9WtrKjBPQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>>
>>> --
>>> 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/is
>>> ocpp.org/d/msgid/std-proposals/CAJnLdOY5KWX5hy4vimzPco1JE0nc
>>> e4bbfYxho0XJhX8%2BkoaYcQ%40mail.gmail.com
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOY5KWX5hy4vimzPco1JE0nce4bbfYxho0XJhX8%2BkoaYcQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/is
> ocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
> To unsubscribe from this group and all its topics, 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/is
> ocpp.org/d/msgid/std-proposals/CALvx3hZN0X3L5wr-mgwSA7q5ODQq
> mmav2DaLy-WgZrpQSbUhyQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZN0X3L5wr-mgwSA7q5ODQqmmav2DaLy-WgZrpQSbUhyQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
>
> --
> 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/CAJnLdOaqVNLV-RdGz%
> 3DUokpemFOU8ekf10Sj%2Be%2B%3DSKUg2q9J56w%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOaqVNLV-RdGz%3DUokpemFOU8ekf10Sj%2Be%2B%3DSKUg2q9J56w%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CALvx3hYSH%2BoUy-KCRRMM%2BQAYQYKxexrSey%2BXQ_%2BywNLD3Nq%3DRg%40mail.gmail.com.
--001a113fbc08ebd4a305614f37f9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">This is an unne=
cessary imposition.=C2=A0</span><div><span style=3D"font-size:12.8px"><br><=
/span></div><div><span style=3D"font-size:12.8px">None of any of it is '=
;necessary'. We can just limp along, remembering to plaster over the br=
oken bits of the language and remembering to dodge the landmines inherent i=
n the language if we want.<br><br>Or we can find a way to take this much-lo=
ved but deeply flawed language and turn it into something beautiful and per=
fect.<br><br>Wouldn't you prefer that?<br><br><br><br></span></div></di=
v><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 27 December =
2017 at 10:37, 'Edward Catmur' via ISO C++ Standard - Future Propos=
als <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@isocpp.org" targe=
t=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"auto"><span class=3D""><div><br><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On 27 Dec 2017 09:27, "=
;Richard Hodges" <<a href=3D"mailto:hodges.r@gmail.com" target=3D"_=
blank">hodges.r@gmail.com</a>> wrote:<br type=3D"attribution"><blockquot=
e class=3D"m_-2630504461780809314quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">>=C2=A0<span style=
=3D"font-size:12.8px">=C2=A0This is normally solved with some trivial condi=
tional assembly.<br><br>I of course mean conditional compilation :) Look at=
me, showing my age...</span><div><span style=3D"font-size:12.8px"></span><=
/div></div></blockquote></div></div></div><div dir=3D"auto"><br></div></spa=
n><div dir=3D"auto">Noexcept and constexpr are optional additions to a prog=
ram; they can easily be omitted. Your proposed unreachable would require ei=
ther a minimum of 3 extra lines per function or a preprocessor macro librar=
y. This is an unnecessary imposition.=C2=A0</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><=
blockquote class=3D"m_-2630504461780809314quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><div d=
ir=3D"ltr"><div><span style=3D"font-size:12.8px"><br></span></div></div><di=
v class=3D"m_-2630504461780809314elided-text"><div class=3D"gmail_extra"><b=
r><div class=3D"gmail_quote">On 27 December 2017 at 10:25, Richard Hodges <=
span dir=3D"ltr"><<a href=3D"mailto:hodges.r@gmail.com" target=3D"_blank=
">hodges.r@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">If on the oth=
er hand the error is produced in a version after std::unreachable is introd=
uced<br><br>noexcept, constexpr, if constexpr et al. are incompatible with =
previous versions. This is normally solved with some trivial conditional as=
sembly.</span></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quot=
e">On 24 December 2017 at 11:25, 'Edward Catmur' via ISO C++ Standa=
rd - Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals=
@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><span><div><br><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 24 Dec 2017 08:37, =
"Viacheslav Usov" <<a href=3D"mailto:via.usov@gmail.com" targe=
t=3D"_blank">via.usov@gmail.com</a>> wrote:<br type=3D"attribution"><blo=
ckquote class=3D"m_-2630504461780809314m_3151646788672652149m_-295753152284=
829927m_-652367320257834468quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"m_-2630504461780809314m_3151646788672652149m_-295753152284829=
927m_-652367320257834468quoted-text"><div class=3D"gmail_quote">On Sat, Dec=
23, 2017 at 9:45 PM, 'Edward Catmur' via ISO C++ Standard - Future=
Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@isocpp.org=
" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:</div><di=
v class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">>=C2=A0If t=
he errors are in their own code, they will never upgrade.</div></div><div c=
lass=3D"gmail_quote"><br><div>Unqualified "most projects" and unq=
ualified "will never upgrade" do not sound convincing. I can agre=
e with a trivial statement that "while there are errors, they will not=
officially upgrade". But this does not imply "they will not work=
on those errors in order to upgrade". This lacks any basis in fact an=
d directly contradicts my own experience.=C2=A0</div><div></div></div></div=
></div></blockquote></div></div></div><div dir=3D"auto"><br></div></span><d=
iv dir=3D"auto">My concern is that they will not be able to work on those e=
rrors, because the simplest solution - inserting calls to std::unreachable =
- will prevent their code working on the previous version. If on the other =
hand the error is produced in a version after std::unreachable is introduce=
d, then projects that aim only for compatibility with the most recent versi=
on and two versions during the transition at least will be able to cope.=C2=
=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_=
extra"><div class=3D"gmail_quote"><blockquote class=3D"m_-26305044617808093=
14m_3151646788672652149m_-295753152284829927m_-652367320257834468quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><br><=
/div><div>Cheers,</div><div>V.</div></div></div></div><div class=3D"m_-2630=
504461780809314m_3151646788672652149m_-295753152284829927m_-652367320257834=
468quoted-text">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/is<wbr>ocpp.org/d/topic/std-proposals<wbr>/U=
u2QViiWh4k/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isoc<wbr>pp.org</a>.<span><span><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></span></di=
v><span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0%2BnAQi8fonMbya6wJiDw5oT46Fmv=
3SCx2ud9WtrKjBPQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/st=
d-proposals<wbr>/CAA7YVg0%2BnAQi8fonMbya6wJiDw<wbr>5oT46Fmv3SCx2ud9WtrKjBPQ=
%40mai<wbr>l.gmail.com</a>.<br>
</span></blockquote></div><br></div></div></div><span><span>
<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@isoc<wbr>pp.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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdOY5KWX5hy4vimzPco1JE0nce4bbfYxh=
o0XJhX8%2BkoaYcQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/st=
d-proposals<wbr>/CAJnLdOY5KWX5hy4vimzPco1JE0nc<wbr>e4bbfYxho0XJhX8%2BkoaYcQ=
%40mai<wbr>l.gmail.com</a>.<br>
</blockquote></div><br></div>
</blockquote></div><br></div>
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/is<wbr>ocpp.org/d/topic/std-proposals<wbr>/U=
u2QViiWh4k/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isoc<wbr>pp.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></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hZN0X3L5wr-mgwSA7q5ODQqmmav2DaL=
y-WgZrpQSbUhyQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-=
proposals<wbr>/CALvx3hZN0X3L5wr-mgwSA7q5ODQq<wbr>mmav2DaLy-WgZrpQSbUhyQ%40m=
ail.<wbr>gmail.com</a>.<br>
</blockquote></div><br></div></div></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/CAJnLdOaqVNLV-RdGz%3DUokpemFOU8ekf10S=
j%2Be%2B%3DSKUg2q9J56w%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/=
msgid/std-<wbr>proposals/CAJnLdOaqVNLV-RdGz%<wbr>3DUokpemFOU8ekf10Sj%2Be%2B=
%<wbr>3DSKUg2q9J56w%40mail.gmail.com</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/CALvx3hYSH%2BoUy-KCRRMM%2BQAYQYKxexrS=
ey%2BXQ_%2BywNLD3Nq%3DRg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3h=
YSH%2BoUy-KCRRMM%2BQAYQYKxexrSey%2BXQ_%2BywNLD3Nq%3DRg%40mail.gmail.com</a>=
..<br />
--001a113fbc08ebd4a305614f37f9--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 27 Dec 2017 10:49:40 -0200
Raw View
On quarta-feira, 27 de dezembro de 2017 07:42:31 -02 Richard Hodges wrote:
> None of any of it is 'necessary'. We can just limp along, remembering to
> plaster over the broken bits of the language and remembering to dodge the
> landmines inherent in the language if we want.
>
> Or we can find a way to take this much-loved but deeply flawed language and
> turn it into something beautiful and perfect.
>
> Wouldn't you prefer that?
Dude, for the last time. We all agree that the language should be improved. We
all agree that all sources should use std::unreachable() everywhere that it
needs to, eventually.
We only disagree on how fast we can break people's code.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/5653330.860i0d3HXX%40tjmaciei-mobl1.
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Wed, 27 Dec 2017 13:37:54 +0000
Raw View
--001a113dd154b920b605615281e4
Content-Type: text/plain; charset="UTF-8"
On 27 Dec 2017 09:37, "'Edward Catmur' via ISO C++ Standard - Future
Proposals" <std-proposals@isocpp.org> wrote:
Your proposed unreachable would require either a minimum of 3 extra lines
per function
Whilst I agree that this should be optional for quite some time, I don't
see how this needs a minimum of 3 extra lines per function. It needs a
single line at the end of the function in the case of a non-returner, does
it not?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMtEQ_N%2B2CF8bO2TRqD%2BvNb9d_U%3Dp0N9ECgCS%3Ddn2X%2B7A%40mail.gmail.com.
--001a113dd154b920b605615281e4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><br><div class=3D"gmail_extra" dir=3D"auto"><br><div clas=
s=3D"gmail_quote">On 27 Dec 2017 09:37, "'Edward Catmur' via I=
SO C++ Standard - Future Proposals" <<a href=3D"mailto:std-proposal=
s@isocpp.org">std-proposals@isocpp.org</a>> wrote:<blockquote class=3D"q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"auto"><div dir=3D"auto">Your proposed unreachable would requ=
ire either a minimum of 3 extra lines per function</div></div></blockquote>=
</div></div><div dir=3D"auto"><br></div><div dir=3D"auto">Whilst I agree th=
at this should be optional for quite some time, I don't see how this ne=
eds a minimum of 3 extra lines per function. It needs a single line at the =
end of the function in the case of a non-returner, does it not?</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/CAC%2B0CCMtEQ_N%2B2CF8bO2TRqD%2BvNb9d=
_U%3Dp0N9ECgCS%3Ddn2X%2B7A%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC=
%2B0CCMtEQ_N%2B2CF8bO2TRqD%2BvNb9d_U%3Dp0N9ECgCS%3Ddn2X%2B7A%40mail.gmail.c=
om</a>.<br />
--001a113dd154b920b605615281e4--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Wed, 27 Dec 2017 14:53:32 +0100
Raw View
> Dude, for the last time. We all agree that the language should be improve=
d.
This is a refreshingly positive response from a group of people who seem to=
be otherwise deeply jaded and negative. Merry Christmas!
> We only disagree on how fast we can break people's code.
A deprecation cycle followed by a mandate would seem to be the normal patte=
rn.
Since we are all in agreement, at least on the eventual aims, let=E2=80=99s=
get started. If I submit a paper on these lines which of you will sponsor =
it through a committee meeting?
> On 27 Dec 2017, at 13:49, Thiago Macieira <thiago@macieira.org> wrote:
>=20
> On quarta-feira, 27 de dezembro de 2017 07:42:31 -02 Richard Hodges wrote=
:
>> None of any of it is 'necessary'. We can just limp along, remembering to
>> plaster over the broken bits of the language and remembering to dodge th=
e
>> landmines inherent in the language if we want.
>>=20
>> Or we can find a way to take this much-loved but deeply flawed language =
and
>> turn it into something beautiful and perfect.
>>=20
>> Wouldn't you prefer that?
>=20
> Dude, for the last time. We all agree that the language should be improve=
d. We=20
> all agree that all sources should use std::unreachable() everywhere that =
it=20
> needs to, eventually.
>=20
> We only disagree on how fast we can break people's code.
>=20
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
>=20
> --=20
> You received this message because you are subscribed to the Google Groups=
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
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/isoc=
pp.org/d/msgid/std-proposals/5653330.860i0d3HXX%40tjmaciei-mobl1.
--=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/20BB9420-24A3-429C-BD16-40BA312678C7%40gmail.com=
..
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 27 Dec 2017 14:14:54 +0000
Raw View
--001a1148e9fc1aaf1b0561530645
Content-Type: text/plain; charset="UTF-8"
On Wed, Dec 27, 2017 at 1:37 PM, Jake Arkinstall <jake.arkinstall@gmail.com>
wrote:
>
>
> On 27 Dec 2017 09:37, "'Edward Catmur' via ISO C++ Standard - Future
> Proposals" <std-proposals@isocpp.org> wrote:
>
> Your proposed unreachable would require either a minimum of 3 extra lines
> per function
>
>
> Whilst I agree that this should be optional for quite some time, I don't
> see how this needs a minimum of 3 extra lines per function. It needs a
> single line at the end of the function in the case of a non-returner, does
> it not?
>
#if __cplusplus >= 202000L
std::unreachable();
#endif
--
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAC%2B0CCMtEQ_N%2B2CF8bO2TRqD%2BvNb9d_U%
> 3Dp0N9ECgCS%3Ddn2X%2B7A%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMtEQ_N%2B2CF8bO2TRqD%2BvNb9d_U%3Dp0N9ECgCS%3Ddn2X%2B7A%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAJnLdOb1P5gcXnCPdsOfBBfs3XL%3DtNWUO%3DM9CiTBBaZSGEPTFw%40mail.gmail.com.
--001a1148e9fc1aaf1b0561530645
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Dec 27, 2017 at 1:37 PM, Jake Arkinstall <span dir=3D"ltr"><=
<a href=3D"mailto:jake.arkinstall@gmail.com" target=3D"_blank">jake.arkinst=
all@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"auto"><br><div class=3D"gmail_extra" dir=3D"auto"><br><div class=3D"=
gmail_quote">On 27 Dec 2017 09:37, "'Edward Catmur' via ISO C+=
+ Standard - Future Proposals" <<a href=3D"mailto:std-proposals@iso=
cpp.org" target=3D"_blank">std-proposals@isocpp.org</a>> wrote:<blockquo=
te class=3D"m_-1355690860246941683quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto">Y=
our proposed unreachable would require either a minimum of 3 extra lines pe=
r function</div></div></blockquote></div></div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">Whilst I agree that this should be optional for quite som=
e time, I don't see how this needs a minimum of 3 extra lines per funct=
ion. It needs a single line at the end of the function in the case of a non=
-returner, does it not?</div></div></blockquote><div><br></div><div>#if __c=
plusplus >=3D 202000L</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 std::unreach=
able();</div><div>#endif</div><div><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><span class=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/U=
u2QViiWh4k/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMtEQ_N%2B2CF8bO2TRqD%2BvNb9d=
_U%3Dp0N9ECgCS%3Ddn2X%2B7A%40mail.gmail.com?utm_medium=3Demail&utm_sour=
ce=3Dfooter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/=
d/msgid/std-<wbr>proposals/CAC%2B0CCMtEQ_N%<wbr>2B2CF8bO2TRqD%2BvNb9d_U%<wb=
r>3Dp0N9ECgCS%3Ddn2X%2B7A%<wbr>40mail.gmail.com</a>.<br>
</font></span></blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAJnLdOb1P5gcXnCPdsOfBBfs3XL%3DtNWUO%=
3DM9CiTBBaZSGEPTFw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOb1P5gc=
XnCPdsOfBBfs3XL%3DtNWUO%3DM9CiTBBaZSGEPTFw%40mail.gmail.com</a>.<br />
--001a1148e9fc1aaf1b0561530645--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 27 Dec 2017 06:49:43 -0800 (PST)
Raw View
------=_Part_21443_1332333981.1514386183818
Content-Type: multipart/alternative;
boundary="----=_Part_21444_1333656844.1514386183818"
------=_Part_21444_1333656844.1514386183818
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wednesday, December 27, 2017 at 8:53:37 AM UTC-5, Richard Hodges wrote:
>
> > Dude, for the last time. We all agree that the language should be=20
> improved.=20
>
> This is a refreshingly positive response from a group of people who seem=
=20
> to be otherwise deeply jaded and negative. Merry Christmas!=20
>
> > We only disagree on how fast we can break people's code.=20
>
> A deprecation cycle followed by a mandate would seem to be the normal=20
> pattern.=20
>
> Since we are all in agreement, at least on the eventual aims, let=E2=80=
=99s get=20
> started. If I submit a paper on these lines which of you will sponsor it=
=20
> through a committee meeting?=20
>
A paper along* what* lines? That sometime in the future, something might be=
=20
deprecated? What's the point of that?
We already have a proposal on "unreachable" of some form, working its way=
=20
forward. We don't need anything more.
--=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/43180692-4ba6-4eba-ab40-dce561269679%40isocpp.or=
g.
------=_Part_21444_1333656844.1514386183818
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, December 27, 2017 at 8:53:37 AM UTC-=
5, Richard Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">> D=
ude, for the last time. We all agree that the language should be improved.
<br>
<br>This is a refreshingly positive response from a group of people who see=
m to be otherwise deeply jaded and negative. Merry Christmas!
<br>
<br>> We only disagree on how fast we can break people's code.
<br>
<br>A deprecation cycle followed by a mandate would seem to be the normal p=
attern.
<br>
<br>Since we are all in agreement, at least on the eventual aims, let=E2=80=
=99s get started. If I submit a paper on these lines which of you will spon=
sor it through a committee meeting?
<br></blockquote><div><br></div><div>A paper along<i> what</i> lines? That =
sometime in the future, something might be deprecated? What's the point=
of that?</div><div><br></div><div>We already have a proposal on "unre=
achable" of some form, working its way forward. We don't need anyt=
hing more.<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/43180692-4ba6-4eba-ab40-dce561269679%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/43180692-4ba6-4eba-ab40-dce561269679=
%40isocpp.org</a>.<br />
------=_Part_21444_1333656844.1514386183818--
------=_Part_21443_1332333981.1514386183818--
.
Author: Ricardo Fabiano de Andrade <ricardofabianodeandrade@gmail.com>
Date: Wed, 27 Dec 2017 16:09:08 +0000
Raw View
--001a11443dcc32d7d50561549fca
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I=E2=80=99ve seen many proposals in the form of feedback, analysis or even
suggesting a change in direction for an existing proposal, I don=E2=80=99t =
see why
not a proposal about =E2=80=9Cunreachable as a path to make return-less non=
-void
functions invalid=E2=80=9D wouldn=E2=80=99t be beneficial.
On Wed, Dec 27, 2017 at 8:49 AM Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Wednesday, December 27, 2017 at 8:53:37 AM UTC-5, Richard Hodges wrote=
:
>>
>> > Dude, for the last time. We all agree that the language should be
>> improved.
>>
>> This is a refreshingly positive response from a group of people who seem
>> to be otherwise deeply jaded and negative. Merry Christmas!
>>
>> > We only disagree on how fast we can break people's code.
>>
>> A deprecation cycle followed by a mandate would seem to be the normal
>> pattern.
>>
>> Since we are all in agreement, at least on the eventual aims, let=E2=80=
=99s get
>> started. If I submit a paper on these lines which of you will sponsor it
>> through a committee meeting?
>>
>
> A paper along* what* lines? That sometime in the future, something might
> be deprecated? What's the point of that?
>
> We already have a proposal on "unreachable" of some form, working its way
> forward. We don't need anything more.
>
> --
> 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/43180692-4ba=
6-4eba-ab40-dce561269679%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/43180692-4b=
a6-4eba-ab40-dce561269679%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/CA%2BfGSbN5-f2fbB8vur59svjLYJSS2yWoMdakL7B-2P_8p=
KTb4Q%40mail.gmail.com.
--001a11443dcc32d7d50561549fca
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">I=E2=80=99ve seen many proposals in the form of feedback,=
analysis or even suggesting a change in direction for an existing proposal=
, I don=E2=80=99t see why not a proposal about =E2=80=9Cunreachable as a pa=
th to make return-less non-void functions invalid=E2=80=9D wouldn=E2=80=99t=
be beneficial.</div><div><br><div class=3D"gmail_quote"><div>On Wed, Dec 2=
7, 2017 at 8:49 AM Nicol Bolas <<a href=3D"mailto:jmckesson@gmail.com">j=
mckesson@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div><br><br>On Wednesday, December 27, 2017 at 8:53:37 AM UTC-5, Richard Ho=
dges wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:=
0.8ex;border-left:1px #ccc solid;padding-left:1ex">> Dude, for the last =
time. We all agree that the language should be improved.
<br>
<br>This is a refreshingly positive response from a group of people who see=
m to be otherwise deeply jaded and negative. Merry Christmas!
<br>
<br>> We only disagree on how fast we can break people's code.
<br>
<br>A deprecation cycle followed by a mandate would seem to be the normal p=
attern.
<br>
<br>Since we are all in agreement, at least on the eventual aims, let=E2=80=
=99s get started. If I submit a paper on these lines which of you will spon=
sor it through a committee meeting?
<br></blockquote><div><br></div></div><div><div>A paper along<i> what</i> l=
ines? That sometime in the future, something might be deprecated? What'=
s the point of that?</div><div><br></div><div>We already have a proposal on=
"unreachable" of some form, working its way forward. We don'=
t need anything more.<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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/43180692-4ba6-4eba-ab40-dce561269679%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/43180692-4ba6-=
4eba-ab40-dce561269679%40isocpp.org</a>.<br>
</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/CA%2BfGSbN5-f2fbB8vur59svjLYJSS2yWoMd=
akL7B-2P_8pKTb4Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbN5-f2f=
bB8vur59svjLYJSS2yWoMdakL7B-2P_8pKTb4Q%40mail.gmail.com</a>.<br />
--001a11443dcc32d7d50561549fca--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 26 Dec 2017 12:00:10 -0500
Raw View
On 2017-12-22 23:20, Nicol Bolas wrote:
> On Friday, December 22, 2017 at 9:05:42 PM UTC-5, Matthew Woehlke wrote:
>> Such code has Undefined Behavior.
>
> No, it does not. Undefined behavior is not a static construct; it is a
> runtime construct. Therefore, outside of the simplest of cases, you cannot*
> know* that a function that doesn't have all control paths return/throw "has
> Undefined Behavior".
>
> Ill-formed is a static property of the code. The OP wants to turn any code
> that* theoretically* might exhibit UB into ill-formed code.
There are two categories of such functions: functions that *might* fall
off the end, and functions that *definitely* fall off the end.
I'm concerned mainly with the latter.
For example:
int foo {}
This code *definitely* has UB. Calling this function *will* invoke UB,
period. Don't give me any BS about it being a "runtime construct"
whether or not this function will cause UB; I can trivially tell that
there is *no chance at all* that it will *not* cause UB. I believe
compilers can tell also.
My preference, w.r.t. the OP's suggestion, is that compilers should only
reject code that *almost certainly* is UB, i.e. can be statically proven
that the function *will* be called with some input for which execution
will fall off the end (given the assumption that functions not marked
[[noreturn]] will in fact return normally).
(And, to be clear, I have limited sympathy for the case of a function
that is addressed but never called. I very much doubt those are so
common that having to instrument them, or insert a call to std::abort or
the like, is sufficiently onerous.)
>> We're not talking about breaking *good* code. We're talking about
>> refusing to compile code that is most definitely bad.
>
> No, we're not. We're talking about making this code not compile:
>
> std::string get_enum_name(SomeEnumeration e)
> {
> switch(e)
> {
> case SomeEnumeration::Enum1: return "Enum1";
> case ...;
> }
> }
Disagree; see above. While my own preference would be for that to not
compile either, I'm willing to be lenient there. What is absurd is that
code that *always* falls off the end of a function is accepted.
> "Ill formed, NDR" is typically used for cases where compilers have a hard
> time diagnosing a problem (ODR violations).
I think we've established that "will this function fall off the end" is
hard (impossible, even) to determine in the general case.
Again, my objective is for compilers to diagnose easy cases, and let it
slide otherwise. "Ill formed, NDR" may or may not be the right way to
express that...
> But it's clear that, if the
> condition happens, it is *most certainly* a problem and the compiler can
> guarantee nothing about the result. That's not the case here; if the
> compiler can't tell if the function can walk off the bottom, the compiler
> doesn't know if it is certainly a problem.
That... sure *sounds* like exactly what I'm trying to describe. (With
the minor variance that, instead of "can guarantee nothing about the
result", the expectation is that the compiler would compile the code as
if it is well-formed.)
> I don't understand what's so bad about just having the `unreachable`
> syntax, however it is that this gets spelled.
What's bad is that compilers consider "int foo() {}" to be perfectly
valid code. This is absurd and should have been fixed 10 years ago.
--
Matthew
--
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/p1tv2v%24sgt%241%40blaine.gmane.org.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 26 Dec 2017 16:33:39 -0500
Raw View
On 2017-12-21 07:58, Edward Catmur wrote:
> On 21 Dec 2017 12:01, Viacheslav Usov wrote:
>> On Thu, Dec 21, 2017 at 11:58 AM, Edward Catmur wrote:
>>> That's non-conformant. There is no latitude for an implementation to
>>> terminate translation of that function.
>>
>> Possible. However, it is a fact. Note that MSVC does this only when there
>> is no return statement at all, if there are some, then it emits a warning.
>
> Quite. Microsoft could have made the latter an error, since they are
> already non conformant. However, they did not. Why?
....because MSVC is rejecting code that is "almost certainly" broken
(claims about functions that are never executed notwithstanding; I'm
still waiting to see an *extant* example of such), but not rejecting
code that is only "possibly" broken but might never experience UB under
operational conditions. Many examples have been given of such functions,
and certainly these exist in the wild.
MSVC is Doing The Right Thing. Trying to strong-arm MSVC into
"conformance" would be IMO the worst thing we could do here.
--
Matthew
--
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/p1uf3p%2434a%241%40blaine.gmane.org.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 26 Dec 2017 15:56:46 -0500
Raw View
On 2017-12-24 05:37, Edward Catmur wrote:
::terminate preclude its being called from a constexpr
> function? I suppose there could be some compiler magic to allow it, but I
> think std::unreachable should be constexpr if at all possible.
I don't see why; per the standard, the effect of std::unreachable being
called is UB. In a constexpr context, I would expect that to translate
to the compiler rejecting your code. Transforming it to std::terminate
would be a conforming compiler extension, not something mandated by the
standard.
--
Matthew
--
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/p1ucuj%242nl%241%40blaine.gmane.org.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 26 Dec 2017 11:39:11 -0500
Raw View
On 2017-12-22 21:43, Ren Industries wrote:
> Again, demanding currently completely valid code to be altered for no
> reason is a non-starter.
It occurs to me, if we *did* get this, compiler vendors (that implement
it) would very likely add something like `-fallow-no-return` to turn it
off. That would allow code that depends on the old behavior to still
compile without modification, while still providing the safety benefits
for the 90+% of users that don't write code like that.
--
Matthew
--
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/p1ttrk%24er7%241%40blaine.gmane.org.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 26 Dec 2017 16:28:17 -0500
Raw View
On 2017-12-20 12:17, Ville Voutilainen wrote:
> On 20 December 2017 at 19:02, Richard Hodges <hodges.r@gmail.com> wrote:
>> One of my engineers, an experienced guy with 20 years writing c++, spent=
the
>> first half of today diagnosing something that turned out to be a result =
of
>> exactly this. Forgetting to return the shared_ptr he had created. In a
>> function he had written 30 minutes prior. The crash occurred in thread 3=
,
>> nowhere near the offending code that was executed in thread 1.
>>
>> Half a day. Over something the compiler could, no, *should* have told hi=
m on
>> the first compile.
>=20
> You're saying your compiler can't tell you that?
Not "can't". *DOESN'T*. The whole reason this thread exists is because
the current default behavior=C2=B9 - silently accept code that is clearly
broken - is... less than optimal. Since compiler vendors have proven
unwilling to change, we are proposing to change the standard to, ah,
"encourage" compiler vendors to quit doing the wrong thing by default.
(=C2=B9 ...at least in GCC and Clang. It's been claimed that MSVC is less
insane in this regard, although given that I've seen this sort of
garbage code slip into supposedly portable code bases, I'm not sure I
believe that.)
On 2017-12-20 12:55, Edward Catmur wrote:
> So you're admitting that you don't use Werror=3Dreturn-type nor=20
> fsanitize=3Dreturn? And yet you want to force this into the language?
Yes. Because these should be the *defaults*. Having to write build logic
to turn these on and/or manually enable them in *every single project*
is a problem. Developers forget to do this. It is absurd that they need
to remember to ask the compiler to tell them if they write broken code.
--=20
Matthew
--=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/p1uepm%24e2a%241%40blaine.gmane.org.
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Wed, 27 Dec 2017 18:15:32 +0100
Raw View
--001a113f259810164d0561558cc0
Content-Type: text/plain; charset="UTF-8"
On Tue, Dec 26, 2017 at 10:33 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:
> MSVC is Doing The Right Thing. Trying to strong-arm MSVC into
"conformance" would be IMO the worst thing we could do here.
As I mentioned earlier in the thread, MSVC's behaviour in this respect is
fully controllable, with the safer, if non-conformant, settings being the
default.
The full controllability is probably the explanation why code with
statically unsafe return paths is portable.
Cheers,
V.
--
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/CAA7YVg1XuZZDnWNXPTW71uSPW8J-%3DH%3DKJD-KLhKXdb4i98rfng%40mail.gmail.com.
--001a113f259810164d0561558cc0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Dec 26, 2017 at 10:33 PM, Matthew Woehlke <span dir=3D"ltr"><<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>></span> wrote:<br><div><br></div><div>>=C2=A0 MSVC is Doing =
The Right Thing. Trying to strong-arm MSVC into "conformance" wou=
ld be IMO the worst thing we could do here.</div><div><br></div><div>As I m=
entioned earlier in the thread, MSVC's behaviour in this respect is ful=
ly controllable, with the safer, if non-conformant, settings being the defa=
ult.</div><div><br></div><div>The full controllability is probably the expl=
anation why code with statically unsafe return paths is portable.</div><div=
><br></div><div>Cheers,</div><div>V.</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/CAA7YVg1XuZZDnWNXPTW71uSPW8J-%3DH%3DK=
JD-KLhKXdb4i98rfng%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1XuZZD=
nWNXPTW71uSPW8J-%3DH%3DKJD-KLhKXdb4i98rfng%40mail.gmail.com</a>.<br />
--001a113f259810164d0561558cc0--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 27 Dec 2017 09:46:55 -0800 (PST)
Raw View
------=_Part_21744_565884016.1514396815578
Content-Type: multipart/alternative;
boundary="----=_Part_21745_540137522.1514396815578"
------=_Part_21745_540137522.1514396815578
Content-Type: text/plain; charset="UTF-8"
On Wednesday, December 27, 2017 at 11:11:22 AM UTC-5, Matthew Woehlke wrote:
>
> On 2017-12-22 23:20, Nicol Bolas wrote:
> > On Friday, December 22, 2017 at 9:05:42 PM UTC-5, Matthew Woehlke wrote:
> >> Such code has Undefined Behavior.
> >
> > No, it does not. Undefined behavior is not a static construct; it is a
> > runtime construct. Therefore, outside of the simplest of cases, you
> cannot*
> > know* that a function that doesn't have all control paths return/throw
> "has
> > Undefined Behavior".
> >
> > Ill-formed is a static property of the code. The OP wants to turn any
> code
> > that* theoretically* might exhibit UB into ill-formed code.
>
> There are two categories of such functions: functions that *might* fall
> off the end, and functions that *definitely* fall off the end.
>
> I'm concerned mainly with the latter.
>
> For example:
>
> int foo {}
>
> This code *definitely* has UB. Calling this function *will* invoke UB,
> period. Don't give me any BS about it being a "runtime construct"
> whether or not this function will cause UB; I can trivially tell that
> there is *no chance at all* that it will *not* cause UB. I believe
> compilers can tell also.
>
> My preference, w.r.t. the OP's suggestion, is that compilers should only
> reject code that *almost certainly* is UB, i.e. can be statically proven
> that the function *will* be called with some input for which execution
> will fall off the end (given the assumption that functions not marked
> [[noreturn]] will in fact return normally).
>
I want to clarify something.
Is your preference that compilers reject this code, or that the* standard*
declare it to be ill-formed? Because those are two completely different
things to be asking for. The OP wants the latter; which do you want?
If all you want is for compilers to make their warnings more strict, that's
one thing. That's a real possibility, but only after several years of
having `std::unreachable` be available for use.
[aside: Personally, I think compilers shouldn't bother warning/erroring
about a completely empty function. If you write a function that has actual
code in it, then clearly you intend for it to be called. So if you forget
to return from it at all, that's obviously a mistake. But if you have a
completely empty function, you probably wrote it that way for a reason.]
But if you want the standard to declare such code ill-formed, you now need
to decide under what circumstances will things be ill-formed. How do you
*formally* express "almost certainly"?
And equally importantly, what of `[[noreturn]]` functions? Remember: the
idea with attributes is that well-formed code with attributes should also
be well-formed* without them*. So you can't have well-formedness be based
on an attribute like that.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dd7657a1-fbcc-47ca-9a8e-d5da33fcd204%40isocpp.org.
------=_Part_21745_540137522.1514396815578
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, December 27, 2017 at 11:11:22 AM UTC-5, Matt=
hew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2017-12-2=
2 23:20, Nicol Bolas wrote:
<br>> On Friday, December 22, 2017 at 9:05:42 PM UTC-5, Matthew Woehlke =
wrote:
<br>>> Such code has Undefined Behavior.=20
<br>>=20
<br>> No, it does not. Undefined behavior is not a static construct; it =
is a=20
<br>> runtime construct. Therefore, outside of the simplest of cases, yo=
u cannot*=20
<br>> know* that a function that doesn't have all control paths retu=
rn/throw "has=20
<br>> Undefined Behavior".
<br>>=20
<br>> Ill-formed is a static property of the code. The OP wants to turn =
any code=20
<br>> that* theoretically* might exhibit UB into ill-formed code.
<br>
<br>There are two categories of such functions: functions that *might* fall
<br>off the end, and functions that *definitely* fall off the end.
<br>
<br>I'm concerned mainly with the latter.
<br>
<br>For example:
<br>
<br>=C2=A0 int foo {}
<br>
<br>This code *definitely* has UB. Calling this function *will* invoke UB,
<br>period. Don't give me any BS about it being a "runtime constru=
ct"
<br>whether or not this function will cause UB; I can trivially tell that
<br>there is *no chance at all* that it will *not* cause UB. I believe
<br>compilers can tell also.
<br>
<br>My preference, w.r.t. the OP's suggestion, is that compilers should=
only
<br>reject code that *almost certainly* is UB, i.e. can be statically prove=
n
<br>that the function *will* be called with some input for which execution
<br>will fall off the end (given the assumption that functions not marked
<br>[[noreturn]] will in fact return normally).<br></blockquote><div><br></=
div><div>I want to clarify something.</div><div><br></div><div>Is your pref=
erence that compilers reject this code, or that the<i> standard</i> declare=
it to be ill-formed? Because those are two completely different things to =
be asking for. The OP wants the latter; which do you want?</div><div><br></=
div><div>If all you want is for compilers to make their warnings more stric=
t, that's one thing. That's a real possibility, but only after seve=
ral years of having `std::unreachable` be available for use.</div><div><br>=
</div><div>[aside: Personally, I think compilers shouldn't bother warni=
ng/erroring about a completely empty function. If you write a function that=
has actual code in it, then clearly you intend for it to be called. So if =
you forget to return from it at all, that's obviously a mistake. But if=
you have a completely empty function, you probably wrote it that way for a=
reason.]</div><div><br></div><div> But if you want the standard to declare=
such code ill-formed, you now need to decide under what circumstances will=
things be ill-formed. How do you <i>formally</i> express "almost cert=
ainly"?</div><div><br></div><div>And equally importantly, what of `[[n=
oreturn]]` functions? Remember: the idea with attributes is that well-forme=
d code with attributes should also be well-formed<i> without them</i>. So y=
ou can't have well-formedness be based on an attribute like that.<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/dd7657a1-fbcc-47ca-9a8e-d5da33fcd204%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dd7657a1-fbcc-47ca-9a8e-d5da33fcd204=
%40isocpp.org</a>.<br />
------=_Part_21745_540137522.1514396815578--
------=_Part_21744_565884016.1514396815578--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 27 Dec 2017 18:10:49 -0200
Raw View
On quarta-feira, 27 de dezembro de 2017 14:09:08 -02 Ricardo Fabiano de=20
Andrade wrote:
> I=E2=80=99ve seen many proposals in the form of feedback, analysis or eve=
n
> suggesting a change in direction for an existing proposal, I don=E2=80=99=
t see why
> not a proposal about =E2=80=9Cunreachable as a path to make return-less n=
on-void
> functions invalid=E2=80=9D wouldn=E2=80=99t be beneficial.
I agree. A paper outlining a future position, even if it's to happen 10 yea=
rs=20
down the line, is beneficial. It may not require committee action, but it w=
ill=20
make sure the debate is had.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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/2197453.8uH3gFBzBs%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 27 Dec 2017 18:19:30 -0200
Raw View
On ter=C3=A7a-feira, 26 de dezembro de 2017 15:00:10 -02 Matthew Woehlke wr=
ote:
> int foo {}
>=20
> This code *definitely* has UB. Calling this function *will* invoke UB,
> period. Don't give me any BS about it being a "runtime construct"
> whether or not this function will cause UB; I can trivially tell that
> there is *no chance at all* that it will *not* cause UB. I believe
> compilers can tell also.
Here's the full source code. Please tell me where the UB happens:
int foo {}
int main() { return 0; }
Please compile this with any compiler, run any sanity checking tool and tel=
l=20
me at what time the UB happens.
> (And, to be clear, I have limited sympathy for the case of a function
> that is addressed but never called. I very much doubt those are so
> common that having to instrument them, or insert a call to std::abort or
> the like, is sufficiently onerous.)
And yet they are possible.
I agree they aren't common at all. But they were never the issue to begin=
=20
with.
> Disagree; see above. While my own preference would be for that to not
> compile either, I'm willing to be lenient there. What is absurd is that
> code that *always* falls off the end of a function is accepted.
It doesn't always fall off the end of a function. In fact, it *never* falls=
=20
off if the contract is respected. But if you give it garbage, you get garba=
ge.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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/3013410.rUM6ukHYDk%40tjmaciei-mobl1.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 27 Dec 2017 13:30:46 -0800 (PST)
Raw View
------=_Part_22308_905246993.1514410246384
Content-Type: multipart/alternative;
boundary="----=_Part_22309_928997273.1514410246385"
------=_Part_22309_928997273.1514410246385
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wednesday, December 27, 2017 at 3:19:39 PM UTC-5, Thiago Macieira wrote:
>
> On ter=C3=A7a-feira, 26 de dezembro de 2017 15:00:10 -02 Matthew Woehlke =
wrote:=20
> > int foo {}=20
> >=20
> > This code *definitely* has UB. Calling this function *will* invoke UB,=
=20
> > period. Don't give me any BS about it being a "runtime construct"=20
> > whether or not this function will cause UB; I can trivially tell that=
=20
> > there is *no chance at all* that it will *not* cause UB. I believe=20
> > compilers can tell also.=20
>
> Here's the full source code. Please tell me where the UB happens:=20
>
> int foo {}=20
> int main() { return 0; }=20
>
> Please compile this with any compiler, run any sanity checking tool and=
=20
> tell=20
> me at what time the UB happens.
A better example would be this:
int foo()
{
int ix =3D 5;
ix +=3D bar(20);
}
Whether the user calls `foo` is essentially incidental; the user has=20
clearly made a mistake, so we should let them know about it.
> (And, to be clear, I have limited sympathy for the case of a function=20
>
> that is addressed but never called. I very much doubt those are so=20
> > common that having to instrument them, or insert a call to std::abort o=
r=20
> > the like, is sufficiently onerous.)=20
>
> And yet they are possible.=20
>
> I agree they aren't common at all. But they were never the issue to begin=
=20
> with.
>
Which is why I'm fine with not saying anything about empty non-returning=20
functions. That's almost certainly a deliberate act.
A non-returning function which has code in it is almost never a deliberate=
=20
act.
> Disagree; see above. While my own preference would be for that to not=20
> > compile either, I'm willing to be lenient there. What is absurd is that=
=20
> > code that *always* falls off the end of a function is accepted.=20
>
> It doesn't always fall off the end of a function. In fact, it *never*=20
> falls=20
> off if the contract is respected. But if you give it garbage, you get=20
> garbage.
>
So, can we agree that the programmer has almost certainly done something=20
wrong if:
1) The function is not empty.
2) The function never issues a return, throw, or call to a [[noreturn]]=20
function. Or one of the `co_*` things.
--=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/d14db8e9-5ec6-4665-a4a2-abd11d7cd8b4%40isocpp.or=
g.
------=_Part_22309_928997273.1514410246385
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, December 27, 2017 at 3:19:39 PM UTC-5, Thiag=
o Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On ter=C3=A7a=
-feira, 26 de dezembro de 2017 15:00:10 -02 Matthew Woehlke wrote:
<br>> =C2=A0 int foo {}
<br>>=20
<br>> This code *definitely* has UB. Calling this function *will* invoke=
UB,
<br>> period. Don't give me any BS about it being a "runtime co=
nstruct"
<br>> whether or not this function will cause UB; I can trivially tell t=
hat
<br>> there is *no chance at all* that it will *not* cause UB. I believe
<br>> compilers can tell also.
<br>
<br>Here's the full source code. Please tell me where the UB happens:
<br>
<br>=C2=A0int foo {}
<br>=C2=A0int main() { return 0; }
<br>
<br>Please compile this with any compiler, run any sanity checking tool and=
tell=20
<br>me at what time the UB happens.</blockquote><div><br></div><div>A bette=
r example would be this:</div><div><br></div><div class=3D"prettyprint" sty=
le=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; backgrou=
nd-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"su=
bprettyprint"><span class=3D"styled-by-prettify" style=3D"color: #008;">int=
</span><span class=3D"styled-by-prettify" style=3D"color: #000;"> foo</span=
><span class=3D"styled-by-prettify" style=3D"color: #660;">()</span><span c=
lass=3D"styled-by-prettify" style=3D"color: #000;"><br></span><span class=
=3D"styled-by-prettify" style=3D"color: #660;">{</span><span class=3D"style=
d-by-prettify" style=3D"color: #000;"><br>=C2=A0 </span><span class=3D"styl=
ed-by-prettify" style=3D"color: #008;">int</span><span class=3D"styled-by-p=
rettify" style=3D"color: #000;"> ix </span><span class=3D"styled-by-prettif=
y" style=3D"color: #660;">=3D</span><span class=3D"styled-by-prettify" styl=
e=3D"color: #000;"> </span><span class=3D"styled-by-prettify" style=3D"colo=
r: #066;">5</span><span class=3D"styled-by-prettify" style=3D"color: #660;"=
>;</span><span class=3D"styled-by-prettify" style=3D"color: #000;"><br>=C2=
=A0 ix </span><span class=3D"styled-by-prettify" style=3D"color: #660;">+=
=3D</span><span class=3D"styled-by-prettify" style=3D"color: #000;"> bar</s=
pan><span class=3D"styled-by-prettify" style=3D"color: #660;">(</span><span=
class=3D"styled-by-prettify" style=3D"color: #066;">20</span><span class=
=3D"styled-by-prettify" style=3D"color: #660;">);</span><span class=3D"styl=
ed-by-prettify" style=3D"color: #000;"><br></span><span class=3D"styled-by-=
prettify" style=3D"color: #660;">}</span></div></code></div><div><br></div>=
<div>Whether the user calls `foo` is essentially incidental; the user has c=
learly made a mistake, so we should let them know about it.</div><div><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">> (And, to be clear, I=
have limited sympathy for the case of a function
<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">> that is =
addressed but never called. I very much doubt those are so
<br>> common that having to instrument them, or insert a call to std::ab=
ort or
<br>> the like, is sufficiently onerous.)
<br>
<br>And yet they are possible.
<br>
<br>I agree they aren't common at all. But they were never the issue to=
begin=20
<br>with.<br></blockquote><div><br></div><div>Which is why I'm fine wit=
h not saying anything about empty non-returning functions. That's almos=
t certainly a deliberate act.</div><div><br></div><div>A non-returning func=
tion which has code in it is almost never a deliberate act.</div><div><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">> Disagree; see above.=
While my own preference would be for that to not
<br>> compile either, I'm willing to be lenient there. What is absur=
d is that
<br>> code that *always* falls off the end of a function is accepted.
<br>
<br>It doesn't always fall off the end of a function. In fact, it *neve=
r* falls=20
<br>off if the contract is respected. But if you give it garbage, you get g=
arbage.<br></blockquote><div><br></div><div>So, can we agree that the progr=
ammer has almost certainly done something wrong if:</div><div><br></div><di=
v>1) The function is not empty.</div><div>2) The function never issues a re=
turn, throw, or call to a [[noreturn]] function. Or one of the `co_*` thing=
s.</div><div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/d14db8e9-5ec6-4665-a4a2-abd11d7cd8b4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d14db8e9-5ec6-4665-a4a2-abd11d7cd8b4=
%40isocpp.org</a>.<br />
------=_Part_22309_928997273.1514410246385--
------=_Part_22308_905246993.1514410246384--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Thu, 28 Dec 2017 11:14:05 -0500
Raw View
On 2017-12-27 16:30, Nicol Bolas wrote:
> So, can we agree that the programmer has almost certainly done something
> wrong if:
>
> 1) The function is not empty.
> 2) The function never issues a return, throw, or call to a [[noreturn]]
> function. Or one of the `co_*` things.
I would be in favor of this. IIRC most of the "obvious mistakes" I've
seen have been of this form (usually a function with 3-5 LOC and no
branching that is missing a `return`), and it's a clear improvement over
what we have now.
--
Matthew
--
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/b82f6c96-f716-23bf-e90a-27697fba9cb4%40gmail.com.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 28 Dec 2017 19:36:40 -0200
Raw View
On quarta-feira, 27 de dezembro de 2017 19:30:46 -02 Nicol Bolas wrote:
> So, can we agree that the programmer has almost certainly done something
> wrong if:
>
> 1) The function is not empty.
> 2) The function never issues a return, throw, or call to a [[noreturn]]
> function. Or one of the `co_*` things.
How about calling a function that doesn't return but isn't marked as
[[noreturn]]? You'll find a few of those in windows.h and unistd.h.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/8807878.UnYpJolRzg%40tjmaciei-mobl1.
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Fri, 29 Dec 2017 00:20:50 +0000
Raw View
--94eb2c1b5444efc6f505616f9a88
Content-Type: text/plain; charset="UTF-8"
On 28 Dec 2017 9:36 pm, "Thiago Macieira" <thiago@macieira.org> wrote:
On quarta-feira, 27 de dezembro de 2017 19:30:46 -02 Nicol Bolas wrote:
> So, can we agree that the programmer has almost certainly done something
> wrong if:
>
> 1) The function is not empty.
> 2) The function never issues a return, throw, or call to a [[noreturn]]
> function. Or one of the `co_*` things.
How about calling a function that doesn't return but isn't marked as
[[noreturn]]? You'll find a few of those in windows.h and unistd.h.
No pain, no gain. But if the user can't persuade their vendor to add
[[noreturn]] to those function declarations, they can still (or while
waiting for updated headers to arrive) add a call to std::unreachable after
the call to the offending function.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
You received this message because you are subscribed to a topic in the
Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/
isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
To unsubscribe from this group and all its topics, 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/8807878.UnYpJolRzg%40tjmaciei-mobl1.
--
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/CAJnLdOZPfanZyK4bFocorAbJ96%3DAFyYZ_wKxs8Ne%3D9L8gM71Mg%40mail.gmail.com.
--94eb2c1b5444efc6f505616f9a88
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On 28 Dec 2017 9:36 pm, "Thiago Macieira" <<a href=
=3D"mailto:thiago@macieira.org">thiago@macieira.org</a>> wrote:<br type=
=3D"attribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div class=3D"quoted-text">On qua=
rta-feira, 27 de dezembro de 2017 19:30:46 -02 Nicol Bolas wrote:<br>
> So, can we agree that the programmer has almost certainly done somethi=
ng<br>
> wrong if:<br>
><br>
> 1) The function is not empty.<br>
> 2) The function never issues a return, throw, or call to a [[noreturn]=
]<br>
> function. Or one of the `co_*` things.<br>
<br>
</div>How about calling a function that doesn't return but isn't ma=
rked as<br>
[[noreturn]]? You'll find a few of those in windows.h and unistd.h.<br>
<div class=3D"quoted-text"></div></blockquote></div></div></div><div dir=3D=
"auto"><br></div><div dir=3D"auto">No pain, no gain. But if the user can=
9;t persuade their vendor to add [[noreturn]] to those function declaration=
s, they can still (or while waiting for updated headers to arrive) add a ca=
ll to std::unreachable after the call to the offending function.=C2=A0</div=
><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_extra"><=
div class=3D"gmail_quote"><blockquote class=3D"quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"quoted-tex=
t"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
</div><div class=3D"quoted-text">--<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/topic/s=
td-<wbr>proposals/Uu2QViiWh4k/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@<wbr>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>
</div>To view this discussion on the web visit <a href=3D"https://groups.go=
ogle.com/a/isocpp.org/d/msgid/std-proposals/8807878.UnYpJolRzg%40tjmaciei-m=
obl1" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/<wbr=
>isocpp.org/d/msgid/std-<wbr>proposals/8807878.UnYpJolRzg%<wbr>40tjmaciei-m=
obl1</a>.<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/CAJnLdOZPfanZyK4bFocorAbJ96%3DAFyYZ_w=
Kxs8Ne%3D9L8gM71Mg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZPfanZ=
yK4bFocorAbJ96%3DAFyYZ_wKxs8Ne%3D9L8gM71Mg%40mail.gmail.com</a>.<br />
--94eb2c1b5444efc6f505616f9a88--
.
Author: Ryan Nicholl <r.p.nicholl@gmail.com>
Date: Mon, 1 Jan 2018 12:57:14 -0800 (PST)
Raw View
------=_Part_36305_859652700.1514840234785
Content-Type: multipart/alternative;
boundary="----=_Part_36306_294890961.1514840234786"
------=_Part_36306_294890961.1514840234786
Content-Type: text/plain; charset="UTF-8"
Consider a case like:
/** it is undefined behavior to pass a value other than 1 or 2 */
int foo(int i)
{
if (i == 1) return ...;
if (i == 2) return ...;
}
That could create issues. Compilers are free to make the UB abort, or they
can take advantage of this behavior to optimize out this case. For example,
since only the cases of 1 and 2 are defined, the compiler could decided to
only check bit-0 to decide which branch to take. While this is a stupid
example and would make it slower (on processors I know), it is illustrative
of the point.
UB is a feature of C++ that makes optimizations easier. Most compilers have
flags debug modes that will make UB abort instead of optimizing it. Try
e.g. -ftrap=undefined and similar flags. Removing UB from the language
would make C++ slower, which is not going to happen as C++ is designed to
be the fastest programming language.
On Tuesday, December 19, 2017 at 7:54:51 AM UTC-5, Richard Hodges wrote:
>
> In c++, this is legal but UB. You may get a warning if you're lucky.
>
> int foo()
> {
> // oops! forgot to return anything
> }
>
> In my view, this not good enough. It seems to me that there is no
> reasonable case where a developer would want this compile. It should be an
> error.
>
> This of course is fine:
>
> int foo()
> {
> throw std::logic_error("not implemented yet!");
> }
>
> And this of course would allow developers who like this sort of thing to
> still get away with it, but force them to explain themselves.
>
> int foo()
> {
> int result = 0;
> while(1)
> {
> result = will_eventually_be_nonzero();
> if (result)
> return result;
> }
>
> [[not_reached]];
>
> // ok, a program reaching here could be allowed to express UB.
> // if the compiler can prove that this is reachable, it should fail to
> compile, because it knows you're lying.
>
> [[assert_not_reached]]
>
> // a program reaching here should by default, std::abort(), ideally
> with a stack dump.
> // if the compiler can prove that this is reachable, it should fail to
> compile, because it knows you're lying.
>
> // intentional non-return
> }
>
> In short, if your function says it returns something, it must return
> something, otherwise compilation error. Anything other outcome is a
> hard-to-track bug in waiting.
>
> Thoughts?
>
>
>
>
>
--
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/64dd021f-de53-4b17-9681-3599ef7c8882%40isocpp.org.
------=_Part_36306_294890961.1514840234786
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Consider a case like:<br><br><div style=3D"background-colo=
r: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: soli=
d; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><co=
de class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color=
: #800;" class=3D"styled-by-prettify">/** it is undefined behavior to pass =
a value other than 1 or 2 */</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> foo</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: #000;" class=3D"styled-by-prettify"> i</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></span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">if</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>i </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an 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 style=3D"color: #008;" =
class=3D"styled-by-prettify">return</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-=
prettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">if</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">i </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #066;" class=3D"styled-by-prettify">2</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-b=
y-prettify">return</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"><br></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></div></cod=
e></div><br>That could create issues. Compilers are free to make the UB abo=
rt, or they can take advantage of this behavior to optimize out this case. =
For example, since only the cases of 1 and 2 are defined, the compiler coul=
d decided to only check bit-0 to decide which branch to take. While this is=
a stupid example and would make it slower (on processors I know), it is i=
llustrative of the point.<br><br>UB is a feature of C++ that makes optimiza=
tions easier. Most compilers have flags debug modes that will make UB abort=
instead of optimizing it. Try e.g. -ftrap=3Dundefined and similar flags. R=
emoving UB from the language would make C++ slower, which is not going to h=
appen as C++ is designed to be the fastest programming language.<br><br>On =
Tuesday, December 19, 2017 at 7:54:51 AM UTC-5, Richard Hodges wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">In c++, this is leg=
al but UB. You may get a warning if you're lucky.<div><br></div><div><f=
ont face=3D"courier new, monospace">int foo()</font></div><div><font face=
=3D"courier new, monospace">{</font></div><div><font face=3D"courier new, m=
onospace">=C2=A0 // oops! forgot to return anything</font></div><div><font =
face=3D"courier new, monospace">}</font></div><div><br></div><div>In my vie=
w, this not good enough. It seems to me that there is no reasonable case wh=
ere a developer would want this compile. It should be an error.<br></div><d=
iv><br></div><div>This of course is fine:</div><div><br></div><div><div><fo=
nt face=3D"courier new, monospace">int foo()</font></div><div><font face=3D=
"courier new, monospace">{</font></div><div><font face=3D"courier new, mono=
space">=C2=A0 throw std::logic_error("not implemented yet!");</fo=
nt></div><div><font face=3D"courier new, monospace">}</font></div></div><di=
v><font face=3D"courier new, monospace"><br></font></div><div><div>And this=
of course would allow developers who like this sort of thing to still get =
away with it, but force them to explain themselves.</div></div><div><br></d=
iv><div><div><font face=3D"courier new, monospace">int foo()</font></div><d=
iv><font face=3D"courier new, monospace">{</font></div><div><font face=3D"c=
ourier new, monospace">=C2=A0 int result =3D 0;</font></div><div><font face=
=3D"courier new, monospace">=C2=A0 while(1)</font></div><div><font face=3D"=
courier new, monospace">=C2=A0 {</font></div><div><font face=3D"courier new=
, monospace">=C2=A0 =C2=A0 result =3D will_eventually_be_nonzero();</font><=
/div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 if (result)</=
font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 return result;</font></div><div><span style=3D"font-family:"cou=
rier new",monospace">=C2=A0 }</span><br></div><div><span style=3D"font=
-family:"courier new",monospace"><br></span></div><div><div><span=
style=3D"font-family:"courier new",monospace">=C2=A0 [[not_reach=
ed]];=C2=A0 =C2=A0</span></div></div><div><span style=3D"font-family:"=
courier new",monospace"><br></span></div><div><span style=3D"font-fami=
ly:"courier new",monospace">=C2=A0=C2=A0</span><span style=3D"fon=
t-family:"courier new",monospace">// ok, a program reaching here =
could be allowed to express UB.</span></div><div><span style=3D"font-family=
:"courier new",monospace">=C2=A0 // if the compiler can prove tha=
t this is reachable, it should fail to compile, because it knows you're=
lying.</span></div><div><span style=3D"font-family:"courier new"=
,monospace"><br></span></div><div><span style=3D"font-family:"courier =
new",monospace">=C2=A0 [[assert_not_reached]]</span></div><div><span s=
tyle=3D"font-family:"courier new",monospace"><br></span></div><di=
v><div><span style=3D"font-family:"courier new",monospace">=C2=A0=
=C2=A0</span><span style=3D"font-family:"courier new",monospace">=
// a program reaching here should by default, std::abort(), ideally with a =
stack dump.</span></div><div><span style=3D"font-family:"courier new&q=
uot;,monospace">=C2=A0 // if the compiler can prove that this is reachable,=
it should fail to compile, because it knows you're lying.</span></div>=
</div></div><div><span style=3D"font-family:"courier new",monospa=
ce"><br></span></div><div><span style=3D"font-family:"courier new"=
;,monospace">=C2=A0 // intentional non-return</span></div><div><span style=
=3D"font-family:"courier new",monospace">}</span></div><div><font=
face=3D"courier new, monospace"><br></font></div><div>In short, if your fu=
nction says it returns something, it must return something, otherwise compi=
lation error. Anything other outcome is a hard-to-track bug in waiting.</di=
v><div><br></div><div>Thoughts?</div><div><br></div><div><br></div><div><br=
></div><div>=C2=A0</div></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/64dd021f-de53-4b17-9681-3599ef7c8882%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/64dd021f-de53-4b17-9681-3599ef7c8882=
%40isocpp.org</a>.<br />
------=_Part_36306_294890961.1514840234786--
------=_Part_36305_859652700.1514840234785--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Mon, 1 Jan 2018 21:30:27 +0000
Raw View
--001a1147c138f74c6b0561bdb01e
Content-Type: text/plain; charset="UTF-8"
On Mon, Jan 1, 2018 at 8:57 PM, Ryan Nicholl <r.p.nicholl@gmail.com> wrote:
> Consider a case like:
>
> /** it is undefined behavior to pass a value other than 1 or 2 */
> int foo(int i)
> {
> if (i == 1) return ...;
> if (i == 2) return ...;
> }
>
> That could create issues. Compilers are free to make the UB abort, or they
> can take advantage of this behavior to optimize out this case. For example,
> since only the cases of 1 and 2 are defined, the compiler could decided to
> only check bit-0 to decide which branch to take. While this is a stupid
> example and would make it slower (on processors I know), it is illustrative
> of the point.
>
The answer to this is to observe that once std::unreachable is available,
the user can write:
int foo(int i)
{
if (i == 1) return ...;
if (i == 2) return ...;
std::unreachable();
}
On the condition that invoking std::unreachable is UB at runtime, this is
just as amenable to optimization as the former code and is arguably clearer.
> UB is a feature of C++ that makes optimizations easier. Most compilers
> have flags debug modes that will make UB abort instead of optimizing it.
> Try e.g. -ftrap=undefined and similar flags. Removing UB from the language
> would make C++ slower, which is not going to happen as C++ is designed to
> be the fastest programming language.
>
> On Tuesday, December 19, 2017 at 7:54:51 AM UTC-5, Richard Hodges wrote:
>>
>> In c++, this is legal but UB. You may get a warning if you're lucky.
>>
>> int foo()
>> {
>> // oops! forgot to return anything
>> }
>>
>> In my view, this not good enough. It seems to me that there is no
>> reasonable case where a developer would want this compile. It should be an
>> error.
>>
>> This of course is fine:
>>
>> int foo()
>> {
>> throw std::logic_error("not implemented yet!");
>> }
>>
>> And this of course would allow developers who like this sort of thing to
>> still get away with it, but force them to explain themselves.
>>
>> int foo()
>> {
>> int result = 0;
>> while(1)
>> {
>> result = will_eventually_be_nonzero();
>> if (result)
>> return result;
>> }
>>
>> [[not_reached]];
>>
>> // ok, a program reaching here could be allowed to express UB.
>> // if the compiler can prove that this is reachable, it should fail to
>> compile, because it knows you're lying.
>>
>> [[assert_not_reached]]
>>
>> // a program reaching here should by default, std::abort(), ideally
>> with a stack dump.
>> // if the compiler can prove that this is reachable, it should fail to
>> compile, because it knows you're lying.
>>
>> // intentional non-return
>> }
>>
>> In short, if your function says it returns something, it must return
>> something, otherwise compilation error. Anything other outcome is a
>> hard-to-track bug in waiting.
>>
>> Thoughts?
>>
>>
>>
>>
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe.
> To unsubscribe from this group and all its topics, 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/64dd021f-de53-4b17-
> 9681-3599ef7c8882%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/64dd021f-de53-4b17-9681-3599ef7c8882%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CAJnLdOZCaf5g3TBwKN0hgo9zgiSJEacsZ3ZFr_9ajpCOBmsogw%40mail.gmail.com.
--001a1147c138f74c6b0561bdb01e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Jan 1, 2018 at 8:57 PM, Ryan Nicholl <span dir=3D"ltr"><<a href=3D"m=
ailto:r.p.nicholl@gmail.com" target=3D"_blank">r.p.nicholl@gmail.com</a>>=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div d=
ir=3D"ltr">Consider a case like:<br><br><div style=3D"background-color:rgb(=
250,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:=
1px" class=3D"gmail-m_-4770813163745909662prettyprint"><code class=3D"gmail=
-m_-4770813163745909662prettyprint"><div class=3D"gmail-m_-4770813163745909=
662subprettyprint"><span style=3D"color:rgb(136,0,0)" class=3D"gmail-m_-477=
0813163745909662styled-by-prettify">/** it is undefined behavior to pass a =
value other than 1 or 2 */</span><span style=3D"color:rgb(0,0,0)" class=3D"=
gmail-m_-4770813163745909662styled-by-prettify"><br></span><span style=3D"c=
olor:rgb(0,0,136)" class=3D"gmail-m_-4770813163745909662styled-by-prettify"=
>int</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-4770813163745=
909662styled-by-prettify"> foo</span><span style=3D"color:rgb(102,102,0)" c=
lass=3D"gmail-m_-4770813163745909662styled-by-prettify">(</span><span style=
=3D"color:rgb(0,0,136)" class=3D"gmail-m_-4770813163745909662styled-by-pret=
tify">int</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-47708131=
63745909662styled-by-prettify"> i</span><span style=3D"color:rgb(102,102,0)=
" class=3D"gmail-m_-4770813163745909662styled-by-prettify">)</span><span st=
yle=3D"color:rgb(0,0,0)" class=3D"gmail-m_-4770813163745909662styled-by-pre=
ttify"><br></span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-47=
70813163745909662styled-by-prettify">{</span><span style=3D"color:rgb(0,0,0=
)" class=3D"gmail-m_-4770813163745909662styled-by-prettify"><br>=C2=A0 </sp=
an><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-4770813163745909662=
styled-by-prettify">if</span><span style=3D"color:rgb(0,0,0)" class=3D"gmai=
l-m_-4770813163745909662styled-by-prettify"> </span><span style=3D"color:rg=
b(102,102,0)" class=3D"gmail-m_-4770813163745909662styled-by-prettify">(</s=
pan><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-4770813163745909662s=
tyled-by-prettify">i </span><span style=3D"color:rgb(102,102,0)" class=3D"g=
mail-m_-4770813163745909662styled-by-prettify">=3D=3D</span><span style=3D"=
color:rgb(0,0,0)" class=3D"gmail-m_-4770813163745909662styled-by-prettify">=
</span><span style=3D"color:rgb(0,102,102)" class=3D"gmail-m_-477081316374=
5909662styled-by-prettify">1</span><span style=3D"color:rgb(102,102,0)" cla=
ss=3D"gmail-m_-4770813163745909662styled-by-prettify">)</span><span style=
=3D"color:rgb(0,0,0)" class=3D"gmail-m_-4770813163745909662styled-by-pretti=
fy"> </span><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-4770813163=
745909662styled-by-prettify">return</span><span style=3D"color:rgb(0,0,0)" =
class=3D"gmail-m_-4770813163745909662styled-by-prettify"> </span><span styl=
e=3D"color:rgb(102,102,0)" class=3D"gmail-m_-4770813163745909662styled-by-p=
rettify">...;</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-4770=
813163745909662styled-by-prettify"><br>=C2=A0 </span><span style=3D"color:r=
gb(0,0,136)" class=3D"gmail-m_-4770813163745909662styled-by-prettify">if</s=
pan><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-4770813163745909662s=
tyled-by-prettify"> </span><span style=3D"color:rgb(102,102,0)" class=3D"gm=
ail-m_-4770813163745909662styled-by-prettify">(</span><span style=3D"color:=
rgb(0,0,0)" class=3D"gmail-m_-4770813163745909662styled-by-prettify">i </sp=
an><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-47708131637459096=
62styled-by-prettify">=3D=3D</span><span style=3D"color:rgb(0,0,0)" class=
=3D"gmail-m_-4770813163745909662styled-by-prettify"> </span><span style=3D"=
color:rgb(0,102,102)" class=3D"gmail-m_-4770813163745909662styled-by-pretti=
fy">2</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-47708131=
63745909662styled-by-prettify">)</span><span style=3D"color:rgb(0,0,0)" cla=
ss=3D"gmail-m_-4770813163745909662styled-by-prettify"> </span><span style=
=3D"color:rgb(0,0,136)" class=3D"gmail-m_-4770813163745909662styled-by-pret=
tify">return</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-47708=
13163745909662styled-by-prettify"> </span><span style=3D"color:rgb(102,102,=
0)" class=3D"gmail-m_-4770813163745909662styled-by-prettify">...;</span><sp=
an style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-4770813163745909662styled-b=
y-prettify"><br></span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-=
m_-4770813163745909662styled-by-prettify">}</span><span style=3D"color:rgb(=
0,0,0)" class=3D"gmail-m_-4770813163745909662styled-by-prettify"><br></span=
></div></code></div><br>That could create issues. Compilers are free to mak=
e the UB abort, or they can take advantage of this behavior to optimize out=
this case. For example, since only the cases of 1 and 2 are defined, the c=
ompiler could decided to only check bit-0 to decide which branch to take. W=
hile this is a stupid example and would make it slower (on processors I kno=
w), it is illustrative of the point.<br></div></blockquote><div><br></div>=
<div>The answer to this is to observe that once std::unreachable is availab=
le, the user can write:</div><div><br></div><div><span class=3D"gmail-m_-47=
70813163745909662styled-by-prettify" style=3D"font-family:monospace;backgro=
und-color:rgb(250,250,250);color:rgb(0,0,136)">int</span><span class=3D"gma=
il-m_-4770813163745909662styled-by-prettify" style=3D"font-family:monospace=
;background-color:rgb(250,250,250);color:rgb(0,0,0)">=C2=A0foo</span><span =
class=3D"gmail-m_-4770813163745909662styled-by-prettify" style=3D"font-fami=
ly:monospace;background-color:rgb(250,250,250);color:rgb(102,102,0)">(</spa=
n><span class=3D"gmail-m_-4770813163745909662styled-by-prettify" style=3D"f=
ont-family:monospace;background-color:rgb(250,250,250);color:rgb(0,0,136)">=
int</span><span class=3D"gmail-m_-4770813163745909662styled-by-prettify" st=
yle=3D"font-family:monospace;background-color:rgb(250,250,250);color:rgb(0,=
0,0)">=C2=A0i</span><span class=3D"gmail-m_-4770813163745909662styled-by-pr=
ettify" style=3D"font-family:monospace;background-color:rgb(250,250,250);co=
lor:rgb(102,102,0)">)</span><span class=3D"gmail-m_-4770813163745909662styl=
ed-by-prettify" style=3D"font-family:monospace;background-color:rgb(250,250=
,250);color:rgb(0,0,0)"><br></span><span class=3D"gmail-m_-4770813163745909=
662styled-by-prettify" style=3D"font-family:monospace;background-color:rgb(=
250,250,250);color:rgb(102,102,0)">{</span><span class=3D"gmail-m_-47708131=
63745909662styled-by-prettify" style=3D"font-family:monospace;background-co=
lor:rgb(250,250,250);color:rgb(0,0,0)"><br>=C2=A0=C2=A0</span><span class=
=3D"gmail-m_-4770813163745909662styled-by-prettify" style=3D"font-family:mo=
nospace;background-color:rgb(250,250,250);color:rgb(0,0,136)">if</span><spa=
n class=3D"gmail-m_-4770813163745909662styled-by-prettify" style=3D"font-fa=
mily:monospace;background-color:rgb(250,250,250);color:rgb(0,0,0)">=C2=A0</=
span><span class=3D"gmail-m_-4770813163745909662styled-by-prettify" style=
=3D"font-family:monospace;background-color:rgb(250,250,250);color:rgb(102,1=
02,0)">(</span><span class=3D"gmail-m_-4770813163745909662styled-by-prettif=
y" style=3D"font-family:monospace;background-color:rgb(250,250,250);color:r=
gb(0,0,0)">i=C2=A0</span><span class=3D"gmail-m_-4770813163745909662styled-=
by-prettify" style=3D"font-family:monospace;background-color:rgb(250,250,25=
0);color:rgb(102,102,0)">=3D=3D</span><span class=3D"gmail-m_-4770813163745=
909662styled-by-prettify" style=3D"font-family:monospace;background-color:r=
gb(250,250,250);color:rgb(0,0,0)">=C2=A0</span><span class=3D"gmail-m_-4770=
813163745909662styled-by-prettify" style=3D"font-family:monospace;backgroun=
d-color:rgb(250,250,250);color:rgb(0,102,102)">1</span><span class=3D"gmail=
-m_-4770813163745909662styled-by-prettify" style=3D"font-family:monospace;b=
ackground-color:rgb(250,250,250);color:rgb(102,102,0)">)</span><span class=
=3D"gmail-m_-4770813163745909662styled-by-prettify" style=3D"font-family:mo=
nospace;background-color:rgb(250,250,250);color:rgb(0,0,0)">=C2=A0</span><s=
pan class=3D"gmail-m_-4770813163745909662styled-by-prettify" style=3D"font-=
family:monospace;background-color:rgb(250,250,250);color:rgb(0,0,136)">retu=
rn</span><span class=3D"gmail-m_-4770813163745909662styled-by-prettify" sty=
le=3D"font-family:monospace;background-color:rgb(250,250,250);color:rgb(0,0=
,0)">=C2=A0</span><span class=3D"gmail-m_-4770813163745909662styled-by-pret=
tify" style=3D"font-family:monospace;background-color:rgb(250,250,250);colo=
r:rgb(102,102,0)">...;</span><span class=3D"gmail-m_-4770813163745909662sty=
led-by-prettify" style=3D"font-family:monospace;background-color:rgb(250,25=
0,250);color:rgb(0,0,0)"><br>=C2=A0=C2=A0</span><span class=3D"gmail-m_-477=
0813163745909662styled-by-prettify" style=3D"font-family:monospace;backgrou=
nd-color:rgb(250,250,250);color:rgb(0,0,136)">if</span><span class=3D"gmail=
-m_-4770813163745909662styled-by-prettify" style=3D"font-family:monospace;b=
ackground-color:rgb(250,250,250);color:rgb(0,0,0)">=C2=A0</span><span class=
=3D"gmail-m_-4770813163745909662styled-by-prettify" style=3D"font-family:mo=
nospace;background-color:rgb(250,250,250);color:rgb(102,102,0)">(</span><sp=
an class=3D"gmail-m_-4770813163745909662styled-by-prettify" style=3D"font-f=
amily:monospace;background-color:rgb(250,250,250);color:rgb(0,0,0)">i=C2=A0=
</span><span class=3D"gmail-m_-4770813163745909662styled-by-prettify" style=
=3D"font-family:monospace;background-color:rgb(250,250,250);color:rgb(102,1=
02,0)">=3D=3D</span><span class=3D"gmail-m_-4770813163745909662styled-by-pr=
ettify" style=3D"font-family:monospace;background-color:rgb(250,250,250);co=
lor:rgb(0,0,0)">=C2=A0</span><span class=3D"gmail-m_-4770813163745909662sty=
led-by-prettify" style=3D"font-family:monospace;background-color:rgb(250,25=
0,250);color:rgb(0,102,102)">2</span><span class=3D"gmail-m_-47708131637459=
09662styled-by-prettify" style=3D"font-family:monospace;background-color:rg=
b(250,250,250);color:rgb(102,102,0)">)</span><span class=3D"gmail-m_-477081=
3163745909662styled-by-prettify" style=3D"font-family:monospace;background-=
color:rgb(250,250,250);color:rgb(0,0,0)">=C2=A0</span><span class=3D"gmail-=
m_-4770813163745909662styled-by-prettify" style=3D"font-family:monospace;ba=
ckground-color:rgb(250,250,250);color:rgb(0,0,136)">return</span><span clas=
s=3D"gmail-m_-4770813163745909662styled-by-prettify" style=3D"font-family:m=
onospace;background-color:rgb(250,250,250);color:rgb(0,0,0)">=C2=A0</span><=
span class=3D"gmail-m_-4770813163745909662styled-by-prettify" style=3D"font=
-family:monospace;background-color:rgb(250,250,250);color:rgb(102,102,0)">.=
...;</span></div><div><span class=3D"gmail-m_-4770813163745909662styled-by-p=
rettify" style=3D"font-family:monospace;background-color:rgb(250,250,250)">=
<font color=3D"#666600">=C2=A0 std::unreachable();<br></font></span><span c=
lass=3D"gmail-m_-4770813163745909662styled-by-prettify" style=3D"font-famil=
y:monospace;background-color:rgb(250,250,250);color:rgb(102,102,0)">}</span=
></div><div><br></div><div>On the condition that invoking std::unreachable =
is UB at runtime, this is just as amenable to optimization as the former co=
de and is arguably clearer.</div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"ltr">UB is a feature of C++ that makes=
optimizations easier. Most compilers have flags debug modes that will make=
UB abort instead of optimizing it. Try e.g. -ftrap=3Dundefined and similar=
flags. Removing UB from the language would make C++ slower, which is not g=
oing to happen as C++ is designed to be the fastest programming language.<b=
r><br>On Tuesday, December 19, 2017 at 7:54:51 AM UTC-5, Richard Hodges wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">In c+=
+, this is legal but UB. You may get a warning if you're lucky.<div><br=
></div><div><font face=3D"courier new, monospace">int foo()</font></div><di=
v><font face=3D"courier new, monospace">{</font></div><div><font face=3D"co=
urier new, monospace">=C2=A0 // oops! forgot to return anything</font></div=
><div><font face=3D"courier new, monospace">}</font></div><div><br></div><d=
iv>In my view, this not good enough. It seems to me that there is no reason=
able case where a developer would want this compile. It should be an error.=
<br></div><div><br></div><div>This of course is fine:</div><div><br></div><=
div><div><font face=3D"courier new, monospace">int foo()</font></div><div><=
font face=3D"courier new, monospace">{</font></div><div><font face=3D"couri=
er new, monospace">=C2=A0 throw std::logic_error("not implemented yet!=
");</font></div><div><font face=3D"courier new, monospace">}</font></d=
iv></div><div><font face=3D"courier new, monospace"><br></font></div><div><=
div>And this of course would allow developers who like this sort of thing t=
o still get away with it, but force them to explain themselves.</div></div>=
<div><br></div><div><div><font face=3D"courier new, monospace">int foo()</f=
ont></div><div><font face=3D"courier new, monospace">{</font></div><div><fo=
nt face=3D"courier new, monospace">=C2=A0 int result =3D 0;</font></div><di=
v><font face=3D"courier new, monospace">=C2=A0 while(1)</font></div><div><f=
ont face=3D"courier new, monospace">=C2=A0 {</font></div><div><font face=3D=
"courier new, monospace">=C2=A0 =C2=A0 result =3D will_eventually_be_nonzer=
o();</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 i=
f (result)</font></div><div><font face=3D"courier new, monospace">=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 return result;</font></div><div><span style=3D"font-fa=
mily:"courier new",monospace">=C2=A0 }</span><br></div><div><span=
style=3D"font-family:"courier new",monospace"><br></span></div><=
div><div><span style=3D"font-family:"courier new",monospace">=C2=
=A0 [[not_reached]];=C2=A0 =C2=A0</span></div></div><div><span style=3D"fon=
t-family:"courier new",monospace"><br></span></div><div><span sty=
le=3D"font-family:"courier new",monospace">=C2=A0=C2=A0</span><sp=
an style=3D"font-family:"courier new",monospace">// ok, a program=
reaching here could be allowed to express UB.</span></div><div><span style=
=3D"font-family:"courier new",monospace">=C2=A0 // if the compile=
r can prove that this is reachable, it should fail to compile, because it k=
nows you're lying.</span></div><div><span style=3D"font-family:"co=
urier new",monospace"><br></span></div><div><span style=3D"font-family=
:"courier new",monospace">=C2=A0 [[assert_not_reached]]</span></d=
iv><div><span style=3D"font-family:"courier new",monospace"><br><=
/span></div><div><div><span style=3D"font-family:"courier new",mo=
nospace">=C2=A0=C2=A0</span><span style=3D"font-family:"courier new&qu=
ot;,monospace">// a program reaching here should by default, std::abort(), =
ideally with a stack dump.</span></div><div><span style=3D"font-family:&quo=
t;courier new",monospace">=C2=A0 // if the compiler can prove that thi=
s is reachable, it should fail to compile, because it knows you're lyin=
g.</span></div></div></div><div><span style=3D"font-family:"courier ne=
w",monospace"><br></span></div><div><span style=3D"font-family:"c=
ourier new",monospace">=C2=A0 // intentional non-return</span></div><d=
iv><span style=3D"font-family:"courier new",monospace">}</span></=
div><div><font face=3D"courier new, monospace"><br></font></div><div>In sho=
rt, if your function says it returns something, it must return something, o=
therwise compilation error. Anything other outcome is a hard-to-track bug i=
n waiting.</div><div><br></div><div>Thoughts?</div><div><br></div><div><br>=
</div><div><br></div><div>=C2=A0</div></div></blockquote></div><span class=
=3D"gmail-HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Uu2QViiWh4k/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/U=
u2QViiWh4k/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/64dd021f-de53-4b17-9681-3599ef7c8882%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/64dd=
021f-de53-4b17-<wbr>9681-3599ef7c8882%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAJnLdOZCaf5g3TBwKN0hgo9zgiSJEacsZ3ZF=
r_9ajpCOBmsogw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZCaf5g3TBw=
KN0hgo9zgiSJEacsZ3ZFr_9ajpCOBmsogw%40mail.gmail.com</a>.<br />
--001a1147c138f74c6b0561bdb01e--
.
Author: olafvdspek@gmail.com
Date: Wed, 3 Jan 2018 02:11:32 -0800 (PST)
Raw View
------=_Part_40912_1109113988.1514974292256
Content-Type: multipart/alternative;
boundary="----=_Part_40913_839215037.1514974292256"
------=_Part_40913_839215037.1514974292256
Content-Type: text/plain; charset="UTF-8"
Op dinsdag 19 december 2017 15:40:56 UTC+1 schreef Nicol Bolas:
>
>
> How is the compiler inserting code where code need not exist "quality"?
> Maybe in debug builds, but in release?
>
What's the actual cost though?
How many functions exist where the compiler would have to emit this guard?
The cost for 'normal' programs seems to be very low or non-existent.
--
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/8cdd9e37-996f-4001-9d25-216d7f5f9031%40isocpp.org.
------=_Part_40913_839215037.1514974292256
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>Op dinsdag 19 december 2017 15:40:56 UTC+1 schreef=
Nicol Bolas:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div><br></div><div>How is the compiler inserting code where code need not =
exist "quality"? Maybe in debug builds, but in release?</div></di=
v></blockquote><div><br></div><div>What's the actual cost though?</div>=
<div>How many functions exist where the compiler would have to emit this gu=
ard?</div><div>The cost for 'normal' programs seems to be very low =
or non-existent.</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/8cdd9e37-996f-4001-9d25-216d7f5f9031%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8cdd9e37-996f-4001-9d25-216d7f5f9031=
%40isocpp.org</a>.<br />
------=_Part_40913_839215037.1514974292256--
------=_Part_40912_1109113988.1514974292256--
.