Topic: proposal: deprecate failure to return
Author: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 29 Sep 2014 13:37:25 -0700
Raw View
--bcaec547cb7d09a17505043a3cf2
Content-Type: text/plain; charset=UTF-8
On Mon, Sep 29, 2014 at 1:20 PM, Matthew Woehlke <
mw_triad@users.sourceforge.net> wrote:
> On 2014-09-29 15:51, Thiago Macieira wrote:
> > On Monday 29 September 2014 15:15:15 Matthew Woehlke wrote:
> >> I'd like to propose that the language be changed such that falling off
> >> the end of a non-void function (i.e. that the compiler can detect that
> >> this legitimately occurs) is ill-formed, unless (a) an annotation
> >> expressing that intent is present, or (b) the compiler detects that the
> >> return value is initialized by some other means (e.g. inline assembly).
> >> The intent is that such functions would raise a compile *error*.
> >
> > Would this be ill-formed:
> >
> > int foo(int x)
> > {
> > if (x == 1)
> > return doOne();
> > else if (x == 2)
> > return doTwo();
> > }
>
> Er... yes? "Yes!", even. That code, exactly as written, clearly has
> problems :-). I want the compiler to reject code like that.
>
> If there were an assert that (x == 1 || x == 2), then no. (Also a good
> reason to get the recent assert-related stuff sorted and into the
> standard :-).)
>
> IOW, if you want to write code like that, either tell the compiler
> explicitly to trust you to know what you're doing, or to trust that
> control can't fall off the end. (See also where I wrote about having a
> standardized way to say 'this is (we hope) unreachable'.)
>
> Even better would be to stick a call to abort() at the bottom :-) (or
> throw an exception, or otherwise invoke a less undefined behavior).
> Since you're off in UB land anyway, performance is probably not a
> concern at this point...
>
> I should also note that I build just about everything with
> -Werror=return-type and have yet to see a single false positive (but
> have caught *lots* of bugs!). I submit that as empirical evidence that
> such code is rare to nonexistent "in the wild".
Using which compiler? GCC's has a lot of false positives in my experience
(primarily with switches over enums).
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--bcaec547cb7d09a17505043a3cf2
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, Sep 29, 2014 at 1:20 PM, Matthew Woehlke <span dir=3D"ltr"><<a href=
=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_blank">mw_triad@users=
..sourceforge.net</a>></span> wrote:<br><blockquote class=3D"gmail_quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><s=
pan class=3D"">On 2014-09-29 15:51, Thiago Macieira wrote:<br>
> On Monday 29 September 2014 15:15:15 Matthew Woehlke wrote:<br>
>> I'd like to propose that the language be changed such that fal=
ling off<br>
>> the end of a non-void function (i.e. that the compiler can detect =
that<br>
>> this legitimately occurs) is ill-formed, unless (a) an annotation<=
br>
>> expressing that intent is present, or (b) the compiler detects tha=
t the<br>
>> return value is initialized by some other means (e.g. inline assem=
bly).<br>
>> The intent is that such functions would raise a compile *error*.<b=
r>
><br>
> Would this be ill-formed:<br>
><br>
> int foo(int x)<br>
> {<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0if (x =3D=3D 1)<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return doOne();<=
br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0else if (x =3D=3D 2)<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return doTwo();<=
br>
> }<br>
<br>
</span>Er... yes? "Yes!", even. That code, exactly as written, cl=
early has<br>
problems :-). I want the compiler to reject code like that.<br>
<br>
If there were an assert that (x =3D=3D 1 || x =3D=3D 2), then no. (Also a g=
ood<br>
reason to get the recent assert-related stuff sorted and into the<br>
standard :-).)<br>
<br>
IOW, if you want to write code like that, either tell the compiler<br>
explicitly to trust you to know what you're doing, or to trust that<br>
control can't fall off the end. (See also where I wrote about having a<=
br>
standardized way to say 'this is (we hope) unreachable'.)<br>
<br>
Even better would be to stick a call to abort() at the bottom :-) (or<br>
throw an exception, or otherwise invoke a less undefined behavior).<br>
Since you're off in UB land anyway, performance is probably not a<br>
concern at this point...<br>
<br>
I should also note that I build just about everything with<br>
-Werror=3Dreturn-type and have yet to see a single false positive (but<br>
have caught *lots* of bugs!). I submit that as empirical evidence that<br>
such code is rare to nonexistent "in the wild".</blockquote><div>=
<br></div><div>Using which compiler? GCC's has a lot of false positives=
in my experience (primarily with switches over enums).</div></div></div></=
div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--bcaec547cb7d09a17505043a3cf2--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 29 Sep 2014 14:11:47 -0700
Raw View
On Monday 29 September 2014 16:20:57 Matthew Woehlke wrote:
> > int foo(int x)
> > {
> > if (x == 1)
> > return doOne();
> > else if (x == 2)
> > return doTwo();
> > }
>
> Er... yes? "Yes!", even. That code, exactly as written, clearly has
> problems :-). I want the compiler to reject code like that.
>
> If there were an assert that (x == 1 || x == 2), then no. (Also a good
> reason to get the recent assert-related stuff sorted and into the
> standard :-).)
>
> IOW, if you want to write code like that, either tell the compiler
> explicitly to trust you to know what you're doing, or to trust that
> control can't fall off the end. (See also where I wrote about having a
> standardized way to say 'this is (we hope) unreachable'.)
Oh, I definitely wouldn't write the code above as-is. I'd have written it as:
int foo(int x) noexcept
{
if (x == 1)
return doOne();
else if (x == 2)
return doTwo();
Q_UNREACHABLE();
}
Q_UNREACHABLE() expands to __builtin_unreachable() for GCC and Clang;
__assume(false) for ICC and MSVC. So that does what I wanted.
Of course, it expands to absolutely nothing on other compilers (it actually
expands to Q_ASSERT_X(false, "Q_UNREACHABLE was reached"), which in release
mode expands to nothing).
Note how the presence of the Q_UNREACHABLE() means I can't remove the "if (x
== 2)" part of the conditional.
If you want to make the code above ill-formed, please give me a standardised
"this is unreachable" marker which is guaranteed to expand to zero code. Don't
make me throw exceptions (my function is noexcept), and don't make me place
calls to functions that don't need to be there.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: gmisocpp@gmail.com
Date: Mon, 29 Sep 2014 16:28:04 -0700 (PDT)
Raw View
------=_Part_3920_1245532875.1412033284750
Content-Type: text/plain; charset=UTF-8
Hi Thiago
On Tuesday, September 30, 2014 10:11:54 AM UTC+13, Thiago Macieira wrote:
>
> On Monday 29 September 2014 16:20:57 Matthew Woehlke wrote:
> > > int foo(int x)
> > > {
> > > if (x == 1)
> > > return doOne();
> > > else if (x == 2)
> > > return doTwo();
> > > }
> >
> > Er... yes? "Yes!", even. That code, exactly as written, clearly has
> > problems :-). I want the compiler to reject code like that.
> >
> > If there were an assert that (x == 1 || x == 2), then no. (Also a good
> > reason to get the recent assert-related stuff sorted and into the
> > standard :-).)
> >
> > IOW, if you want to write code like that, either tell the compiler
> > explicitly to trust you to know what you're doing, or to trust that
> > control can't fall off the end. (See also where I wrote about having a
> > standardized way to say 'this is (we hope) unreachable'.)
>
> Oh, I definitely wouldn't write the code above as-is. I'd have written it
> as:
>
> int foo(int x) noexcept
> {
> if (x == 1)
> return doOne();
> else if (x == 2)
> return doTwo();
> Q_UNREACHABLE();
> }
>
> Q_UNREACHABLE() expands to __builtin_unreachable() for GCC and Clang;
> __assume(false) for ICC and MSVC. So that does what I wanted.
>
> Of course, it expands to absolutely nothing on other compilers (it
> actually
> expands to Q_ASSERT_X(false, "Q_UNREACHABLE was reached"), which in
> release
> mode expands to nothing).
>
> Note how the presence of the Q_UNREACHABLE() means I can't remove the "if
> (x
> == 2)" part of the conditional.
>
> If you want to make the code above ill-formed, please give me a
> standardised
> "this is unreachable" marker which is guaranteed to expand to zero code.
> Don't
> make me throw exceptions (my function is noexcept), and don't make me
> place
> calls to functions that don't need to be there.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
>
Would this construct serve your purpose:
// Richards example with my additions:
void app_exit()
{
exit(EXIT_FAILURE);
}
enum E { a, b, c };
int f(E e) {
// switch cases must cover all enum values or trigger error/warning.
switch (e) [[switch_on_all_enum_values]] (E) {
case a: return 1;
case b: return 2;
case c: return 3;
}
noreturn { // Whatever happens in here, there must be no way out.
app_exit();
}
// noreturn works like this:
// 1. Compiler attempts to verify the no_return block is unreachable,
// if it unreachable, no code is generated and no warning is issued.
// 2. If compiler can't verify the block is unreachable, a warning is
issued
// and the code inside the block is generated.
// 3. If that code cannot be verified as not returning,
// compiler injects code to ensure there is no way to return.
// i.e. code to ensure std::terminate() is called the end of the block.
try
{
app_exit();
}
catch(...)
{
// Would be nice if compiler offered the ability to
inject __debug_break here too in some situations like for debug builds.
//.Then we can more easily diagnose the code where we made a
wrong assumption.
std::terminate();
}
}
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_3920_1245532875.1412033284750
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Thiago<br><br>On Tuesday, September 30, 2014 10:11:54 A=
M UTC+13, Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 2=
04, 204); border-left-width: 1px; border-left-style: solid;">On Monday 29 S=
eptember 2014 16:20:57 Matthew Woehlke wrote:
<br>> > int foo(int x)
<br>> > {
<br>> > if (x =3D=3D 1)
<br>> > return doOne=
();
<br>> > else if (x =3D=3D 2)
<br>> > return doTwo=
();
<br>> > }
<br>>=20
<br>> Er... yes? "Yes!", even. That code, exactly as written, clearly ha=
s
<br>> problems :-). I want the compiler to reject code like that.
<br>>=20
<br>> If there were an assert that (x =3D=3D 1 || x =3D=3D 2), then no. =
(Also a good
<br>> reason to get the recent assert-related stuff sorted and into the
<br>> standard :-).)
<br>>=20
<br>> IOW, if you want to write code like that, either tell the compiler
<br>> explicitly to trust you to know what you're doing, or to trust tha=
t
<br>> control can't fall off the end. (See also where I wrote about havi=
ng a
<br>> standardized way to say 'this is (we hope) unreachable'.)
<br>
<br>Oh, I definitely wouldn't write the code above as-is. I'd have written =
it as:
<br>
<br>int foo(int x) noexcept
<br>{
<br> if (x =3D=3D 1)
<br> return doOne();
<br> else if (x =3D=3D 2)
<br> return doTwo();
<br> Q_UNREACHABLE();
<br>}
<br>
<br>Q_UNREACHABLE() expands to __builtin_unreachable() for GCC and Clang;=
=20
<br>__assume(false) for ICC and MSVC. So that does what I wanted.
<br>
<br>Of course, it expands to absolutely nothing on other compilers (it actu=
ally=20
<br>expands to Q_ASSERT_X(false, "Q_UNREACHABLE was reached"), which in rel=
ease=20
<br>mode expands to nothing).
<br>
<br>Note how the presence of the Q_UNREACHABLE() means I can't remove the "=
if (x=20
<br>=3D=3D 2)" part of the conditional.
<br>
<br>If you want to make the code above ill-formed, please give me a standar=
dised=20
<br>"this is unreachable" marker which is guaranteed to expand to zero code=
.. Don't=20
<br>make me throw exceptions (my function is noexcept), and don't make me p=
lace=20
<br>calls to functions that don't need to be there.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a onmousedown=3D"this.href=3D'http://www=
..google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\07=
51\46usg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" href=3D"http:/=
/macieira.info" target=3D"_blank">macieira.info</a> - thiago (AT) <a onmous=
edown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.org\46=
sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;=
" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.or=
g\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return t=
rue;" href=3D"http://kde.org" target=3D"_blank">kde.org</a>
<br> Software Architect - Intel Open Source Technology Center
<br> PGP/GPG: 0x6EF45358; fingerprint:
<br> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote><div><br></div><div>Would this construct serve your purpos=
e: </div><div><br></div><div>// Richards example with my additions:<br=
></div><div><div><br></div><div>void app_exit()<br>{<br> =
exit(EXIT_FAILURE);<br>}</div><div><br></div>enum E { a, b, c };<br>int f(E=
e) {<br> // switch cases must cover all enum values or trigger error=
/warning.<br> switch (e) [[switch_on_all_enum_values]] (E) {<br> =
; case a: return 1;<br> case b: return 2;<br> case c: return 3;=
<br> }</div><div> noreturn { // Whatever happens in here, there=
must be no way out.<br> app_exit();<br> =
; }</div><div><br></div><div> // noreturn works like this:<br> =
// 1. Compiler attempts to verify the no_return block is unreachable,<br>&n=
bsp; // if it unreachable, no code is generated and no warning is issued.<b=
r> // 2. If compiler can't verify the block is unreachable, a wa=
rning is issued<br> // and the code inside the block is generated.<br=
> // 3. If that code cannot be verified as not returning,<b=
r> // compiler injects code to ensure there is no way to return.=
</div><div> // i.e. code to ensure std::terminate() is called the en=
d of the block.<br> try<br> {<br> =
app_exit(); <br> }<br> catch(...)<br> {</div><div> =
// Would be nice if compiler offered the ability to =
inject __debug_break here too in some situations like for debug b=
uilds.</div><div> //.Then we can more easily diagnos=
e the code where we made a wrong assumption.<br>  =
; std::terminate();<br> } <br>}</div><div><br></div><div>Though=
ts?</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_3920_1245532875.1412033284750--
.
Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Mon, 29 Sep 2014 16:41:21 -0700 (PDT)
Raw View
------=_Part_903_369477850.1412034081120
Content-Type: text/plain; charset=UTF-8
On Monday, September 29, 2014 8:28:04 PM UTC-3, gmis...@gmail.com wrote:
>
> enum E { a, b, c };
> int f(E e) {
> // switch cases must cover all enum values or trigger error/warning.
> switch (e) [[switch_on_all_enum_values]] (E) {
> case a: return 1;
> case b: return 2;
> case c: return 3;
> }
>
There is something wrong with that example, the (E) seems completely out of
place with the language, I am not sure if that was intentional.
But otherwise, this seems like an acceptable use of attributes according to
existing guidelines.
It does not introduce any semantic changes and the attribute can be safely
ignored.
This would be equivalent to:
enum E { a, b, c };
int f(E e) {
// switch cases must cover all enum values or trigger error/warning.
switch (e) {
case a: return 1;
case b: return 2;
case c: return 3;
default: __builtin_unreachable();
}
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_903_369477850.1412034081120
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, September 29, 2014 8:28:04 PM UTC-3, gmis...@gm=
ail.com 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></div>enum E { a, b, c };<br>int f(E e) {<br> // switch ca=
ses must cover all enum values or trigger error/warning.<br> switch (=
e) [[switch_on_all_enum_values]] (E) {<br> case a: return 1;<br> =
; case b: return 2;<br> case c: return 3;<br> }</div></div></bl=
ockquote><div><br>There is something wrong with that example, the (E) seems=
completely out of place with the language, I am not sure if that was inten=
tional.<br><br>But otherwise, this seems like an acceptable use of attribut=
es according to existing guidelines.<br>It does not introduce any semantic =
changes and the attribute can be safely ignored.<br>This would be equivalen=
t to:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250,=
250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-w=
idth: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">enum</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> E =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> a</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"colo=
r: #000;" class=3D"styled-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"> c </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> f</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">E e</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"><br> </span><span style=3D"color: #800;" class=3D=
"styled-by-prettify">// switch cases must cover all enum values or trigger =
error/warning.</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br> </span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">switch</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">e</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"col=
or: #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"><br> </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">case</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> a</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;" 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"><br> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">case</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> b</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">return</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">2</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> </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">case</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> c</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">return</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pr=
ettify">3</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">default</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> __builtin_unreachabl=
e</span><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span></div><=
/code></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_903_369477850.1412034081120--
.
Author: gmisocpp@gmail.com
Date: Mon, 29 Sep 2014 16:54:05 -0700 (PDT)
Raw View
------=_Part_1134_1715752589.1412034845469
Content-Type: text/plain; charset=UTF-8
On Tuesday, September 30, 2014 12:41:21 PM UTC+13, Matheus Izvekov wrote:
>
> On Monday, September 29, 2014 8:28:04 PM UTC-3, gmis...@gmail.com wrote:
>>
>> enum E { a, b, c };
>> int f(E e) {
>> // switch cases must cover all enum values or trigger error/warning.
>> switch (e) [[switch_on_all_enum_values]] (E) {
>> case a: return 1;
>> case b: return 2;
>> case c: return 3;
>> }
>>
>
> There is something wrong with that example, the (E) seems completely out
> of place with the language, I am not sure if that was intentional.
>
> But otherwise, this seems like an acceptable use of attributes according
> to existing guidelines.
> It does not introduce any semantic changes and the attribute can be safely
> ignored.
>
Yes, sorry, the (E) was a typo, perhaps because I was considering at the
time if the type name needed to appear in the attribute.
I decided it didn't but left text relating to it in by mistake. It might
appear in my other post too as I cut and pasted.
Thanks for pointing that out.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1134_1715752589.1412034845469
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, September 30, 2014 12:41:21 PM UTC+13,=
Matheus Izvekov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204);=
border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">On Mon=
day, September 29, 2014 8:28:04 PM UTC-3, <a>gmis...@gmail.com</a> wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding=
-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; =
border-left-style: solid;"><div dir=3D"ltr"><div><div></div>enum E { a, b, =
c };<br>int f(E e) {<br> // switch cases must cover all enum values o=
r trigger error/warning.<br> switch (e) [[switch_on_all_enum_values]]=
(E) {<br> case a: return 1;<br> case b: return 2;<br> ca=
se c: return 3;<br> }</div></div></blockquote><div><br>There is somet=
hing wrong with that example, the (E) seems completely out of place with th=
e language, I am not sure if that was intentional.<br><br>But otherwise, th=
is seems like an acceptable use of attributes according to existing guideli=
nes.<br>It does not introduce any semantic changes and the attribute can be=
safely ignored.<br></div></div></blockquote><div><br></div><div>Yes, sorry=
, the (E) was a typo, perhaps because I was considering at the time if the =
type name needed to appear in the attribute.</div><div>I decided it didn't =
but left text relating to it in by mistake. It might appear in my othe=
r post too as I cut and pasted.</div><div>Thanks for pointing that out.</di=
v><div><br></div><code><div><br></div></code></div>
<p></p>
-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1134_1715752589.1412034845469--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 29 Sep 2014 21:29:34 -0700
Raw View
On Monday 29 September 2014 16:28:04 gmisocpp@gmail.com wrote:
> // Richards example with my additions:
>
> void app_exit()
> {
> exit(EXIT_FAILURE);
> }
>
> enum E { a, b, c };
> int f(E e) {
> // switch cases must cover all enum values or trigger error/warning.
> switch (e) [[switch_on_all_enum_values]] (E) {
> case a: return 1;
> case b: return 2;
> case c: return 3;
> }
> noreturn { // Whatever happens in here, there must be no way out.
> app_exit();
> }
[...]
> }
No, but this would:
enum E { a, b, c };
int f(E e) {
// switch cases must cover all enum values or trigger error/warning.
switch (e) [[switch_on_all_enum_values]] (E) {
case a: return 1;
case b: return 2;
case c: return 3;
}
noreturn { }
}
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Douglas Boffey <douglas.boffey@gmail.com>
Date: Tue, 30 Sep 2014 02:07:43 -0700 (PDT)
Raw View
------=_Part_4142_433762223.1412068064024
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, 30 September 2014 00:28:04 UTC+1, gmis...@gmail.com wrote:
>
> // noreturn works like this:
> // 1. Compiler attempts to verify the no_return block is unreachable,
> // if it unreachable, no code is generated and no warning is issued.
> // 2. If compiler can't verify the block is unreachable, a warning is=
=20
> issued
> // and the code inside the block is generated.
> // 3. If that code cannot be verified as not returning,
> // compiler injects code to ensure there is no way to return.=20
> // i.e. code to ensure std::terminate() is called the end of the block.
> try
> {
> app_exit();=20
> }
> catch(...)
> {
> // Would be nice if compiler offered the ability to=20
> inject __debug_break here too in some situations like for debug builds.
> //.Then we can more easily diagnose the code where we made a=20
> wrong assumption.
> std::terminate();
> } =20
> }
>
> Thoughts?
>
=20
Hmm. std::terminate injected into production code without being=20
explicity stated? I don=E2=80=99t think I=E2=80=99d like that=E2=80=94for =
some production code,=20
premature termination is not an option.=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_4142_433762223.1412068064024
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Tuesday, 30 September 2014 00:28:04 UTC+1, gmis...@=
gmail.com wrote:<blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-le=
ft: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bor=
der-left-style: solid;" class=3D"gmail_quote"><div dir=3D"ltr"><div> =
// noreturn works like this:<br> // 1. Compiler attempts to verify th=
e no_return block is unreachable,<br> // if it unreachable, no code i=
s generated and no warning is issued.<br> // 2. If compiler can'=
t verify the block is unreachable, a warning is issued<br> // and the=
code inside the block is generated.<br> // 3. If that code=
cannot be verified as not returning,<br> // compiler injects co=
de to ensure there is no way to return. </div><div> // i.e. code to e=
nsure std::terminate() is called the end of the block.<br> try<br>&nb=
sp; {<br> app_exit(); <br> }<br> =
catch(...)<br> {</div><div> // Would be nice if com=
piler offered the ability to inject __debug_break here =
too in some situations like for debug builds.</div><div> =
//.Then we can more easily diagnose the code where we made a wron=
g assumption.<br> std::terminate();<br> } =
; <br>}</div><div><br></div><div>Thoughts?</div></div></blockquote><div>&nb=
sp;</div><div>Hmm. std::terminate injected into production code witho=
ut being explicity stated? I don=E2=80=99t think I=E2=80=99=
d like that=E2=80=94for some production code, premature termination is not =
an option. </div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_4142_433762223.1412068064024--
.
Author: =?UTF-8?B?QWd1c3TDrW4gSy1iYWxsbyBCZXJnw6k=?= <kaballo86@hotmail.com>
Date: Tue, 30 Sep 2014 13:55:53 -0300
Raw View
On 30/09/2014 06:07 a.m., Douglas Boffey wrote:
>
> Hmm. std::terminate injected into production code without being
> explicity stated? I don=E2=80=99t think I=E2=80=99d like that=E2=80=94fo=
r some production code,
> premature termination is not an option.
>
Check out [except.terminate] for a list of scenarios where=20
`std::terminate` is injected. I believe this is not an exhaustive list.
I don't have an opinion on the context in which this is proposed=20
(leaning towards against), but an injected call to terminate would make=20
sense there.
Regards,
--=20
Agust=C3=ADn K-ballo Berg=C3=A9.-
http://talesofcpp.fusionfenix.com
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 1 Oct 2014 07:56:17 +0800
Raw View
--Apple-Mail=_2C2F4B8C-749D-429F-A28D-E7636671FF3F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-10-01, at 12:55 AM, Agust=EDn K-ballo Berg=E9 <kaballo86@hotmail.co=
m> wrote:
> Check out [except.terminate] for a list of scenarios where `std::terminat=
e` is injected. I believe this is not an exhaustive list.
>=20
> I don't have an opinion on the context in which this is proposed (leaning=
towards against), but an injected call to terminate would make sense there=
..
Worth mentioning that implementations can certainly call std::terminate as =
part of undefined behavior.
I wouldn't want to see this required simply because the extra "CALL" instru=
ction takes up space. The standard could mention in an informative note, th=
ough, what behavior might be allowed.
I also disagree that a missing return value would fit into the list of term=
inate cases. They all relate to failures in exception handling which leave =
no recourse. There could just as well be a std::missing_return_value except=
ion with implementation-defined support. Failing to install a handler would=
result in terminate preceded by an implementation-specified unwinding pro=
cess. That's already compatible with a proposal of terminate alone.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_2C2F4B8C-749D-429F-A28D-E7636671FF3F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;10–01, at 12:55 AM, Agust=EDn K-ballo Berg=E9 <<a href=3D"ma=
ilto:kaballo86@hotmail.com">kaballo86@hotmail.com</a>> wrote:</div><br c=
lass=3D"Apple-interchange-newline"><blockquote type=3D"cite">Check out [exc=
ept.terminate] for a list of scenarios where `std::terminate` is injected. =
I believe this is not an exhaustive list.<br><br>I don't have an opinion on=
the context in which this is proposed (leaning towards against), but an in=
jected call to terminate would make sense there.<br></blockquote><div><br><=
/div><div>Worth mentioning that implementations can certainly call <font fa=
ce=3D"Courier">std::terminate</font> as part of undefined behavior.</div><d=
iv><br></div><div>I wouldn’t want to see this required simply because=
the extra “CALL” instruction takes up space. The standard coul=
d mention in an informative note, though, what behavior might be allowed.</=
div><div><br></div><div>I also disagree that a missing return value would f=
it into the list of <font face=3D"Courier">terminate</font> cases. They all=
relate to failures in exception handling which leave no recourse. There co=
uld just as well be a <font face=3D"Courier">std::missing_return_value</fon=
t> exception with implementation-defined support. Failing to install a hand=
ler would result in <span style=3D"font-family: Courier;">terminate</s=
pan> preceded by an implementation-specified unwinding process. That&=
rsquo;s already compatible with a proposal of <font face=3D"Courier">termin=
ate</font> alone.</div></div><br></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_2C2F4B8C-749D-429F-A28D-E7636671FF3F--
.