------=_Part_2841_1076251826.1446904525877
Content-Type: multipart/alternative;
 boundary="----=_Part_2842_1942322177.1446904525877"

------=_Part_2842_1942322177.1446904525877
Content-Type: text/plain; charset=UTF-8

In a relatively recent thread, there was a discussion of functions with
return types when not all control paths return a value. This is
occasionally useful if the function will never fall off the end, and it's
impossible for the compiler to get this right at runtime. So the standard
does not require erroring out if the compiler statically detects a path of
execution that could lead to falling off the end.

It would be a good idea for static analysis tools to be able to find cases
where you accidentally fail to return. So I suggest adding the ability to
explicitly say "Yes, I meant to not return something here". This would be
something like [[unreachable]], where the compiler/tool assumes that the
line in question will never be reached. That way, static analysis
tools/compilers can warn on not seeing a return statement, but you can
silence the warning when you actually meant to do 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_2842_1942322177.1446904525877
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">In a relatively recent thread, there was a discussion of f=
unctions with return types when not all control paths return a value. This =
is occasionally useful if the function will never fall off the end, and it&=
#39;s impossible for the compiler to get this right at runtime. So the stan=
dard does not require erroring out if the compiler statically detects a pat=
h of execution that could lead to falling off the end.<br><br>It would be a=
 good idea for static analysis tools to be able to find cases where you acc=
identally fail to return. So I suggest adding the ability to explicitly say=
 &quot;Yes, I meant to not return something here&quot;. This would be somet=
hing like [[unreachable]], where the compiler/tool assumes that the line in=
 question will never be reached. That way, static analysis tools/compilers =
can warn on not seeing a return statement, but you can silence the warning =
when you actually meant to do it.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2842_1942322177.1446904525877--
------=_Part_2841_1076251826.1446904525877--

.

2015-11-07 14:55 GMT+01:00 Nicol Bolas <jmckesson@gmail.com>:
> In a relatively recent thread, there was a discussion of functions with
> return types when not all control paths return a value. This is occasionally
> useful if the function will never fall off the end, and it's impossible for
> the compiler to get this right at runtime. So the standard does not require
> erroring out if the compiler statically detects a path of execution that
> could lead to falling off the end.
>
> It would be a good idea for static analysis tools to be able to find cases
> where you accidentally fail to return. So I suggest adding the ability to
> explicitly say "Yes, I meant to not return something here". This would be
> something like [[unreachable]], where the compiler/tool assumes that the
> line in question will never be reached. That way, static analysis
> tools/compilers can warn on not seeing a return statement, but you can
> silence the warning when you actually meant to do it.

I'm not really sure that I have understood your request correctly,
could you please amend this by an example? At the moment, I'm
wondering why proper marking of never-returning functions with
[[noreturn]] wouldn't already provide the corresponding information to
the compiler.

Thanks,

- Daniel

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

.

On 7 November 2015 at 17:12, Daniel Kr=C3=BCgler <daniel.kruegler@gmail.com=
> wrote:
> 2015-11-07 14:55 GMT+01:00 Nicol Bolas <jmckesson@gmail.com>:
>> In a relatively recent thread, there was a discussion of functions with
>> return types when not all control paths return a value. This is occasion=
ally
>> useful if the function will never fall off the end, and it's impossible =
for
>> the compiler to get this right at runtime. So the standard does not requ=
ire
>> erroring out if the compiler statically detects a path of execution that
>> could lead to falling off the end.
>>
>> It would be a good idea for static analysis tools to be able to find cas=
es
>> where you accidentally fail to return. So I suggest adding the ability t=
o
>> explicitly say "Yes, I meant to not return something here". This would b=
e
>> something like [[unreachable]], where the compiler/tool assumes that the
>> line in question will never be reached. That way, static analysis
>> tools/compilers can warn on not seeing a return statement, but you can
>> silence the warning when you actually meant to do it.
>
> I'm not really sure that I have understood your request correctly,
> could you please amend this by an example? At the moment, I'm
> wondering why proper marking of never-returning functions with
> [[noreturn]] wouldn't already provide the corresponding information to
> the compiler.


Because [[noreturn]] functions should never return, but functions that retu=
rn
may contain unreachable paths. Having said that, I don't understand the
motivation to mark paths as unreachable, so I agree that better motivation
should be provided.

--=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_294_299933343.1446909619376
Content-Type: multipart/alternative;
 boundary="----=_Part_295_817303693.1446909619376"

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

On Saturday, November 7, 2015 at 10:12:48 AM UTC-5, Daniel Kr=C3=BCgler wro=
te:
>
> 2015-11-07 14:55 GMT+01:00 Nicol Bolas <jmck...@gmail.com <javascript:>>:=
=20
> > In a relatively recent thread, there was a discussion of functions with=
=20
> > return types when not all control paths return a value. This is=20
> occasionally=20
> > useful if the function will never fall off the end, and it's impossible=
=20
> for=20
> > the compiler to get this right at runtime. So the standard does not=20
> require=20
> > erroring out if the compiler statically detects a path of execution tha=
t=20
> > could lead to falling off the end.=20
> >=20
> > It would be a good idea for static analysis tools to be able to find=20
> cases=20
> > where you accidentally fail to return. So I suggest adding the ability=
=20
> to=20
> > explicitly say "Yes, I meant to not return something here". This would=
=20
> be=20
> > something like [[unreachable]], where the compiler/tool assumes that th=
e=20
> > line in question will never be reached. That way, static analysis=20
> > tools/compilers can warn on not seeing a return statement, but you can=
=20
> > silence the warning when you actually meant to do it.=20
>
> I'm not really sure that I have understood your request correctly,=20
> could you please amend this by an example? At the moment, I'm=20
> wondering why proper marking of never-returning functions with=20
> [[noreturn]] wouldn't already provide the corresponding information to=20
> the compiler.=20
>

It's not "this function never returns". It's for cases like this:

int func(...)
{
  if(cond1)
  {
    ...
    return 5;
  }

  if(cond2)
  {
    ...
    return 10;
  }

  //unreachable
}
=20
Even though `cond1` and `cond2` are two different expressions, which do not=
=20
locally appear related, the overall system will ensure that at least one=20
condition is true. If you put the [[unreachable]] attribute tag at=20
`//unreachable`, then the compiler/static tool knows that this code should=
=20
never be reached, and thus the lack of return is deliberate.

This could also be a switch statement over a range of values that you know=
=20
will not be exceeded. Each individual condition returns a value, but at=20
runtime the condition will never not be one of those values.

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

On Saturday, November 7, 2015 at 10:12:48 AM UTC-5, Daniel Kr=C3=BCgler wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">2015-11-07 14:55 GMT+01:00 =
Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"X0UzHA75FQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;java=
script:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;ret=
urn true;">jmck...@gmail.com</a>&gt;:
<br>&gt; In a relatively recent thread, there was a discussion of functions=
 with
<br>&gt; return types when not all control paths return a value. This is oc=
casionally
<br>&gt; useful if the function will never fall off the end, and it&#39;s i=
mpossible for
<br>&gt; the compiler to get this right at runtime. So the standard does no=
t require
<br>&gt; erroring out if the compiler statically detects a path of executio=
n that
<br>&gt; could lead to falling off the end.
<br>&gt;
<br>&gt; It would be a good idea for static analysis tools to be able to fi=
nd cases
<br>&gt; where you accidentally fail to return. So I suggest adding the abi=
lity to
<br>&gt; explicitly say &quot;Yes, I meant to not return something here&quo=
t;. This would be
<br>&gt; something like [[unreachable]], where the compiler/tool assumes th=
at the
<br>&gt; line in question will never be reached. That way, static analysis
<br>&gt; tools/compilers can warn on not seeing a return statement, but you=
 can
<br>&gt; silence the warning when you actually meant to do it.
<br>
<br>I&#39;m not really sure that I have understood your request correctly,
<br>could you please amend this by an example? At the moment, I&#39;m
<br>wondering why proper marking of never-returning functions with
<br>[[noreturn]] wouldn&#39;t already provide the corresponding information=
 to
<br>the compiler.
<br></blockquote><div><br>It&#39;s not &quot;this function never returns&qu=
ot;. It&#39;s for cases like this:<br><br>int func(...)<br>{<br>=C2=A0 if(c=
ond1)<br>=C2=A0 {<br>=C2=A0=C2=A0=C2=A0 ...<br>=C2=A0=C2=A0=C2=A0 return 5;=
<br>=C2=A0 }<br><br>=C2=A0 if(cond2)<br>=C2=A0 {<br>=C2=A0=C2=A0=C2=A0 ...<=
br>=C2=A0=C2=A0=C2=A0 return 10;<br>=C2=A0 }<br><br>=C2=A0 //unreachable<br=
>}<br>=C2=A0<br>Even though `cond1` and `cond2` are two different expressio=
ns, which do not locally appear related, the overall system will ensure tha=
t at least one condition is true. If you put the [[unreachable]] attribute =
tag at `//unreachable`, then the compiler/static tool knows that this code =
should never be reached, and thus the lack of return is deliberate.<br><br>=
This could also be a switch statement over a range of values that you know =
will not be exceeded. Each individual condition returns a value, but at run=
time the condition will never not be one of those values.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_295_817303693.1446909619376--
------=_Part_294_299933343.1446909619376--

.

On 7 November 2015 at 17:20, Nicol Bolas <jmckesson@gmail.com> wrote:
> It's not "this function never returns". It's for cases like this:
>
> int func(...)
> {
>   if(cond1)
>   {
>     ...
>     return 5;
>   }
>
>   if(cond2)
>   {
>     ...
>     return 10;
>   }
>
>   //unreachable
> }
>
> Even though `cond1` and `cond2` are two different expressions, which do not
> locally appear related, the overall system will ensure that at least one
> condition is true. If you put the [[unreachable]] attribute tag at
> `//unreachable`, then the compiler/static tool knows that this code should
> never be reached, and thus the lack of return is deliberate.
>
> This could also be a switch statement over a range of values that you know
> will not be exceeded. Each individual condition returns a value, but at
> runtime the condition will never not be one of those values.


So the purpose of this attribute is to quiesce diagnostics that tools otherwise
emit unless the code is convoluted to "handle" the missing cases (and such
"handling" may well be boilerplate nonsense). Having fought with such cases
occasionally, I'm beginning to like the 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a11444938e0450b0523f54c50
Content-Type: text/plain; charset=UTF-8

I've thought about proposing something like this before.

Let us call this an unreachable statement and put aside whether or not it
is an attribute statement or a statement that has a semantic effect for the
moment.

Let us say that the intent of an unreachable statement is to assert that
the statement in question shall never be executed.

The question is, what happens if you get it wrong, and an unreachable
statement, contrary to your assertion, is executed.

I think the answer should be that what happens is the same or similar to an
assert(false).  It is a constraint violation.

You should also study the existing practice before settling on your
design.  In particular do code searches for the term "unreachable".  This
is what such a facility is usually called.

In particular have a look at the LLVM unreachable instruction, and in clang
there is an unreachable statement (I'm not sure right now if it compiles to
the unreachable instruction, or the two are unrelated).

You should also search code.openhub.net and github for occurences of the
term "unreachable" and see what they do.  You should enumerate the
different existing facilities and discuss how they compare to your design.

Enjoy,
Andrew.



On Sat, Nov 7, 2015 at 2:55 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> In a relatively recent thread, there was a discussion of functions with
> return types when not all control paths return a value. This is
> occasionally useful if the function will never fall off the end, and it's
> impossible for the compiler to get this right at runtime. So the standard
> does not require erroring out if the compiler statically detects a path of
> execution that could lead to falling off the end.
>
> It would be a good idea for static analysis tools to be able to find cases
> where you accidentally fail to return. So I suggest adding the ability to
> explicitly say "Yes, I meant to not return something here". This would be
> something like [[unreachable]], where the compiler/tool assumes that the
> line in question will never be reached. That way, static analysis
> tools/compilers can warn on not seeing a return statement, but you can
> silence the warning when you actually meant to do 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--001a11444938e0450b0523f54c50
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;ve thought about proposing something like this befor=
e.<div><br></div><div>Let us call this an unreachable statement and put asi=
de whether or not it is an attribute statement or a statement that has a se=
mantic effect for the moment.<div><br></div><div>Let us say that the intent=
 of an unreachable statement is to assert that the statement in question sh=
all never be executed.</div><div><br></div><div>The question is, what happe=
ns if you get it wrong, and an unreachable statement, contrary to your asse=
rtion, is executed.</div><div><br></div></div><div>I think the answer shoul=
d be that what happens is the same or similar to an assert(false).=C2=A0 It=
 is a constraint violation.</div><div><br></div><div>You should also study =
the existing practice before settling on your design.=C2=A0 In particular d=
o code searches for the term &quot;unreachable&quot;.=C2=A0 This is what su=
ch a facility is usually called.</div><div><br></div><div>In particular hav=
e a look at the LLVM unreachable instruction, and in clang there is an unre=
achable statement (I&#39;m not sure right now if it compiles to the unreach=
able instruction, or the two are unrelated).</div><div><br></div><div>You s=
hould also search <a href=3D"http://code.openhub.net">code.openhub.net</a> =
and github for occurences of the term &quot;unreachable&quot; and see what =
they do.=C2=A0 You should enumerate the different existing facilities and d=
iscuss how they compare to your design.</div><div><br></div><div>Enjoy,</di=
v><div>Andrew.</div><div><br></div><div><br></div></div><div class=3D"gmail=
_extra"><br><div class=3D"gmail_quote">On Sat, Nov 7, 2015 at 2:55 PM, Nico=
l Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=
=3D"_blank">jmckesson@gmail.com</a>&gt;</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">In a relatively recent thread, there was a d=
iscussion of functions with return types when not all control paths return =
a value. This is occasionally useful if the function will never fall off th=
e end, and it&#39;s impossible for the compiler to get this right at runtim=
e. So the standard does not require erroring out if the compiler statically=
 detects a path of execution that could lead to falling off the end.<br><br=
>It would be a good idea for static analysis tools to be able to find cases=
 where you accidentally fail to return. So I suggest adding the ability to =
explicitly say &quot;Yes, I meant to not return something here&quot;. This =
would be something like [[unreachable]], where the compiler/tool assumes th=
at the line in question will never be reached. That way, static analysis to=
ols/compilers can warn on not seeing a return statement, but you can silenc=
e the warning when you actually meant to do it.<span class=3D"HOEnZb"><font=
 color=3D"#888888"><br></font></span></div><span class=3D"HOEnZb"><font col=
or=3D"#888888">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11444938e0450b0523f54c50--

.

> 2015-11-07 14:55 GMT+01:00 Nicol Bolas <jmckesson@gmail.com>:
>
> In a relatively recent thread, there was a discussion of functions
> with return types when not all control paths return a value. This is
> occasionally useful if the function will never fall off the end, and
> it's impossible for the compiler to get this right at runtime. So the
> standard does not require erroring out if the compiler statically
> detects a path of execution that could lead to falling off the end.
>
> It would be a good idea for static analysis tools to be able to find
> cases where you accidentally fail to return. So I suggest adding the
> ability to explicitly say "Yes, I meant to not return something
> here". This would be something like [[unreachable]], where the
> compiler/tool assumes that the line in question will never be
> reached. That way, static analysis tools/compilers can warn on not
> seeing a return statement, but you can silence the warning when you
> actually meant to do it.

This sounds a lot to me like GCC's `__builtin_unreachable`.  From the
[documentation](https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-g_t_005f_005fbuiltin_005funreachable-4123):

> If control flow reaches the point of the `__builtin_unreachable`, the
> program is undefined.  It is useful in situations where the compiler
> cannot deduce the unreachability of the code.
>
> One such case is immediately following an asm statement that either
> never terminates, or one that transfers control elsewhere and never
> returns. In this example, without the `__builtin_unreachable`, GCC
> issues a warning that control reaches the end of a non-void function.
> It also generates code to return after the `asm`.
>
>     int f (int c, int v)
>     {
>       if (c)
>         {
>           return v;
>         }
>       else
>         {
>           asm("jmp error_handler");
>           __builtin_unreachable ();
>         }
>     }
>
> Because the `asm` statement unconditionally transfers control out of
> the function, control never reaches the end of the function body.  The
> `__builtin_unreachable` is in fact unreachable and communicates this
> fact to the compiler.
>
> Another use for `__builtin_unreachable` is following a call a function
> that never returns but that is not declared
> `__attribute__((noreturn))`, as in this example:
>
>     void function_that_never_returns (void);
>
>     int g (int c)
>     {
>       if (c)
>         {
>           return 1;
>         }
>       else
>         {
>           function_that_never_returns ();
>           __builtin_unreachable ();
>         }
>     }

Are these the semantics you have in mind?  I think such a feature could
be useful if provided directly by the language rather than a compiler
specific extension.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

.

2015-11-07 16:20 GMT+01:00 Nicol Bolas <jmckesson@gmail.com>:
> On Saturday, November 7, 2015 at 10:12:48 AM UTC-5, Daniel Kr=C3=BCgler w=
rote:
>> I'm not really sure that I have understood your request correctly,
>> could you please amend this by an example? At the moment, I'm
>> wondering why proper marking of never-returning functions with
>> [[noreturn]] wouldn't already provide the corresponding information to
>> the compiler.
>
>
> It's not "this function never returns". It's for cases like this:
>
> int func(...)
> {
>   if(cond1)
>   {
>     ...
>     return 5;
>   }
>
>   if(cond2)
>   {
>     ...
>     return 10;
>   }
>
>   //unreachable
> }
>
> Even though `cond1` and `cond2` are two different expressions, which do n=
ot
> locally appear related, the overall system will ensure that at least one
> condition is true. If you put the [[unreachable]] attribute tag at
> `//unreachable`, then the compiler/static tool knows that this code shoul=
d
> never be reached, and thus the lack of return is deliberate.
>
> This could also be a switch statement over a range of values that you kno=
w
> will not be exceeded. Each individual condition returns a value, but at
> runtime the condition will never not be one of those values.

So what precisely is the attribute referring to: Is this a "statement"
attribute and it would be used such as in

int func(...)
{
  if(cond1)
  {
    ...
    return 5;
  }

  if(cond2)
  {
    ...
    return 10;
  }

  [[unreachable]]
}

? If so, this sounds to me like an odd use case for attributes.
Informally attributes apply to "source constructs such as types,
variables, names, blocks, or translation units" and I would like to
know of an existing compiler that would use an attribute for this. Can
you name an example? [I'm aware of function-like intrinsics such as
__builtin_unreachable(), that seem to realize what you want to
describe in a portable fashion, but these are not attributes].

Unless I misunderstood your requet completely, I have the feeling that
an attribute might not be the best way to realize that. Why couldn't
that be a standard library function instead?

- Daniel

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

.

--047d7beb9ec4e85e870523f58e43
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Nov 7, 2015 at 4:53 PM, Daniel Kr=C3=BCgler <daniel.kruegler@gmail.=
com>
wrote:

> 2015-11-07 16:20 GMT+01:00 Nicol Bolas <jmckesson@gmail.com>:
> > On Saturday, November 7, 2015 at 10:12:48 AM UTC-5, Daniel Kr=C3=BCgler=
 wrote:
> >> I'm not really sure that I have understood your request correctly,
> >> could you please amend this by an example? At the moment, I'm
> >> wondering why proper marking of never-returning functions with
> >> [[noreturn]] wouldn't already provide the corresponding information to
> >> the compiler.
> >
> >
> > It's not "this function never returns". It's for cases like this:
> >
> > int func(...)
> > {
> >   if(cond1)
> >   {
> >     ...
> >     return 5;
> >   }
> >
> >   if(cond2)
> >   {
> >     ...
> >     return 10;
> >   }
> >
> >   //unreachable
> > }
> >
> > Even though `cond1` and `cond2` are two different expressions, which do
> not
> > locally appear related, the overall system will ensure that at least on=
e
> > condition is true. If you put the [[unreachable]] attribute tag at
> > `//unreachable`, then the compiler/static tool knows that this code
> should
> > never be reached, and thus the lack of return is deliberate.
> >
> > This could also be a switch statement over a range of values that you
> know
> > will not be exceeded. Each individual condition returns a value, but at
> > runtime the condition will never not be one of those values.
>
> So what precisely is the attribute referring to: Is this a "statement"
> attribute and it would be used such as in
>
> int func(...)
> {
>   if(cond1)
>   {
>     ...
>     return 5;
>   }
>
>   if(cond2)
>   {
>     ...
>     return 10;
>   }
>
>   [[unreachable]]
> }
>
> ? If so, this sounds to me like an odd use case for attributes.
> Informally attributes apply to "source constructs such as types,
> variables, names, blocks, or translation units" and I would like to
> know of an existing compiler that would use an attribute for this. Can
> you name an example?


Formally an "attribute statement" is an attribute marked on a null
statement.  There will be a precedent shortly with the fallthrough
statement, a standardization of clang::fallthrough - but this won't/can't
have semantic effect.

As I said in my previous message, I suspect the answer is that we want
unreachable to do the same thing as an assert(false), as such I think it
should be a library function like std::unreachable(), possibly marked
[[noreturn]].  It is unclear if it should terminate or throw an exception
or result in undefined behaviour.  It could only be an attribute if it had
no runtime side-effect.

[I'm aware of function-like intrinsics such as
> __builtin_unreachable(), that seem to realize what you want to
> describe in a portable fashion, but these are not attributes].
>
> Unless I misunderstood your requet completely, I have the feeling that
> an attribute might not be the best way to realize that. Why couldn't
> that be a standard library function instead?
>
> - Daniel
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving 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/.
>

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

--047d7beb9ec4e85e870523f58e43
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 Sat, Nov 7, 2015 at 4:53 PM, Daniel Kr=C3=BCgler <span dir=3D"ltr">&=
lt;<a href=3D"mailto:daniel.kruegler@gmail.com" target=3D"_blank">daniel.kr=
uegler@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"><s=
pan class=3D"">2015-11-07 16:20 GMT+01:00 Nicol Bolas &lt;<a href=3D"mailto=
:jmckesson@gmail.com">jmckesson@gmail.com</a>&gt;:<br>
&gt; On Saturday, November 7, 2015 at 10:12:48 AM UTC-5, Daniel Kr=C3=BCgle=
r wrote:<br>
</span><span class=3D"">&gt;&gt; I&#39;m not really sure that I have unders=
tood your request correctly,<br>
&gt;&gt; could you please amend this by an example? At the moment, I&#39;m<=
br>
&gt;&gt; wondering why proper marking of never-returning functions with<br>
&gt;&gt; [[noreturn]] wouldn&#39;t already provide the corresponding inform=
ation to<br>
&gt;&gt; the compiler.<br>
&gt;<br>
&gt;<br>
&gt; It&#39;s not &quot;this function never returns&quot;. It&#39;s for cas=
es like this:<br>
&gt;<br>
&gt; int func(...)<br>
&gt; {<br>
&gt;=C2=A0 =C2=A0if(cond1)<br>
&gt;=C2=A0 =C2=A0{<br>
&gt;=C2=A0 =C2=A0 =C2=A0...<br>
&gt;=C2=A0 =C2=A0 =C2=A0return 5;<br>
&gt;=C2=A0 =C2=A0}<br>
&gt;<br>
&gt;=C2=A0 =C2=A0if(cond2)<br>
&gt;=C2=A0 =C2=A0{<br>
&gt;=C2=A0 =C2=A0 =C2=A0...<br>
&gt;=C2=A0 =C2=A0 =C2=A0return 10;<br>
&gt;=C2=A0 =C2=A0}<br>
&gt;<br>
&gt;=C2=A0 =C2=A0//unreachable<br>
&gt; }<br>
&gt;<br>
&gt; Even though `cond1` and `cond2` are two different expressions, which d=
o not<br>
&gt; locally appear related, the overall system will ensure that at least o=
ne<br>
&gt; condition is true. If you put the [[unreachable]] attribute tag at<br>
&gt; `//unreachable`, then the compiler/static tool knows that this code sh=
ould<br>
&gt; never be reached, and thus the lack of return is deliberate.<br>
&gt;<br>
&gt; This could also be a switch statement over a range of values that you =
know<br>
&gt; will not be exceeded. Each individual condition returns a value, but a=
t<br>
&gt; runtime the condition will never not be one of those values.<br>
<br>
</span>So what precisely is the attribute referring to: Is this a &quot;sta=
tement&quot;<br>
attribute and it would be used such as in<br>
<span class=3D""><br>
int func(...)<br>
{<br>
=C2=A0 if(cond1)<br>
=C2=A0 {<br>
=C2=A0 =C2=A0 ...<br>
=C2=A0 =C2=A0 return 5;<br>
=C2=A0 }<br>
<br>
=C2=A0 if(cond2)<br>
=C2=A0 {<br>
=C2=A0 =C2=A0 ...<br>
=C2=A0 =C2=A0 return 10;<br>
=C2=A0 }<br>
<br>
</span>=C2=A0 [[unreachable]]<br>
}<br>
<br>
? If so, this sounds to me like an odd use case for attributes.<br>
Informally attributes apply to &quot;source constructs such as types,<br>
variables, names, blocks, or translation units&quot; and I would like to<br=
>
know of an existing compiler that would use an attribute for this. Can<br>
you name an example?</blockquote><div><br></div><div>Formally an &quot;attr=
ibute statement&quot; is an attribute marked on a null statement.=C2=A0 The=
re will be a precedent shortly with the fallthrough statement, a standardiz=
ation of clang::fallthrough - but this won&#39;t/can&#39;t have semantic ef=
fect.</div><div><br></div><div>As I said in my previous message, I suspect =
the answer is that we want unreachable to do the same thing as an assert(fa=
lse), as such I think it should be a library function like std::unreachable=
(), possibly marked [[noreturn]].=C2=A0 It is unclear if it should terminat=
e or throw an exception or result in undefined behaviour.=C2=A0 It could on=
ly be an attribute if it had no runtime side-effect.</div><div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"> [I&#39;m aware of function-like intrinsics su=
ch as<br>
__builtin_unreachable(), that seem to realize what you want to<br>
describe in a portable fashion, but these are not attributes].<br>
<br>
Unless I misunderstood your requet completely, I have the feeling that<br>
an attribute might not be the best way to realize that. Why couldn&#39;t<br=
>
that be a standard library function instead?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
- Daniel<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7beb9ec4e85e870523f58e43--

.

------=_Part_3451_1604465321.1446913239352
Content-Type: multipart/alternative;
 boundary="----=_Part_3452_1930751676.1446913239352"

------=_Part_3452_1930751676.1446913239352
Content-Type: text/plain; charset=UTF-8



On Saturday, November 7, 2015 at 10:49:09 AM UTC-5, Andrew Tomazos wrote:
>
> I've thought about proposing something like this before.
>
> Let us call this an unreachable statement and put aside whether or not it
> is an attribute statement or a statement that has a semantic effect for the
> moment.
>
> Let us say that the intent of an unreachable statement is to assert that
> the statement in question shall never be executed.
>

But that's not the intent of what I was wanting. All I want is a marker to
tell compilers/static tools that "I really did mean to not return here."
That's it. Anything more is scope creep.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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_3452_1930751676.1446913239352
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, November 7, 2015 at 10:49:09 AM UTC-5=
, Andrew Tomazos 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&#39;ve thought about proposing something like this before.<div>=
<br></div><div>Let us call this an unreachable statement and put aside whet=
her or not it is an attribute statement or a statement that has a semantic =
effect for the moment.<div><br></div><div>Let us say that the intent of an =
unreachable statement is to assert that the statement in question shall nev=
er be executed.</div></div></div></blockquote><div><br>But that&#39;s not t=
he intent of what I was wanting. All I want is a marker to tell compilers/s=
tatic tools that &quot;I really did mean to not return here.&quot; That&#39=
;s it. Anything more is scope creep.</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3452_1930751676.1446913239352--
------=_Part_3451_1604465321.1446913239352--

.

--001a1143c04ec1907d0523f5ffb6
Content-Type: text/plain; charset=UTF-8

On Sat, Nov 7, 2015 at 5:20 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

>
>
> On Saturday, November 7, 2015 at 10:49:09 AM UTC-5, Andrew Tomazos wrote:
>>
>> I've thought about proposing something like this before.
>>
>> Let us call this an unreachable statement and put aside whether or not it
>> is an attribute statement or a statement that has a semantic effect for the
>> moment.
>>
>> Let us say that the intent of an unreachable statement is to assert that
>> the statement in question shall never be executed.
>>
>
> But that's not the intent of what I was wanting. All I want is a marker to
> tell compilers/static tools that "I really did mean to not return here."
> That's it. Anything more is scope creep.
>

:)  You need a supermajority of committee votes to get this passed.  They
do not give a crap what you want, they vote based on what they want.  It
may be that an attribute statement with no semantic effect is the way to
go, but you will need to show that you have carefully considered all the
alternatives, have carefully studied existing practice, and have worked
through all the different options in excruciating detail before settling on
a design.  It's the only way to build the needed consensus.

Note that this is not the same thing as pre-deciding what you want and then
writing a big long paper to try and justify it, people will see straight
through 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1143c04ec1907d0523f5ffb6
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 Sat, Nov 7, 2015 at 5:20 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bor=
der-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><b=
r><br>On Saturday, November 7, 2015 at 10:49:09 AM UTC-5, Andrew Tomazos wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:sol=
id;padding-left:1ex"><div dir=3D"ltr">I&#39;ve thought about proposing some=
thing like this before.<div><br></div><div>Let us call this an unreachable =
statement and put aside whether or not it is an attribute statement or a st=
atement that has a semantic effect for the moment.<div><br></div><div>Let u=
s say that the intent of an unreachable statement is to assert that the sta=
tement in question shall never be executed.</div></div></div></blockquote><=
/span><div><br>But that&#39;s not the intent of what I was wanting. All I w=
ant is a marker to tell compilers/static tools that &quot;I really did mean=
 to not return here.&quot; That&#39;s it. Anything more is scope creep.</di=
v></div></blockquote><div><br></div><div>:) =C2=A0You need a supermajority =
of committee votes to get this passed.=C2=A0 They do not give a crap what y=
ou want, they vote based on what they want.=C2=A0 It may be that an attribu=
te statement with no semantic effect is the way to go, but you will need to=
 show that you have carefully considered all the alternatives, have careful=
ly studied existing practice, and have worked through all the different opt=
ions in excruciating detail before settling on a design.=C2=A0 It&#39;s the=
 only way to build the needed consensus.</div><div><br></div><div>Note that=
 this is not the same thing as pre-deciding what you want and then writing =
a big long paper to try and justify it, people will see straight through th=
at.</div><div><br></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1143c04ec1907d0523f5ffb6--

.

--001a11409e3e65ff0d0523f68889
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

El 7/11/2015 13:20, "Nicol Bolas" <jmckesson@gmail.com> escribi=C3=B3:
>
>
>
> On Saturday, November 7, 2015 at 10:49:09 AM UTC-5, Andrew Tomazos wrote:
>>
>> I've thought about proposing something like this before.
>>
>> Let us call this an unreachable statement and put aside whether or not
it is an attribute statement or a statement that has a semantic effect for
the moment.
>>
>> Let us say that the intent of an unreachable statement is to assert that
the statement in question shall never be executed.
>
>
> But that's not the intent of what I was wanting. All I want is a marker
to tell compilers/static tools that "I really did mean to not return here."
That's it. Anything more is scope creep.

I am a very big fan of attributes (my team wrote almost 10 gcc extensions
based on them, successfully improving static analysis on real life mission
critical code).
However, in this case I do prefer Andrews's suggestion, because: 1) as he
suggests, this may (or may not) have runtime comsequences (we could even
have an unreacheable_handler() with its setter, a la uncaught_handler)
enabling runtime consistency checks and even allowing the user to decide
weather to abort() or take a different action; and 2) this is perfectly
understandable by static checkers (what's the difference in a checker's
parser to handle a std function call and an attribute?).

>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving 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/.

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

--001a11409e3e65ff0d0523f68889
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
El 7/11/2015 13:20, &quot;Nicol Bolas&quot; &lt;<a href=3D"mailto:jmckesson=
@gmail.com">jmckesson@gmail.com</a>&gt; escribi=C3=B3:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Saturday, November 7, 2015 at 10:49:09 AM UTC-5, Andrew Tomazos wro=
te:<br>
&gt;&gt;<br>
&gt;&gt; I&#39;ve thought about proposing something like this before.<br>
&gt;&gt;<br>
&gt;&gt; Let us call this an unreachable statement and put aside whether or=
 not it is an attribute statement or a statement that has a semantic effect=
 for the moment.<br>
&gt;&gt;<br>
&gt;&gt; Let us say that the intent of an unreachable statement is to asser=
t that the statement in question shall never be executed.<br>
&gt;<br>
&gt;<br>
&gt; But that&#39;s not the intent of what I was wanting. All I want is a m=
arker to tell compilers/static tools that &quot;I really did mean to not re=
turn here.&quot; That&#39;s it. Anything more is scope creep.</p>
<p dir=3D"ltr">I am a very big fan of attributes (my team wrote almost 10 g=
cc extensions based on them, successfully improving static analysis on real=
 life mission critical code).<br>
However, in this case I do prefer Andrews&#39;s suggestion, because: 1) as =
he suggests, this may (or may not) have runtime comsequences (we could even=
 have an unreacheable_handler() with its setter, a la uncaught_handler) ena=
bling runtime consistency checks and even allowing the user to decide weath=
er to abort() or take a different action; and 2) this is perfectly understa=
ndable by static checkers (what&#39;s the difference in a checker&#39;s par=
ser to handle a std function call and an attribute?).<br></p>
<p dir=3D"ltr">&gt;<br>
&gt; -- <br>
&gt;<br>
&gt; --- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-propos=
als/</a>.<br>
</p>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11409e3e65ff0d0523f68889--

.

On 11/07/2015 04:53 PM, Daniel Kr=C3=BCgler wrote:

> ? If so, this sounds to me like an odd use case for attributes.

Consider the following example:

   enum values { one, two };

   double convert(enum values v) noexcept
   {
     switch (v)
     {
     case one:
       return 1.0;
     case two:
       return 2.0;
     }
   }

The switch statement does not contain a default case, because we want
a compiler warning if we add another enumerator and forget to handle it
in the switch statement.

Unfortunately, the above code also causes the compiler to warn that
there is no return after the switch statement. With an unreachable
attribute we can get the compiler warnings only when we want them.

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

.

--047d7beb9ec4f8a03c0523f7401c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Nov 7, 2015 at 6:40 PM, Bjorn Reese <breese@mail1.stofanet.dk>
wrote:

> On 11/07/2015 04:53 PM, Daniel Kr=C3=BCgler wrote:
>
> ? If so, this sounds to me like an odd use case for attributes.
>>
>
> Consider the following example:
>
>   enum values { one, two };
>
>   double convert(enum values v) noexcept
>   {
>     switch (v)
>     {
>     case one:
>       return 1.0;
>     case two:
>       return 2.0;
>     }
>   }
>
> The switch statement does not contain a default case, because we want
> a compiler warning if we add another enumerator and forget to handle it
> in the switch statement.
>
> Unfortunately, the above code also causes the compiler to warn that
> there is no return after the switch statement. With an unreachable
> attribute we can get the compiler warnings only when we want them.
>

Sure, I think the point is that if we made it a blessed standard library
function (instead of an attribute) and you wrote:

  double convert(values v) noexcept
  {
    switch (v)
    {
    case one:
      return 1.0;
    case two:
      return 2.0;
    }
    std::unreachable();
  }

You would:

   1. Get no warning. (like an attribute)
   2. In the case someone calls convert(values(one | two)), you would get
predictable (perhaps even configurable) behavior, and not undefined
behavior.

For no-default enum switch instances like this, we also need to consider
the following use case:

  1. A new enumerator is added to the enumeration definition (eg three).
  2. The switch has been forgotten to be updated.

We would like to get a warning that the switch needs to be updated with the
new enumerator.  We need to be mindful of any interactions between
unreachable statements and this case.

Also I see you marked this noexcept.  This would interact with whether or
not unreachable can throw an exception, and needs consideration.

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

--047d7beb9ec4f8a03c0523f7401c
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 Sat, Nov 7, 2015 at 6:40 PM, Bjorn Reese <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:breese@mail1.stofanet.dk" target=3D"_blank">breese@mail1.stofa=
net.dk</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,20=
4,204);border-left-style:solid;padding-left:1ex"><span>On 11/07/2015 04:53 =
PM, Daniel Kr=C3=BCgler wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
? If so, this sounds to me like an odd use case for attributes.<br>
</blockquote>
<br></span>
Consider the following example:<br>
<br>
=C2=A0 enum values { one, two };<br>
<br>
=C2=A0 double convert(enum values v) noexcept<br>
=C2=A0 {<br>
=C2=A0 =C2=A0 switch (v)<br>
=C2=A0 =C2=A0 {<br>
=C2=A0 =C2=A0 case one:<br>
=C2=A0 =C2=A0 =C2=A0 return 1.0;<br>
=C2=A0 =C2=A0 case two:<br>
=C2=A0 =C2=A0 =C2=A0 return 2.0;<br>
=C2=A0 =C2=A0 }<br>
=C2=A0 }<br>
<br>
The switch statement does not contain a default case, because we want<br>
a compiler warning if we add another enumerator and forget to handle it<br>
in the switch statement.<br>
<br>
Unfortunately, the above code also causes the compiler to warn that<br>
there is no return after the switch statement. With an unreachable<br>
attribute we can get the compiler warnings only when we want them.<div><div=
></div></div></blockquote></div><br></div><div class=3D"gmail_extra">Sure, =
I think the point is that if we made it a blessed standard library function=
 (instead of an attribute) and you wrote:</div><div class=3D"gmail_extra"><=
br></div><div class=3D"gmail_extra">=C2=A0 double convert(values v) noexcep=
t<br>=C2=A0 {<br>=C2=A0 =C2=A0 switch (v)<br>=C2=A0 =C2=A0 {<br>=C2=A0 =C2=
=A0 case one:<br>=C2=A0 =C2=A0 =C2=A0 return 1.0;<br>=C2=A0 =C2=A0 case two=
:<br>=C2=A0 =C2=A0 =C2=A0 return 2.0;<br>=C2=A0 =C2=A0 }</div><div class=3D=
"gmail_extra">=C2=A0 =C2=A0 std::unreachable();<br>=C2=A0 }<br></div><div c=
lass=3D"gmail_extra"><br></div><div class=3D"gmail_extra">You would:</div><=
div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">=C2=A0 =C2=
=A01. Get no warning. (like an attribute)</div><div class=3D"gmail_extra">=
=C2=A0 =C2=A02. In the case someone calls convert(values(one | two)), you w=
ould get predictable (perhaps even configurable) behavior, and not undefine=
d behavior.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_e=
xtra">For no-default enum switch instances like this, we also need to consi=
der the following use case:</div><div class=3D"gmail_extra"><br></div><div =
class=3D"gmail_extra">=C2=A0 1. A new enumerator is added to the enumeratio=
n definition (eg three).</div><div class=3D"gmail_extra">=C2=A0 2. The swit=
ch has been forgotten to be updated.</div><div class=3D"gmail_extra"><br></=
div><div class=3D"gmail_extra">We would like to get a warning that the swit=
ch needs to be updated with the new enumerator.=C2=A0 We need to be mindful=
 of any interactions between unreachable statements and this case.</div><di=
v class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Also I see you=
 marked this noexcept.=C2=A0 This would interact with whether or not unreac=
hable can throw an exception, and needs consideration.</div><div class=3D"g=
mail_extra"><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7beb9ec4f8a03c0523f7401c--

.

On Saturday 07 November 2015 17:07:34 Andrew Tomazos wrote:
> As I said in my previous message, I suspect the answer is that we want
> unreachable to do the same thing as an assert(false), as such I think it
> should be a library function like std::unreachable(), possibly marked
> [[noreturn]].  It is unclear if it should terminate or throw an exception
> or result in undefined behaviour.  It could only be an attribute if it had
> no runtime side-effect.

We want the compiler to delete any code paths leading to that unreachable
marker. So there's no termination or exception because, as its name says, that
is not reached, ever.

Unless you meant as a debugging technique. The Q_UNREACHABLE() macro, in debug
mode, is a false assertion saying "unreachable reached" and terminates the
program.

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

.

On Saturday 07 November 2015 08:20:39 Nicol Bolas wrote:
> > Let us call this an unreachable statement and put aside whether or not it
> > is an attribute statement or a statement that has a semantic effect for
> > the  moment.
> >
> > Let us say that the intent of an unreachable statement is to assert that
> > the statement in question shall never be executed.
>
> But that's not the intent of what I was wanting. All I want is a marker to
> tell compilers/static tools that "I really did mean to not return here."
> That's it. Anything more is scope creep.

Actually, it is the same thing.

Since falling off the edge of a function is undefined, if you really meant not
to return from there, it means reaching the closing brace is impossible.
Therefore, the "I'm not returning from here" means "this is unreachable".

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

.

------=_Part_84_1235717856.1446927790539
Content-Type: multipart/alternative;
 boundary="----=_Part_85_317493225.1446927790539"

------=_Part_85_317493225.1446927790539
Content-Type: text/plain; charset=UTF-8

On Saturday, November 7, 2015 at 12:08:59 PM UTC-6, Andrew Tomazos wrote:
>
>
> Sure, I think the point is that if we made it a blessed standard library
> function (instead of an attribute) and you wrote:
>
>   double convert(values v) noexcept
>   {
>     switch (v)
>     {
>     case one:
>       return 1.0;
>     case two:
>       return 2.0;
>     }
>     std::unreachable();
>   }
>
> You would:
>
>    1. Get no warning. (like an attribute)
>    2. In the case someone calls convert(values(one | two)), you would get
> predictable (perhaps even configurable) behavior, and not undefined
> behavior.
>
> For no-default enum switch instances like this, we also need to consider
> the following use case:
>
>   1. A new enumerator is added to the enumeration definition (eg three).
>   2. The switch has been forgotten to be updated.
>

Ironically enough, we can write this function today: [[noreturn]] inline
void unreachable() {}
Of course, now the problem is to keep the compiler from warning about the
fact that unreachable returns despite being declared [[noreturn]].

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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_85_317493225.1446927790539
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Saturday, November 7, 2015 at 12:08:59 PM UTC-6, Andrew Tomazos wrote:<b=
lockquote 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"><br><div>Sure, =
I think the point is that if we made it a blessed standard library function=
 (instead of an attribute) and you wrote:<br></div><div><br></div><div>=C2=
=A0 double convert(values v) noexcept<br>=C2=A0 {<br>=C2=A0 =C2=A0 switch (=
v)<br>=C2=A0 =C2=A0 {<br>=C2=A0 =C2=A0 case one:<br>=C2=A0 =C2=A0 =C2=A0 re=
turn 1.0;<br>=C2=A0 =C2=A0 case two:<br>=C2=A0 =C2=A0 =C2=A0 return 2.0;<br=
>=C2=A0 =C2=A0 }</div><div>=C2=A0 =C2=A0 std::unreachable();<br>=C2=A0 }<br=
></div><div><br></div><div>You would:</div><div><br></div><div>=C2=A0 =C2=
=A01. Get no warning. (like an attribute)</div><div>=C2=A0 =C2=A02. In the =
case someone calls convert(values(one | two)), you would get predictable (p=
erhaps even configurable) behavior, and not undefined behavior.</div><div><=
br></div><div>For no-default enum switch instances like this, we also need =
to consider the following use case:</div><div><br></div><div>=C2=A0 1. A ne=
w enumerator is added to the enumeration definition (eg three).</div><div>=
=C2=A0 2. The switch has been forgotten to be updated.</div></div></blockqu=
ote><div><br></div><div>Ironically enough, we can write this function today=
: <font face=3D"courier new, monospace">[[noreturn]] inline void unreachabl=
e() {}</font></div><div>Of course, now the problem is to keep the compiler =
from warning about the fact that <font face=3D"courier new, monospace">unre=
achable </font>returns despite being declared <font face=3D"courier new, mo=
nospace">[[noreturn]]</font>.</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_85_317493225.1446927790539--
------=_Part_84_1235717856.1446927790539--

.

On Saturday 07 November 2015 12:23:10 Casey Carter wrote:
> Ironically enough, we can write this function today: [[noreturn]] inline
> void unreachable() {}
> Of course, now the problem is to keep the compiler from warning about the
> fact that unreachable returns despite being declared [[noreturn]].

It either needs a compiler-specific token to indicate that the code is
unreachable or it needs to call another [[noreturn]] function.

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

.

------=_Part_4101_1746742765.1447108369513
Content-Type: multipart/alternative;
 boundary="----=_Part_4102_542508872.1447108369514"

------=_Part_4102_542508872.1447108369514
Content-Type: text/plain; charset=UTF-8

On Saturday, November 7, 2015 at 9:17:22 AM UTC-8, dgutson wrote:
>
> > But that's not the intent of what I was wanting. All I want is a marker
> to tell compilers/static tools that "I really did mean to not return here."
> That's it. Anything more is scope creep.
>
> I am a very big fan of attributes (my team wrote almost 10 gcc extensions
> based on them, successfully improving static analysis on real life mission
> critical code).
> However, in this case I do prefer Andrews's suggestion, because: 1) as he
> suggests, this may (or may not) have runtime comsequences (we could even
> have an unreacheable_handler() with its setter, a la uncaught_handler)
> enabling runtime consistency checks and even allowing the user to decide
> weather to abort() or take a different action; and 2) this is perfectly
> understandable by static checkers (what's the difference in a checker's
> parser to handle a std function call and an attribute?).
>
>
>
Essentially, [[unreachable]] would be defined as "the behavior of executing
a statement containing the [[unreachable]] attribute is undefined".  That's
pretty much what GCC/Clang's __builtin_unreachable() and Visual C++'s
__assume(false) do.  Often, these compilers will place a trap opcode at
these locations, such as int3 for the x86 case.  Or they will change the
code flow based on the assumption that the statement never executes.
Either one is within the purview of "undefined behavior".

For compilers that don't implement [[unreachable]] and thus ignore it,
executing the statement properly falls within "undefined behavior" as well.

I suppose that the Standard could put a non-normative Note that
[[unreachable]] is intended to suppress implementation-defined diagnostics
regarding code paths that lead to undefined behavior (such as falling off
the end of a non-void function).

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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_4102_542508872.1447108369514
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Saturday, November 7, 2015 at 9:17:22 AM UTC-8, dgutson wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr">&gt; But that&#39;s not t=
he intent of what I was wanting. All I want is a marker to tell compilers/s=
tatic tools that &quot;I really did mean to not return here.&quot; That&#39=
;s it. Anything more is scope creep.</p>
<p dir=3D"ltr">I am a very big fan of attributes (my team wrote almost 10 g=
cc extensions based on them, successfully improving static analysis on real=
 life mission critical code).<br>
However, in this case I do prefer Andrews&#39;s suggestion, because: 1) as =
he suggests, this may (or may not) have runtime comsequences (we could even=
 have an unreacheable_handler() with its setter, a la uncaught_handler) ena=
bling runtime consistency checks and even allowing the user to decide weath=
er to abort() or take a different action; and 2) this is perfectly understa=
ndable by static checkers (what&#39;s the difference in a checker&#39;s par=
ser to handle a std function call and an attribute?).<br></p>
<p dir=3D"ltr"><br></p></blockquote><div><br>Essentially, [[unreachable]] w=
ould be defined as &quot;the behavior of executing a statement containing t=
he [[unreachable]] attribute is undefined&quot;.=C2=A0 That&#39;s pretty mu=
ch what GCC/Clang&#39;s __builtin_unreachable() and Visual C++&#39;s __assu=
me(false) do.=C2=A0 Often, these compilers will place a trap opcode at thes=
e locations, such as int3 for the x86 case.=C2=A0 Or they will change the c=
ode flow based on the assumption that the statement never executes.=C2=A0 E=
ither one is within the purview of &quot;undefined behavior&quot;.<br><br>F=
or compilers that don&#39;t implement [[unreachable]] and thus ignore it, e=
xecuting the statement properly falls within &quot;undefined behavior&quot;=
 as well.<br><br>I suppose that the Standard could put a non-normative Note=
 that [[unreachable]] is intended to suppress implementation-defined diagno=
stics regarding code paths that lead to undefined behavior (such as falling=
 off the end of a non-void function).<br><br>Melissa<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4102_542508872.1447108369514--
------=_Part_4101_1746742765.1447108369513--

.

--001a1144010a8c260c0524237154
Content-Type: text/plain; charset=UTF-8

On 9 November 2015 at 16:32, Myriachan <myriachan@gmail.com> wrote:

> Essentially, [[unreachable]] would be defined as "the behavior of
> executing a statement containing the [[unreachable]] attribute is
> undefined".


That definition sounds like a semantic effect to me...
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1144010a8c260c0524237154
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">On 9 November 2015 at 16:32, My=
riachan <span dir=3D"ltr">&lt;<a href=3D"mailto:myriachan@gmail.com" target=
=3D"_blank">myriachan@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">Essentially, [[unreachable]] would =
be defined as &quot;the behavior of executing a statement containing the [[=
unreachable]] attribute is undefined&quot;.</blockquote></div><br>That defi=
nition sounds like a semantic effect to me...</div><div class=3D"gmail_extr=
a">-- <br><div class=3D"gmail_signature">=C2=A0Nevin &quot;:-)&quot; Liber=
=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blan=
k">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-1404</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1144010a8c260c0524237154--

.

--089e0103f05863f02b05242392b9
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 9, 2015 at 11:51 PM, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 9 November 2015 at 16:32, Myriachan <myriachan@gmail.com> wrote:
>
>> Essentially, [[unreachable]] would be defined as "the behavior of
>> executing a statement containing the [[unreachable]] attribute is
>> undefined".
>
>
> That definition sounds like a semantic effect to me...
>

[[noreturn]] causes undefined behavior.  Some consider undefined behavior a
semantic effect, some don't.

(Having said that, I still don't see the benefit of a UB [[unreachable]]
attribute statement over having an std::unreachable() statement causing
some well-defined runtime error.)

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--089e0103f05863f02b05242392b9
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, Nov 9, 2015 at 11:51 PM, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.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"><div c=
lass=3D"gmail_extra"><span class=3D"">On 9 November 2015 at 16:32, Myriacha=
n <span dir=3D"ltr">&lt;<a href=3D"mailto:myriachan@gmail.com" target=3D"_b=
lank">myriachan@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">Essentially, [[unreachable]] would be def=
ined as &quot;the behavior of executing a statement containing the [[unreac=
hable]] attribute is undefined&quot;.</blockquote></div><br></span>That def=
inition sounds like a semantic effect to me...</div></div></blockquote><div=
><br></div><div>[[noreturn]] causes undefined behavior.=C2=A0 Some consider=
 undefined behavior a semantic effect, some don&#39;t.</div><div><br></div>=
<div>(Having said that, I still don&#39;t see the benefit of a UB [[unreach=
able]] attribute statement over having an std::unreachable() statement caus=
ing some well-defined runtime error.)</div><div><br></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0103f05863f02b05242392b9--

.

------=_Part_4144_873700424.1447110146435
Content-Type: multipart/alternative;
 boundary="----=_Part_4145_1573417382.1447110146435"

------=_Part_4145_1573417382.1447110146435
Content-Type: text/plain; charset=UTF-8

On Monday, November 9, 2015 at 2:52:13 PM UTC-8, Nevin ":-)" Liber wrote:
>
> On 9 November 2015 at 16:32, Myriachan <myri...@gmail.com <javascript:>>
> wrote:
>
>> Essentially, [[unreachable]] would be defined as "the behavior of
>> executing a statement containing the [[unreachable]] attribute is
>> undefined".
>
>
> That definition sounds like a semantic effect to me...
>
>
So does the definition of the existing [[noreturn]] attribute:

If a function f is called where f was previously declared with the noreturn
> attribute and f eventually returns, the behavior is undefined.
>

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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_4145_1573417382.1447110146435
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, November 9, 2015 at 2:52:13 PM UTC-8, Nevin &qu=
ot;:-)&quot; Liber 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>On 9 November 2015 at 16:32, Myriachan <span dir=3D"ltr">&=
lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"PiyBO=
0mvFgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;=
return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">my=
ri...@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">Essentially, [[unreachable]] would be defined as &q=
uot;the behavior of executing a statement containing the [[unreachable]] at=
tribute is undefined&quot;.</blockquote></div><br>That definition sounds li=
ke a semantic effect to me...</div><div><br></div></div></blockquote><div><=
br>So does the definition of the existing [[noreturn]] attribute:<br><br><b=
lockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(20=
4, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">If a function f is =
called where f was previously declared with the noreturn attribute and f ev=
entually returns, the behavior is undefined.<br></blockquote><div><br>Melis=
sa <br></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4145_1573417382.1447110146435--
------=_Part_4144_873700424.1447110146435--

.

--001a1143c04e0926c7052423995f
Content-Type: text/plain; charset=UTF-8

On Tue, Nov 10, 2015 at 12:01 AM, Andrew Tomazos <andrewtomazos@gmail.com>
wrote:

> On Mon, Nov 9, 2015 at 11:51 PM, Nevin Liber <nevin@eviloverlord.com>
> wrote:
>
>> On 9 November 2015 at 16:32, Myriachan <myriachan@gmail.com> wrote:
>>
>>> Essentially, [[unreachable]] would be defined as "the behavior of
>>> executing a statement containing the [[unreachable]] attribute is
>>> undefined".
>>
>>
>> That definition sounds like a semantic effect to me...
>>
>
> [[noreturn]] causes undefined behavior.  Some consider undefined behavior
> a semantic effect, some don't.
>

The confusion arises because whether or not undefined behavior has a
semantic effect is unspecified. :) lol

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--001a1143c04e0926c7052423995f
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 Tue, Nov 10, 2015 at 12:01 AM, Andrew Tomazos <span dir=3D"ltr">&lt;=
<a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@=
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"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=
=3D"">On Mon, Nov 9, 2015 at 11:51 PM, Nevin Liber <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlor=
d.com</a>&gt;</span> wrote:<br><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"><div class=3D"gmail_extra"><span>On 9 November 2015 at 16:32, Myriachan=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:myriachan@gmail.com" target=3D"_bl=
ank">myriachan@gmail.com</a>&gt;</span> wrote:<br><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">Essentially, [[unreachable]] would be defi=
ned as &quot;the behavior of executing a statement containing the [[unreach=
able]] attribute is undefined&quot;.</blockquote></div><br></span>That defi=
nition sounds like a semantic effect to me...</div></div></blockquote><div>=
<br></div></span><div>[[noreturn]] causes undefined behavior.=C2=A0 Some co=
nsider undefined behavior a semantic effect, some don&#39;t.</div></div></d=
iv></div></blockquote><div><br></div><div>The confusion arises because whet=
her or not undefined behavior has a semantic effect is unspecified. :) lol<=
/div><div>=C2=A0</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1143c04e0926c7052423995f--

.

On Tuesday, November 10, 2015 12:01:21 AM Andrew Tomazos wrote:
> On Mon, Nov 9, 2015 at 11:51 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> > On 9 November 2015 at 16:32, Myriachan <myriachan@gmail.com> wrote:
> >> Essentially, [[unreachable]] would be defined as "the behavior of
> >> executing a statement containing the [[unreachable]] attribute is
> >> undefined".
> >
> > That definition sounds like a semantic effect to me...
>
> [[noreturn]] causes undefined behavior.  Some consider undefined behavior a
> semantic effect, some don't.
>
> (Having said that, I still don't see the benefit of a UB [[unreachable]]
> attribute statement over having an std::unreachable() statement causing
> some well-defined runtime error.)

I remember using __assume(false) in a switch/case branch so that the compiler
knew that a certain case or cases never happen. The compiler would then be
able to optimize the code better as it would be able to remove the checks and
branching instructions for these cases altogether. I suspect that would not be
possible with std::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_1620_1614033344.1447110810734
Content-Type: multipart/alternative;
 boundary="----=_Part_1621_1708131591.1447110810735"

------=_Part_1621_1708131591.1447110810735
Content-Type: text/plain; charset=UTF-8

On Monday, November 9, 2015 at 3:01:24 PM UTC-8, Andrew Tomazos wrote:
>
> On Mon, Nov 9, 2015 at 11:51 PM, Nevin Liber <ne...@eviloverlord.com
> <javascript:>> wrote:
>
>> On 9 November 2015 at 16:32, Myriachan <myri...@gmail.com <javascript:>>
>> wrote:
>>
>>> Essentially, [[unreachable]] would be defined as "the behavior of
>>> executing a statement containing the [[unreachable]] attribute is
>>> undefined".
>>
>>
>> That definition sounds like a semantic effect to me...
>>
>
> [[noreturn]] causes undefined behavior.  Some consider undefined behavior
> a semantic effect, some don't.
>
>
An attribute resulting in undefined behavior has the convenient property
that on an implementation that doesn't understand the attribute and thus
ignores it, the implementation is still compliant: "continue executing
normally as if nothing happened" is within the definition of "undefined
behavior".


> (Having said that, I still don't see the benefit of a UB [[unreachable]]
> attribute statement over having an std::unreachable() statement causing
> some well-defined runtime error.)
>
>
switch (day)
{
    case Days::SATURDAY:
    case Days::SUNDAY:
        Weekend();
        break;
    case Days::MONDAY:
    case Days::TUESDAY:
    case Days::WEDNESDAY:
    case Days::THURSDAY:
    case Days::FRIDAY:
        Weekday();
        break;
    default:
        [[unreachable]];
}



mov eax, [rcx + 12]
cmp eax, 7
jae call_error_function
lea rdx, [rel jump_table]
jmp qword [rdx + rax * 8]

The "cmp eax" and "jae call_error_function" aren't necessary with
[[unreachable]].

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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1621_1708131591.1447110810735
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Monday, November 9, 2015 at 3:01:24 PM UTC-8, Andrew Tomazos wrote:<bloc=
kquote 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><div class=3D=
"gmail_quote">On Mon, Nov 9, 2015 at 11:51 PM, Nevin Liber <span dir=3D"ltr=
">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Sx=
9bYcmvFgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#3=
9;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;"=
>ne...@eviloverlord.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"><div><span>On 9 November 2015 at 16:32, Myriachan <sp=
an dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated=
-mailto=3D"Sx9bYcmvFgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;j=
avascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;=
return true;">myri...@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">Essentially, [[unreachable]] would =
be defined as &quot;the behavior of executing a statement containing the [[=
unreachable]] attribute is undefined&quot;.</blockquote></div><br></span>Th=
at definition sounds like a semantic effect to me...</div></div></blockquot=
e><div><br></div><div>[[noreturn]] causes undefined behavior.=C2=A0 Some co=
nsider undefined behavior a semantic effect, some don&#39;t.</div><div><br>=
</div></div></div></div></blockquote><div><br>An attribute resulting in und=
efined behavior has the convenient property that on an implementation that =
doesn&#39;t understand the attribute and thus ignores it, the implementatio=
n is still compliant: &quot;continue executing normally as if nothing happe=
ned&quot; is within the definition of &quot;undefined behavior&quot;.<br>=
=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><div class=3D"gmail_quote"><div></div><div>(Having said that, I still d=
on&#39;t see the benefit of a UB [[unreachable]] attribute statement over h=
aving an std::unreachable() statement causing some well-defined runtime err=
or.)</div><div><br></div></div></div></div></blockquote><div><br><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">switch</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">day</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">case</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Days</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">SATURDAY</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">case</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">Days</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">SUNDAY</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #60=
6;" class=3D"styled-by-prettify">Weekend</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">break</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">case</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" cla=
ss=3D"styled-by-prettify">Days</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">MONDAY</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">case</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Days</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">TUESDAY</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>=C2=A0 =C2=A0 </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">case</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">Days</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">WEDNESDAY</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">case</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettif=
y">Days</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">THURSDAY</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">case</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Days</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">FRIDAY</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">Weekday</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">break</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">default</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">[[</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">unreachable</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"co=
lor: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br><br></span></div></code></div><br><br><=
div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bo=
rder-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; wor=
d-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettypri=
nt"><span style=3D"color: #000;" class=3D"styled-by-prettify">mov eax</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">[</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">rcx </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">+</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pr=
ettify">12</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
]</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>cmp e=
ax</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #066;" class=3D"styled-by-prettify">7</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>jae call_error_function<br>lea =
rdx</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">rel jump_table</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">]</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>jmp qword </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">[</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">rdx </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">+</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> rax </span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">8</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">]</span></div>=
</code></div><br>The &quot;cmp eax&quot; and &quot;jae call_error_function&=
quot; aren&#39;t necessary with [[unreachable]].<br><br>Melissa<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1621_1708131591.1447110810735--
------=_Part_1620_1614033344.1447110810734--

.

--001a11497420fc9382052423cc85
Content-Type: text/plain; charset=UTF-8

On Tue, Nov 10, 2015 at 12:09 AM, Andrey Semashev <andrey.semashev@gmail.com
> wrote:

> On Tuesday, November 10, 2015 12:01:21 AM Andrew Tomazos wrote:
> > On Mon, Nov 9, 2015 at 11:51 PM, Nevin Liber <nevin@eviloverlord.com>
> wrote:
> > > On 9 November 2015 at 16:32, Myriachan <myriachan@gmail.com> wrote:
> > >> Essentially, [[unreachable]] would be defined as "the behavior of
> > >> executing a statement containing the [[unreachable]] attribute is
> > >> undefined".
> > >
> > > That definition sounds like a semantic effect to me...
> >
> > [[noreturn]] causes undefined behavior.  Some consider undefined
> behavior a
> > semantic effect, some don't.
> >
> > (Having said that, I still don't see the benefit of a UB [[unreachable]]
> > attribute statement over having an std::unreachable() statement causing
> > some well-defined runtime error.)
>
> I remember using __assume(false) in a switch/case branch so that the
> compiler
> knew that a certain case or cases never happen. The compiler would then be
> able to optimize the code better as it would be able to remove the checks
> and
> branching instructions for these cases altogether. I suspect that would
> not be
> possible with std::unreachable().


A std::unreachable() standard library call can necessarily do everything
that an attribute statement does and more.  So, no it is possible.

I think the right approach would be to first design exactly what we want an
unreachable statement to do - and then once that is decided, we can look at
whether it is a better fit as a library function or attribute.

It sounds like there are tradeoffs here between it being an optimization
tool, a static analysis tool, and/or a runtime diagnostic tool.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--001a11497420fc9382052423cc85
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 Tue, Nov 10, 2015 at 12:09 AM, Andrey Semashev <span dir=3D"ltr">&lt=
;<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.sema=
shev@gmail.com</a>&gt;</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=
 class=3D"HOEnZb"><div class=3D"h5">On Tuesday, November 10, 2015 12:01:21 =
AM Andrew Tomazos wrote:<br>
&gt; On Mon, Nov 9, 2015 at 11:51 PM, Nevin Liber &lt;<a href=3D"mailto:nev=
in@eviloverlord.com">nevin@eviloverlord.com</a>&gt; wrote:<br>
&gt; &gt; On 9 November 2015 at 16:32, Myriachan &lt;<a href=3D"mailto:myri=
achan@gmail.com">myriachan@gmail.com</a>&gt; wrote:<br>
&gt; &gt;&gt; Essentially, [[unreachable]] would be defined as &quot;the be=
havior of<br>
&gt; &gt;&gt; executing a statement containing the [[unreachable]] attribut=
e is<br>
&gt; &gt;&gt; undefined&quot;.<br>
&gt; &gt;<br>
&gt; &gt; That definition sounds like a semantic effect to me...<br>
&gt;<br>
&gt; [[noreturn]] causes undefined behavior.=C2=A0 Some consider undefined =
behavior a<br>
&gt; semantic effect, some don&#39;t.<br>
&gt;<br>
&gt; (Having said that, I still don&#39;t see the benefit of a UB [[unreach=
able]]<br>
&gt; attribute statement over having an std::unreachable() statement causin=
g<br>
&gt; some well-defined runtime error.)<br>
<br>
</div></div>I remember using __assume(false) in a switch/case branch so tha=
t the compiler<br>
knew that a certain case or cases never happen. The compiler would then be<=
br>
able to optimize the code better as it would be able to remove the checks a=
nd<br>
branching instructions for these cases altogether. I suspect that would not=
 be<br>
possible with std::unreachable().</blockquote><div><br></div><div>A std::un=
reachable() standard library call can necessarily do everything that an att=
ribute statement does and more.=C2=A0 So, no it is possible.</div><div><br>=
</div><div>I think the right approach would be to first design exactly what=
 we want an unreachable statement to do - and then once that is decided, we=
 can look at whether it is a better fit as a library function or attribute.=
</div><div><br></div><div>It sounds like there are tradeoffs here between i=
t being an optimization tool, a static analysis tool, and/or a runtime diag=
nostic tool.</div><div><br></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11497420fc9382052423cc85--

.

--001a114420d017108c052424d8aa
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 9, 2015 at 2:51 PM, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 9 November 2015 at 16:32, Myriachan <myriachan@gmail.com> wrote:
>
>> Essentially, [[unreachable]] would be defined as "the behavior of
>> executing a statement containing the [[unreachable]] attribute is
>> undefined".
>
>
> That definition sounds like a semantic effect to me...
>

Ignoring all occurrences of the [[unreachable]] attribute would be a
correct implementation of it, so I think it still satisfies our
weakly-established criteria for what an attribute can do.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--001a114420d017108c052424d8aa
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, Nov 9, 2015 at 2:51 PM, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.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 cl=
ass=3D"gmail_extra"><span class=3D"">On 9 November 2015 at 16:32, Myriachan=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:myriachan@gmail.com" target=3D"_bl=
ank">myriachan@gmail.com</a>&gt;</span> wrote:<br><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">Essentially, [[unreachable]] would be defi=
ned as &quot;the behavior of executing a statement containing the [[unreach=
able]] attribute is undefined&quot;.</blockquote></div><br></span>That defi=
nition sounds like a semantic effect to me...</div></div></blockquote><div>=
<br></div><div>Ignoring all occurrences of the [[unreachable]] attribute wo=
uld be a correct implementation of it, so I think it still satisfies our we=
akly-established criteria for what an attribute can do.=C2=A0</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a114420d017108c052424d8aa--

.

On Tuesday, November 10, 2015 12:17:44 AM Andrew Tomazos wrote:
> On Tue, Nov 10, 2015 at 12:09 AM, Andrey Semashev <andrey.semashev@gmail.com
> > wrote:
> >
> > I remember using __assume(false) in a switch/case branch so that the
> > compiler
> > knew that a certain case or cases never happen. The compiler would then be
> > able to optimize the code better as it would be able to remove the checks
> > and
> > branching instructions for these cases altogether. I suspect that would
> > not be
> > possible with std::unreachable().
>
> A std::unreachable() standard library call can necessarily do everything
> that an attribute statement does and more.  So, no it is possible.

My concern is that to make that library call the compiler would have to
compile all cases, which nullifies the effect of optimization. I guess the
optimization would only be possible if std::unreachable() was an intrinsic
function that has no side effects (i.e. a no-op).

> I think the right approach would be to first design exactly what we want an
> unreachable statement to do - and then once that is decided, we can look at
> whether it is a better fit as a library function or attribute.
>
> It sounds like there are tradeoffs here between it being an optimization
> tool, a static analysis tool, and/or a runtime diagnostic tool.

I think as a runtime tool it has little use - we can already use
std::terminate() to catch unexpected cases now.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

.

--089e0103e8a4f9266e05242568d2
Content-Type: text/plain; charset=UTF-8

On Tue, Nov 10, 2015 at 1:43 AM, Andrey Semashev <andrey.semashev@gmail.com>
wrote:

> On Tuesday, November 10, 2015 12:17:44 AM Andrew Tomazos wrote:
> > On Tue, Nov 10, 2015 at 12:09 AM, Andrey Semashev <
> andrey.semashev@gmail.com
> > > wrote:
> > >
> > > I remember using __assume(false) in a switch/case branch so that the
> > > compiler
> > > knew that a certain case or cases never happen. The compiler would
> then be
> > > able to optimize the code better as it would be able to remove the
> checks
> > > and
> > > branching instructions for these cases altogether. I suspect that would
> > > not be
> > > possible with std::unreachable().
> >
> > A std::unreachable() standard library call can necessarily do everything
> > that an attribute statement does and more.  So, no it is possible.
>
> My concern is that to make that library call the compiler would have to
> compile all cases, which nullifies the effect of optimization. I guess the
> optimization would only be possible if std::unreachable() was an intrinsic
> function that has no side effects (i.e. a no-op).
>
> > I think the right approach would be to first design exactly what we want
> an
> > unreachable statement to do - and then once that is decided, we can look
> at
> > whether it is a better fit as a library function or attribute.
> >
> > It sounds like there are tradeoffs here between it being an optimization
> > tool, a static analysis tool, and/or a runtime diagnostic tool.
>
> I think as a runtime tool it has little use - we can already use
> std::terminate() to catch unexpected cases now.


The use is in the case you get it wrong, and an unreachable statement, is
reached.  The question is, what happens then?

Options are:

- Nothing.  The statement is a no-op.
- Undefined behavior.
- An exception is thrown.
- std::terminate is called.
- A user-defined handler is called.
- Configurably one of the above.
- Something else?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--089e0103e8a4f9266e05242568d2
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 Tue, Nov 10, 2015 at 1:43 AM, Andrey Semashev <span dir=3D"ltr">&lt;=
<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semas=
hev@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span=
 class=3D"">On Tuesday, November 10, 2015 12:17:44 AM Andrew Tomazos wrote:=
<br>
&gt; On Tue, Nov 10, 2015 at 12:09 AM, Andrey Semashev &lt;<a href=3D"mailt=
o:andrey.semashev@gmail.com">andrey.semashev@gmail.com</a><br>
&gt; &gt; wrote:<br>
&gt; &gt;<br>
</span><span class=3D"">&gt; &gt; I remember using __assume(false) in a swi=
tch/case branch so that the<br>
&gt; &gt; compiler<br>
&gt; &gt; knew that a certain case or cases never happen. The compiler woul=
d then be<br>
&gt; &gt; able to optimize the code better as it would be able to remove th=
e checks<br>
&gt; &gt; and<br>
&gt; &gt; branching instructions for these cases altogether. I suspect that=
 would<br>
&gt; &gt; not be<br>
&gt; &gt; possible with std::unreachable().<br>
&gt;<br>
&gt; A std::unreachable() standard library call can necessarily do everythi=
ng<br>
&gt; that an attribute statement does and more.=C2=A0 So, no it is possible=
..<br>
<br>
</span>My concern is that to make that library call the compiler would have=
 to<br>
compile all cases, which nullifies the effect of optimization. I guess the<=
br>
optimization would only be possible if std::unreachable() was an intrinsic<=
br>
function that has no side effects (i.e. a no-op).<br>
<span class=3D""><br>
&gt; I think the right approach would be to first design exactly what we wa=
nt an<br>
&gt; unreachable statement to do - and then once that is decided, we can lo=
ok at<br>
&gt; whether it is a better fit as a library function or attribute.<br>
&gt;<br>
&gt; It sounds like there are tradeoffs here between it being an optimizati=
on<br>
&gt; tool, a static analysis tool, and/or a runtime diagnostic tool.<br>
<br>
</span>I think as a runtime tool it has little use - we can already use<br>
std::terminate() to catch unexpected cases now.</blockquote><div><br></div>=
<div>The use is in the case you get it wrong, and an unreachable statement,=
 is reached.=C2=A0 The question is, what happens then?</div><div><br></div>=
<div>Options are:</div><div><br></div><div>- Nothing.=C2=A0 The statement i=
s a no-op.</div><div>- Undefined behavior.</div><div>- An exception is thro=
wn.</div><div>- std::terminate is called.</div><div>- A user-defined handle=
r is called.</div><div>- Configurably one of the above.</div><div>- Somethi=
ng else?<br></div><div><br></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0103e8a4f9266e05242568d2--

.

On Tuesday 10 November 2015 02:09:02 Andrey Semashev wrote:
> I remember using __assume(false) in a switch/case branch so that the
> compiler  knew that a certain case or cases never happen. The compiler
> would then be able to optimize the code better as it would be able to
> remove the checks and branching instructions for these cases altogether. I
> suspect that would not be possible with std::unreachable().

Why not?
--
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/.

.

On Tuesday 10 November 2015 02:12:56 Andrew Tomazos wrote:
> Options are:
>
> - Nothing.  The statement is a no-op.
> - Undefined behavior.
> - An exception is thrown.
> - std::terminate is called.
> - A user-defined handler is called.
> - Configurably one of the above.
> - Something else?

My preference: undefined behaviour. For two reasons:

1) it matches what happens if a [[noreturn]] function does return (undefined
behaviour)

2) it allows the implementation to do any of the other options if it wants to,
like in UBSAN mode.

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

.

On 2015-11-10 04:27, Thiago Macieira wrote:
> On Tuesday 10 November 2015 02:09:02 Andrey Semashev wrote:
>> I remember using __assume(false) in a switch/case branch so that the
>> compiler  knew that a certain case or cases never happen. The compiler
>> would then be able to optimize the code better as it would be able to
>> remove the checks and branching instructions for these cases altogether. I
>> suspect that would not be possible with std::unreachable().
>
> Why not?

Because if that function is allowed to have side effects the compiler
will have to compile the code leading to its call.


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

.

--001a1142789ec080b605242e53e0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

El 9/11/2015 22:12, "Andrew Tomazos" <andrewtomazos@gmail.com> escribi=C3=
=B3:
>
>
>
> On Tue, Nov 10, 2015 at 1:43 AM, Andrey Semashev <
andrey.semashev@gmail.com> wrote:
>>
>> On Tuesday, November 10, 2015 12:17:44 AM Andrew Tomazos wrote:
>> > On Tue, Nov 10, 2015 at 12:09 AM, Andrey Semashev <
andrey.semashev@gmail.com
>> > > wrote:
>> > >
>> > > I remember using __assume(false) in a switch/case branch so that the
>> > > compiler
>> > > knew that a certain case or cases never happen. The compiler would
then be
>> > > able to optimize the code better as it would be able to remove the
checks
>> > > and
>> > > branching instructions for these cases altogether. I suspect that
would
>> > > not be
>> > > possible with std::unreachable().
>> >
>> > A std::unreachable() standard library call can necessarily do
everything
>> > that an attribute statement does and more.  So, no it is possible.
>>
>> My concern is that to make that library call the compiler would have to
>> compile all cases, which nullifies the effect of optimization. I guess
the
>> optimization would only be possible if std::unreachable() was an
intrinsic
>> function that has no side effects (i.e. a no-op).
>>
>> > I think the right approach would be to first design exactly what we
want an
>> > unreachable statement to do - and then once that is decided, we can
look at
>> > whether it is a better fit as a library function or attribute.
>> >
>> > It sounds like there are tradeoffs here between it being an
optimization
>> > tool, a static analysis tool, and/or a runtime diagnostic tool.
>>
>> I think as a runtime tool it has little use - we can already use
>> std::terminate() to catch unexpected cases now.
>
>
> The use is in the case you get it wrong, and an unreachable statement, is
reached.  The question is, what happens then?
>
> Options are:
>
> - Nothing.  The statement is a no-op.
> - Undefined behavior.
> - An exception is thrown.
> - std::terminate is called.
> - A user-defined handler is called.
Throwing an exception or calling std::terminate() are covered by this
option, which could default to call terminate.

Again, nothing prevents static analyzers and even optimizers to do the same
analysis whereas this is an attribute or a specific function call.

> - Configurably one of the above.
> - Something else?
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving 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/.

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

--001a1142789ec080b605242e53e0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
El 9/11/2015 22:12, &quot;Andrew Tomazos&quot; &lt;<a href=3D"mailto:andrew=
tomazos@gmail.com">andrewtomazos@gmail.com</a>&gt; escribi=C3=B3:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Nov 10, 2015 at 1:43 AM, Andrey Semashev &lt;<a href=3D"mailto=
:andrey.semashev@gmail.com">andrey.semashev@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Tuesday, November 10, 2015 12:17:44 AM Andrew Tomazos wrote:<br=
>
&gt;&gt; &gt; On Tue, Nov 10, 2015 at 12:09 AM, Andrey Semashev &lt;<a href=
=3D"mailto:andrey.semashev@gmail.com">andrey.semashev@gmail.com</a><br>
&gt;&gt; &gt; &gt; wrote:<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; I remember using __assume(false) in a switch/case branch=
 so that the<br>
&gt;&gt; &gt; &gt; compiler<br>
&gt;&gt; &gt; &gt; knew that a certain case or cases never happen. The comp=
iler would then be<br>
&gt;&gt; &gt; &gt; able to optimize the code better as it would be able to =
remove the checks<br>
&gt;&gt; &gt; &gt; and<br>
&gt;&gt; &gt; &gt; branching instructions for these cases altogether. I sus=
pect that would<br>
&gt;&gt; &gt; &gt; not be<br>
&gt;&gt; &gt; &gt; possible with std::unreachable().<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; A std::unreachable() standard library call can necessarily do=
 everything<br>
&gt;&gt; &gt; that an attribute statement does and more.=C2=A0 So, no it is=
 possible.<br>
&gt;&gt;<br>
&gt;&gt; My concern is that to make that library call the compiler would ha=
ve to<br>
&gt;&gt; compile all cases, which nullifies the effect of optimization. I g=
uess the<br>
&gt;&gt; optimization would only be possible if std::unreachable() was an i=
ntrinsic<br>
&gt;&gt; function that has no side effects (i.e. a no-op).<br>
&gt;&gt;<br>
&gt;&gt; &gt; I think the right approach would be to first design exactly w=
hat we want an<br>
&gt;&gt; &gt; unreachable statement to do - and then once that is decided, =
we can look at<br>
&gt;&gt; &gt; whether it is a better fit as a library function or attribute=
..<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; It sounds like there are tradeoffs here between it being an o=
ptimization<br>
&gt;&gt; &gt; tool, a static analysis tool, and/or a runtime diagnostic too=
l.<br>
&gt;&gt;<br>
&gt;&gt; I think as a runtime tool it has little use - we can already use<b=
r>
&gt;&gt; std::terminate() to catch unexpected cases now.<br>
&gt;<br>
&gt;<br>
&gt; The use is in the case you get it wrong, and an unreachable statement,=
 is reached.=C2=A0 The question is, what happens then?<br>
&gt;<br>
&gt; Options are:<br>
&gt;<br>
&gt; - Nothing.=C2=A0 The statement is a no-op.<br>
&gt; - Undefined behavior.<br>
&gt; - An exception is thrown.<br>
&gt; - std::terminate is called.<br>
&gt; - A user-defined handler is called.<br>
Throwing an exception or calling std::terminate() are covered by this optio=
n, which could default to call terminate.</p>
<p dir=3D"ltr">Again, nothing prevents static analyzers and even optimizers=
 to do the same analysis whereas this is an attribute or a specific functio=
n call.<br></p>
<p dir=3D"ltr">&gt; - Configurably one of the above.<br>
&gt; - Something else?<br>
&gt;<br>
&gt; -- <br>
&gt;<br>
&gt; --- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-propos=
als/</a>.<br>
</p>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1142789ec080b605242e53e0--

.

--001a11c36b2ad1da8205243601de
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 10, 2015 at 6:51 AM, dgutson . <danielgutson@gmail.com> wrote:

>
> El 9/11/2015 22:12, "Andrew Tomazos" <andrewtomazos@gmail.com> escribi=C3=
=B3:
> >
> >
> >
> > On Tue, Nov 10, 2015 at 1:43 AM, Andrey Semashev <
> andrey.semashev@gmail.com> wrote:
> >>
> >> On Tuesday, November 10, 2015 12:17:44 AM Andrew Tomazos wrote:
> >> > On Tue, Nov 10, 2015 at 12:09 AM, Andrey Semashev <
> andrey.semashev@gmail.com
> >> > >The compiler would then be
> >> > > able to optimize the code better as it would be able to remove the
> checks
> >> > > and
> >> > > branching instructions for these cases altogether. I suspect that
> would
> >> > > not be
> >> > > possible with std::unreachable().
> >> >
> >> > A std::unreachable() standard library call can necessarily do
> everything
> >> > that an attribute statement does and more.  So, no it is possible.
> >>
> >
> > Options are:
> >
> > - Nothing.  The statement is a no-op.
> > - Undefined behavior.
> > - An exception is thrown.
> > - std::terminate is called.
> > - A user-defined handler is called.
> Throwing an exception or calling std::terminate() are covered by this
> option, which could default to call terminate.
>
> Again, nothing prevents static analyzers and even optimizers to do the
> same analysis whereas this is an attribute or a specific function call.
>
> > - Configurably one of the above.
> > - Something else?
> >
>

Just to be clear about what some others are trying to point out:


switch (day)
{
    case Days::SATURDAY:
    case Days::SUNDAY:
        Weekend();
        break;
    case Days::MONDAY:
    case Days::TUESDAY:
    case Days::WEDNESDAY:
    case Days::THURSDAY:
    case Days::FRIDAY:
        Weekday();
        break;
    default:
        std::unreachable();
}

If std::unreachable() is defined to
- throw an exception
- std::terminate
- or be configurable

Then the above code can't be optimized.  In particular, I can write
"correct" code that purposely passes in a bad 'day' so that an exception is
thrown and then catch that exception and continue. If we _define_ it to
throw an exception (or call my handler, etc), then it better throw an
exception (or call my handler, etc).

However, if we leave it as undefined behaviour, then the code can be
removed/optimized.  And optionally an implementation can offer various
behaviours.

Tony

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

--001a11c36b2ad1da8205243601de
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 Tue, Nov 10, 2015 at 6:51 AM, dgutson . <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:danielgutson@gmail.com" target=3D"_blank">danielgutson@gmail.co=
m</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><p dir=3D"ltr"></p><div><div class=3D"h5"><br>
El 9/11/2015 22:12, &quot;Andrew Tomazos&quot; &lt;<a href=3D"mailto:andrew=
tomazos@gmail.com" target=3D"_blank">andrewtomazos@gmail.com</a>&gt; escrib=
i=C3=B3:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Nov 10, 2015 at 1:43 AM, Andrey Semashev &lt;<a href=3D"mailto=
:andrey.semashev@gmail.com" target=3D"_blank">andrey.semashev@gmail.com</a>=
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Tuesday, November 10, 2015 12:17:44 AM Andrew Tomazos wrote:<br=
>
&gt;&gt; &gt; On Tue, Nov 10, 2015 at 12:09 AM, Andrey Semashev &lt;<a href=
=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semashev@gma=
il.com</a><br>
&gt;&gt; &gt; &gt;The compiler would then be<br>
&gt;&gt; &gt; &gt; able to optimize the code better as it would be able to =
remove the checks<br>
&gt;&gt; &gt; &gt; and<br>
&gt;&gt; &gt; &gt; branching instructions for these cases altogether. I sus=
pect that would<br>
&gt;&gt; &gt; &gt; not be<br>
&gt;&gt; &gt; &gt; possible with std::unreachable().<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; A std::unreachable() standard library call can necessarily do=
 everything<br>
&gt;&gt; &gt; that an attribute statement does and more.=C2=A0 So, no it is=
 possible.<br>
&gt;&gt;<br>&gt;<br>
&gt; Options are:<br>
&gt;<br>
&gt; - Nothing.=C2=A0 The statement is a no-op.<br>
&gt; - Undefined behavior.<br>
&gt; - An exception is thrown.<br>
&gt; - std::terminate is called.<br>
&gt; - A user-defined handler is called.<br></div></div>
Throwing an exception or calling std::terminate() are covered by this optio=
n, which could default to call terminate.<p></p>
<p dir=3D"ltr">Again, nothing prevents static analyzers and even optimizers=
 to do the same analysis whereas this is an attribute or a specific functio=
n call.<br></p><div class=3D""><div class=3D"h5">
<p dir=3D"ltr">&gt; - Configurably one of the above.<br>
&gt; - Something else?<br>
&gt;<br></p></div></div></blockquote></div><br></div><div class=3D"gmail_ex=
tra">Just to be clear about what some others are trying to point out:<br><b=
r><br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,=
187,187);border-style:solid;border-width:1px;word-wrap:break-word"><code><d=
iv><span style=3D"color:rgb(0,0,136)">switch</span><span style=3D"color:rgb=
(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">(</span><span style=
=3D"color:rgb(0,0,0)">day</span><span style=3D"color:rgb(102,102,0)">)</spa=
n><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(102,=
102,0)">{</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><=
span style=3D"color:rgb(0,0,136)">case</span><span style=3D"color:rgb(0,0,0=
)"> </span><span style=3D"color:rgb(102,0,102)">Days</span><span style=3D"c=
olor:rgb(102,102,0)">::</span><span style=3D"color:rgb(0,0,0)"><span tabind=
ex=3D"0" class=3D""><span class=3D"">SATURDAY</span></span></span><span sty=
le=3D"color:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0,0)"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,0,136)">case</span><span st=
yle=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,0,102)">Days<=
/span><span style=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rg=
b(0,0,0)"><span tabindex=3D"0" class=3D""><span class=3D"">SUNDAY</span></s=
pan></span><span style=3D"color:rgb(102,102,0)">:</span><span style=3D"colo=
r:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:r=
gb(102,0,102)">Weekend</span><span style=3D"color:rgb(102,102,0)">();</span=
><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><s=
pan style=3D"color:rgb(0,0,136)">break</span><span style=3D"color:rgb(102,1=
02,0)">;</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><s=
pan style=3D"color:rgb(0,0,136)">case</span><span style=3D"color:rgb(0,0,0)=
"> </span><span style=3D"color:rgb(102,0,102)">Days</span><span style=3D"co=
lor:rgb(102,102,0)">::</span><span style=3D"color:rgb(0,0,0)">MONDAY</span>=
<span style=3D"color:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0,0=
)"><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,0,136)">case</span><=
span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,0,102)=
">Days</span><span style=3D"color:rgb(102,102,0)">::</span><span style=3D"c=
olor:rgb(0,0,0)"><span tabindex=3D"0" class=3D""><span class=3D"">TUESDAY</=
span></span></span><span style=3D"color:rgb(102,102,0)">:</span><span style=
=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,0=
,136)">case</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"c=
olor:rgb(102,0,102)">Days</span><span style=3D"color:rgb(102,102,0)">::</sp=
an><span style=3D"color:rgb(0,0,0)"><span tabindex=3D"0" class=3D""><span c=
lass=3D"">WEDNESDAY</span></span></span><span style=3D"color:rgb(102,102,0)=
">:</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span s=
tyle=3D"color:rgb(0,0,136)">case</span><span style=3D"color:rgb(0,0,0)"> </=
span><span style=3D"color:rgb(102,0,102)">Days</span><span style=3D"color:r=
gb(102,102,0)">::</span><span style=3D"color:rgb(0,0,0)"><span tabindex=3D"=
0" class=3D""><span class=3D"">THURSDAY</span></span></span><span style=3D"=
color:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color:rgb(0,0,136)">case</span><span style=3D"=
color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,0,102)">Days</span><=
span style=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rgb(0,0,0=
)"><span tabindex=3D"0" class=3D""><span class=3D"">FRIDAY</span></span></s=
pan><span style=3D"color:rgb(102,102,0)">:</span><span style=3D"color:rgb(0=
,0,0)"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:rgb(102,=
0,102)">Weekday</span><span style=3D"color:rgb(102,102,0)">();</span><span =
style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span sty=
le=3D"color:rgb(0,0,136)">break</span><span style=3D"color:rgb(102,102,0)">=
;</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span sty=
le=3D"color:rgb(0,0,136)">default</span><span style=3D"color:rgb(102,102,0)=
">:</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
</span><span style=3D"color:rgb(102,102,0)">std::unreachable()</span><span =
style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br=
></span><span style=3D"color:rgb(102,102,0)">}</span><span style=3D"color:r=
gb(0,0,0)"><br></span></div></code></div><br></div><div class=3D"gmail_extr=
a">If std::unreachable() is defined to <br></div><div class=3D"gmail_extra"=
>- throw an exception<br></div>- std::terminate<br><div class=3D"gmail_extr=
a"><div class=3D"gmail_extra">- or be configurable<br><br></div></div><div =
class=3D"gmail_extra">Then the above code can&#39;t be optimized.=C2=A0 In =
particular, I can write &quot;correct&quot; code that purposely passes in a=
 bad &#39;day&#39; so that an exception is thrown and then catch that excep=
tion and continue. If we _define_ it to throw an exception (or call my hand=
ler, etc), then it better throw an exception (or call my handler, etc).<br>=
<br></div><div class=3D"gmail_extra">However, if we leave it as undefined b=
ehaviour, then the code can be removed/optimized.=C2=A0 And optionally an i=
mplementation can offer various behaviours.<br><br></div><div class=3D"gmai=
l_extra">Tony<br></div><div class=3D"gmail_extra"><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c36b2ad1da8205243601de--

.

--089e0103f058981ee805243656cb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 10, 2015 at 10:01 PM, Tony V E <tvaneerd@gmail.com> wrote:

>
>
> On Tue, Nov 10, 2015 at 6:51 AM, dgutson . <danielgutson@gmail.com> wrote=
:
>
>>
>> El 9/11/2015 22:12, "Andrew Tomazos" <andrewtomazos@gmail.com> escribi=
=C3=B3:
>> >
>> >
>> >
>> > On Tue, Nov 10, 2015 at 1:43 AM, Andrey Semashev <
>> andrey.semashev@gmail.com> wrote:
>> >>
>> >> On Tuesday, November 10, 2015 12:17:44 AM Andrew Tomazos wrote:
>> >> > On Tue, Nov 10, 2015 at 12:09 AM, Andrey Semashev <
>> andrey.semashev@gmail.com
>> >> > >The compiler would then be
>> >> > > able to optimize the code better as it would be able to remove th=
e
>> checks
>> >> > > and
>> >> > > branching instructions for these cases altogether. I suspect that
>> would
>> >> > > not be
>> >> > > possible with std::unreachable().
>> >> >
>> >> > A std::unreachable() standard library call can necessarily do
>> everything
>> >> > that an attribute statement does and more.  So, no it is possible.
>> >>
>> >
>> > Options are:
>> >
>> > - Nothing.  The statement is a no-op.
>> > - Undefined behavior.
>> > - An exception is thrown.
>> > - std::terminate is called.
>> > - A user-defined handler is called.
>> Throwing an exception or calling std::terminate() are covered by this
>> option, which could default to call terminate.
>>
>> Again, nothing prevents static analyzers and even optimizers to do the
>> same analysis whereas this is an attribute or a specific function call.
>>
>> > - Configurably one of the above.
>> > - Something else?
>> >
>>
>
> Just to be clear about what some others are trying to point out:
>
>
> switch (day)
> {
>     case Days::SATURDAY:
>     case Days::SUNDAY:
>         Weekend();
>         break;
>     case Days::MONDAY:
>     case Days::TUESDAY:
>     case Days::WEDNESDAY:
>     case Days::THURSDAY:
>     case Days::FRIDAY:
>         Weekday();
>         break;
>     default:
>         std::unreachable();
> }
>
> If std::unreachable() is defined to
> - throw an exception
> - std::terminate
> - or be configurable
>
> Then the above code can't be optimized.  In particular, I can write
> "correct" code that purposely passes in a bad 'day' so that an exception =
is
> thrown and then catch that exception and continue. If we _define_ it to
> throw an exception (or call my handler, etc), then it better throw an
> exception (or call my handler, etc).
>
> However, if we leave it as undefined behaviour, then the code can be
> removed/optimized.  And optionally an implementation can offer various
> behaviours.
>

If we pick the configurable option, and the configuration is made at
compile-time, one of the configuration options could result in undefined
behavior (and encourage optimizing the code out).  For example they may
want this behavior in release build, but in debug build they want to get a
handler called (that prints a stack trace say and then gracefully crashes).

It's hard to get excited about the optimization, though.  We're talking one
(unlikely-marked) branch and a few bytes of code size.

Getting rid of undefined behavior on the other hand, has a whole SG
dedicated to it.

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

--089e0103f058981ee805243656cb
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 Tue, Nov 10, 2015 at 10:01 PM, Tony V E <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@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"><br><div=
 class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span class=3D"">On T=
ue, Nov 10, 2015 at 6:51 AM, dgutson . <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:danielgutson@gmail.com" target=3D"_blank">danielgutson@gmail.com</a>&gt=
;</span> wrote:<br></span><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
><p dir=3D"ltr"></p><div><div><span class=3D""><br>
El 9/11/2015 22:12, &quot;Andrew Tomazos&quot; &lt;<a href=3D"mailto:andrew=
tomazos@gmail.com" target=3D"_blank">andrewtomazos@gmail.com</a>&gt; escrib=
i=C3=B3:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Nov 10, 2015 at 1:43 AM, Andrey Semashev &lt;<a href=3D"mailto=
:andrey.semashev@gmail.com" target=3D"_blank">andrey.semashev@gmail.com</a>=
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Tuesday, November 10, 2015 12:17:44 AM Andrew Tomazos wrote:<br=
>
&gt;&gt; &gt; On Tue, Nov 10, 2015 at 12:09 AM, Andrey Semashev &lt;<a href=
=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semashev@gma=
il.com</a><br></span><span class=3D"">
&gt;&gt; &gt; &gt;The compiler would then be<br>
&gt;&gt; &gt; &gt; able to optimize the code better as it would be able to =
remove the checks<br>
&gt;&gt; &gt; &gt; and<br>
&gt;&gt; &gt; &gt; branching instructions for these cases altogether. I sus=
pect that would<br>
&gt;&gt; &gt; &gt; not be<br>
&gt;&gt; &gt; &gt; possible with std::unreachable().<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; A std::unreachable() standard library call can necessarily do=
 everything<br>
&gt;&gt; &gt; that an attribute statement does and more.=C2=A0 So, no it is=
 possible.<br>
&gt;&gt;<br>&gt;<br></span><span class=3D"">
&gt; Options are:<br>
&gt;<br>
&gt; - Nothing.=C2=A0 The statement is a no-op.<br>
&gt; - Undefined behavior.<br>
&gt; - An exception is thrown.<br>
&gt; - std::terminate is called.<br>
&gt; - A user-defined handler is called.<br></span></div></div><span class=
=3D"">
Throwing an exception or calling std::terminate() are covered by this optio=
n, which could default to call terminate.<p></p>
<p dir=3D"ltr">Again, nothing prevents static analyzers and even optimizers=
 to do the same analysis whereas this is an attribute or a specific functio=
n call.<br></p><div><div>
<p dir=3D"ltr">&gt; - Configurably one of the above.<br>
&gt; - Something else?<br>
&gt;<br></p></div></div></span></blockquote></div><br></div><div class=3D"g=
mail_extra">Just to be clear about what some others are trying to point out=
:<br><br><br><div style=3D"background-color:rgb(250,250,250);border-color:r=
gb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><=
code><div><span class=3D""><span style=3D"color:rgb(0,0,136)">switch</span>=
<span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0=
)">(</span><span style=3D"color:rgb(0,0,0)">day</span><span style=3D"color:=
rgb(102,102,0)">)</span><span style=3D"color:rgb(0,0,0)"><br></span><span s=
tyle=3D"color:rgb(102,102,0)">{</span><span style=3D"color:rgb(0,0,0)"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,0,136)">case</span><span st=
yle=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,0,102)">Days<=
/span><span style=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rg=
b(0,0,0)"><span><span>SATURDAY</span></span></span><span style=3D"color:rgb=
(102,102,0)">:</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </s=
pan><span style=3D"color:rgb(0,0,136)">case</span><span style=3D"color:rgb(=
0,0,0)"> </span><span style=3D"color:rgb(102,0,102)">Days</span><span style=
=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rgb(0,0,0)"><span><=
span>SUNDAY</span></span></span><span style=3D"color:rgb(102,102,0)">:</spa=
n><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><=
span style=3D"color:rgb(102,0,102)">Weekend</span><span style=3D"color:rgb(=
102,102,0)">();</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,0,136)">break</span><span s=
tyle=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,0,136)">case</span><span st=
yle=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,0,102)">Days<=
/span><span style=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rg=
b(0,0,0)">MONDAY</span><span style=3D"color:rgb(102,102,0)">:</span><span s=
tyle=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb=
(0,0,136)">case</span><span style=3D"color:rgb(0,0,0)"> </span><span style=
=3D"color:rgb(102,0,102)">Days</span><span style=3D"color:rgb(102,102,0)">:=
:</span><span style=3D"color:rgb(0,0,0)"><span><span>TUESDAY</span></span><=
/span><span style=3D"color:rgb(102,102,0)">:</span><span style=3D"color:rgb=
(0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,0,136)">case</=
span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,=
0,102)">Days</span><span style=3D"color:rgb(102,102,0)">::</span><span styl=
e=3D"color:rgb(0,0,0)"><span><span>WEDNESDAY</span></span></span><span styl=
e=3D"color:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0,0)"><br>=C2=
=A0 =C2=A0 </span><span style=3D"color:rgb(0,0,136)">case</span><span style=
=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,0,102)">Days</sp=
an><span style=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rgb(0=
,0,0)"><span><span>THURSDAY</span></span></span><span style=3D"color:rgb(10=
2,102,0)">:</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span=
><span style=3D"color:rgb(0,0,136)">case</span><span style=3D"color:rgb(0,0=
,0)"> </span><span style=3D"color:rgb(102,0,102)">Days</span><span style=3D=
"color:rgb(102,102,0)">::</span><span style=3D"color:rgb(0,0,0)"><span><spa=
n>FRIDAY</span></span></span><span style=3D"color:rgb(102,102,0)">:</span><=
span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><spa=
n style=3D"color:rgb(102,0,102)">Weekday</span><span style=3D"color:rgb(102=
,102,0)">();</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 </span><span style=3D"color:rgb(0,0,136)">break</span><span styl=
e=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br>=C2=
=A0 =C2=A0 </span><span style=3D"color:rgb(0,0,136)">default</span><span st=
yle=3D"color:rgb(102,102,0)">:</span></span><span style=3D"color:rgb(0,0,0)=
"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:rgb(102,102,0=
)">std::unreachable()</span><span style=3D"color:rgb(102,102,0)">;</span><s=
pan style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(102,102,=
0)">}</span><span style=3D"color:rgb(0,0,0)"><br></span></div></code></div>=
<br></div><div class=3D"gmail_extra">If std::unreachable() is defined to <b=
r></div><div class=3D"gmail_extra">- throw an exception<br></div>- std::ter=
minate<br><div class=3D"gmail_extra"><div class=3D"gmail_extra">- or be con=
figurable<br><br></div></div><div class=3D"gmail_extra">Then the above code=
 can&#39;t be optimized.=C2=A0 In particular, I can write &quot;correct&quo=
t; code that purposely passes in a bad &#39;day&#39; so that an exception i=
s thrown and then catch that exception and continue. If we _define_ it to t=
hrow an exception (or call my handler, etc), then it better throw an except=
ion (or call my handler, etc).<br><br></div><div class=3D"gmail_extra">Howe=
ver, if we leave it as undefined behaviour, then the code can be removed/op=
timized.=C2=A0 And optionally an implementation can offer various behaviour=
s.</div></div></blockquote></div><br></div><div class=3D"gmail_extra">If we=
 pick the configurable option, and the configuration is made at compile-tim=
e, one of the configuration options could result in undefined behavior (and=
 encourage optimizing the code out).=C2=A0 For example they may want this b=
ehavior in release build, but in debug build they want to get a handler cal=
led (that prints a stack trace say and then gracefully crashes).</div><div =
class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">It&#39;s hard to=
 get excited about the optimization, though.=C2=A0 We&#39;re talking one (u=
nlikely-marked) branch and a few bytes of code size.</div><div class=3D"gma=
il_extra"><br></div><div class=3D"gmail_extra">Getting rid of undefined beh=
avior on the other hand, has a whole SG dedicated to it.</div><div class=3D=
"gmail_extra"><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0103f058981ee805243656cb--

.

------=_Part_2538_1735659628.1447191947011
Content-Type: multipart/alternative;
 boundary="----=_Part_2539_704563806.1447191947012"

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

On Tuesday, November 10, 2015 at 4:24:45 PM UTC-5, Andrew Tomazos wrote:
>
> On Tue, Nov 10, 2015 at 10:01 PM, Tony V E <tvan...@gmail.com=20
> <javascript:>> wrote:
>
>> On Tue, Nov 10, 2015 at 6:51 AM, dgutson . <daniel...@gmail.com=20
>> <javascript:>> wrote:
>>
>>>
>>> El 9/11/2015 22:12, "Andrew Tomazos" <andrew...@gmail.com <javascript:>=
>=20
>>> escribi=C3=B3:
>>> >
>>> >
>>> >
>>> > On Tue, Nov 10, 2015 at 1:43 AM, Andrey Semashev <andrey....@gmail.co=
m=20
>>> <javascript:>> wrote:
>>> >>
>>> >> On Tuesday, November 10, 2015 12:17:44 AM Andrew Tomazos wrote:
>>> >> > On Tue, Nov 10, 2015 at 12:09 AM, Andrey Semashev <
>>> andrey....@gmail.com <javascript:>
>>> >> > >The compiler would then be
>>> >> > > able to optimize the code better as it would be able to remove=
=20
>>> the checks
>>> >> > > and
>>> >> > > branching instructions for these cases altogether. I suspect tha=
t=20
>>> would
>>> >> > > not be
>>> >> > > possible with std::unreachable().
>>> >> >
>>> >> > A std::unreachable() standard library call can necessarily do=20
>>> everything
>>> >> > that an attribute statement does and more.  So, no it is possible.
>>> >>
>>> >
>>> > Options are:
>>> >
>>> > - Nothing.  The statement is a no-op.
>>> > - Undefined behavior.
>>> > - An exception is thrown.
>>> > - std::terminate is called.
>>> > - A user-defined handler is called.
>>> Throwing an exception or calling std::terminate() are covered by this=
=20
>>> option, which could default to call terminate.
>>>
>>> Again, nothing prevents static analyzers and even optimizers to do the=
=20
>>> same analysis whereas this is an attribute or a specific function call.
>>>
>>> > - Configurably one of the above.
>>> > - Something else?
>>> >
>>>
>>
>> Just to be clear about what some others are trying to point out:
>>
>>
>> switch (day)
>> {
>>     case Days::SATURDAY:
>>     case Days::SUNDAY:
>>         Weekend();
>>         break;
>>     case Days::MONDAY:
>>     case Days::TUESDAY:
>>     case Days::WEDNESDAY:
>>     case Days::THURSDAY:
>>     case Days::FRIDAY:
>>         Weekday();
>>         break;
>>     default:
>>         std::unreachable();
>> }
>>
>> If std::unreachable() is defined to=20
>> - throw an exception
>> - std::terminate
>> - or be configurable
>>
>> Then the above code can't be optimized.  In particular, I can write=20
>> "correct" code that purposely passes in a bad 'day' so that an exception=
 is=20
>> thrown and then catch that exception and continue. If we _define_ it to=
=20
>> throw an exception (or call my handler, etc), then it better throw an=20
>> exception (or call my handler, etc).
>>
>> However, if we leave it as undefined behaviour, then the code can be=20
>> removed/optimized.  And optionally an implementation can offer various=
=20
>> behaviours.
>>
>
> If we pick the configurable option, and the configuration is made at=20
> compile-time, one of the configuration options could result in undefined=
=20
> behavior (and encourage optimizing the code out).  For example they may=
=20
> want this behavior in release build, but in debug build they want to get =
a=20
> handler called (that prints a stack trace say and then gracefully crashes=
).
>
> It's hard to get excited about the optimization, though.  We're talking=
=20
> one (unlikely-marked) branch and a few bytes of code size.
>
> Getting rid of undefined behavior on the other hand, has a whole SG=20
> dedicated to it.
>
>
Here's the thing: there's no such thing in the C++ standard as a=20
"configurable option". There are only 3 options: standard-defined behavior,=
=20
implementation-defined behavior, and un-defined behavior. All those=20
compiler switches you have? Those either deal with something outside of the=
=20
standard, define how the compiler deals with implementation/undefined=20
behavior, or specifies behavior that is against what the standard requires.

In all cases, they're not something that is a part of the standard. So the=
=20
best thing the standard can do is say "undefined behavior", thus allowing=
=20
specific implementations to decide whether to define it or not.

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

On Tuesday, November 10, 2015 at 4:24:45 PM UTC-5, Andrew Tomazos wrote:<bl=
ockquote 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 Tue, Nov 10, 2015 at 10:01 PM, Tony V E <span dir=3D"lt=
r">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"N=
pkAvxf5FgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#=
39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;=
">tvan...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" 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"><span>On Tue, Nov 10, 201=
5 at 6:51 AM, dgutson . <span dir=3D"ltr">&lt;<a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"NpkAvxf5FgAJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;">daniel...@gmail.com</a>&gt;</span>=
 wrote:<br></span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir=
=3D"ltr"></p><div><div><span><br>
El 9/11/2015 22:12, &quot;Andrew Tomazos&quot; &lt;<a href=3D"javascript:" =
target=3D"_blank" gdf-obfuscated-mailto=3D"NpkAvxf5FgAJ" rel=3D"nofollow" o=
nmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"th=
is.href=3D&#39;javascript:&#39;;return true;">andrew...@gmail.com</a>&gt; e=
scribi=C3=B3:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Nov 10, 2015 at 1:43 AM, Andrey Semashev &lt;<a href=3D"javasc=
ript:" target=3D"_blank" gdf-obfuscated-mailto=3D"NpkAvxf5FgAJ" rel=3D"nofo=
llow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclic=
k=3D"this.href=3D&#39;javascript:&#39;;return true;">andrey....@gmail.com</=
a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Tuesday, November 10, 2015 12:17:44 AM Andrew Tomazos wrote:<br=
>
&gt;&gt; &gt; On Tue, Nov 10, 2015 at 12:09 AM, Andrey Semashev &lt;<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"NpkAvxf5FgAJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">andrey....@g=
mail.com</a><br></span><span>
&gt;&gt; &gt; &gt;The compiler would then be<br>
&gt;&gt; &gt; &gt; able to optimize the code better as it would be able to =
remove the checks<br>
&gt;&gt; &gt; &gt; and<br>
&gt;&gt; &gt; &gt; branching instructions for these cases altogether. I sus=
pect that would<br>
&gt;&gt; &gt; &gt; not be<br>
&gt;&gt; &gt; &gt; possible with std::unreachable().<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; A std::unreachable() standard library call can necessarily do=
 everything<br>
&gt;&gt; &gt; that an attribute statement does and more.=C2=A0 So, no it is=
 possible.<br>
&gt;&gt;<br>&gt;<br></span><span>
&gt; Options are:<br>
&gt;<br>
&gt; - Nothing.=C2=A0 The statement is a no-op.<br>
&gt; - Undefined behavior.<br>
&gt; - An exception is thrown.<br>
&gt; - std::terminate is called.<br>
&gt; - A user-defined handler is called.<br></span></div></div><span>
Throwing an exception or calling std::terminate() are covered by this optio=
n, which could default to call terminate.<p></p>
<p dir=3D"ltr">Again, nothing prevents static analyzers and even optimizers=
 to do the same analysis whereas this is an attribute or a specific functio=
n call.<br></p><div><div>
<p dir=3D"ltr">&gt; - Configurably one of the above.<br>
&gt; - Something else?<br>
&gt;<br></p></div></div></span></blockquote></div><br></div><div>Just to be=
 clear about what some others are trying to point out:<br><br><br><div styl=
e=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border=
-style:solid;border-width:1px;word-wrap:break-word"><code><div><span><span =
style=3D"color:rgb(0,0,136)">switch</span><span style=3D"color:rgb(0,0,0)">=
 </span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:r=
gb(0,0,0)">day</span><span style=3D"color:rgb(102,102,0)">)</span><span sty=
le=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(102,102,0)">{</=
span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color:rgb(0,0,136)">case</span><span style=3D"color:rgb(0,0,0)"> </span=
><span style=3D"color:rgb(102,0,102)">Days</span><span style=3D"color:rgb(1=
02,102,0)">::</span><span style=3D"color:rgb(0,0,0)"><span><span>SATURDAY</=
span></span></span><span style=3D"color:rgb(102,102,0)">:</span><span style=
=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,0=
,136)">case</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"c=
olor:rgb(102,0,102)">Days</span><span style=3D"color:rgb(102,102,0)">::</sp=
an><span style=3D"color:rgb(0,0,0)"><span><span>SUNDAY</span></span></span>=
<span style=3D"color:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0,0=
)"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:rgb(102,0,10=
2)">Weekend</span><span style=3D"color:rgb(102,102,0)">();</span><span styl=
e=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=
=3D"color:rgb(0,0,136)">break</span><span style=3D"color:rgb(102,102,0)">;<=
/span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color:rgb(0,0,136)">case</span><span style=3D"color:rgb(0,0,0)"> </span=
><span style=3D"color:rgb(102,0,102)">Days</span><span style=3D"color:rgb(1=
02,102,0)">::</span><span style=3D"color:rgb(0,0,0)">MONDAY</span><span sty=
le=3D"color:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0,0)"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,0,136)">case</span><span st=
yle=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,0,102)">Days<=
/span><span style=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rg=
b(0,0,0)"><span><span>TUESDAY</span></span></span><span style=3D"color:rgb(=
102,102,0)">:</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </sp=
an><span style=3D"color:rgb(0,0,136)">case</span><span style=3D"color:rgb(0=
,0,0)"> </span><span style=3D"color:rgb(102,0,102)">Days</span><span style=
=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rgb(0,0,0)"><span><=
span>WEDNESDAY</span></span></span><span style=3D"color:rgb(102,102,0)">:</=
span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color:rgb(0,0,136)">case</span><span style=3D"color:rgb(0,0,0)"> </span=
><span style=3D"color:rgb(102,0,102)">Days</span><span style=3D"color:rgb(1=
02,102,0)">::</span><span style=3D"color:rgb(0,0,0)"><span><span>THURSDAY</=
span></span></span><span style=3D"color:rgb(102,102,0)">:</span><span style=
=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,0=
,136)">case</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"c=
olor:rgb(102,0,102)">Days</span><span style=3D"color:rgb(102,102,0)">::</sp=
an><span style=3D"color:rgb(0,0,0)"><span><span>FRIDAY</span></span></span>=
<span style=3D"color:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0,0=
)"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:rgb(102,0,10=
2)">Weekday</span><span style=3D"color:rgb(102,102,0)">();</span><span styl=
e=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=
=3D"color:rgb(0,0,136)">break</span><span style=3D"color:rgb(102,102,0)">;<=
/span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color:rgb(0,0,136)">default</span><span style=3D"color:rgb(102,102,0)">=
:</span></span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 </span><span style=3D"color:rgb(102,102,0)">std::unreachable()</span=
><span style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,=
0)"><br></span><span style=3D"color:rgb(102,102,0)">}</span><span style=3D"=
color:rgb(0,0,0)"><br></span></div></code></div><br></div><div>If std::unre=
achable() is defined to <br></div><div>- throw an exception<br></div>- std:=
:terminate<br><div><div>- or be configurable<br><br></div></div><div>Then t=
he above code can&#39;t be optimized.=C2=A0 In particular, I can write &quo=
t;correct&quot; code that purposely passes in a bad &#39;day&#39; so that a=
n exception is thrown and then catch that exception and continue. If we _de=
fine_ it to throw an exception (or call my handler, etc), then it better th=
row an exception (or call my handler, etc).<br><br></div><div>However, if w=
e leave it as undefined behaviour, then the code can be removed/optimized.=
=C2=A0 And optionally an implementation can offer various behaviours.</div>=
</div></blockquote></div><br></div><div>If we pick the configurable option,=
 and the configuration is made at compile-time, one of the configuration op=
tions could result in undefined behavior (and encourage optimizing the code=
 out).=C2=A0 For example they may want this behavior in release build, but =
in debug build they want to get a handler called (that prints a stack trace=
 say and then gracefully crashes).</div><div><br></div><div>It&#39;s hard t=
o get excited about the optimization, though.=C2=A0 We&#39;re talking one (=
unlikely-marked) branch and a few bytes of code size.</div><div><br></div><=
div>Getting rid of undefined behavior on the other hand, has a whole SG ded=
icated to it.</div><div><br></div></div></blockquote><div><br>Here&#39;s th=
e thing: there&#39;s no such thing in the C++ standard as a &quot;configura=
ble option&quot;. There are only 3 options: standard-defined behavior, impl=
ementation-defined behavior, and un-defined behavior. All those compiler sw=
itches you have? Those either deal with something outside of the standard, =
define how the compiler deals with implementation/undefined behavior, or sp=
ecifies behavior that is against what the standard requires.<br><br>In all =
cases, they&#39;re not something that is a part of the standard. So the bes=
t thing the standard can do is say &quot;undefined behavior&quot;, thus all=
owing specific implementations to decide whether to define it or not.<br></=
div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2539_704563806.1447191947012--
------=_Part_2538_1735659628.1447191947011--

.

--001a1143c04e94cd7c0524370136
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 10, 2015 at 10:45 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Tuesday, November 10, 2015 at 4:24:45 PM UTC-5, Andrew Tomazos wrote:
>>
>> On Tue, Nov 10, 2015 at 10:01 PM, Tony V E <tvan...@gmail.com> wrote:
>>
>>> On Tue, Nov 10, 2015 at 6:51 AM, dgutson . <daniel...@gmail.com> wrote:
>>>
>>>>
>>>> El 9/11/2015 22:12, "Andrew Tomazos" <andrew...@gmail.com> escribi=C3=
=B3:
>>>> >
>>>> >
>>>> >
>>>> > On Tue, Nov 10, 2015 at 1:43 AM, Andrey Semashev <
>>>> andrey....@gmail.com> wrote:
>>>> >>
>>>> >> On Tuesday, November 10, 2015 12:17:44 AM Andrew Tomazos wrote:
>>>> >> > On Tue, Nov 10, 2015 at 12:09 AM, Andrey Semashev <
>>>> andrey....@gmail.com
>>>> >> > >The compiler would then be
>>>> >> > > able to optimize the code better as it would be able to remove
>>>> the checks
>>>> >> > > and
>>>> >> > > branching instructions for these cases altogether. I suspect
>>>> that would
>>>> >> > > not be
>>>> >> > > possible with std::unreachable().
>>>> >> >
>>>> >> > A std::unreachable() standard library call can necessarily do
>>>> everything
>>>> >> > that an attribute statement does and more.  So, no it is possible=
..
>>>> >>
>>>> >
>>>> > Options are:
>>>> >
>>>> > - Nothing.  The statement is a no-op.
>>>> > - Undefined behavior.
>>>> > - An exception is thrown.
>>>> > - std::terminate is called.
>>>> > - A user-defined handler is called.
>>>> Throwing an exception or calling std::terminate() are covered by this
>>>> option, which could default to call terminate.
>>>>
>>>> Again, nothing prevents static analyzers and even optimizers to do the
>>>> same analysis whereas this is an attribute or a specific function call=
..
>>>>
>>>> > - Configurably one of the above.
>>>> > - Something else?
>>>> >
>>>>
>>>
>>> Just to be clear about what some others are trying to point out:
>>>
>>>
>>> switch (day)
>>> {
>>>     case Days::SATURDAY:
>>>     case Days::SUNDAY:
>>>         Weekend();
>>>         break;
>>>     case Days::MONDAY:
>>>     case Days::TUESDAY:
>>>     case Days::WEDNESDAY:
>>>     case Days::THURSDAY:
>>>     case Days::FRIDAY:
>>>         Weekday();
>>>         break;
>>>     default:
>>>         std::unreachable();
>>> }
>>>
>>> If std::unreachable() is defined to
>>> - throw an exception
>>> - std::terminate
>>> - or be configurable
>>>
>>> Then the above code can't be optimized.  In particular, I can write
>>> "correct" code that purposely passes in a bad 'day' so that an exceptio=
n is
>>> thrown and then catch that exception and continue. If we _define_ it to
>>> throw an exception (or call my handler, etc), then it better throw an
>>> exception (or call my handler, etc).
>>>
>>> However, if we leave it as undefined behaviour, then the code can be
>>> removed/optimized.  And optionally an implementation can offer various
>>> behaviours.
>>>
>>
>> If we pick the configurable option, and the configuration is made at
>> compile-time, one of the configuration options could result in undefined
>> behavior (and encourage optimizing the code out).  For example they may
>> want this behavior in release build, but in debug build they want to get=
 a
>> handler called (that prints a stack trace say and then gracefully crashe=
s).
>>
>> It's hard to get excited about the optimization, though.  We're talking
>> one (unlikely-marked) branch and a few bytes of code size.
>>
>> Getting rid of undefined behavior on the other hand, has a whole SG
>> dedicated to it.
>>
>>
> Here's the thing: there's no such thing in the C++ standard as a
> "configurable option".
>
>
For example, NDEBUG + assert.h configures at compile-time the behavior of
assert.

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

--001a1143c04e94cd7c0524370136
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 Tue, Nov 10, 2015 at 10:45 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a =
href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;padding-left:1ex">On Tuesday, November 10, 2015 at 4=
:24:45 PM UTC-5, Andrew Tomazos wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(=
204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><di=
v><div class=3D"gmail_quote">On Tue, Nov 10, 2015 at 10:01 PM, Tony V E <sp=
an dir=3D"ltr">&lt;<a rel=3D"nofollow">tvan...@gmail.com</a>&gt;</span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:=
solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><s=
pan>On Tue, Nov 10, 2015 at 6:51 AM, dgutson . <span dir=3D"ltr">&lt;<a rel=
=3D"nofollow">daniel...@gmail.com</a>&gt;</span> wrote:<br></span><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-le=
ft:1ex"><p dir=3D"ltr"></p><div><div><span><br>
El 9/11/2015 22:12, &quot;Andrew Tomazos&quot; &lt;<a rel=3D"nofollow">andr=
ew...@gmail.com</a>&gt; escribi=C3=B3:<span class=3D""><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Nov 10, 2015 at 1:43 AM, Andrey Semashev &lt;<a rel=3D"nofollo=
w">andrey....@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Tuesday, November 10, 2015 12:17:44 AM Andrew Tomazos wrote:<br=
></span>
&gt;&gt; &gt; On Tue, Nov 10, 2015 at 12:09 AM, Andrey Semashev &lt;<a rel=
=3D"nofollow">andrey....@gmail.com</a><br></span><div><div class=3D"h5"><sp=
an>
&gt;&gt; &gt; &gt;The compiler would then be<br>
&gt;&gt; &gt; &gt; able to optimize the code better as it would be able to =
remove the checks<br>
&gt;&gt; &gt; &gt; and<br>
&gt;&gt; &gt; &gt; branching instructions for these cases altogether. I sus=
pect that would<br>
&gt;&gt; &gt; &gt; not be<br>
&gt;&gt; &gt; &gt; possible with std::unreachable().<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; A std::unreachable() standard library call can necessarily do=
 everything<br>
&gt;&gt; &gt; that an attribute statement does and more.=C2=A0 So, no it is=
 possible.<br>
&gt;&gt;<br>&gt;<br></span><span>
&gt; Options are:<br>
&gt;<br>
&gt; - Nothing.=C2=A0 The statement is a no-op.<br>
&gt; - Undefined behavior.<br>
&gt; - An exception is thrown.<br>
&gt; - std::terminate is called.<br>
&gt; - A user-defined handler is called.<br></span></div></div></div></div>=
<div><div class=3D"h5"><span>
Throwing an exception or calling std::terminate() are covered by this optio=
n, which could default to call terminate.<p></p>
<p dir=3D"ltr">Again, nothing prevents static analyzers and even optimizers=
 to do the same analysis whereas this is an attribute or a specific functio=
n call.<br></p><div><div>
<p dir=3D"ltr">&gt; - Configurably one of the above.<br>
&gt; - Something else?<br>
&gt;<br></p></div></div></span></div></div></blockquote></div><br></div><di=
v><div class=3D"h5"><div>Just to be clear about what some others are trying=
 to point out:<br><br><br><div style=3D"border:1px solid rgb(187,187,187);w=
ord-wrap:break-word;background-color:rgb(250,250,250)"><code><div><span><sp=
an style=3D"color:rgb(0,0,136)">switch</span><span style=3D"color:rgb(0,0,0=
)"> </span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"colo=
r:rgb(0,0,0)">day</span><span style=3D"color:rgb(102,102,0)">)</span><span =
style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(102,102,0)">=
{</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span sty=
le=3D"color:rgb(0,0,136)">case</span><span style=3D"color:rgb(0,0,0)"> </sp=
an><span style=3D"color:rgb(102,0,102)">Days</span><span style=3D"color:rgb=
(102,102,0)">::</span><span style=3D"color:rgb(0,0,0)"><span><span>SATURDAY=
</span></span></span><span style=3D"color:rgb(102,102,0)">:</span><span sty=
le=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0=
,0,136)">case</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D=
"color:rgb(102,0,102)">Days</span><span style=3D"color:rgb(102,102,0)">::</=
span><span style=3D"color:rgb(0,0,0)"><span><span>SUNDAY</span></span></spa=
n><span style=3D"color:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0=
,0)"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:rgb(102,0,=
102)">Weekend</span><span style=3D"color:rgb(102,102,0)">();</span><span st=
yle=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=
=3D"color:rgb(0,0,136)">break</span><span style=3D"color:rgb(102,102,0)">;<=
/span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color:rgb(0,0,136)">case</span><span style=3D"color:rgb(0,0,0)"> </span=
><span style=3D"color:rgb(102,0,102)">Days</span><span style=3D"color:rgb(1=
02,102,0)">::</span><span style=3D"color:rgb(0,0,0)">MONDAY</span><span sty=
le=3D"color:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0,0)"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,0,136)">case</span><span st=
yle=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,0,102)">Days<=
/span><span style=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rg=
b(0,0,0)"><span><span>TUESDAY</span></span></span><span style=3D"color:rgb(=
102,102,0)">:</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </sp=
an><span style=3D"color:rgb(0,0,136)">case</span><span style=3D"color:rgb(0=
,0,0)"> </span><span style=3D"color:rgb(102,0,102)">Days</span><span style=
=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rgb(0,0,0)"><span><=
span>WEDNESDAY</span></span></span><span style=3D"color:rgb(102,102,0)">:</=
span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color:rgb(0,0,136)">case</span><span style=3D"color:rgb(0,0,0)"> </span=
><span style=3D"color:rgb(102,0,102)">Days</span><span style=3D"color:rgb(1=
02,102,0)">::</span><span style=3D"color:rgb(0,0,0)"><span><span>THURSDAY</=
span></span></span><span style=3D"color:rgb(102,102,0)">:</span><span style=
=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,0=
,136)">case</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"c=
olor:rgb(102,0,102)">Days</span><span style=3D"color:rgb(102,102,0)">::</sp=
an><span style=3D"color:rgb(0,0,0)"><span><span>FRIDAY</span></span></span>=
<span style=3D"color:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0,0=
)"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:rgb(102,0,10=
2)">Weekday</span><span style=3D"color:rgb(102,102,0)">();</span><span styl=
e=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=
=3D"color:rgb(0,0,136)">break</span><span style=3D"color:rgb(102,102,0)">;<=
/span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color:rgb(0,0,136)">default</span><span style=3D"color:rgb(102,102,0)">=
:</span></span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 </span><span style=3D"color:rgb(102,102,0)">std::unreachable()</span=
><span style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,=
0)"><br></span><span style=3D"color:rgb(102,102,0)">}</span><span style=3D"=
color:rgb(0,0,0)"><br></span></div></code></div><br></div><div>If std::unre=
achable() is defined to <br></div><div>- throw an exception<br></div>- std:=
:terminate<br><div><div>- or be configurable<br><br></div></div><div>Then t=
he above code can&#39;t be optimized.=C2=A0 In particular, I can write &quo=
t;correct&quot; code that purposely passes in a bad &#39;day&#39; so that a=
n exception is thrown and then catch that exception and continue. If we _de=
fine_ it to throw an exception (or call my handler, etc), then it better th=
row an exception (or call my handler, etc).<br><br></div><div>However, if w=
e leave it as undefined behaviour, then the code can be removed/optimized.=
=C2=A0 And optionally an implementation can offer various behaviours.</div>=
</div></div></div></blockquote></div><br></div><div><div class=3D"h5"><div>=
If we pick the configurable option, and the configuration is made at compil=
e-time, one of the configuration options could result in undefined behavior=
 (and encourage optimizing the code out).=C2=A0 For example they may want t=
his behavior in release build, but in debug build they want to get a handle=
r called (that prints a stack trace say and then gracefully crashes).</div>=
<div><br></div><div>It&#39;s hard to get excited about the optimization, th=
ough.=C2=A0 We&#39;re talking one (unlikely-marked) branch and a few bytes =
of code size.</div><div><br></div><div>Getting rid of undefined behavior on=
 the other hand, has a whole SG dedicated to it.</div><div><br></div></div>=
</div></div></blockquote><div><br>Here&#39;s the thing: there&#39;s no such=
 thing in the C++ standard as a &quot;configurable option&quot;.</div><div>=
<br></div></blockquote><div><br></div><div>For example, NDEBUG + assert.h c=
onfigures at compile-time the behavior of assert.</div><div><br></div><div>=
<br></div><div><br></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1143c04e94cd7c0524370136--

.

--047d7b414028db0efd05243703ad
Content-Type: text/plain; charset=UTF-8

On Tue, Nov 10, 2015 at 1:45 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Tuesday, November 10, 2015 at 4:24:45 PM UTC-5, Andrew Tomazos wrote:
>>
>> If we pick the configurable option, and the configuration is made at
>> compile-time, one of the configuration options could result in undefined
>> behavior (and encourage optimizing the code out).  For example they may
>> want this behavior in release build, but in debug build they want to get a
>> handler called (that prints a stack trace say and then gracefully crashes).
>>
>> It's hard to get excited about the optimization, though.  We're talking
>> one (unlikely-marked) branch and a few bytes of code size.
>>
>> Getting rid of undefined behavior on the other hand, has a whole SG
>> dedicated to it.
>>
>>
> Here's the thing: there's no such thing in the C++ standard as a
> "configurable option". There are only 3 options: standard-defined behavior,
> implementation-defined behavior, and un-defined behavior. All those
> compiler switches you have? Those either deal with something outside of the
> standard, define how the compiler deals with implementation/undefined
> behavior, or specifies behavior that is against what the standard requires.
>
> In all cases, they're not something that is a part of the standard. So the
> best thing the standard can do is say "undefined behavior", thus allowing
> specific implementations to decide whether to define it or not.
>

I would have agreed with you prior to Kona, but contracts are basically
going down the configurable route. I don't think anybody talked about exact
wording of how it might be specified in the standard, but the general idea
I gleaned is that things like the ability to provide a run-time
specification of a precondition violation handler would be configurable at
build time. Violations could be UB, but you would be able to build in a way
that lets you register a handler, making behavior upon violation defined,
which then has the trade-offs mentioned in this thread. Though wording
wasn't talked about in detail at Kona, I think the idea of how to specify
this in the standard, without explicitly talking about things like build
options, is that there would be some standard registration function that
lets you specify a hook at run-time, however it would be
implementation-specified whether or not invoking this function *actually*
registers the hook (it might do nothing at all on some implementations, or
it might quick_exit if you try to call it, etc.). This would mean in
practice, without being too explicit, that the ability to register a
handler at run-time can be build-time configurable. You have UB if the
implementation specifies that the registration function doesn't actually
register a handler.

Again, the details of this weren't talked about in detail regarding
contracts a Kona even though there seemed to be agreement that there would
be some kind of configuration available. This is just my personal
interpretation of how it might actually be specified in a sensible manner
in the standard. If this is really the way we'd be moving forward with
contracts, it might be equally acceptable for a facility such as
unreachable. In my personal opinion, I don't think unreachable needs such a
hook, but it might not be outside of the realm of possibility that there is
some kind of a configurable approach that is at least partially endorsed in
the standard.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--047d7b414028db0efd05243703ad
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, Nov 10, 2015 at 1:45 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">On Tuesday, November 10, 2015=
 at 4:24:45 PM UTC-5, Andrew Tomazos wrote:<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><div class=3D"h5"><div>If we pick the configu=
rable option, and the configuration is made at compile-time, one of the con=
figuration options could result in undefined behavior (and encourage optimi=
zing the code out).=C2=A0 For example they may want this behavior in releas=
e build, but in debug build they want to get a handler called (that prints =
a stack trace say and then gracefully crashes).</div><div><br></div><div>It=
&#39;s hard to get excited about the optimization, though.=C2=A0 We&#39;re =
talking one (unlikely-marked) branch and a few bytes of code size.</div><di=
v><br></div><div>Getting rid of undefined behavior on the other hand, has a=
 whole SG dedicated to it.</div><div><br></div></div></div></div></blockquo=
te><div><br>Here&#39;s the thing: there&#39;s no such thing in the C++ stan=
dard as a &quot;configurable option&quot;. There are only 3 options: standa=
rd-defined behavior, implementation-defined behavior, and un-defined behavi=
or. All those compiler switches you have? Those either deal with something =
outside of the standard, define how the compiler deals with implementation/=
undefined behavior, or specifies behavior that is against what the standard=
 requires.<br><br>In all cases, they&#39;re not something that is a part of=
 the standard. So the best thing the standard can do is say &quot;undefined=
 behavior&quot;, thus allowing specific implementations to decide whether t=
o define it or not.</div></blockquote><div><br></div><div>I would have agre=
ed with you prior to Kona, but contracts are basically going down the confi=
gurable route. I don&#39;t think anybody talked about exact wording of how =
it might be specified in the standard, but the general idea I gleaned is th=
at things like the ability to provide a run-time specification of a precond=
ition violation handler would be configurable at build time. Violations cou=
ld be UB, but you would be able to build in a way that lets you register a =
handler, making behavior upon violation defined, which then has the trade-o=
ffs mentioned in this thread. Though wording wasn&#39;t talked about in det=
ail at Kona, I think the idea of how to specify this in the standard, witho=
ut explicitly talking about things like build options, is that there would =
be some standard registration function that lets you specify a hook at run-=
time, however it would be implementation-specified whether or not invoking =
this function <i>actually</i> registers the hook (it might do nothing at al=
l on some implementations, or it might quick_exit if you try to call it, et=
c.). This would mean in practice, without being too explicit, that the abil=
ity to register a handler at run-time can be build-time configurable. You h=
ave UB if the implementation specifies that the registration function doesn=
&#39;t actually register a handler.</div><div><br></div><div>Again, the det=
ails of this weren&#39;t talked about in detail regarding contracts a Kona =
even though there seemed to be agreement that there would be some kind of c=
onfiguration available. This is just my personal interpretation of how it m=
ight actually be specified in a sensible manner in the standard. If this is=
 really the way we&#39;d be moving forward with contracts, it might be equa=
lly acceptable for a facility such as unreachable. In my personal opinion, =
I don&#39;t think unreachable needs such a hook, but it might not be outsid=
e of the realm of possibility that there is some kind of a configurable app=
roach that is at least partially endorsed in the standard.</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b414028db0efd05243703ad--

.

--94eb2c0926321e5e920524372795
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 10, 2015 at 1:24 PM, Andrew Tomazos <andrewtomazos@gmail.com>
wrote:

> On Tue, Nov 10, 2015 at 10:01 PM, Tony V E <tvaneerd@gmail.com> wrote:
>
>> On Tue, Nov 10, 2015 at 6:51 AM, dgutson . <danielgutson@gmail.com>
>> wrote:
>>
>>> El 9/11/2015 22:12, "Andrew Tomazos" <andrewtomazos@gmail.com> escribi=
=C3=B3:
>>> >
>>> >
>>> >
>>> > On Tue, Nov 10, 2015 at 1:43 AM, Andrey Semashev <
>>> andrey.semashev@gmail.com> wrote:
>>> >>
>>> >> On Tuesday, November 10, 2015 12:17:44 AM Andrew Tomazos wrote:
>>> >> > On Tue, Nov 10, 2015 at 12:09 AM, Andrey Semashev <
>>> andrey.semashev@gmail.com
>>> >> > >The compiler would then be
>>> >> > > able to optimize the code better as it would be able to remove
>>> the checks
>>> >> > > and
>>> >> > > branching instructions for these cases altogether. I suspect tha=
t
>>> would
>>> >> > > not be
>>> >> > > possible with std::unreachable().
>>> >> >
>>> >> > A std::unreachable() standard library call can necessarily do
>>> everything
>>> >> > that an attribute statement does and more.  So, no it is possible.
>>> >>
>>> >
>>> > Options are:
>>> >
>>> > - Nothing.  The statement is a no-op.
>>> > - Undefined behavior.
>>> > - An exception is thrown.
>>> > - std::terminate is called.
>>> > - A user-defined handler is called.
>>> Throwing an exception or calling std::terminate() are covered by this
>>> option, which could default to call terminate.
>>>
>>> Again, nothing prevents static analyzers and even optimizers to do the
>>> same analysis whereas this is an attribute or a specific function call.
>>>
>>> > - Configurably one of the above.
>>> > - Something else?
>>> >
>>>
>>
>> Just to be clear about what some others are trying to point out:
>>
>>
>> switch (day)
>> {
>>     case Days::SATURDAY:
>>     case Days::SUNDAY:
>>         Weekend();
>>         break;
>>     case Days::MONDAY:
>>     case Days::TUESDAY:
>>     case Days::WEDNESDAY:
>>     case Days::THURSDAY:
>>     case Days::FRIDAY:
>>         Weekday();
>>         break;
>>     default:
>>         std::unreachable();
>> }
>>
>> If std::unreachable() is defined to
>> - throw an exception
>> - std::terminate
>> - or be configurable
>>
>> Then the above code can't be optimized.  In particular, I can write
>> "correct" code that purposely passes in a bad 'day' so that an exception=
 is
>> thrown and then catch that exception and continue. If we _define_ it to
>> throw an exception (or call my handler, etc), then it better throw an
>> exception (or call my handler, etc).
>>
>> However, if we leave it as undefined behaviour, then the code can be
>> removed/optimized.  And optionally an implementation can offer various
>> behaviours.
>>
>
> If we pick the configurable option, and the configuration is made at
> compile-time, one of the configuration options could result in undefined
> behavior (and encourage optimizing the code out).  For example they may
> want this behavior in release build, but in debug build they want to get =
a
> handler called (that prints a stack trace say and then gracefully crashes=
).
>
> It's hard to get excited about the optimization, though.  We're talking
> one (unlikely-marked) branch and a few bytes of code size.
>
> Getting rid of undefined behavior on the other hand, has a whole SG
> dedicated to it.
>

The purpose of SG12 is to rationalize C++'s handling of undefined behavior,
not to get rid of it.

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

--94eb2c0926321e5e920524372795
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, Nov 10, 2015 at 1:24 PM, Andrew Tomazos <span dir=3D"ltr">&lt;<a href=
=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@gmail.c=
om</a>&gt;</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"ltr"=
><div><div class=3D"h5"><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e">On Tue, Nov 10, 2015 at 10:01 PM, Tony V E <span dir=3D"ltr">&lt;<a href=
=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@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"><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><span>On Tue, Nov 10, 2015 at =
6:51 AM, dgutson . <span dir=3D"ltr">&lt;<a href=3D"mailto:danielgutson@gma=
il.com" target=3D"_blank">danielgutson@gmail.com</a>&gt;</span> wrote:<br><=
/span><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"><p dir=3D"ltr"></p>=
<div><div><span>El 9/11/2015 22:12, &quot;Andrew Tomazos&quot; &lt;<a href=
=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@gmail.c=
om</a>&gt; escribi=C3=B3:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Nov 10, 2015 at 1:43 AM, Andrey Semashev &lt;<a href=3D"mailto=
:andrey.semashev@gmail.com" target=3D"_blank">andrey.semashev@gmail.com</a>=
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Tuesday, November 10, 2015 12:17:44 AM Andrew Tomazos wrote:<br=
>
&gt;&gt; &gt; On Tue, Nov 10, 2015 at 12:09 AM, Andrey Semashev &lt;<a href=
=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semashev@gma=
il.com</a><br></span><span>
&gt;&gt; &gt; &gt;The compiler would then be<br>
&gt;&gt; &gt; &gt; able to optimize the code better as it would be able to =
remove the checks<br>
&gt;&gt; &gt; &gt; and<br>
&gt;&gt; &gt; &gt; branching instructions for these cases altogether. I sus=
pect that would<br>
&gt;&gt; &gt; &gt; not be<br>
&gt;&gt; &gt; &gt; possible with std::unreachable().<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; A std::unreachable() standard library call can necessarily do=
 everything<br>
&gt;&gt; &gt; that an attribute statement does and more.=C2=A0 So, no it is=
 possible.<br>
&gt;&gt;<br>&gt;<br></span><span>
&gt; Options are:<br>
&gt;<br>
&gt; - Nothing.=C2=A0 The statement is a no-op.<br>
&gt; - Undefined behavior.<br>
&gt; - An exception is thrown.<br>
&gt; - std::terminate is called.<br>
&gt; - A user-defined handler is called.<br></span></div></div><span>
Throwing an exception or calling std::terminate() are covered by this optio=
n, which could default to call terminate.<p></p>
<p dir=3D"ltr">Again, nothing prevents static analyzers and even optimizers=
 to do the same analysis whereas this is an attribute or a specific functio=
n call.<br></p><div><div>
<p dir=3D"ltr">&gt; - Configurably one of the above.<br>
&gt; - Something else?<br>
&gt;<br></p></div></div></span></blockquote></div><br></div><div class=3D"g=
mail_extra">Just to be clear about what some others are trying to point out=
:<br><br><br><div style=3D"background-color:rgb(250,250,250);border-color:r=
gb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><=
code><div><span><span style=3D"color:rgb(0,0,136)">switch</span><span style=
=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">(</span>=
<span style=3D"color:rgb(0,0,0)">day</span><span style=3D"color:rgb(102,102=
,0)">)</span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"col=
or:rgb(102,102,0)">{</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color:rgb(0,0,136)">case</span><span style=3D"col=
or:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,0,102)">Days</span><spa=
n style=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rgb(0,0,0)">=
<span><span>SATURDAY</span></span></span><span style=3D"color:rgb(102,102,0=
)">:</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span =
style=3D"color:rgb(0,0,136)">case</span><span style=3D"color:rgb(0,0,0)"> <=
/span><span style=3D"color:rgb(102,0,102)">Days</span><span style=3D"color:=
rgb(102,102,0)">::</span><span style=3D"color:rgb(0,0,0)"><span><span>SUNDA=
Y</span></span></span><span style=3D"color:rgb(102,102,0)">:</span><span st=
yle=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=
=3D"color:rgb(102,0,102)">Weekend</span><span style=3D"color:rgb(102,102,0)=
">();</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 </span><span style=3D"color:rgb(0,0,136)">break</span><span style=3D"co=
lor:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color:rgb(0,0,136)">case</span><span style=3D"col=
or:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,0,102)">Days</span><spa=
n style=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rgb(0,0,0)">=
MONDAY</span><span style=3D"color:rgb(102,102,0)">:</span><span style=3D"co=
lor:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,0,136)"=
>case</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:r=
gb(102,0,102)">Days</span><span style=3D"color:rgb(102,102,0)">::</span><sp=
an style=3D"color:rgb(0,0,0)"><span><span>TUESDAY</span></span></span><span=
 style=3D"color:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0,0)"><b=
r>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,0,136)">case</span><span =
style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,0,102)">Day=
s</span><span style=3D"color:rgb(102,102,0)">::</span><span style=3D"color:=
rgb(0,0,0)"><span><span>WEDNESDAY</span></span></span><span style=3D"color:=
rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =
</span><span style=3D"color:rgb(0,0,136)">case</span><span style=3D"color:r=
gb(0,0,0)"> </span><span style=3D"color:rgb(102,0,102)">Days</span><span st=
yle=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rgb(0,0,0)"><spa=
n><span>THURSDAY</span></span></span><span style=3D"color:rgb(102,102,0)">:=
</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span styl=
e=3D"color:rgb(0,0,136)">case</span><span style=3D"color:rgb(0,0,0)"> </spa=
n><span style=3D"color:rgb(102,0,102)">Days</span><span style=3D"color:rgb(=
102,102,0)">::</span><span style=3D"color:rgb(0,0,0)"><span><span>FRIDAY</s=
pan></span></span><span style=3D"color:rgb(102,102,0)">:</span><span style=
=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D=
"color:rgb(102,0,102)">Weekday</span><span style=3D"color:rgb(102,102,0)">(=
);</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <=
/span><span style=3D"color:rgb(0,0,136)">break</span><span style=3D"color:r=
gb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 <=
/span><span style=3D"color:rgb(0,0,136)">default</span><span style=3D"color=
:rgb(102,102,0)">:</span></span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:rgb(102,102,0)">std::unre=
achable()</span><span style=3D"color:rgb(102,102,0)">;</span><span style=3D=
"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(102,102,0)">}</span>=
<span style=3D"color:rgb(0,0,0)"><br></span></div></code></div><br></div><d=
iv class=3D"gmail_extra">If std::unreachable() is defined to <br></div><div=
 class=3D"gmail_extra">- throw an exception<br></div>- std::terminate<br><d=
iv class=3D"gmail_extra"><div class=3D"gmail_extra">- or be configurable<br=
><br></div></div><div class=3D"gmail_extra">Then the above code can&#39;t b=
e optimized.=C2=A0 In particular, I can write &quot;correct&quot; code that=
 purposely passes in a bad &#39;day&#39; so that an exception is thrown and=
 then catch that exception and continue. If we _define_ it to throw an exce=
ption (or call my handler, etc), then it better throw an exception (or call=
 my handler, etc).<br><br></div><div class=3D"gmail_extra">However, if we l=
eave it as undefined behaviour, then the code can be removed/optimized.=C2=
=A0 And optionally an implementation can offer various behaviours.</div></d=
iv></blockquote></div><br></div></div></div><div class=3D"gmail_extra">If w=
e pick the configurable option, and the configuration is made at compile-ti=
me, one of the configuration options could result in undefined behavior (an=
d encourage optimizing the code out).=C2=A0 For example they may want this =
behavior in release build, but in debug build they want to get a handler ca=
lled (that prints a stack trace say and then gracefully crashes).</div><div=
 class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">It&#39;s hard t=
o get excited about the optimization, though.=C2=A0 We&#39;re talking one (=
unlikely-marked) branch and a few bytes of code size.</div><div class=3D"gm=
ail_extra"><br></div><div class=3D"gmail_extra">Getting rid of undefined be=
havior on the other hand, has a whole SG dedicated to it.</div></div></bloc=
kquote><div><br></div><div>The purpose of SG12 is to rationalize C++&#39;s =
handling of undefined behavior, not to get rid of it.=C2=A0</div></div></di=
v></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--94eb2c0926321e5e920524372795--

.

--001a1148ef94d7be200524372e51
Content-Type: text/plain; charset=UTF-8

On Tue, Nov 10, 2015 at 11:23 PM, Richard Smith <richard@metafoo.co.uk>
wrote:

> On Tue, Nov 10, 2015 at 1:24 PM, Andrew Tomazos <andrewtomazos@gmail.com>
> wrote:
>
>> Getting rid of undefined behavior on the other hand, has a whole SG
>> dedicated to it.
>>
>
> The purpose of SG12 is to rationalize C++'s handling of undefined
> behavior, not to get rid of it.
>
> My bad.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--001a1148ef94d7be200524372e51
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, Nov 10, 2015 at 11:23 PM, Richard Smith <span dir=3D"ltr">&lt;<a href=
=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</=
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"><di=
v class=3D"gmail_extra"><div class=3D"gmail_quote"><div><div class=3D"h5">O=
n Tue, Nov 10, 2015 at 1:24 PM, Andrew Tomazos <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@gmail.=
com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div><div><div class=3D"gmail_extra"><div class=3D"gmail_quote">Getting r=
id of undefined behavior on the other hand, has a whole SG dedicated to it.=
<br></div></div></div></div></div></blockquote><div><br></div></div></div><=
div>The purpose of SG12 is to rationalize C++&#39;s handling of undefined b=
ehavior, not to get rid of it.=C2=A0</div></div></div></div><div class=3D"H=
OEnZb"><div class=3D"h5">

<p></p>

</div></div></blockquote></div></div><div class=3D"gmail_extra">My bad.</di=
v><div class=3D"gmail_extra"><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1148ef94d7be200524372e51--

.

------=_Part_6712_1384623745.1447199827221
Content-Type: multipart/alternative;
 boundary="----=_Part_6713_1173468200.1447199827222"

------=_Part_6713_1173468200.1447199827222
Content-Type: text/plain; charset=UTF-8

On Tuesday, 10 November 2015 22:13:11 UTC, Matt Calabrese wrote:
>
> On Tue, Nov 10, 2015 at 1:45 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> On Tuesday, November 10, 2015 at 4:24:45 PM UTC-5, Andrew Tomazos wrote:
>>>
>>> If we pick the configurable option, and the configuration is made at
>>> compile-time, one of the configuration options could result in undefined
>>> behavior (and encourage optimizing the code out).  For example they may
>>> want this behavior in release build, but in debug build they want to get a
>>> handler called (that prints a stack trace say and then gracefully crashes).
>>>
>>> It's hard to get excited about the optimization, though.  We're talking
>>> one (unlikely-marked) branch and a few bytes of code size.
>>>
>>> Getting rid of undefined behavior on the other hand, has a whole SG
>>> dedicated to it.
>>>
>>>
>> Here's the thing: there's no such thing in the C++ standard as a
>> "configurable option". There are only 3 options: standard-defined behavior,
>> implementation-defined behavior, and un-defined behavior. All those
>> compiler switches you have? Those either deal with something outside of the
>> standard, define how the compiler deals with implementation/undefined
>> behavior, or specifies behavior that is against what the standard requires.
>>
>> In all cases, they're not something that is a part of the standard. So
>> the best thing the standard can do is say "undefined behavior", thus
>> allowing specific implementations to decide whether to define it or not.
>>
>
> I would have agreed with you prior to Kona, but contracts are basically
> going down the configurable route. I don't think anybody talked about exact
> wording of how it might be specified in the standard, but the general idea
> I gleaned is that things like the ability to provide a run-time
> specification of a precondition violation handler would be configurable at
> build time. Violations could be UB, but you would be able to build in a way
> that lets you register a handler, making behavior upon violation defined,
> which then has the trade-offs mentioned in this thread. Though wording
> wasn't talked about in detail at Kona, I think the idea of how to specify
> this in the standard, without explicitly talking about things like build
> options, is that there would be some standard registration function that
> lets you specify a hook at run-time, however it would be
> implementation-specified whether or not invoking this function *actually*
> registers the hook (it might do nothing at all on some implementations, or
> it might quick_exit if you try to call it, etc.). This would mean in
> practice, without being too explicit, that the ability to register a
> handler at run-time can be build-time configurable. You have UB if the
> implementation specifies that the registration function doesn't actually
> register a handler.
>
> Again, the details of this weren't talked about in detail regarding
> contracts a Kona even though there seemed to be agreement that there would
> be some kind of configuration available. This is just my personal
> interpretation of how it might actually be specified in a sensible manner
> in the standard. If this is really the way we'd be moving forward with
> contracts, it might be equally acceptable for a facility such as
> unreachable. In my personal opinion, I don't think unreachable needs such a
> hook, but it might not be outside of the realm of possibility that there is
> some kind of a configurable approach that is at least partially endorsed in
> the standard.
>

Note that if we get contracts and don't get [[unreachable]], one will be
able to write []()[[expects: false]]{}() with presumptively similar
results. I would hope this counts as an argument in favour of
[[unreachable]] with similar UB semantics; code deletion in release mode,
trap/throw/hook in debug mode.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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_6713_1173468200.1447199827222
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, 10 November 2015 22:13:11 UTC, Matt Calabrese  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"><div><div class=3D"gmai=
l_quote">On Tue, Nov 10, 2015 at 1:45 PM, Nicol Bolas <span dir=3D"ltr">&lt=
;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"LglUZLz=
7FgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;re=
turn true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">jmck=
....@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tu=
esday, November 10, 2015 at 4:24:45 PM UTC-5, Andrew Tomazos wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div>If we pick =
the configurable option, and the configuration is made at compile-time, one=
 of the configuration options could result in undefined behavior (and encou=
rage optimizing the code out).=C2=A0 For example they may want this behavio=
r in release build, but in debug build they want to get a handler called (t=
hat prints a stack trace say and then gracefully crashes).</div><div><br></=
div><div>It&#39;s hard to get excited about the optimization, though.=C2=A0=
 We&#39;re talking one (unlikely-marked) branch and a few bytes of code siz=
e.</div><div><br></div><div>Getting rid of undefined behavior on the other =
hand, has a whole SG dedicated to it.</div><div><br></div></div></div></div=
></blockquote><div><br>Here&#39;s the thing: there&#39;s no such thing in t=
he C++ standard as a &quot;configurable option&quot;. There are only 3 opti=
ons: standard-defined behavior, implementation-defined behavior, and un-def=
ined behavior. All those compiler switches you have? Those either deal with=
 something outside of the standard, define how the compiler deals with impl=
ementation/undefined behavior, or specifies behavior that is against what t=
he standard requires.<br><br>In all cases, they&#39;re not something that i=
s a part of the standard. So the best thing the standard can do is say &quo=
t;undefined behavior&quot;, thus allowing specific implementations to decid=
e whether to define it or not.</div></blockquote><div><br></div><div>I woul=
d have agreed with you prior to Kona, but contracts are basically going dow=
n the configurable route. I don&#39;t think anybody talked about exact word=
ing of how it might be specified in the standard, but the general idea I gl=
eaned is that things like the ability to provide a run-time specification o=
f a precondition violation handler would be configurable at build time. Vio=
lations could be UB, but you would be able to build in a way that lets you =
register a handler, making behavior upon violation defined, which then has =
the trade-offs mentioned in this thread. Though wording wasn&#39;t talked a=
bout in detail at Kona, I think the idea of how to specify this in the stan=
dard, without explicitly talking about things like build options, is that t=
here would be some standard registration function that lets you specify a h=
ook at run-time, however it would be implementation-specified whether or no=
t invoking this function <i>actually</i> registers the hook (it might do no=
thing at all on some implementations, or it might quick_exit if you try to =
call it, etc.). This would mean in practice, without being too explicit, th=
at the ability to register a handler at run-time can be build-time configur=
able. You have UB if the implementation specifies that the registration fun=
ction doesn&#39;t actually register a handler.</div><div><br></div><div>Aga=
in, the details of this weren&#39;t talked about in detail regarding contra=
cts a Kona even though there seemed to be agreement that there would be som=
e kind of configuration available. This is just my personal interpretation =
of how it might actually be specified in a sensible manner in the standard.=
 If this is really the way we&#39;d be moving forward with contracts, it mi=
ght be equally acceptable for a facility such as unreachable. In my persona=
l opinion, I don&#39;t think unreachable needs such a hook, but it might no=
t be outside of the realm of possibility that there is some kind of a confi=
gurable approach that is at least partially endorsed in the standard.</div>=
</div></div></div></blockquote><div><br></div><div>Note that if we get cont=
racts and don&#39;t get [[unreachable]], one will be able to write []()[[ex=
pects: false]]{}() with presumptively similar results. I would hope this co=
unts as an argument in favour of [[unreachable]] with similar UB semantics;=
 code deletion in release mode, trap/throw/hook in debug mode.</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_6713_1173468200.1447199827222--
------=_Part_6712_1384623745.1447199827221--

.

------=_Part_8193_502871429.1447243459133
Content-Type: multipart/alternative;
 boundary="----=_Part_8194_554084797.1447243459134"

------=_Part_8194_554084797.1447243459134
Content-Type: text/plain; charset=UTF-8

On Tuesday, November 10, 2015 at 10:13:11 PM UTC, Matt Calabrese wrote:
>
> On Tue, Nov 10, 2015 at 1:45 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> On Tuesday, November 10, 2015 at 4:24:45 PM UTC-5, Andrew Tomazos wrote:
>>>
>>> If we pick the configurable option, and the configuration is made at
>>> compile-time, one of the configuration options could result in undefined
>>> behavior (and encourage optimizing the code out).  For example they may
>>> want this behavior in release build, but in debug build they want to get a
>>> handler called (that prints a stack trace say and then gracefully crashes).
>>>
>>> It's hard to get excited about the optimization, though.  We're talking
>>> one (unlikely-marked) branch and a few bytes of code size.
>>>
>>> Getting rid of undefined behavior on the other hand, has a whole SG
>>> dedicated to it.
>>>
>>>
>> Here's the thing: there's no such thing in the C++ standard as a
>> "configurable option". There are only 3 options: standard-defined behavior,
>> implementation-defined behavior, and un-defined behavior. All those
>> compiler switches you have? Those either deal with something outside of the
>> standard, define how the compiler deals with implementation/undefined
>> behavior, or specifies behavior that is against what the standard requires.
>>
>> In all cases, they're not something that is a part of the standard. So
>> the best thing the standard can do is say "undefined behavior", thus
>> allowing specific implementations to decide whether to define it or not.
>>
>
> I would have agreed with you prior to Kona, but contracts are basically
> going down the configurable route [...].
>

Interesting. A possible definition of std::unreachable() would be an empty
function whose precondition is always false. The problem of defining its
behavior if is actually invoked would be part of the general handling of
contracts.

I see now that Edward Catmur made a similar comment elsethread.

-- gpd

-- gpd

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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_8194_554084797.1447243459134
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, November 10, 2015 at 10:13:11 PM UTC, Matt Calabrese wrote:<blo=
ckquote 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 Tue, Nov 10, 2015 at 1:45 PM, Nicol Bolas <span dir=3D"=
ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D=
"LglUZLz7FgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:=
&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;">jmck...@gmail.com</a>&gt;</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">On Tuesday, November 10, 2015 at 4:24:45 PM UTC-5, Andrew Tomazos 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"><div><div><div>If =
we pick the configurable option, and the configuration is made at compile-t=
ime, one of the configuration options could result in undefined behavior (a=
nd encourage optimizing the code out).=C2=A0 For example they may want this=
 behavior in release build, but in debug build they want to get a handler c=
alled (that prints a stack trace say and then gracefully crashes).</div><di=
v><br></div><div>It&#39;s hard to get excited about the optimization, thoug=
h.=C2=A0 We&#39;re talking one (unlikely-marked) branch and a few bytes of =
code size.</div><div><br></div><div>Getting rid of undefined behavior on th=
e other hand, has a whole SG dedicated to it.</div><div><br></div></div></d=
iv></div></blockquote><div><br>Here&#39;s the thing: there&#39;s no such th=
ing in the C++ standard as a &quot;configurable option&quot;. There are onl=
y 3 options: standard-defined behavior, implementation-defined behavior, an=
d un-defined behavior. All those compiler switches you have? Those either d=
eal with something outside of the standard, define how the compiler deals w=
ith implementation/undefined behavior, or specifies behavior that is agains=
t what the standard requires.<br><br>In all cases, they&#39;re not somethin=
g that is a part of the standard. So the best thing the standard can do is =
say &quot;undefined behavior&quot;, thus allowing specific implementations =
to decide whether to define it or not.</div></blockquote><div><br></div><di=
v>I would have agreed with you prior to Kona, but contracts are basically g=
oing down the configurable route [...]. </div></div></div></div></blockquot=
e><div><br>Interesting. A possible definition of std::unreachable() would b=
e an empty function whose precondition is always false. The problem of defi=
ning its behavior if is actually invoked would be part of the general handl=
ing of contracts.<br><br>I see now that Edward Catmur made a similar commen=
t elsethread.<br><br>-- gpd<br></div><br>-- gpd<br>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_8194_554084797.1447243459134--
------=_Part_8193_502871429.1447243459133--

.

--Apple-Mail=_737943FC-B84D-4448-B600-BD6AD1C94627
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9311=E2=80=9311, at 8:04 PM, Giovanni Piero Deretta <gpdere=
tta@gmail.com> wrote:
>=20
> Interesting. A possible definition of std::unreachable() would be an empt=
y function whose precondition is always false. The problem of defining its =
behavior if is actually invoked would be part of the general handling of co=
ntracts.

The contract is an attribute in Ed=E2=80=99s example because the consensus =
is that UB on precondition failure doesn=E2=80=99t alter semantics, right? =
So, a language extension for contracts isn=E2=80=99t needed for [[unreachab=
le]].

It would still be nice to spell unreachable as an attribute-statement as op=
posed to a function, even if it=E2=80=99s not magic. It acts like a languag=
e construct. Inside switch, it=E2=80=99s also an alternative to [[fallthrou=
gh]].

[[noreturn]] void foo();

switch ( sel ) {
case blah:
    foo();
    [[unreachable]]; // break and [[fallthrough]] are inappropriate,
                     // but it's nice to write something here.

default:
    [[unreachable]]; // Completing a switch is a common use-case
                     // for unreachable.
}

--=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=_737943FC-B84D-4448-B600-BD6AD1C94627
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9311=
=E2=80=9311, at 8:04 PM, Giovanni Piero Deretta &lt;<a href=3D"mailto:gpder=
etta@gmail.com" class=3D"">gpderetta@gmail.com</a>&gt; wrote:</div><br clas=
s=3D"Apple-interchange-newline"><div class=3D""><span style=3D"font-family:=
 Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font=
-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto=
; text-align: start; text-indent: 0px; text-transform: none; white-space: n=
ormal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; flo=
at: none; display: inline !important;" class=3D"">Interesting. A possible d=
efinition of std::unreachable() would be an empty function whose preconditi=
on is always false. The problem of defining its behavior if is actually inv=
oked would be part of the general handling of contracts.</span><br style=3D=
"font-family: Helvetica; font-size: 12px; font-style: normal; font-variant:=
 normal; font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: none; w=
hite-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-wi=
dth: 0px;" class=3D""></div></blockquote></div><br class=3D""><div class=3D=
"">The contract is an attribute in Ed=E2=80=99s example because the consens=
us is that UB on precondition failure doesn=E2=80=99t alter semantics, righ=
t? So, a language extension for contracts isn=E2=80=99t needed for&nbsp;<fo=
nt face=3D"Courier" class=3D"">[[unreachable]]</font>.</div><div class=3D""=
><br class=3D""></div><div class=3D"">It would still be nice to spell <font=
 face=3D"Courier" class=3D"">unreachable</font> as an attribute-statement a=
s opposed to a function, even if it=E2=80=99s not magic. It acts like a lan=
guage construct. Inside <font face=3D"Courier" class=3D"">switch</font>, it=
=E2=80=99s also an alternative to <font face=3D"Courier" class=3D"">[[fallt=
hrough]]</font>.</div><div class=3D""><br class=3D""></div><div class=3D"">=
<font face=3D"Courier" class=3D"">[[noreturn]] void foo();</font></div><div=
 class=3D""><font face=3D"Courier" class=3D""><br class=3D""></font></div><=
div class=3D""><font face=3D"Courier" class=3D"">switch ( sel ) {</font></d=
iv><div class=3D""><font face=3D"Courier" class=3D"">case blah:</font></div=
><div class=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp; foo();</fo=
nt></div><div class=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp; [[=
unreachable]]; // break and [[fallthrough]] are inappropriate,</font></div>=
<div class=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// but it's nice to writ=
e something here.</font></div><div class=3D""><font face=3D"Courier" class=
=3D""><br class=3D""></font></div><div class=3D""><font face=3D"Courier" cl=
ass=3D"">default:</font></div><div class=3D""><font face=3D"Courier" class=
=3D"">&nbsp; &nbsp; [[unreachable]]; // Completing a switch is a common use=
-case</font></div><div class=3D""><font face=3D"Courier" class=3D"">&nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// for=
 unreachable.</font></div><div class=3D""><font face=3D"Courier" class=3D""=
>}</font></div><div class=3D""><br class=3D""></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_737943FC-B84D-4448-B600-BD6AD1C94627--

.

------=_Part_578_1486298431.1447254541267
Content-Type: multipart/alternative;
 boundary="----=_Part_579_1056508357.1447254541274"

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



On Wednesday, November 11, 2015 at 1:51:22 PM UTC, David Krauss wrote:
>
>
> On 2015=E2=80=9311=E2=80=9311, at 8:04 PM, Giovanni Piero Deretta <gpde..=
..@gmail.com=20
> <javascript:>> wrote:
>
> Interesting. A possible definition of std::unreachable() would be an empt=
y=20
> function whose precondition is always false. The problem of defining its=
=20
> behavior if is actually invoked would be part of the general handling of=
=20
> contracts.
>
>
> The contract is an attribute in Ed=E2=80=99s example because the consensu=
s is that=20
> UB on precondition failure doesn=E2=80=99t alter semantics, right? So, a =
language=20
> extension for contracts isn=E2=80=99t needed for [[unreachable]].
>
>
if that's the consensus for contracts, then yes, there is no need for=20
explicit support for unreachable.
=20

> It would still be nice to spell unreachable as an attribute-statement as=
=20
> opposed to a function, even if it=E2=80=99s not magic. It acts like a lan=
guage=20
> construct. Inside switch, it=E2=80=99s also an alternative to [[fallthrou=
gh]].
>

why though? Wouldn't an std::unreachable() work just fine in your example?=
=20
I don't have strong preference either way, but wouldn't a function call be=
=20
more idiomatic than an attribute attached to an empty statement?

-- gpd

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

<br><br>On Wednesday, November 11, 2015 at 1:51:22 PM UTC, David Krauss wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:bre=
ak-word"><br><div><blockquote type=3D"cite"><div>On 2015=E2=80=9311=E2=80=
=9311, at 8:04 PM, Giovanni Piero Deretta &lt;<a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"4CA3t-4uFwAJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;">gpde...@gmail.com</a>&gt; wrote:</=
div><br><div><span style=3D"font-family:Helvetica;font-size:12px;font-style=
:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-h=
eight:normal;text-align:start;text-indent:0px;text-transform:none;white-spa=
ce:normal;word-spacing:0px;float:none;display:inline!important">Interesting=
.. A possible definition of std::unreachable() would be an empty function wh=
ose precondition is always false. The problem of defining its behavior if i=
s actually invoked would be part of the general handling of contracts.</spa=
n><br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-=
variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;=
text-align:start;text-indent:0px;text-transform:none;white-space:normal;wor=
d-spacing:0px"></div></blockquote></div><br><div>The contract is an attribu=
te in Ed=E2=80=99s example because the consensus is that UB on precondition=
 failure doesn=E2=80=99t alter semantics, right? So, a language extension f=
or contracts isn=E2=80=99t needed for=C2=A0<font face=3D"Courier">[[unreach=
able]]</font>.</div><div><br></div></div></blockquote><div><br>if that&#39;=
s the consensus for contracts, then yes, there is no need for explicit supp=
ort for unreachable.<br>=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 style=3D"word-wrap:break-word"><div></div><div>It would still be=
 nice to spell <font face=3D"Courier">unreachable</font> as an attribute-st=
atement as opposed to a function, even if it=E2=80=99s not magic. It acts l=
ike a language construct. Inside <font face=3D"Courier">switch</font>, it=
=E2=80=99s also an alternative to <font face=3D"Courier">[[fallthrough]]</f=
ont>.</div></div></blockquote><div><br>why though? Wouldn&#39;t an std::unr=
eachable() work just fine in your example? I don&#39;t have strong preferen=
ce either way, but wouldn&#39;t a function call be more idiomatic than an a=
ttribute attached to an empty statement?<br><br>-- gpd<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_579_1056508357.1447254541274--
------=_Part_578_1486298431.1447254541267--

.

--001a114b2d40e0054005244597d1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 11, 2015 at 4:09 PM, Giovanni Piero Deretta <gpderetta@gmail.co=
m
> wrote:

>
>
> On Wednesday, November 11, 2015 at 1:51:22 PM UTC, David Krauss wrote:
>>
>>
>> On 2015=E2=80=9311=E2=80=9311, at 8:04 PM, Giovanni Piero Deretta <gpde.=
...@gmail.com>
>> wrote:
>>
>> Interesting. A possible definition of std::unreachable() would be an
>> empty function whose precondition is always false. The problem of defini=
ng
>> its behavior if is actually invoked would be part of the general handlin=
g
>> of contracts.
>>
>>
>> The contract is an attribute in Ed=E2=80=99s example because the consens=
us is
>> that UB on precondition failure doesn=E2=80=99t alter semantics, right? =
So, a
>> language extension for contracts isn=E2=80=99t needed for [[unreachable]=
].
>>
>>
> if that's the consensus for contracts, then yes, there is no need for
> explicit support for unreachable.
>
>
>> It would still be nice to spell unreachable as an attribute-statement as
>> opposed to a function, even if it=E2=80=99s not magic. It acts like a la=
nguage
>> construct. Inside switch, it=E2=80=99s also an alternative to [[fallthro=
ugh]].
>>
>
> why though? Wouldn't an std::unreachable() work just fine in your example=
?
> I don't have strong preference either way, but wouldn't a function call b=
e
> more idiomatic than an attribute attached to an empty statement?
>
> -- gpd
>
> This can't be how contracts work. That would be very confusing.
If the compiler figure out that a precondition is always false it has to
either fail to compile or invoke the violation handler.
It can use the preconditions to optimize inside the function, but not
silently optimize away the code on the caller side as we would expect
[[unreachable]] to do.

  / Jonas

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

--001a114b2d40e0054005244597d1
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, Nov 11, 2015 at 4:09 PM, Giovanni Piero Deretta <span dir=3D"lt=
r">&lt;<a href=3D"mailto:gpderetta@gmail.com" target=3D"_blank">gpderetta@g=
mail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><br><br>On Wednesday, =
November 11, 2015 at 1:51:22 PM UTC, David Krauss wrote:<span class=3D""><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pad=
ding-left:1ex"><div style=3D"word-wrap:break-word"><br><div><blockquote typ=
e=3D"cite"><div>On 2015=E2=80=9311=E2=80=9311, at 8:04 PM, Giovanni Piero D=
eretta &lt;<a rel=3D"nofollow">gpde...@gmail.com</a>&gt; wrote:</div><br><d=
iv><span style=3D"font-family:Helvetica;font-size:12px;font-style:normal;fo=
nt-variant:normal;font-weight:normal;letter-spacing:normal;line-height:norm=
al;text-align:start;text-indent:0px;text-transform:none;white-space:normal;=
word-spacing:0px;float:none;display:inline!important">Interesting. A possib=
le definition of std::unreachable() would be an empty function whose precon=
dition is always false. The problem of defining its behavior if is actually=
 invoked would be part of the general handling of contracts.</span><br styl=
e=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-variant:no=
rmal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align=
:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:=
0px"></div></blockquote></div><br><div>The contract is an attribute in Ed=
=E2=80=99s example because the consensus is that UB on precondition failure=
 doesn=E2=80=99t alter semantics, right? So, a language extension for contr=
acts isn=E2=80=99t needed for=C2=A0<font face=3D"Courier">[[unreachable]]</=
font>.</div><div><br></div></div></blockquote></span><div><br>if that&#39;s=
 the consensus for contracts, then yes, there is no need for explicit suppo=
rt for unreachable.<br>=C2=A0</div><span class=3D""><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div s=
tyle=3D"word-wrap:break-word"><div></div><div>It would still be nice to spe=
ll <font face=3D"Courier">unreachable</font> as an attribute-statement as o=
pposed to a function, even if it=E2=80=99s not magic. It acts like a langua=
ge construct. Inside <font face=3D"Courier">switch</font>, it=E2=80=99s als=
o an alternative to <font face=3D"Courier">[[fallthrough]]</font>.</div></d=
iv></blockquote></span><div><br>why though? Wouldn&#39;t an std::unreachabl=
e() work just fine in your example? I don&#39;t have strong preference eith=
er way, but wouldn&#39;t a function call be more idiomatic than an attribut=
e attached to an empty statement?<span class=3D""><font color=3D"#888888"><=
br><br>-- gpd<br></font></span></div><div class=3D""><div class=3D"h5">

<p></p></div></div></blockquote></div><div class=3D"gmail_extra">This can&#=
39;t be how contracts work. That would be very confusing.=C2=A0</div><div c=
lass=3D"gmail_extra">If the compiler figure out that a precondition is alwa=
ys false it has to either fail to compile or invoke the violation handler.=
=C2=A0</div><div class=3D"gmail_extra">It can use the preconditions to opti=
mize inside the function, but not silently optimize away the code on the ca=
ller side as we would expect [[unreachable]] to do.</div><div class=3D"gmai=
l_extra"><br></div><div class=3D"gmail_extra">=C2=A0 / Jonas=C2=A0</div><di=
v><br></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a114b2d40e0054005244597d1--

.

------=_Part_712_1541014582.1447259036275
Content-Type: multipart/alternative;
 boundary="----=_Part_713_928087947.1447259036276"

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

On Wednesday, November 11, 2015 at 10:36:44 AM UTC-5, Jonas Persson wrote:
>
> On Wed, Nov 11, 2015 at 4:09 PM, Giovanni Piero Deretta <gpde...@gmail.co=
m=20
> <javascript:>> wrote:
>
>> On Wednesday, November 11, 2015 at 1:51:22 PM UTC, David Krauss wrote:
>>>
>>>
>>> On 2015=E2=80=9311=E2=80=9311, at 8:04 PM, Giovanni Piero Deretta <gpde=
....@gmail.com>=20
>>> wrote:
>>>
>>> Interesting. A possible definition of std::unreachable() would be an=20
>>> empty function whose precondition is always false. The problem of defin=
ing=20
>>> its behavior if is actually invoked would be part of the general handli=
ng=20
>>> of contracts.
>>>
>>>
>>> The contract is an attribute in Ed=E2=80=99s example because the consen=
sus is=20
>>> that UB on precondition failure doesn=E2=80=99t alter semantics, right?=
 So, a=20
>>> language extension for contracts isn=E2=80=99t needed for [[unreachable=
]].
>>>
>>>
>> if that's the consensus for contracts, then yes, there is no need for=20
>> explicit support for unreachable.
>> =20
>>
>>> It would still be nice to spell unreachable as an attribute-statement=
=20
>>> as opposed to a function, even if it=E2=80=99s not magic. It acts like =
a language=20
>>> construct. Inside switch, it=E2=80=99s also an alternative to [[fallthr=
ough]].
>>>
>>
>> why though? Wouldn't an std::unreachable() work just fine in your=20
>> example? I don't have strong preference either way, but wouldn't a funct=
ion=20
>> call be more idiomatic than an attribute attached to an empty statement?
>>
>> -- gpd
>>
>> This can't be how contracts work. That would be very confusing.=20
> If the compiler figure out that a precondition is always false it has to=
=20
> either fail to compile or invoke the violation handler.=20
> It can use the preconditions to optimize inside the function, but not=20
> silently optimize away the code on the caller side as we would expect=20
> [[unreachable]] to do.
>

What kind of [[unreachable]] are you talking about? My original idea was=20
simply an attribute statement that tells the compiler that control flow=20
within a function cannot reach this point. How would the caller of that=20
function know about that and therefore be optimized by it?

You don't label a function as "unreachable". You label a place in the code.

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

On Wednesday, November 11, 2015 at 10:36:44 AM UTC-5, Jonas Persson 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><div clas=
s=3D"gmail_quote">On Wed, Nov 11, 2015 at 4:09 PM, Giovanni Piero Deretta <=
span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscat=
ed-mailto=3D"sHGvwa40FwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39=
;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39=
;;return true;">gpde...@gmail.com</a>&gt;</span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"=
>On Wednesday, November 11, 2015 at 1:51:22 PM UTC, David Krauss wrote:<spa=
n><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid=
;padding-left:1ex"><div style=3D"word-wrap:break-word"><br><div><blockquote=
 type=3D"cite"><div>On 2015=E2=80=9311=E2=80=9311, at 8:04 PM, Giovanni Pie=
ro Deretta &lt;<a rel=3D"nofollow">gpde...@gmail.com</a>&gt; wrote:</div><b=
r><div><span style=3D"font-family:Helvetica;font-size:12px;font-style:norma=
l;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:=
normal;text-align:start;text-indent:0px;text-transform:none;white-space:nor=
mal;word-spacing:0px;float:none;display:inline!important">Interesting. A po=
ssible definition of std::unreachable() would be an empty function whose pr=
econdition is always false. The problem of defining its behavior if is actu=
ally invoked would be part of the general handling of contracts.</span><br =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varian=
t:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-a=
lign:start;text-indent:0px;text-transform:none;white-space:normal;word-spac=
ing:0px"></div></blockquote></div><br><div>The contract is an attribute in =
Ed=E2=80=99s example because the consensus is that UB on precondition failu=
re doesn=E2=80=99t alter semantics, right? So, a language extension for con=
tracts isn=E2=80=99t needed for=C2=A0<font face=3D"Courier">[[unreachable]]=
</font>.</div><div><br></div></div></blockquote></span><div><br>if that&#39=
;s the consensus for contracts, then yes, there is no need for explicit sup=
port for unreachable.<br>=C2=A0</div><span><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color=
:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style=3D"w=
ord-wrap:break-word"><div></div><div>It would still be nice to spell <font =
face=3D"Courier">unreachable</font> as an attribute-statement as opposed to=
 a function, even if it=E2=80=99s not magic. It acts like a language constr=
uct. Inside <font face=3D"Courier">switch</font>, it=E2=80=99s also an alte=
rnative to <font face=3D"Courier">[[fallthrough]]</font>.</div></div></bloc=
kquote></span><div><br>why though? Wouldn&#39;t an std::unreachable() work =
just fine in your example? I don&#39;t have strong preference either way, b=
ut wouldn&#39;t a function call be more idiomatic than an attribute attache=
d to an empty statement?<span><font color=3D"#888888"><br><br>-- gpd<br></f=
ont></span></div><div><div>

<p></p></div></div></blockquote></div><div>This can&#39;t be how contracts =
work. That would be very confusing.=C2=A0</div><div>If the compiler figure =
out that a precondition is always false it has to either fail to compile or=
 invoke the violation handler.=C2=A0</div><div>It can use the preconditions=
 to optimize inside the function, but not silently optimize away the code o=
n the caller side as we would expect [[unreachable]] to do.</div></div></di=
v></blockquote><div><br>What kind of [[unreachable]] are you talking about?=
 My original idea was simply an attribute statement that tells the compiler=
 that control flow within a function cannot reach this point. How would the=
 caller of that function know about that and therefore be optimized by it?<=
br><br>You don&#39;t label a function as &quot;unreachable&quot;. You label=
 a place in the code.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_713_928087947.1447259036276--
------=_Part_712_1541014582.1447259036275--

.

------=_Part_537_919400357.1447259302712
Content-Type: multipart/alternative;
 boundary="----=_Part_538_1749340968.1447259302712"

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

On Wednesday, November 11, 2015 at 3:36:44 PM UTC, Jonas Persson wrote:
>
>
>
> On Wed, Nov 11, 2015 at 4:09 PM, Giovanni Piero Deretta <gpde...@gmail.co=
m=20
> <javascript:>> wrote:
>
>>
>>
>> On Wednesday, November 11, 2015 at 1:51:22 PM UTC, David Krauss wrote:
>>>
>>>
>>> On 2015=E2=80=9311=E2=80=9311, at 8:04 PM, Giovanni Piero Deretta <gpde=
....@gmail.com>=20
>>> wrote:
>>>
>>> Interesting. A possible definition of std::unreachable() would be an=20
>>> empty function whose precondition is always false. The problem of defin=
ing=20
>>> its behavior if is actually invoked would be part of the general handli=
ng=20
>>> of contracts.
>>>
>>>
>>> The contract is an attribute in Ed=E2=80=99s example because the consen=
sus is=20
>>> that UB on precondition failure doesn=E2=80=99t alter semantics, right?=
 So, a=20
>>> language extension for contracts isn=E2=80=99t needed for [[unreachable=
]].
>>>
>>>
>> if that's the consensus for contracts, then yes, there is no need for=20
>> explicit support for unreachable.
>> =20
>>
>>> It would still be nice to spell unreachable as an attribute-statement=
=20
>>> as opposed to a function, even if it=E2=80=99s not magic. It acts like =
a language=20
>>> construct. Inside switch, it=E2=80=99s also an alternative to [[fallthr=
ough]].
>>>
>>
>> why though? Wouldn't an std::unreachable() work just fine in your=20
>> example? I don't have strong preference either way, but wouldn't a funct=
ion=20
>> call be more idiomatic than an attribute attached to an empty statement?
>>
>> -- gpd
>>
>> This can't be how contracts work. That would be very confusing.=20
> If the compiler figure out that a precondition is always false it has to=
=20
> either fail to compile or invoke the violation handler.=20
> It can use the preconditions to optimize inside the function, but not=20
> silently optimize away the code on the caller side as we would expect=20
> [[unreachable]] to do.
>
>
Assuming that the effect contract violations can be configured as UB, then=
=20
it is just another source of UB. Compilers already optimize today by=20
backpropagating UB, std::unreachable wouldn't be any different. If you=20
prefer an exception or an handler to be called on precondition violation,=
=20
you probably want that on a reached std::unreachable as well.

Also the compiler (or static analyser) should complain only if it can=20
statically prove that a function with invalid preconditions is actually=20
called.

-- gpd

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

On Wednesday, November 11, 2015 at 3:36:44 PM UTC, Jonas Persson wrote:<blo=
ckquote 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><div><br><div=
 class=3D"gmail_quote">On Wed, Nov 11, 2015 at 4:09 PM, Giovanni Piero Dere=
tta <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"sHGvwa40FwAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">gpde...@gmail.com</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex"><br><br>On Wednesday, November 11, 2015 at 1:51:22 PM UTC, David Kr=
auss wrote:<span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><br><=
div><blockquote type=3D"cite"><div>On 2015=E2=80=9311=E2=80=9311, at 8:04 P=
M, Giovanni Piero Deretta &lt;<a rel=3D"nofollow">gpde...@gmail.com</a>&gt;=
 wrote:</div><br><div><span style=3D"font-family:Helvetica;font-size:12px;f=
ont-style:normal;font-variant:normal;font-weight:normal;letter-spacing:norm=
al;line-height:normal;text-align:start;text-indent:0px;text-transform:none;=
white-space:normal;word-spacing:0px;float:none;display:inline!important">In=
teresting. A possible definition of std::unreachable() would be an empty fu=
nction whose precondition is always false. The problem of defining its beha=
vior if is actually invoked would be part of the general handling of contra=
cts.</span><br style=3D"font-family:Helvetica;font-size:12px;font-style:nor=
mal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-heigh=
t:normal;text-align:start;text-indent:0px;text-transform:none;white-space:n=
ormal;word-spacing:0px"></div></blockquote></div><br><div>The contract is a=
n attribute in Ed=E2=80=99s example because the consensus is that UB on pre=
condition failure doesn=E2=80=99t alter semantics, right? So, a language ex=
tension for contracts isn=E2=80=99t needed for=C2=A0<font face=3D"Courier">=
[[unreachable]]</font>.</div><div><br></div></div></blockquote></span><div>=
<br>if that&#39;s the consensus for contracts, then yes, there is no need f=
or explicit support for unreachable.<br>=C2=A0</div><span><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<div style=3D"word-wrap:break-word"><div></div><div>It would still be nice =
to spell <font face=3D"Courier">unreachable</font> as an attribute-statemen=
t as opposed to a function, even if it=E2=80=99s not magic. It acts like a =
language construct. Inside <font face=3D"Courier">switch</font>, it=E2=80=
=99s also an alternative to <font face=3D"Courier">[[fallthrough]]</font>.<=
/div></div></blockquote></span><div><br>why though? Wouldn&#39;t an std::un=
reachable() work just fine in your example? I don&#39;t have strong prefere=
nce either way, but wouldn&#39;t a function call be more idiomatic than an =
attribute attached to an empty statement?<span><font color=3D"#888888"><br>=
<br>-- gpd<br></font></span></div><div><div>

<p></p></div></div></blockquote></div><div>This can&#39;t be how contracts =
work. That would be very confusing.=C2=A0</div><div>If the compiler figure =
out that a precondition is always false it has to either fail to compile or=
 invoke the violation handler.=C2=A0</div><div>It can use the preconditions=
 to optimize inside the function, but not silently optimize away the code o=
n the caller side as we would expect [[unreachable]] to do.</div><div><br><=
/div></div></div></blockquote><div><br>Assuming that the effect contract vi=
olations can be configured as UB, then it is just another source of UB. Com=
pilers already optimize today by backpropagating UB, std::unreachable would=
n&#39;t be any different. If you prefer an exception or an handler to be ca=
lled on precondition violation, you probably want that on a reached std::un=
reachable as well.<br><br>Also the compiler (or static analyser) should com=
plain only if it can statically prove that a function with invalid precondi=
tions is actually called.<br></div><br>-- gpd<br>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_538_1749340968.1447259302712--
------=_Part_537_919400357.1447259302712--

.

On Wednesday 11 November 2015 16:36:42 Jonas Persson wrote:
> If the compiler figure out that a precondition is always false it has to
> either fail to compile or invoke the violation handler.
> It can use the preconditions to optimize inside the function, but not
> silently optimize away the code on the caller side as we would expect
> [[unreachable]] to do.

That's exactly what MSVC's __assume builtin does.

__assume(expr) assumes that expr is true, which means it is allowed to
optimise away any code paths that would lead to expr being false. If expr is
always false, the same stands true: all code paths leading there can be
optimised away.

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

.

--001a1145aa8c4ea8a605244b51b2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 11, 2015 at 5:28 PM, Giovanni Piero Deretta <gpderetta@gmail.co=
m
> wrote:

> On Wednesday, November 11, 2015 at 3:36:44 PM UTC, Jonas Persson wrote:
>>
>>
>>
>> On Wed, Nov 11, 2015 at 4:09 PM, Giovanni Piero Deretta <
>> gpde...@gmail.com> wrote:
>>
>>>
>>>
>>> On Wednesday, November 11, 2015 at 1:51:22 PM UTC, David Krauss wrote:
>>>>
>>>>
>>>> On 2015=E2=80=9311=E2=80=9311, at 8:04 PM, Giovanni Piero Deretta <gpd=
e...@gmail.com>
>>>> wrote:
>>>>
>>>> Interesting. A possible definition of std::unreachable() would be an
>>>> empty function whose precondition is always false. The problem of defi=
ning
>>>> its behavior if is actually invoked would be part of the general handl=
ing
>>>> of contracts.
>>>>
>>>>
>>>> The contract is an attribute in Ed=E2=80=99s example because the conse=
nsus is
>>>> that UB on precondition failure doesn=E2=80=99t alter semantics, right=
? So, a
>>>> language extension for contracts isn=E2=80=99t needed for [[unreachabl=
e]].
>>>>
>>>>
>>> if that's the consensus for contracts, then yes, there is no need for
>>> explicit support for unreachable.
>>>
>>>
>>>> It would still be nice to spell unreachable as an attribute-statement
>>>> as opposed to a function, even if it=E2=80=99s not magic. It acts like=
 a language
>>>> construct. Inside switch, it=E2=80=99s also an alternative to [[fallth=
rough]].
>>>>
>>>
>>> why though? Wouldn't an std::unreachable() work just fine in your
>>> example? I don't have strong preference either way, but wouldn't a func=
tion
>>> call be more idiomatic than an attribute attached to an empty statement=
?
>>>
>>> -- gpd
>>>
>>> This can't be how contracts work. That would be very confusing.
>> If the compiler figure out that a precondition is always false it has to
>> either fail to compile or invoke the violation handler.
>> It can use the preconditions to optimize inside the function, but not
>> silently optimize away the code on the caller side as we would expect
>> [[unreachable]] to do.
>>
>>
> Assuming that the effect contract violations can be configured as UB, the=
n
> it is just another source of UB. Compilers already optimize today by
> backpropagating UB, std::unreachable wouldn't be any different.
>

It is a bit strange to reason about precondition UB that way. There is
usefulness in assuming that the preconditions true and optimize for that,
where it beeing false leads to UB. But here the compiler first proves the
program to be incorrect and than uses that information for optimizations.
Why optimize an incorrect program?



> If you prefer an exception or an handler to be called on precondition
> violation, you probably want that on a reached std::unreachable as well.
>

  If the handler I choose is the compile time check(I dont know if this
part of the proposal, but is really should be) any use of std::unreachable
would be a compiler error.


>
> Also the compiler (or static analyser) should complain only if it can
> statically prove that a function with invalid preconditions is actually
> called.
>
> -- gpd
>

  Why would you want that? It would lead to runtime check for a lot
conditions that are fully known at compile time.

  So in the case of std::unreachable it is not allowed to complain since it
cannot prove it will be called, but is is allowed to optimize as if it is
not, even if that cannot be proved?

  / Jonas

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

--001a1145aa8c4ea8a605244b51b2
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, Nov 11, 2015 at 5:28 PM, Giovanni Piero Deretta <span dir=3D"lt=
r">&lt;<a href=3D"mailto:gpderetta@gmail.com" target=3D"_blank">gpderetta@g=
mail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex">On Wednesday, November=
 11, 2015 at 3:36:44 PM UTC, Jonas Persson wrote:<span class=3D""><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex"><div dir=3D"ltr"><br><div><br><div class=3D"gmail_quote">On Wed, No=
v 11, 2015 at 4:09 PM, Giovanni Piero Deretta <span dir=3D"ltr">&lt;<a rel=
=3D"nofollow">gpde...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<br><br>On Wednesday, November 11, 2015 at 1:51:22 PM UTC, David Krauss wro=
te:<span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><br><div><blo=
ckquote type=3D"cite"><div>On 2015=E2=80=9311=E2=80=9311, at 8:04 PM, Giova=
nni Piero Deretta &lt;<a rel=3D"nofollow">gpde...@gmail.com</a>&gt; wrote:<=
/div><br><div><span style=3D"font-family:Helvetica;font-size:12px;font-styl=
e:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-=
height:normal;text-align:start;text-indent:0px;text-transform:none;white-sp=
ace:normal;word-spacing:0px;float:none;display:inline!important">Interestin=
g. A possible definition of std::unreachable() would be an empty function w=
hose precondition is always false. The problem of defining its behavior if =
is actually invoked would be part of the general handling of contracts.</sp=
an><br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font=
-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal=
;text-align:start;text-indent:0px;text-transform:none;white-space:normal;wo=
rd-spacing:0px"></div></blockquote></div><br><div>The contract is an attrib=
ute in Ed=E2=80=99s example because the consensus is that UB on preconditio=
n failure doesn=E2=80=99t alter semantics, right? So, a language extension =
for contracts isn=E2=80=99t needed for=C2=A0<font face=3D"Courier">[[unreac=
hable]]</font>.</div><div><br></div></div></blockquote></span><div><br>if t=
hat&#39;s the consensus for contracts, then yes, there is no need for expli=
cit support for unreachable.<br>=C2=A0</div><span><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div sty=
le=3D"word-wrap:break-word"><div></div><div>It would still be nice to spell=
 <font face=3D"Courier">unreachable</font> as an attribute-statement as opp=
osed to a function, even if it=E2=80=99s not magic. It acts like a language=
 construct. Inside <font face=3D"Courier">switch</font>, it=E2=80=99s also =
an alternative to <font face=3D"Courier">[[fallthrough]]</font>.</div></div=
></blockquote></span><div><br>why though? Wouldn&#39;t an std::unreachable(=
) work just fine in your example? I don&#39;t have strong preference either=
 way, but wouldn&#39;t a function call be more idiomatic than an attribute =
attached to an empty statement?<span><font color=3D"#888888"><br><br>-- gpd=
<br></font></span></div><div><div>

<p></p></div></div></blockquote></div><div>This can&#39;t be how contracts =
work. That would be very confusing.=C2=A0</div><div>If the compiler figure =
out that a precondition is always false it has to either fail to compile or=
 invoke the violation handler.=C2=A0</div><div>It can use the preconditions=
 to optimize inside the function, but not silently optimize away the code o=
n the caller side as we would expect [[unreachable]] to do.</div><div><br><=
/div></div></div></blockquote></span><div><br>Assuming that the effect cont=
ract violations can be configured as UB, then it is just another source of =
UB. Compilers already optimize today by backpropagating UB, std::unreachabl=
e wouldn&#39;t be any different.</div></blockquote><div><div>=C2=A0=C2=A0</=
div><div>It is a bit strange to reason about precondition UB that way. Ther=
e is usefulness in assuming that the preconditions true and optimize for th=
at, where it beeing false leads to UB. But here the compiler first proves t=
he program to be incorrect and than uses that information for optimizations=
.. Why optimize an incorrect program?</div></div><div><br></div><div>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:so=
lid;padding-left:1ex"><div> If you prefer an exception or an handler to be =
called on precondition violation, you probably want that on a reached std::=
unreachable as well.<br></div></blockquote><div><br></div><div>=C2=A0 If th=
e handler I choose is the compile time check(I dont know if this part of th=
e proposal, but is really should be) any use of std::unreachable would be a=
 compiler error.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb=
(204,204,204);border-left-style:solid;padding-left:1ex"><div><br>Also the c=
ompiler (or static analyser) should complain only if it can statically prov=
e that a function with invalid preconditions is actually called.<br></div><=
div class=3D""><div class=3D"h5"><br>-- gpd<br></div></div></blockquote><di=
v><br></div><div>=C2=A0 Why would you want that? It would lead to runtime c=
heck for a lot conditions that are fully known at compile time.=C2=A0</div>=
<div><br></div><div><div>=C2=A0 So in the case of std::unreachable it is no=
t allowed to complain since it cannot prove it will be called, but is is al=
lowed to optimize as if it is not, even if that cannot be proved?</div></di=
v><div><br></div><div>=C2=A0 / Jonas</div><div><br></div></div><br></div></=
div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1145aa8c4ea8a605244b51b2--

.

--089e0122893cea408905244b6fc2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 11, 2015 at 5:23 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Wednesday, November 11, 2015 at 10:36:44 AM UTC-5, Jonas Persson wrote=
:
>>
>> On Wed, Nov 11, 2015 at 4:09 PM, Giovanni Piero Deretta <
>> gpde...@gmail.com> wrote:
>>
>>> On Wednesday, November 11, 2015 at 1:51:22 PM UTC, David Krauss wrote:
>>>>
>>>>
>>>> On 2015=E2=80=9311=E2=80=9311, at 8:04 PM, Giovanni Piero Deretta <gpd=
e...@gmail.com>
>>>> wrote:
>>>>
>>>> Interesting. A possible definition of std::unreachable() would be an
>>>> empty function whose precondition is always false. The problem of defi=
ning
>>>> its behavior if is actually invoked would be part of the general handl=
ing
>>>> of contracts.
>>>>
>>>>
>>>> The contract is an attribute in Ed=E2=80=99s example because the conse=
nsus is
>>>> that UB on precondition failure doesn=E2=80=99t alter semantics, right=
? So, a
>>>> language extension for contracts isn=E2=80=99t needed for [[unreachabl=
e]].
>>>>
>>>>
>>> if that's the consensus for contracts, then yes, there is no need for
>>> explicit support for unreachable.
>>>
>>>
>>>> It would still be nice to spell unreachable as an attribute-statement
>>>> as opposed to a function, even if it=E2=80=99s not magic. It acts like=
 a language
>>>> construct. Inside switch, it=E2=80=99s also an alternative to [[fallth=
rough]].
>>>>
>>>
>>> why though? Wouldn't an std::unreachable() work just fine in your
>>> example? I don't have strong preference either way, but wouldn't a func=
tion
>>> call be more idiomatic than an attribute attached to an empty statement=
?
>>>
>>> -- gpd
>>>
>>> This can't be how contracts work. That would be very confusing.
>> If the compiler figure out that a precondition is always false it has to
>> either fail to compile or invoke the violation handler.
>> It can use the preconditions to optimize inside the function, but not
>> silently optimize away the code on the caller side as we would expect
>> [[unreachable]] to do.
>>
>
> What kind of [[unreachable]] are you talking about? My original idea was
> simply an attribute statement that tells the compiler that control flow
> within a function cannot reach this point. How would the caller of that
> function know about that and therefore be optimized by it?
>
> You don't label a function as "unreachable". You label a place in the cod=
e.
>

I fully agree  on that definition of [[unreachable]]. I was talking about
the caller of std::unreachable() (or any function with failed a
precondition)  in contrast to a built in attribute.

  / Jonas

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

--089e0122893cea408905244b6fc2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>=C2=A0</div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Wed, Nov 11, 2015 at 5:23 PM, Nicol Bolas <span dir=3D"=
ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson=
@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex">On Wednesday, November=
 11, 2015 at 10:36:44 AM UTC-5, Jonas Persson wrote:<span class=3D""><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding=
-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Wed, Nov 11,=
 2015 at 4:09 PM, Giovanni Piero Deretta <span dir=3D"ltr">&lt;<a rel=3D"no=
follow">gpde...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On Wedn=
esday, November 11, 2015 at 1:51:22 PM UTC, David Krauss wrote:<span><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding=
-left:1ex"><div style=3D"word-wrap:break-word"><br><div><blockquote type=3D=
"cite"><div>On 2015=E2=80=9311=E2=80=9311, at 8:04 PM, Giovanni Piero Deret=
ta &lt;<a rel=3D"nofollow">gpde...@gmail.com</a>&gt; wrote:</div><br><div><=
span style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-v=
ariant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;t=
ext-align:start;text-indent:0px;text-transform:none;white-space:normal;word=
-spacing:0px;float:none;display:inline!important">Interesting. A possible d=
efinition of std::unreachable() would be an empty function whose preconditi=
on is always false. The problem of defining its behavior if is actually inv=
oked would be part of the general handling of contracts.</span><br style=3D=
"font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal=
;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:sta=
rt;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"=
></div></blockquote></div><br><div>The contract is an attribute in Ed=E2=80=
=99s example because the consensus is that UB on precondition failure doesn=
=E2=80=99t alter semantics, right? So, a language extension for contracts i=
sn=E2=80=99t needed for=C2=A0<font face=3D"Courier">[[unreachable]]</font>.=
</div><div><br></div></div></blockquote></span><div><br>if that&#39;s the c=
onsensus for contracts, then yes, there is no need for explicit support for=
 unreachable.<br>=C2=A0</div><span><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div style=3D"word-wra=
p:break-word"><div></div><div>It would still be nice to spell <font face=3D=
"Courier">unreachable</font> as an attribute-statement as opposed to a func=
tion, even if it=E2=80=99s not magic. It acts like a language construct. In=
side <font face=3D"Courier">switch</font>, it=E2=80=99s also an alternative=
 to <font face=3D"Courier">[[fallthrough]]</font>.</div></div></blockquote>=
</span><div><br>why though? Wouldn&#39;t an std::unreachable() work just fi=
ne in your example? I don&#39;t have strong preference either way, but woul=
dn&#39;t a function call be more idiomatic than an attribute attached to an=
 empty statement?<span><font color=3D"#888888"><br><br>-- gpd<br></font></s=
pan></div><div><div>

<p></p></div></div></blockquote></div><div>This can&#39;t be how contracts =
work. That would be very confusing.=C2=A0</div><div>If the compiler figure =
out that a precondition is always false it has to either fail to compile or=
 invoke the violation handler.=C2=A0</div><div>It can use the preconditions=
 to optimize inside the function, but not silently optimize away the code o=
n the caller side as we would expect [[unreachable]] to do.</div></div></di=
v></blockquote></span><div><br>What kind of [[unreachable]] are you talking=
 about? My original idea was simply an attribute statement that tells the c=
ompiler that control flow within a function cannot reach this point. How wo=
uld the caller of that function know about that and therefore be optimized =
by it?<br><br>You don&#39;t label a function as &quot;unreachable&quot;. Yo=
u label a place in the code.</div></blockquote><div>=C2=A0</div><div>I full=
y agree =C2=A0on that definition of [[unreachable]]. I was talking about th=
e caller of std::unreachable() (or any function with failed a precondition)=
 =C2=A0in contrast to a built in attribute.</div><div><br></div><div>=C2=A0=
 / Jonas</div></div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0122893cea408905244b6fc2--

.

--001a114063ec56f83605244b79a4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 11, 2015 at 5:26 PM, Jonas Persson <l.j.persson@gmail.com>
wrote:

>
>
> On Wed, Nov 11, 2015 at 5:28 PM, Giovanni Piero Deretta <
> gpderetta@gmail.com> wrote:
>
>> On Wednesday, November 11, 2015 at 3:36:44 PM UTC, Jonas Persson wrote:
>>>
>>>
>>>
>>> On Wed, Nov 11, 2015 at 4:09 PM, Giovanni Piero Deretta <
>>> gpde...@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Wednesday, November 11, 2015 at 1:51:22 PM UTC, David Krauss wrote:
>>>>>
>>>>>
>>>>> On 2015=E2=80=9311=E2=80=9311, at 8:04 PM, Giovanni Piero Deretta <gp=
de...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Interesting. A possible definition of std::unreachable() would be an
>>>>> empty function whose precondition is always false. The problem of def=
ining
>>>>> its behavior if is actually invoked would be part of the general hand=
ling
>>>>> of contracts.
>>>>>
>>>>>
>>>>> The contract is an attribute in Ed=E2=80=99s example because the cons=
ensus is
>>>>> that UB on precondition failure doesn=E2=80=99t alter semantics, righ=
t? So, a
>>>>> language extension for contracts isn=E2=80=99t needed for [[unreachab=
le]].
>>>>>
>>>>>
>>>> if that's the consensus for contracts, then yes, there is no need for
>>>> explicit support for unreachable.
>>>>
>>>>
>>>>> It would still be nice to spell unreachable as an attribute-statement
>>>>> as opposed to a function, even if it=E2=80=99s not magic. It acts lik=
e a language
>>>>> construct. Inside switch, it=E2=80=99s also an alternative to [[fallt=
hrough]].
>>>>>
>>>>
>>>> why though? Wouldn't an std::unreachable() work just fine in your
>>>> example? I don't have strong preference either way, but wouldn't a fun=
ction
>>>> call be more idiomatic than an attribute attached to an empty statemen=
t?
>>>>
>>>> -- gpd
>>>>
>>>> This can't be how contracts work. That would be very confusing.
>>> If the compiler figure out that a precondition is always false it has t=
o
>>> either fail to compile or invoke the violation handler.
>>> It can use the preconditions to optimize inside the function, but not
>>> silently optimize away the code on the caller side as we would expect
>>> [[unreachable]] to do.
>>>
>>>
>> Assuming that the effect contract violations can be configured as UB,
>> then it is just another source of UB. Compilers already optimize today b=
y
>> backpropagating UB, std::unreachable wouldn't be any different.
>>
>
> It is a bit strange to reason about precondition UB that way. There is
> usefulness in assuming that the preconditions true and optimize for that,
> where it beeing false leads to UB. But here the compiler first proves the
> program to be incorrect and than uses that information for optimizations.
> Why optimize an incorrect program?
>
>
>
>> If you prefer an exception or an handler to be called on precondition
>> violation, you probably want that on a reached std::unreachable as well.
>>
>
>   If the handler I choose is the compile time check(I dont know if this
> part of the proposal, but is really should be) any use of std::unreachabl=
e
> would be a compiler error.
>
>
>>
>> Also the compiler (or static analyser) should complain only if it can
>> statically prove that a function with invalid preconditions is actually
>> called.
>>
>> -- gpd
>>
>
>   Why would you want that? It would lead to runtime check for a lot
> conditions that are fully known at compile time.
>
>   So in the case of std::unreachable it is not allowed to complain since
> it cannot prove it will be called, but is is allowed to optimize as if it
> is not, even if that cannot be proved?
>

I'm not 100% sure I understand what you are saying, but I think my answer
is:

Yes, exactly.

The point of facilities like this is for you, the developer, to tell the
compiler things that it can't (with current technology) prove on its own.
It is your way of saying "trust me, even if you can't prove this, I can".
So optimize as if it was proven.

Then on the flip side, maybe in debug, ie no optimizations, we want to say
"but wait, if it turns out I was wrong, scream and yell at runtime".

Tony


>   / Jonas
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving 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/.
>

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

--001a114063ec56f83605244b79a4
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, Nov 11, 2015 at 5:26 PM, Jonas Persson <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:l.j.persson@gmail.com" target=3D"_blank">l.j.persson@gmail.=
com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin: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 Wed, Nov 11, 2015 at 5:28 PM, Giovanni Piero Deretta <span dir=3D"=
ltr">&lt;<a href=3D"mailto:gpderetta@gmail.com" target=3D"_blank">gpderetta=
@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex">On Wednesday, November=
 11, 2015 at 3:36:44 PM UTC, Jonas Persson wrote:<span><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde=
r-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><di=
v dir=3D"ltr"><br><div><br><div class=3D"gmail_quote">On Wed, Nov 11, 2015 =
at 4:09 PM, Giovanni Piero Deretta <span dir=3D"ltr">&lt;<a rel=3D"nofollow=
">gpde...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-col=
or:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br><br>On We=
dnesday, November 11, 2015 at 1:51:22 PM UTC, David Krauss wrote:<span><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex"><div style=3D"word-wrap:break-word"><br><div><blockquote type=
=3D"cite"><div>On 2015=E2=80=9311=E2=80=9311, at 8:04 PM, Giovanni Piero De=
retta &lt;<a rel=3D"nofollow">gpde...@gmail.com</a>&gt; wrote:</div><br><di=
v><span style=3D"font-family:Helvetica;font-size:12px;font-style:normal;fon=
t-variant:normal;font-weight:normal;letter-spacing:normal;line-height:norma=
l;text-align:start;text-indent:0px;text-transform:none;white-space:normal;w=
ord-spacing:0px;float:none;display:inline!important">Interesting. A possibl=
e definition of std::unreachable() would be an empty function whose precond=
ition is always false. The problem of defining its behavior if is actually =
invoked would be part of the general handling of contracts.</span><br style=
=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-variant:nor=
mal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:=
start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0=
px"></div></blockquote></div><br><div>The contract is an attribute in Ed=E2=
=80=99s example because the consensus is that UB on precondition failure do=
esn=E2=80=99t alter semantics, right? So, a language extension for contract=
s isn=E2=80=99t needed for=C2=A0<font face=3D"Courier">[[unreachable]]</fon=
t>.</div><div><br></div></div></blockquote></span><div><br>if that&#39;s th=
e consensus for contracts, then yes, there is no need for explicit support =
for unreachable.<br>=C2=A0</div><span><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(=
204,204,204);border-left-style:solid;padding-left:1ex"><div style=3D"word-w=
rap:break-word"><div></div><div>It would still be nice to spell <font face=
=3D"Courier">unreachable</font> as an attribute-statement as opposed to a f=
unction, even if it=E2=80=99s not magic. It acts like a language construct.=
 Inside <font face=3D"Courier">switch</font>, it=E2=80=99s also an alternat=
ive to <font face=3D"Courier">[[fallthrough]]</font>.</div></div></blockquo=
te></span><div><br>why though? Wouldn&#39;t an std::unreachable() work just=
 fine in your example? I don&#39;t have strong preference either way, but w=
ouldn&#39;t a function call be more idiomatic than an attribute attached to=
 an empty statement?<span><font color=3D"#888888"><br><br>-- gpd<br></font>=
</span></div><div><div>

<p></p></div></div></blockquote></div><div>This can&#39;t be how contracts =
work. That would be very confusing.=C2=A0</div><div>If the compiler figure =
out that a precondition is always false it has to either fail to compile or=
 invoke the violation handler.=C2=A0</div><div>It can use the preconditions=
 to optimize inside the function, but not silently optimize away the code o=
n the caller side as we would expect [[unreachable]] to do.</div><div><br><=
/div></div></div></blockquote></span><div><br>Assuming that the effect cont=
ract violations can be configured as UB, then it is just another source of =
UB. Compilers already optimize today by backpropagating UB, std::unreachabl=
e wouldn&#39;t be any different.</div></blockquote></span><div><div>=C2=A0=
=C2=A0</div><div>It is a bit strange to reason about precondition UB that w=
ay. There is usefulness in assuming that the preconditions true and optimiz=
e for that, where it beeing false leads to UB. But here the compiler first =
proves the program to be incorrect and than uses that information for optim=
izations. Why optimize an incorrect program?</div></div><span class=3D""><d=
iv><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex"><div> If you prefer an excep=
tion or an handler to be called on precondition violation, you probably wan=
t that on a reached std::unreachable as well.<br></div></blockquote><div><b=
r></div></span><div>=C2=A0 If the handler I choose is the compile time chec=
k(I dont know if this part of the proposal, but is really should be) any us=
e of std::unreachable would be a compiler error.</div><span class=3D""><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex"><div><br>Also the compiler (or static analyse=
r) should complain only if it can statically prove that a function with inv=
alid preconditions is actually called.<br></div><div><div><br>-- gpd<br></d=
iv></div></blockquote><div><br></div></span><div>=C2=A0 Why would you want =
that? It would lead to runtime check for a lot conditions that are fully kn=
own at compile time.=C2=A0</div><div><br></div><div><div>=C2=A0 So in the c=
ase of std::unreachable it is not allowed to complain since it cannot prove=
 it will be called, but is is allowed to optimize as if it is not, even if =
that cannot be proved?</div></div></div></div></div></blockquote><div><br><=
/div><div>I&#39;m not 100% sure I understand what you are saying, but I thi=
nk my answer is:<br><br>Yes, exactly.<br><br></div><div>The point of facili=
ties like this is for you, the developer, to tell the compiler things that =
it can&#39;t (with current technology) prove on its own.<br></div><div>It i=
s your way of saying &quot;trust me, even if you can&#39;t prove this, I ca=
n&quot;.=C2=A0 So optimize as if it was proven.<br><br></div><div>Then on t=
he flip side, maybe in debug, ie no optimizations, we want to say &quot;but=
 wait, if it turns out I was wrong, scream and yell at runtime&quot;.<br><b=
r></div><div>Tony<br></div><div><br></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 class=3D"gmail_extra"><div class=3D"gmail_quote"><span =
class=3D"HOEnZb"><font color=3D"#888888"><div><br></div><div>=C2=A0 / Jonas=
</div><div><br></div></font></span></div><br></div></div><div class=3D"HOEn=
Zb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a114063ec56f83605244b79a4--

.

--047d7b5d36b26095fb05244b90d3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 11, 2015 at 11:37 PM, Tony V E <tvaneerd@gmail.com> wrote:

>
>
> On Wed, Nov 11, 2015 at 5:26 PM, Jonas Persson <l.j.persson@gmail.com>
> wrote:
>
>>
>>
>> On Wed, Nov 11, 2015 at 5:28 PM, Giovanni Piero Deretta <
>> gpderetta@gmail.com> wrote:
>>
>>> On Wednesday, November 11, 2015 at 3:36:44 PM UTC, Jonas Persson wrote:
>>>>
>>>>
>>>>
>>>> On Wed, Nov 11, 2015 at 4:09 PM, Giovanni Piero Deretta <
>>>> gpde...@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wednesday, November 11, 2015 at 1:51:22 PM UTC, David Krauss wrote=
:
>>>>>>
>>>>>>
>>>>>> On 2015=E2=80=9311=E2=80=9311, at 8:04 PM, Giovanni Piero Deretta <g=
pde...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Interesting. A possible definition of std::unreachable() would be an
>>>>>> empty function whose precondition is always false. The problem of de=
fining
>>>>>> its behavior if is actually invoked would be part of the general han=
dling
>>>>>> of contracts.
>>>>>>
>>>>>>
>>>>>> The contract is an attribute in Ed=E2=80=99s example because the con=
sensus is
>>>>>> that UB on precondition failure doesn=E2=80=99t alter semantics, rig=
ht? So, a
>>>>>> language extension for contracts isn=E2=80=99t needed for [[unreacha=
ble]].
>>>>>>
>>>>>>
>>>>> if that's the consensus for contracts, then yes, there is no need for
>>>>> explicit support for unreachable.
>>>>>
>>>>>
>>>>>> It would still be nice to spell unreachable as an
>>>>>> attribute-statement as opposed to a function, even if it=E2=80=99s n=
ot magic. It
>>>>>> acts like a language construct. Inside switch, it=E2=80=99s also an
>>>>>> alternative to [[fallthrough]].
>>>>>>
>>>>>
>>>>> why though? Wouldn't an std::unreachable() work just fine in your
>>>>> example? I don't have strong preference either way, but wouldn't a fu=
nction
>>>>> call be more idiomatic than an attribute attached to an empty stateme=
nt?
>>>>>
>>>>> -- gpd
>>>>>
>>>>> This can't be how contracts work. That would be very confusing.
>>>> If the compiler figure out that a precondition is always false it has
>>>> to either fail to compile or invoke the violation handler.
>>>> It can use the preconditions to optimize inside the function, but not
>>>> silently optimize away the code on the caller side as we would expect
>>>> [[unreachable]] to do.
>>>>
>>>>
>>> Assuming that the effect contract violations can be configured as UB,
>>> then it is just another source of UB. Compilers already optimize today =
by
>>> backpropagating UB, std::unreachable wouldn't be any different.
>>>
>>
>> It is a bit strange to reason about precondition UB that way. There is
>> usefulness in assuming that the preconditions true and optimize for that=
,
>> where it beeing false leads to UB. But here the compiler first proves th=
e
>> program to be incorrect and than uses that information for optimizations=
..
>> Why optimize an incorrect program?
>>
>>
>>
>>> If you prefer an exception or an handler to be called on precondition
>>> violation, you probably want that on a reached std::unreachable as well=
..
>>>
>>
>>   If the handler I choose is the compile time check(I dont know if this
>> part of the proposal, but is really should be) any use of std::unreachab=
le
>> would be a compiler error.
>>
>>
>>>
>>> Also the compiler (or static analyser) should complain only if it can
>>> statically prove that a function with invalid preconditions is actually
>>> called.
>>>
>>> -- gpd
>>>
>>
>>   Why would you want that? It would lead to runtime check for a lot
>> conditions that are fully known at compile time.
>>
>>   So in the case of std::unreachable it is not allowed to complain since
>> it cannot prove it will be called, but is is allowed to optimize as if i=
t
>> is not, even if that cannot be proved?
>>
>
> I'm not 100% sure I understand what you are saying, but I think my answer
> is:
>
> Yes, exactly.
>
> The point of facilities like this is for you, the developer, to tell the
> compiler things that it can't (with current technology) prove on its own.
> It is your way of saying "trust me, even if you can't prove this, I can".
> So optimize as if it was proven.
>
> Then on the flip side, maybe in debug, ie no optimizations, we want to sa=
y
> "but wait, if it turns out I was wrong, scream and yell at runtime".
>
> Tony
>

I agree that is a thing we need. What I am objecting to is using a
funtction with a precondition to achive this. A precondition from the
callers perspective is something that should be checked, not a thruth.
For that it would be better to have something designed for the task, like
__assume(expr)

  / Jonas

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

--047d7b5d36b26095fb05244b90d3
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, Nov 11, 2015 at 11:37 PM, Tony V E <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@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"><br><div=
 class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span class=3D"">On W=
ed, Nov 11, 2015 at 5:26 PM, Jonas Persson <span dir=3D"ltr">&lt;<a href=3D=
"mailto:l.j.persson@gmail.com" target=3D"_blank">l.j.persson@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"><br><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span>On Wed, Nov 1=
1, 2015 at 5:28 PM, Giovanni Piero Deretta <span dir=3D"ltr">&lt;<a href=3D=
"mailto:gpderetta@gmail.com" target=3D"_blank">gpderetta@gmail.com</a>&gt;<=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex">On Wednesday, November 11, 2015 at 3:36:4=
4 PM UTC, Jonas Persson wrote:<span><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><br><=
div><br><div class=3D"gmail_quote">On Wed, Nov 11, 2015 at 4:09 PM, Giovann=
i Piero Deretta <span dir=3D"ltr">&lt;<a rel=3D"nofollow">gpde...@gmail.com=
</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)=
;border-left-style:solid;padding-left:1ex"><br><br>On Wednesday, November 1=
1, 2015 at 1:51:22 PM UTC, David Krauss wrote:<span><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div s=
tyle=3D"word-wrap:break-word"><br><div><blockquote type=3D"cite"><div>On 20=
15=E2=80=9311=E2=80=9311, at 8:04 PM, Giovanni Piero Deretta &lt;<a rel=3D"=
nofollow">gpde...@gmail.com</a>&gt; wrote:</div><br><div><span style=3D"fon=
t-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;fon=
t-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;t=
ext-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;floa=
t:none;display:inline!important">Interesting. A possible definition of std:=
:unreachable() would be an empty function whose precondition is always fals=
e. The problem of defining its behavior if is actually invoked would be par=
t of the general handling of contracts.</span><br style=3D"font-family:Helv=
etica;font-size:12px;font-style:normal;font-variant:normal;font-weight:norm=
al;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0p=
x;text-transform:none;white-space:normal;word-spacing:0px"></div></blockquo=
te></div><br><div>The contract is an attribute in Ed=E2=80=99s example beca=
use the consensus is that UB on precondition failure doesn=E2=80=99t alter =
semantics, right? So, a language extension for contracts isn=E2=80=99t need=
ed for=C2=A0<font face=3D"Courier">[[unreachable]]</font>.</div><div><br></=
div></div></blockquote></span><div><br>if that&#39;s the consensus for cont=
racts, then yes, there is no need for explicit support for unreachable.<br>=
=C2=A0</div><span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-=
left-style:solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div=
></div><div>It would still be nice to spell <font face=3D"Courier">unreacha=
ble</font> as an attribute-statement as opposed to a function, even if it=
=E2=80=99s not magic. It acts like a language construct. Inside <font face=
=3D"Courier">switch</font>, it=E2=80=99s also an alternative to <font face=
=3D"Courier">[[fallthrough]]</font>.</div></div></blockquote></span><div><b=
r>why though? Wouldn&#39;t an std::unreachable() work just fine in your exa=
mple? I don&#39;t have strong preference either way, but wouldn&#39;t a fun=
ction call be more idiomatic than an attribute attached to an empty stateme=
nt?<span><font color=3D"#888888"><br><br>-- gpd<br></font></span></div><div=
><div>

<p></p></div></div></blockquote></div><div>This can&#39;t be how contracts =
work. That would be very confusing.=C2=A0</div><div>If the compiler figure =
out that a precondition is always false it has to either fail to compile or=
 invoke the violation handler.=C2=A0</div><div>It can use the preconditions=
 to optimize inside the function, but not silently optimize away the code o=
n the caller side as we would expect [[unreachable]] to do.</div><div><br><=
/div></div></div></blockquote></span><div><br>Assuming that the effect cont=
ract violations can be configured as UB, then it is just another source of =
UB. Compilers already optimize today by backpropagating UB, std::unreachabl=
e wouldn&#39;t be any different.</div></blockquote></span><div><div>=C2=A0=
=C2=A0</div><div>It is a bit strange to reason about precondition UB that w=
ay. There is usefulness in assuming that the preconditions true and optimiz=
e for that, where it beeing false leads to UB. But here the compiler first =
proves the program to be incorrect and than uses that information for optim=
izations. Why optimize an incorrect program?</div></div><span><div><br></di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border=
-left-style:solid;padding-left:1ex"><div> If you prefer an exception or an =
handler to be called on precondition violation, you probably want that on a=
 reached std::unreachable as well.<br></div></blockquote><div><br></div></s=
pan><div>=C2=A0 If the handler I choose is the compile time check(I dont kn=
ow if this part of the proposal, but is really should be) any use of std::u=
nreachable would be a compiler error.</div><span><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex"><div><br>Also the compiler (or static analyser) should complain onl=
y if it can statically prove that a function with invalid preconditions is =
actually called.<br></div><div><div><br>-- gpd<br></div></div></blockquote>=
<div><br></div></span><div>=C2=A0 Why would you want that? It would lead to=
 runtime check for a lot conditions that are fully known at compile time.=
=C2=A0</div><div><br></div><div><div>=C2=A0 So in the case of std::unreacha=
ble it is not allowed to complain since it cannot prove it will be called, =
but is is allowed to optimize as if it is not, even if that cannot be prove=
d?</div></div></div></div></div></blockquote><div><br></div></span><div>I&#=
39;m not 100% sure I understand what you are saying, but I think my answer =
is:<br><br>Yes, exactly.<br><br></div><div>The point of facilities like thi=
s is for you, the developer, to tell the compiler things that it can&#39;t =
(with current technology) prove on its own.<br></div><div>It is your way of=
 saying &quot;trust me, even if you can&#39;t prove this, I can&quot;.=C2=
=A0 So optimize as if it was proven.<br><br></div><div>Then on the flip sid=
e, maybe in debug, ie no optimizations, we want to say &quot;but wait, if i=
t turns out I was wrong, scream and yell at runtime&quot;.<br><br></div><di=
v>Tony</div></div></div></div></blockquote><div><br></div><div>I agree that=
 is a thing we need. What I am objecting to is using a funtction with a pre=
condition to achive this. A precondition from the callers perspective is so=
mething that should be checked, not a thruth.</div><div>For that it would b=
e better to have something designed for the task, like __assume(expr)=C2=A0=
</div><div><br></div><div>=C2=A0 / Jonas</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b5d36b26095fb05244b90d3--

.

--047d7b3a82908246d005244bd3b7
Content-Type: text/plain; charset=UTF-8

>   So in the case of std::unreachable it is not allowed to complain since
>>> it cannot prove it will be called, but is is allowed to optimize as if it
>>> is not, even if that cannot be proved?
>>>
>>
>> I'm not 100% sure I understand what you are saying, but I think my answer
>> is:
>>
>> Yes, exactly.
>>
>> The point of facilities like this is for you, the developer, to tell the
>> compiler things that it can't (with current technology) prove on its own.
>> It is your way of saying "trust me, even if you can't prove this, I
>> can".  So optimize as if it was proven.
>>
>> Then on the flip side, maybe in debug, ie no optimizations, we want to
>> say "but wait, if it turns out I was wrong, scream and yell at runtime".
>>
>> Tony
>>
>
> I agree that is a thing we need. What I am objecting to is using a
> funtction with a precondition to achive this. A precondition from the
> callers perspective is something that should be checked, not a thruth.
> For that it would be better to have something designed for the task, like
> __assume(expr)
>
>
Let's say the precondition on sqrt(x) is  x >= 0.  So for this (bad
contrived example) code:

    if (x >= 0) {
       do_stuff();
    } else {
       x = sqrt(x);
       do_other_stuff();
    }

Shouldn't the compiler be able to remove the else block completely?  (Maybe
not in debug, but at least in some "max optimize" mode where it assumes
preconditions mean UB and thus never happen?)




>   / Jonas
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving 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/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--047d7b3a82908246d005244bd3b7
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"><div=
>=C2=A0</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"><div class=3D"=
gmail_extra"><div class=3D"gmail_quote"><div><div class=3D"h5"><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><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></div><div><div>=C2=
=A0 So in the case of std::unreachable it is not allowed to complain since =
it cannot prove it will be called, but is is allowed to optimize as if it i=
s not, even if that cannot be proved?</div></div></div></div></div></blockq=
uote><div><br></div></span><div>I&#39;m not 100% sure I understand what you=
 are saying, but I think my answer is:<br><br>Yes, exactly.<br><br></div><d=
iv>The point of facilities like this is for you, the developer, to tell the=
 compiler things that it can&#39;t (with current technology) prove on its o=
wn.<br></div><div>It is your way of saying &quot;trust me, even if you can&=
#39;t prove this, I can&quot;.=C2=A0 So optimize as if it was proven.<br><b=
r></div><div>Then on the flip side, maybe in debug, ie no optimizations, we=
 want to say &quot;but wait, if it turns out I was wrong, scream and yell a=
t runtime&quot;.<br><br></div><div>Tony</div></div></div></div></blockquote=
><div><br></div></div></div><div>I agree that is a thing we need. What I am=
 objecting to is using a funtction with a precondition to achive this. A pr=
econdition from the callers perspective is something that should be checked=
, not a thruth.</div><div>For that it would be better to have something des=
igned for the task, like __assume(expr)=C2=A0</div><span class=3D"HOEnZb"><=
font color=3D"#888888"><div><br></div></font></span></div></div></div></blo=
ckquote><div><br></div><div>Let&#39;s say the precondition on sqrt(x) is=C2=
=A0 x &gt;=3D 0.=C2=A0 So for this (bad contrived example) code:<br><br></d=
iv><div>=C2=A0=C2=A0=C2=A0 if (x &gt;=3D 0) {<br></div><div>=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 do_stuff();<br></div><div>=C2=A0=C2=A0=C2=A0 } else {=
<br></div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x =3D sqrt(x);<br></div=
><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 do_other_stuff();<br>=C2=A0=C2=
=A0=C2=A0 }<br><br></div><div>Shouldn&#39;t the compiler be able to remove =
the else block completely?=C2=A0 (Maybe not in debug, but at least in some =
&quot;max optimize&quot; mode where it assumes preconditions mean UB and th=
us never happen?)<br><br><br></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"><div class=3D"gmail_extra"><div class=3D"gmail_quo=
te"><span class=3D"HOEnZb"><font color=3D"#888888"><div></div><div>=C2=A0 /=
 Jonas</div></font></span></div></div></div><div class=3D"HOEnZb"><div clas=
s=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b3a82908246d005244bd3b7--

.

--001a114354aaba0ccd052454da2a
Content-Type: text/plain; charset=UTF-8

On Thu, Nov 12, 2015 at 12:02 AM, Tony V E <tvaneerd@gmail.com> wrote:

>
>
>>   So in the case of std::unreachable it is not allowed to complain since
>>>> it cannot prove it will be called, but is is allowed to optimize as if it
>>>> is not, even if that cannot be proved?
>>>>
>>>
>>> I'm not 100% sure I understand what you are saying, but I think my
>>> answer is:
>>>
>>> Yes, exactly.
>>>
>>> The point of facilities like this is for you, the developer, to tell the
>>> compiler things that it can't (with current technology) prove on its own.
>>> It is your way of saying "trust me, even if you can't prove this, I
>>> can".  So optimize as if it was proven.
>>>
>>> Then on the flip side, maybe in debug, ie no optimizations, we want to
>>> say "but wait, if it turns out I was wrong, scream and yell at runtime".
>>>
>>> Tony
>>>
>>
>> I agree that is a thing we need. What I am objecting to is using a
>> funtction with a precondition to achive this. A precondition from the
>> callers perspective is something that should be checked, not a thruth.
>> For that it would be better to have something designed for the task, like
>> __assume(expr)
>>
>>
> Let's say the precondition on sqrt(x) is  x >= 0.  So for this (bad
> contrived example) code:
>
>     if (x >= 0) {
>        do_stuff();
>     } else {
>        x = sqrt(x);
>        do_other_stuff();
>     }
>
> Shouldn't the compiler be able to remove the else block completely?
> (Maybe not in debug, but at least in some "max optimize" mode where it
> assumes preconditions mean UB and thus never happen?)
>
>
No, I dont think it should. It should fail. we dont know what x is. A
precondition is there to force the caller check his data before calling,
and in this case he hasn't. A correctness thing.
void foo(auto x) {
    if (x >= 0) {
       do_stuff();
    } else {
       x = sqrt(x);  // Call sqrt. Or fail to compile as x is statically
known to be incorrect here.
       do_other_stuff();
    }
}
[[unreachable]] on the other hand, is an assurance from the programmer that
he know what he is doing. So unless the compiler can prove him wrong the
compiler should accept.
void foo(auto x) {
    if (x >= 0) {
       do_stuff();
    } else {
       [[unreachable]];  // branch can be optimized away since we say its
ok.
       do_other_stuff();
    }
}
the same happen is we lift the precondition to the enclosing function.
void foo(auto x) [expects:x>=0] {
    if (x >= 0) {
       do_stuff();
    } else {
       // branch can be optimized away as prcondition says its ok. Probably
with a warning.
       do_other_stuff();
    }
}
Any UB from not fulfilling the precondition should only happen inside the
called function.
We would gain nothing from keeping a function call with a broken
precondition. It is better to be explicit and force the programmer to
correct his code.


  / Jonas

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--001a114354aaba0ccd052454da2a
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, Nov 12, 2015 at 12:02 AM, Tony V E <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border=
-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote"><span class=3D""><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quo=
te"><div><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><span><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2=
04,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><div></div><div><div>=C2=A0 S=
o in the case of std::unreachable it is not allowed to complain since it ca=
nnot prove it will be called, but is is allowed to optimize as if it is not=
, even if that cannot be proved?</div></div></div></div></div></blockquote>=
<div><br></div></span><div>I&#39;m not 100% sure I understand what you are =
saying, but I think my answer is:<br><br>Yes, exactly.<br><br></div><div>Th=
e point of facilities like this is for you, the developer, to tell the comp=
iler things that it can&#39;t (with current technology) prove on its own.<b=
r></div><div>It is your way of saying &quot;trust me, even if you can&#39;t=
 prove this, I can&quot;.=C2=A0 So optimize as if it was proven.<br><br></d=
iv><div>Then on the flip side, maybe in debug, ie no optimizations, we want=
 to say &quot;but wait, if it turns out I was wrong, scream and yell at run=
time&quot;.<br><br></div><div>Tony</div></div></div></div></blockquote><div=
><br></div></div></div><div>I agree that is a thing we need. What I am obje=
cting to is using a funtction with a precondition to achive this. A precond=
ition from the callers perspective is something that should be checked, not=
 a thruth.</div><div>For that it would be better to have something designed=
 for the task, like __assume(expr)=C2=A0</div><span><font color=3D"#888888"=
><div><br></div></font></span></div></div></div></blockquote><div><br></div=
></span><div>Let&#39;s say the precondition on sqrt(x) is=C2=A0 x &gt;=3D 0=
..=C2=A0 So for this (bad contrived example) code:<br><br></div><div>=C2=A0=
=C2=A0=C2=A0 if (x &gt;=3D 0) {<br></div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 do_stuff();<br></div><div>=C2=A0=C2=A0=C2=A0 } else {<br></div><d=
iv>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x =3D sqrt(x);<br></div><div>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 do_other_stuff();<br>=C2=A0=C2=A0=C2=A0 }<br=
><br></div><div>Shouldn&#39;t the compiler be able to remove the else block=
 completely?=C2=A0 (Maybe not in debug, but at least in some &quot;max opti=
mize&quot; mode where it assumes preconditions mean UB and thus never happe=
n?)<br><br></div></div></div></div></blockquote><div><br></div><div>No, I d=
ont think it should. It should fail. we dont know what x is. A precondition=
 is there to force the caller check his data before calling, and in this ca=
se he hasn&#39;t. A correctness thing.</div><div>void foo(auto x) {</div><d=
iv>=C2=A0 =C2=A0 if (x &gt;=3D 0) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0do=
_stuff();</div><div>=C2=A0 =C2=A0 } else {</div><div>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0x =3D sqrt(x); =C2=A0// Call sqrt. Or fail to compile as x is statica=
lly known to be incorrect here.</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0do_oth=
er_stuff();</div><div>=C2=A0 =C2=A0 }</div><div>}</div><div>[[unreachable]]=
 on the other hand, is an assurance from the programmer that he know what h=
e is doing. So unless the compiler can prove him wrong the compiler should =
accept.</div><div>void foo(auto x) {</div><div>=C2=A0 =C2=A0 if (x &gt;=3D =
0) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0do_stuff();</div><div>=C2=A0 =C2=
=A0 } else {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0[[unreachable]]; =C2=A0//=
 branch can be optimized away since we say its ok.</div><div>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0do_other_stuff();</div><div>=C2=A0 =C2=A0 }</div><div>}</div><=
div>the same happen is we lift the precondition to the enclosing function.<=
/div><div>void foo(auto x) [expects:x&gt;=3D0] {</div><div>=C2=A0 =C2=A0 if=
 (x &gt;=3D 0) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0do_stuff();</div><div=
>=C2=A0 =C2=A0 } else {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0// branch can =
be optimized away as prcondition says its ok. Probably with a warning.</div=
><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0do_other_stuff();</div><div>=C2=A0 =C2=A0 =
}</div><div>}</div><div>Any UB from not fulfilling the precondition should =
only happen inside the called function.</div><div>We would gain nothing fro=
m keeping a function call with a broken precondition. It is better to be ex=
plicit and force the programmer to correct his code.</div><div>=C2=A0</div>=
<div><br></div><div>=C2=A0 / Jonas</div></div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a114354aaba0ccd052454da2a--

.

------=_Part_758_831930061.1447330213337
Content-Type: multipart/alternative;
 boundary="----=_Part_759_1287874668.1447330213337"

------=_Part_759_1287874668.1447330213337
Content-Type: text/plain; charset=UTF-8



On Thursday, November 12, 2015 at 9:49:11 AM UTC, Jonas Persson wrote:
[...]

Any UB from not fulfilling the precondition should only happen inside the
> called function.
> We would gain nothing from keeping a function call with a broken
> precondition. It is better to be explicit and force the programmer to
> correct his code.
>


the problem is that C++ doesn't really distinguish between different
flavours of UB. C11 tried with Annex L, which I think that it is covered by
the recent wave of 'sanitizer' support in compilers. It has a non-zero cost
though as the additional checks are non-free and some optimizations are no
longer possible.

Constraining UB inside a function is also a lost cause. I'm not a compiler
writer, but as far as I understand, under aggressive inter-procedural
optimizations and inlining most compilers really do not track function
boundaries.

What you want is probably a 'santizer' version of preconditions: all
violations are detected and will guarantee that the program will abort.
That still allows optimizations as preconditions that have already been
checked do not need to be checked over and over. I do not doubt that
compilers will offer this option.

-- gpd

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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_759_1287874668.1447330213337
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, November 12, 2015 at 9:49:11 AM UTC, =
Jonas Persson wrote:<div dir=3D"ltr">[...]</div><div><br></div><blockquote =
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">Any UB from not fulfillin=
g the precondition should only happen inside the called function.<div><div =
class=3D"gmail_quote"><div>We would gain nothing from keeping a function ca=
ll with a broken precondition. It is better to be explicit and force the pr=
ogrammer to correct his code.</div><div></div></div></div></div></blockquot=
e><div><br><br>the problem is that C++ doesn&#39;t really distinguish betwe=
en different flavours of UB. C11 tried with Annex L, which I think that it =
is covered by the recent wave of &#39;sanitizer&#39; support in compilers. =
It has a non-zero cost though as the additional checks are non-free and som=
e optimizations are no longer possible.<br><br>Constraining UB inside a fun=
ction is also a lost cause. I&#39;m not a compiler writer, but as far as I =
understand, under aggressive inter-procedural optimizations and inlining mo=
st compilers really do not track function boundaries.</div><br>What you wan=
t is probably a &#39;santizer&#39; version of preconditions: all violations=
 are detected and will guarantee that the program will abort. That still al=
lows optimizations as preconditions that have already been checked do not n=
eed to be checked over and over. I do not doubt that compilers will offer t=
his option.<br><br>-- gpd<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_759_1287874668.1447330213337--
------=_Part_758_831930061.1447330213337--

.

--001a114b2d409dc2dd052457be46
Content-Type: text/plain; charset=UTF-8

On Thu, Nov 12, 2015 at 1:10 PM, Giovanni Piero Deretta <gpderetta@gmail.com
> wrote:

>
>
> On Thursday, November 12, 2015 at 9:49:11 AM UTC, Jonas Persson wrote:
> [...]
>
> Any UB from not fulfilling the precondition should only happen inside the
>> called function.
>> We would gain nothing from keeping a function call with a broken
>> precondition. It is better to be explicit and force the programmer to
>> correct his code.
>>
>
>
> the problem is that C++ doesn't really distinguish between different
> flavours of UB. C11 tried with Annex L, which I think that it is covered by
> the recent wave of 'sanitizer' support in compilers. It has a non-zero cost
> though as the additional checks are non-free and some optimizations are no
> longer possible.
>
> Constraining UB inside a function is also a lost cause. I'm not a compiler
> writer, but as far as I understand, under aggressive inter-procedural
> optimizations and inlining most compilers really do not track function
> boundaries.
>
> What you want is probably a 'santizer' version of preconditions: all
> violations are detected and will guarantee that the program will abort.
> That still allows optimizations as preconditions that have already been
> checked do not need to be checked over and over. I do not doubt that
> compilers will offer this option.
>

I'm not a compiler writer either so I don't understand al details about UB,
but even if UB is allowed to propagare everywhere and do whatever to the
code,
in practice it is used for optimizations while keeping the bahavior of the
program as close to expected as possible.

The problem of using a failed precondition to optimize away code is more
practical. Suppose I have a function with a precondition that is already
used in many places. I then make a slight modification to that
precondition, and now suddenly the compiler is able to figure out at
compile time that that precondition is false in some places. It then just
remove all the branches leading to those calls without telling.
This is very brittle.

To reformulate. What I want is that a contract violation that the compiler
figure out at compile time should be ill-formed and not undefined.

  / Jonas

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--001a114b2d409dc2dd052457be46
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, Nov 12, 2015 at 1:10 PM, Giovanni Piero Deretta <span dir=3D"lt=
r">&lt;<a href=3D"mailto:gpderetta@gmail.com" target=3D"_blank">gpderetta@g=
mail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><br><=
br>On Thursday, November 12, 2015 at 9:49:11 AM UTC, Jonas Persson wrote:<d=
iv dir=3D"ltr">[...]</div><span class=3D""><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<div dir=3D"ltr">Any UB from not fulfilling the precondition should only ha=
ppen inside the called function.<div><div class=3D"gmail_quote"><div>We wou=
ld gain nothing from keeping a function call with a broken precondition. It=
 is better to be explicit and force the programmer to correct his code.</di=
v><div></div></div></div></div></blockquote></span><div><br><br>the problem=
 is that C++ doesn&#39;t really distinguish between different flavours of U=
B. C11 tried with Annex L, which I think that it is covered by the recent w=
ave of &#39;sanitizer&#39; support in compilers. It has a non-zero cost tho=
ugh as the additional checks are non-free and some optimizations are no lon=
ger possible.<br><br>Constraining UB inside a function is also a lost cause=
.. I&#39;m not a compiler writer, but as far as I understand, under aggressi=
ve inter-procedural optimizations and inlining most compilers really do not=
 track function boundaries.</div><br>What you want is probably a &#39;santi=
zer&#39; version of preconditions: all violations are detected and will gua=
rantee that the program will abort. That still allows optimizations as prec=
onditions that have already been checked do not need to be checked over and=
 over. I do not doubt that compilers will offer this option.</div></blockqu=
ote><div>=C2=A0</div></div><div class=3D"gmail_extra">I&#39;m not a compile=
r writer either so I don&#39;t understand al details about UB, but even if =
UB is allowed to propagare everywhere and do whatever to the code,</div><di=
v class=3D"gmail_extra">in practice it is used for optimizations while keep=
ing the bahavior of the program as close to expected as possible.</div><div=
 class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">The problem of =
using a failed precondition to optimize away code is more practical. Suppos=
e I have a function with a precondition that is already used in many places=
.. I then make a slight modification to that precondition, and now suddenly =
the compiler is able to figure out at compile time that that precondition i=
s false in some places. It then just remove all the branches leading to tho=
se calls without telling.</div><div class=3D"gmail_extra">This is very brit=
tle.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">T=
o reformulate. What I want is that a contract violation that the compiler f=
igure out at compile time should be ill-formed and not undefined.</div><div=
 class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">=C2=A0 / Jonas<=
/div><div><br></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a114b2d409dc2dd052457be46--

.

--001a1147114a9f5f140524598b52
Content-Type: text/plain; charset=UTF-8

On Thu, Nov 12, 2015 at 1:16 PM, Jonas Persson <l.j.persson@gmail.com>
wrote:

>
>
> On Thu, Nov 12, 2015 at 1:10 PM, Giovanni Piero Deretta <
> gpderetta@gmail.com> wrote:
>
>>
>>
>> On Thursday, November 12, 2015 at 9:49:11 AM UTC, Jonas Persson wrote:
>> [...]
>>
>> Any UB from not fulfilling the precondition should only happen inside the
>>> called function.
>>> We would gain nothing from keeping a function call with a broken
>>> precondition. It is better to be explicit and force the programmer to
>>> correct his code.
>>>
>>
>>
>> the problem is that C++ doesn't really distinguish between different
>> flavours of UB. C11 tried with Annex L, which I think that it is covered by
>> the recent wave of 'sanitizer' support in compilers. It has a non-zero cost
>> though as the additional checks are non-free and some optimizations are no
>> longer possible.
>>
>> Constraining UB inside a function is also a lost cause. I'm not a
>> compiler writer, but as far as I understand, under aggressive
>> inter-procedural optimizations and inlining most compilers really do not
>> track function boundaries.
>>
>> What you want is probably a 'santizer' version of preconditions: all
>> violations are detected and will guarantee that the program will abort.
>> That still allows optimizations as preconditions that have already been
>> checked do not need to be checked over and over. I do not doubt that
>> compilers will offer this option.
>>
>
> I'm not a compiler writer either so I don't understand al details about
> UB, but even if UB is allowed to propagare everywhere and do whatever to
> the code,
> in practice it is used for optimizations while keeping the bahavior of the
> program as close to expected as possible.
>
> The problem of using a failed precondition to optimize away code is more
> practical. Suppose I have a function with a precondition that is already
> used in many places. I then make a slight modification to that
> precondition, and now suddenly the compiler is able to figure out at
> compile time that that precondition is false in some places. It then just
> remove all the branches leading to those calls without telling.
> This is very brittle.
>
> To reformulate. What I want is that a contract violation that the compiler
> figure out at compile time should be ill-formed and not undefined.
>

If that's what you want, then pass the appropriate compiler flags; in this
case -fsanitize=contract-conditions. Meanwhile, those of us who value speed
over safety will omit those flags and instead pass
-fassume-contract-conditions.

Please understand: we're perfectly happy to allow a contract violation to
result in a compile-time or runtime error; indeed we want that behavior for
our debug builds. However, in order to permit the optimizer free rein in
release builds, we need the standard to say that contract violation is UB.
Since UB encompasses all possible behaviors including compile-time and
run-time diagnostic termination, this permits your preferred behavior as
well as code pruning.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--001a1147114a9f5f140524598b52
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, Nov 12, 2015 at 1:16 PM, Jonas Persson <span dir=3D"ltr">&lt;<a href=3D=
"mailto:l.j.persson@gmail.com" target=3D"_blank">l.j.persson@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"><br><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Nov 12, 201=
5 at 1:10 PM, Giovanni Piero Deretta <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:gpderetta@gmail.com" target=3D"_blank">gpderetta@gmail.com</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-st=
yle:solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Thursday, November =
12, 2015 at 9:49:11 AM UTC, Jonas Persson wrote:<div dir=3D"ltr">[...]</div=
><span><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bor=
der-left-style:solid;padding-left:1ex"><div dir=3D"ltr">Any UB from not ful=
filling the precondition should only happen inside the called function.<div=
><div class=3D"gmail_quote"><div>We would gain nothing from keeping a funct=
ion call with a broken precondition. It is better to be explicit and force =
the programmer to correct his code.</div><div></div></div></div></div></blo=
ckquote></span><div><br><br>the problem is that C++ doesn&#39;t really dist=
inguish between different flavours of UB. C11 tried with Annex L, which I t=
hink that it is covered by the recent wave of &#39;sanitizer&#39; support i=
n compilers. It has a non-zero cost though as the additional checks are non=
-free and some optimizations are no longer possible.<br><br>Constraining UB=
 inside a function is also a lost cause. I&#39;m not a compiler writer, but=
 as far as I understand, under aggressive inter-procedural optimizations an=
d inlining most compilers really do not track function boundaries.</div><br=
>What you want is probably a &#39;santizer&#39; version of preconditions: a=
ll violations are detected and will guarantee that the program will abort. =
That still allows optimizations as preconditions that have already been che=
cked do not need to be checked over and over. I do not doubt that compilers=
 will offer this option.</div></blockquote><div>=C2=A0</div></div><div clas=
s=3D"gmail_extra">I&#39;m not a compiler writer either so I don&#39;t under=
stand al details about UB, but even if UB is allowed to propagare everywher=
e and do whatever to the code,</div><div class=3D"gmail_extra">in practice =
it is used for optimizations while keeping the bahavior of the program as c=
lose to expected as possible.</div><div class=3D"gmail_extra"><br></div><di=
v class=3D"gmail_extra">The problem of using a failed precondition to optim=
ize away code is more practical. Suppose I have a function with a precondit=
ion that is already used in many places. I then make a slight modification =
to that precondition, and now suddenly the compiler is able to figure out a=
t compile time that that precondition is false in some places. It then just=
 remove all the branches leading to those calls without telling.</div><div =
class=3D"gmail_extra">This is very brittle.</div><div class=3D"gmail_extra"=
><br></div><div class=3D"gmail_extra">To reformulate. What I want is that a=
 contract violation that the compiler figure out at compile time should be =
ill-formed and not undefined.</div></div></div></blockquote><div><br></div>=
<div>If that&#39;s what you want, then pass the appropriate compiler flags;=
 in this case -fsanitize=3Dcontract-conditions. Meanwhile, those of us who =
value speed over safety will omit those flags and instead pass -fassume-con=
tract-conditions.</div><div><br></div><div>Please understand: we&#39;re per=
fectly happy to allow a contract violation to result in a compile-time or r=
untime error; indeed we want that behavior for our debug builds. However, i=
n order to permit the optimizer free rein in release builds, we need the st=
andard to say that contract violation is UB. Since UB encompasses all possi=
ble behaviors including compile-time and run-time diagnostic termination, t=
his permits your preferred behavior as well as code pruning.</div></div></d=
iv></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1147114a9f5f140524598b52--

.

--047d7b3a829001f6aa05245cf866
Content-Type: text/plain; charset=UTF-8

On Thu, Nov 12, 2015 at 4:49 AM, Jonas Persson <l.j.persson@gmail.com>
wrote:

>
>
> On Thu, Nov 12, 2015 at 12:02 AM, Tony V E <tvaneerd@gmail.com> wrote:
>
>>
>>
>>>   So in the case of std::unreachable it is not allowed to complain since
>>>>> it cannot prove it will be called, but is is allowed to optimize as if it
>>>>> is not, even if that cannot be proved?
>>>>>
>>>>
>>>> I'm not 100% sure I understand what you are saying, but I think my
>>>> answer is:
>>>>
>>>> Yes, exactly.
>>>>
>>>> The point of facilities like this is for you, the developer, to tell
>>>> the compiler things that it can't (with current technology) prove on its
>>>> own.
>>>> It is your way of saying "trust me, even if you can't prove this, I
>>>> can".  So optimize as if it was proven.
>>>>
>>>> Then on the flip side, maybe in debug, ie no optimizations, we want to
>>>> say "but wait, if it turns out I was wrong, scream and yell at runtime".
>>>>
>>>> Tony
>>>>
>>>
>>> I agree that is a thing we need. What I am objecting to is using a
>>> funtction with a precondition to achive this. A precondition from the
>>> callers perspective is something that should be checked, not a thruth.
>>> For that it would be better to have something designed for the task,
>>> like __assume(expr)
>>>
>>>
>> Let's say the precondition on sqrt(x) is  x >= 0.  So for this (bad
>> contrived example) code:
>>
>>     if (x >= 0) {
>>        do_stuff();
>>     } else {
>>        x = sqrt(x);
>>        do_other_stuff();
>>     }
>>
>> Shouldn't the compiler be able to remove the else block completely?
>> (Maybe not in debug, but at least in some "max optimize" mode where it
>> assumes preconditions mean UB and thus never happen?)
>>
>>
> No, I dont think it should. It should fail. we dont know what x is. A
> precondition is there to force the caller check his data before calling,
> and in this case he hasn't. A correctness thing.
> void foo(auto x) {
>     if (x >= 0) {
>        do_stuff();
>     } else {
>        x = sqrt(x);  // Call sqrt. Or fail to compile as x is statically
> known to be incorrect here.
>        do_other_stuff();
>     }
> }
>

OK, I see, and I agree with you - in part.  If the compiler can look at
things and say "I can tell this leads to UB, which must never happen, so I
can remove this code", you'd prefer that it says "I can tell this leads to
UB, so I'm not going to compile it".

I think that is good for the obvious cases.  But I suspect there are cases,
such as inlining and/or templates, where the code isn't "wrong", but when a
few functions and templates are put together, the compiler determines a
certain path shouldn't happen.  And maybe, due to higher up program logic
it doesn't happen.  Not sure I can make a decent example:

void foo(auto x, Func f) {
    // for non-negative, do the other stuff first
    // otherwise it is important to do f() first (because blah...
    if (x >= 0) {
       do_stuff();
       x = f(x);
    } else {
       x = f(x);
       do_other_stuff();
    }
}

void handleMsg(Msg m) {
     switch (m.event) {
     case Blah:
         foo(m.data, sqrt);
         break;
     case Etc:
         ...
     }
}

Here the developer knows that a Msg with event == Blah always carries
non-negative data.  (Maybe Msg is sanitized before calling handleMsg or
before sending, etc).  So the developer knows that calling foo(m.data,
sqrt) will never send negative data and never fall into foo()'s else case,
and never hit undefined behaviour.  So passing sqrt for the function is not
UB.

However, the compiler (without whole-program optimization) can't tell
whether m.data might be negative.  ie can't tell in foo(x, f) whether x
will be negative.
Should the compiler fail to compile foo()?  Or maybe fail when compiling
handleMsg()?  Or should it look at foo(m.data, sqrt), including sqrt's x >=
0 precondition, and determine (when inlining into handleMsg) that the else
case can't happen (because it would be UB, not because m.data is known to
be non-negative), and can be removed?

I agree that the compiler should fail to compile when it sees UB that it
_knows_ the UB _will_ be reached.  But when it sees UB that it doesn't know
whether it will be reached or not (typically in a particular inlining
situation), the compiler can _assume_ it won't be reached and remove it.

Tony

P.S. in the above example, if handleMsg's preconditions were detailed
enough, maybe the compiler could _know_ that m.data is non-negative, and
then it could remove the code when inlining foo() by _forward_ propagating
the assumptions, instead of _back_ propagating via bumping into UB.  But
until all preconditions are fully detailed, sometimes the compiler can only
work backwards.

Maybe the compiler should issue an error/warning like "handleMsg() requires
a precondition of { m.data >= 0 when m.event == Blah }"?  I don't think we
are quite there yet, but current compilers do know how how far they
back-propagate a condition, so I suppose they could issue a warning near
the right place.  I just suspect that it would currently be a bunch of
noise with no good ways to modify the code to stop the warnings.

P.P.S. the other case I've seen is using if-statements in templates, when
you know it is a compile-time decision.  Like if (sizeof(T) < 16) {...}.
That can be done via enable_if or other tricks, but sometimes a "runtime"
if is simplest - particularly when you know that the compiler is just going
to remove the code completely under the right conditions.


[[unreachable]] on the other hand, is an assurance from the programmer that
> he know what he is doing. So unless the compiler can prove him wrong the
> compiler should accept.
> void foo(auto x) {
>     if (x >= 0) {
>        do_stuff();
>     } else {
>        [[unreachable]];  // branch can be optimized away since we say its
> ok.
>        do_other_stuff();
>     }
> }
> the same happen is we lift the precondition to the enclosing function.
> void foo(auto x) [expects:x>=0] {
>     if (x >= 0) {
>        do_stuff();
>     } else {
>        // branch can be optimized away as prcondition says its ok.
> Probably with a warning.
>        do_other_stuff();
>     }
> }
> Any UB from not fulfilling the precondition should only happen inside the
> called function.
> We would gain nothing from keeping a function call with a broken
> precondition. It is better to be explicit and force the programmer to
> correct his code.
>
>
>   / Jonas
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving 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/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--047d7b3a829001f6aa05245cf866
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, Nov 12, 2015 at 4:49 AM, Jonas Persson <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:l.j.persson@gmail.com" target=3D"_blank">l.j.persson@gmail.=
com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin: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, Nov 12, 2015 at 12:02 AM, Tony V E <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bord=
er-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_=
extra"><div class=3D"gmail_quote"><span><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><span><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);=
border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gm=
ail_extra"><div class=3D"gmail_quote"><div></div><div><div>=C2=A0 So in the=
 case of std::unreachable it is not allowed to complain since it cannot pro=
ve it will be called, but is is allowed to optimize as if it is not, even i=
f that cannot be proved?</div></div></div></div></div></blockquote><div><br=
></div></span><div>I&#39;m not 100% sure I understand what you are saying, =
but I think my answer is:<br><br>Yes, exactly.<br><br></div><div>The point =
of facilities like this is for you, the developer, to tell the compiler thi=
ngs that it can&#39;t (with current technology) prove on its own.<br></div>=
<div>It is your way of saying &quot;trust me, even if you can&#39;t prove t=
his, I can&quot;.=C2=A0 So optimize as if it was proven.<br><br></div><div>=
Then on the flip side, maybe in debug, ie no optimizations, we want to say =
&quot;but wait, if it turns out I was wrong, scream and yell at runtime&quo=
t;.<br><br></div><div>Tony</div></div></div></div></blockquote><div><br></d=
iv></div></div><div>I agree that is a thing we need. What I am objecting to=
 is using a funtction with a precondition to achive this. A precondition fr=
om the callers perspective is something that should be checked, not a thrut=
h.</div><div>For that it would be better to have something designed for the=
 task, like __assume(expr)=C2=A0</div><span><font color=3D"#888888"><div><b=
r></div></font></span></div></div></div></blockquote><div><br></div></span>=
<div>Let&#39;s say the precondition on sqrt(x) is=C2=A0 x &gt;=3D 0.=C2=A0 =
So for this (bad contrived example) code:<br><br></div><div>=C2=A0=C2=A0=C2=
=A0 if (x &gt;=3D 0) {<br></div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 d=
o_stuff();<br></div><div>=C2=A0=C2=A0=C2=A0 } else {<br></div><div>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x =3D sqrt(x);<br></div><div>=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 do_other_stuff();<br>=C2=A0=C2=A0=C2=A0 }<br><br></di=
v><div>Shouldn&#39;t the compiler be able to remove the else block complete=
ly?=C2=A0 (Maybe not in debug, but at least in some &quot;max optimize&quot=
; mode where it assumes preconditions mean UB and thus never happen?)<br><b=
r></div></div></div></div></blockquote><div><br></div></span><div>No, I don=
t think it should. It should fail. we dont know what x is. A precondition i=
s there to force the caller check his data before calling, and in this case=
 he hasn&#39;t. A correctness thing.</div><div>void foo(auto x) {</div><spa=
n class=3D""><div>=C2=A0 =C2=A0 if (x &gt;=3D 0) {</div><div>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0do_stuff();</div><div>=C2=A0 =C2=A0 } else {</div></span><div>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0x =3D sqrt(x); =C2=A0// Call sqrt. Or fail to co=
mpile as x is statically known to be incorrect here.</div><div>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0do_other_stuff();</div><div>=C2=A0 =C2=A0 }</div><div>}</d=
iv></div></div></div></blockquote><div><br></div><div>OK, I see, and I agre=
e with you - in part.=C2=A0 If the compiler can look at things and say &quo=
t;I can tell this leads to UB, which must never happen, so I can remove thi=
s code&quot;, you&#39;d prefer that it says &quot;I can tell this leads to =
UB, so I&#39;m not going to compile it&quot;.<br><br></div><div>I think tha=
t is good for the obvious cases.=C2=A0 But I suspect there are cases, such =
as inlining and/or templates, where the code isn&#39;t &quot;wrong&quot;, b=
ut when a few functions and templates are put together, the compiler determ=
ines a certain path shouldn&#39;t happen.=C2=A0 And maybe, due to higher up=
 program logic it doesn&#39;t happen.=C2=A0 Not sure I can make a decent ex=
ample:<br><br></div><div>void foo(auto x, Func f) {<br></div><div>=C2=A0=C2=
=A0=C2=A0 // for non-negative, do the other stuff first<br></div><div>=C2=
=A0=C2=A0=C2=A0 // otherwise it is important to do f() first (because blah.=
...<br></div><div>=C2=A0=C2=A0=C2=A0 if (x &gt;=3D 0) {<br></div><div>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 do_stuff();<br></div><div>=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 x =3D f(x);<br></div><div>=C2=A0=C2=A0=C2=A0 } else {<br=
></div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x =3D f(x);<br></div><div>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 do_other_stuff();<br>=C2=A0=C2=A0=C2=
=A0 }<br>}<br><br></div><div>void handleMsg(Msg m) {<br></div><div>=C2=A0=
=C2=A0=C2=A0=C2=A0 switch (m.event) {<br></div><div>=C2=A0=C2=A0=C2=A0=C2=
=A0 case Blah:<br></div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 foo(m.data, sqrt);<br></div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 break;<br></div><div>=C2=A0=C2=A0=C2=A0=C2=A0 case Etc:<br>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ...<br>=C2=A0=C2=A0=C2=A0=C2=
=A0 }<br>}<br><br></div><div>Here the developer knows that a Msg with event=
 =3D=3D Blah always carries non-negative data.=C2=A0 (Maybe Msg is sanitize=
d before calling handleMsg or before sending, etc).=C2=A0 So the developer =
knows that calling foo(m.data, sqrt) will never send negative data and neve=
r fall into foo()&#39;s else case, and never hit undefined behaviour.=C2=A0=
 So passing sqrt for the function is not UB.<br><br></div><div>However, the=
 compiler (without whole-program optimization) can&#39;t tell whether m.dat=
a might be negative.=C2=A0 ie can&#39;t tell in foo(x, f) whether x will be=
 negative.<br></div><div>Should the compiler fail to compile foo()?=C2=A0 O=
r maybe fail when compiling handleMsg()?=C2=A0 Or should it look at foo(m.d=
ata, sqrt), including sqrt&#39;s x &gt;=3D 0 precondition, and determine (w=
hen inlining into handleMsg) that the else case can&#39;t happen (because i=
t would be UB, not because m.data is known to be non-negative), and can be =
removed?<br><br></div><div>I agree that the compiler should fail to compile=
 when it sees UB that it _knows_ the UB _will_ be reached.=C2=A0 But when i=
t sees UB that it doesn&#39;t know whether it will be reached or not (typic=
ally in a particular inlining situation), the compiler can _assume_ it won&=
#39;t be reached and remove it.<br></div><div>=C2=A0<br></div><div>Tony<br>=
<br></div><div>P.S. in the above example, if handleMsg&#39;s preconditions =
were detailed enough, maybe the compiler could _know_ that m.data is non-ne=
gative, and then it could remove the code when inlining foo() by _forward_ =
propagating the assumptions, instead of _back_ propagating via bumping into=
 UB.=C2=A0 But until all preconditions are fully detailed, sometimes the co=
mpiler can only work backwards.<br></div><div><br>Maybe the compiler should=
 issue an error/warning like &quot;handleMsg() requires a precondition of {=
 m.data &gt;=3D 0 when m.event =3D=3D Blah }&quot;?=C2=A0 I don&#39;t think=
 we are quite there yet, but current compilers do know how how far they bac=
k-propagate a condition, so I suppose they could issue a warning near the r=
ight place.=C2=A0 I just suspect that it would currently be a bunch of nois=
e with no good ways to modify the code to stop the warnings.<br><br></div><=
div>P.P.S. the other case I&#39;ve seen is using if-statements in templates=
, when you know it is a compile-time decision.=C2=A0 Like if (sizeof(T) &lt=
; 16) {...}.=C2=A0 That can be done via enable_if or other tricks, but some=
times a &quot;runtime&quot; if is simplest - particularly when you know tha=
t the compiler is just going to remove the code completely under the right =
conditions.<br></div><div><br></div><div><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><div>[[unreachable]] on the other hand, is an assurance from the program=
mer that he know what he is doing. So unless the compiler can prove him wro=
ng the compiler should accept.</div><div>void foo(auto x) {</div><span clas=
s=3D""><div>=C2=A0 =C2=A0 if (x &gt;=3D 0) {</div><div>=C2=A0 =C2=A0 =C2=A0=
 =C2=A0do_stuff();</div><div>=C2=A0 =C2=A0 } else {</div></span><div>=C2=A0=
 =C2=A0 =C2=A0 =C2=A0[[unreachable]]; =C2=A0// branch can be optimized away=
 since we say its ok.</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0do_other_stuff()=
;</div><div>=C2=A0 =C2=A0 }</div><div>}</div><div>the same happen is we lif=
t the precondition to the enclosing function.</div><div>void foo(auto x) [e=
xpects:x&gt;=3D0] {</div><span class=3D""><div>=C2=A0 =C2=A0 if (x &gt;=3D =
0) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0do_stuff();</div><div>=C2=A0 =C2=
=A0 } else {</div></span><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0// branch can be o=
ptimized away as prcondition says its ok. Probably with a warning.</div><di=
v>=C2=A0 =C2=A0 =C2=A0 =C2=A0do_other_stuff();</div><div>=C2=A0 =C2=A0 }</d=
iv><div>}</div><div>Any UB from not fulfilling the precondition should only=
 happen inside the called function.</div><div>We would gain nothing from ke=
eping a function call with a broken precondition. It is better to be explic=
it and force the programmer to correct his code.</div><span class=3D"HOEnZb=
"><font color=3D"#888888"><div>=C2=A0</div><div><br></div><div>=C2=A0 / Jon=
as</div></font></span></div><br></div></div><div class=3D"HOEnZb"><div clas=
s=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b3a829001f6aa05245cf866--

.

--047d7b5d36b24274ca05245f8bee
Content-Type: text/plain; charset=UTF-8

On Thu, Nov 12, 2015 at 8:29 PM, Tony V E <tvaneerd@gmail.com> wrote:

>
>
> On Thu, Nov 12, 2015 at 4:49 AM, Jonas Persson <l.j.persson@gmail.com>
> wrote:
>>
>> No, I dont think it should. It should fail. we dont know what x is. A
>> precondition is there to force the caller check his data before calling,
>> and in this case he hasn't. A correctness thing.
>> void foo(auto x) {
>>     if (x >= 0) {
>>        do_stuff();
>>     } else {
>>        x = sqrt(x);  // Call sqrt. Or fail to compile as x is statically
>> known to be incorrect here.
>>        do_other_stuff();
>>     }
>> }
>>
>
> OK, I see, and I agree with you - in part.  If the compiler can look at
> things and say "I can tell this leads to UB, which must never happen, so I
> can remove this code", you'd prefer that it says "I can tell this leads to
> UB, so I'm not going to compile it".
>
> I think that is good for the obvious cases.  But I suspect there are
> cases, such as inlining and/or templates, where the code isn't "wrong", but
> when a few functions and templates are put together, the compiler
> determines a certain path shouldn't happen.  And maybe, due to higher up
> program logic it doesn't happen.  Not sure I can make a decent example:
>
> void foo(auto x, Func f) {
>     // for non-negative, do the other stuff first
>     // otherwise it is important to do f() first (because blah...
>     if (x >= 0) {
>        do_stuff();
>        x = f(x);
>     } else {
>        x = f(x);
>        do_other_stuff();
>     }
> }
>
> void handleMsg(Msg m) {
>      switch (m.event) {
>      case Blah:
>          foo(m.data, sqrt);
>          break;
>      case Etc:
>          ...
>      }
> }
>
> Here the developer knows that a Msg with event == Blah always carries
> non-negative data.  (Maybe Msg is sanitized before calling handleMsg or
> before sending, etc).  So the developer knows that calling foo(m.data,
> sqrt) will never send negative data and never fall into foo()'s else case,
> and never hit undefined behaviour.  So passing sqrt for the function is not
> UB.
>
> However, the compiler (without whole-program optimization) can't tell
> whether m.data might be negative.  ie can't tell in foo(x, f) whether x
> will be negative.
> Should the compiler fail to compile foo()?  Or maybe fail when compiling
> handleMsg()?  Or should it look at foo(m.data, sqrt), including sqrt's x >=
> 0 precondition, and determine (when inlining into handleMsg) that the else
> case can't happen (because it would be UB, not because m.data is known to
> be non-negative), and can be removed?
>
> I agree that the compiler should fail to compile when it sees UB that it
> _knows_ the UB _will_ be reached.  But when it sees UB that it doesn't know
> whether it will be reached or not (typically in a particular inlining
> situation), the compiler can _assume_ it won't be reached and remove it.
>
> Tony
>
> P.S. in the above example, if handleMsg's preconditions were detailed
> enough, maybe the compiler could _know_ that m.data is non-negative, and
> then it could remove the code when inlining foo() by _forward_ propagating
> the assumptions, instead of _back_ propagating via bumping into UB.  But
> until all preconditions are fully detailed, sometimes the compiler can only
> work backwards.
>
> Maybe the compiler should issue an error/warning like "handleMsg()
> requires a precondition of { m.data >= 0 when m.event == Blah }"?  I don't
> think we are quite there yet, but current compilers do know how how far
> they back-propagate a condition, so I suppose they could issue a warning
> near the right place.  I just suspect that it would currently be a bunch of
> noise with no good ways to modify the code to stop the warnings.
>
> P.P.S. the other case I've seen is using if-statements in templates, when
> you know it is a compile-time decision.  Like if (sizeof(T) < 16) {...}.
> That can be done via enable_if or other tricks, but sometimes a "runtime"
> if is simplest - particularly when you know that the compiler is just going
> to remove the code completely under the right conditions.
>
>
I dont think it is necessary to fall back to precondition UB here either.
It is better to tell the compiler what the value of x is, so it can
eliminate the else branch. Preconditions on handleMsg may work as you say,
but might be tricky to write. An easy way of just stating our assumptions
in the code would be a simpler first step.

void handleMsg(Msg m) {
  switch (m.event) {
    case Blah:
      assume(m.data>=0); // Give compiler info to eliminate branch.
Explicit point of UB if not true
      foo(m.data, sqrt);
      break;
    case Etc:
      ...
  }
}
assume(expr) here is like MS version. It tells the compiler 'expr' is true.
The compiler accepts unless it can prove otherwise
What we gain here is an explicit easy to spot location in the code where
undefined behavior is created. Allowing us to reason about the code and
possible bugs, and a place to start refactor into more correct code with
preconditions on handleMsg or postcondition on m.data()
If that is not enough to help the compiler it may be better to split the
function into foo and foo_non_neg.

I can see that this might become arbitrarily complex. But so will the task
of understanding why the code didnt work. So I think that it will always be
better to refactor into more explicit code, and there are no reason why
that would lead to slower code.

  / Jonas

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--047d7b5d36b24274ca05245f8bee
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, Nov 12, 2015 at 8:29 PM, Tony V E <span dir=3D"ltr">&lt;<a href=
=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-=
left-style:solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail=
_extra"><br><div class=3D"gmail_quote"><div><div class=3D"h5">On Thu, Nov 1=
2, 2015 at 4:49 AM, Jonas Persson <span dir=3D"ltr">&lt;<a href=3D"mailto:l=
..j.persson@gmail.com" target=3D"_blank">l.j.persson@gmail.com</a>&gt;</span=
> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style=
:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div c=
lass=3D"gmail_quote"><div>No, I dont think it should. It should fail. we do=
nt know what x is. A precondition is there to force the caller check his da=
ta before calling, and in this case he hasn&#39;t. A correctness thing.</di=
v><div>void foo(auto x) {</div><span><div>=C2=A0 =C2=A0 if (x &gt;=3D 0) {<=
/div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0do_stuff();</div><div>=C2=A0 =C2=A0 } =
else {</div></span><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0x =3D sqrt(x); =C2=A0// =
Call sqrt. Or fail to compile as x is statically known to be incorrect here=
..</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0do_other_stuff();</div><div>=C2=A0 =
=C2=A0 }</div><div>}</div></div></div></div></blockquote><div><br></div></d=
iv></div><div>OK, I see, and I agree with you - in part.=C2=A0 If the compi=
ler can look at things and say &quot;I can tell this leads to UB, which mus=
t never happen, so I can remove this code&quot;, you&#39;d prefer that it s=
ays &quot;I can tell this leads to UB, so I&#39;m not going to compile it&q=
uot;.<br><br></div><div>I think that is good for the obvious cases.=C2=A0 B=
ut I suspect there are cases, such as inlining and/or templates, where the =
code isn&#39;t &quot;wrong&quot;, but when a few functions and templates ar=
e put together, the compiler determines a certain path shouldn&#39;t happen=
..=C2=A0 And maybe, due to higher up program logic it doesn&#39;t happen.=C2=
=A0 Not sure I can make a decent example:<br><br></div><div>void foo(auto x=
, Func f) {<br></div><div>=C2=A0=C2=A0=C2=A0 // for non-negative, do the ot=
her stuff first<br></div><div>=C2=A0=C2=A0=C2=A0 // otherwise it is importa=
nt to do f() first (because blah...<br></div><span class=3D""><div>=C2=A0=
=C2=A0=C2=A0 if (x &gt;=3D 0) {<br></div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 do_stuff();<br></div></span><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 x =3D f(x);<br></div><div>=C2=A0=C2=A0=C2=A0 } else {<br></div><div>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x =3D f(x);<br></div><div>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 do_other_stuff();<br>=C2=A0=C2=A0=C2=A0 }<br>}<br>=
<br></div><div>void handleMsg(Msg m) {<br></div><div>=C2=A0=C2=A0=C2=A0=C2=
=A0 switch (m.event) {<br></div><div>=C2=A0=C2=A0=C2=A0=C2=A0 case Blah:<br=
></div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 foo(m.data, sq=
rt);<br></div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break;<=
br></div><div>=C2=A0=C2=A0=C2=A0=C2=A0 case Etc:<br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 ...<br>=C2=A0=C2=A0=C2=A0=C2=A0 }<br>}<br><br><=
/div><div>Here the developer knows that a Msg with event =3D=3D Blah always=
 carries non-negative data.=C2=A0 (Maybe Msg is sanitized before calling ha=
ndleMsg or before sending, etc).=C2=A0 So the developer knows that calling =
foo(m.data, sqrt) will never send negative data and never fall into foo()&#=
39;s else case, and never hit undefined behaviour.=C2=A0 So passing sqrt fo=
r the function is not UB.<br><br></div><div>However, the compiler (without =
whole-program optimization) can&#39;t tell whether m.data might be negative=
..=C2=A0 ie can&#39;t tell in foo(x, f) whether x will be negative.<br></div=
><div>Should the compiler fail to compile foo()?=C2=A0 Or maybe fail when c=
ompiling handleMsg()?=C2=A0 Or should it look at foo(m.data, sqrt), includi=
ng sqrt&#39;s x &gt;=3D 0 precondition, and determine (when inlining into h=
andleMsg) that the else case can&#39;t happen (because it would be UB, not =
because m.data is known to be non-negative), and can be removed?<br><br></d=
iv><div>I agree that the compiler should fail to compile when it sees UB th=
at it _knows_ the UB _will_ be reached.=C2=A0 But when it sees UB that it d=
oesn&#39;t know whether it will be reached or not (typically in a particula=
r inlining situation), the compiler can _assume_ it won&#39;t be reached an=
d remove it.<br></div><div>=C2=A0<br></div><div>Tony<br><br></div><div>P.S.=
 in the above example, if handleMsg&#39;s preconditions were detailed enoug=
h, maybe the compiler could _know_ that m.data is non-negative, and then it=
 could remove the code when inlining foo() by _forward_ propagating the ass=
umptions, instead of _back_ propagating via bumping into UB.=C2=A0 But unti=
l all preconditions are fully detailed, sometimes the compiler can only wor=
k backwards.<br></div><div><br>Maybe the compiler should issue an error/war=
ning like &quot;handleMsg() requires a precondition of { m.data &gt;=3D 0 w=
hen m.event =3D=3D Blah }&quot;?=C2=A0 I don&#39;t think we are quite there=
 yet, but current compilers do know how how far they back-propagate a condi=
tion, so I suppose they could issue a warning near the right place.=C2=A0 I=
 just suspect that it would currently be a bunch of noise with no good ways=
 to modify the code to stop the warnings.<br><br></div><div>P.P.S. the othe=
r case I&#39;ve seen is using if-statements in templates, when you know it =
is a compile-time decision.=C2=A0 Like if (sizeof(T) &lt; 16) {...}.=C2=A0 =
That can be done via enable_if or other tricks, but sometimes a &quot;runti=
me&quot; if is simplest - particularly when you know that the compiler is j=
ust going to remove the code completely under the right conditions.<br></di=
v><div><br></div></div></div></div></blockquote><div><br></div><div>I dont =
think it is necessary to fall back to precondition UB here either. It is be=
tter to tell the compiler what the value of x is, so it can eliminate the e=
lse branch. Preconditions on handleMsg may work as you say, but might be tr=
icky to write. An easy way of just stating our assumptions in the code woul=
d be a simpler first step.</div><div><br></div><div>void handleMsg(Msg m) {=
</div><div>=C2=A0 switch (m.event) {</div><div>=C2=A0 =C2=A0 case Blah:</di=
v><div>=C2=A0 =C2=A0 =C2=A0 assume(m.data&gt;=3D0); // Give compiler info t=
o eliminate branch. Explicit point of UB if not true</div><div>=C2=A0 =C2=
=A0 =C2=A0 foo(m.data, sqrt);</div><div>=C2=A0 =C2=A0 =C2=A0 break;</div><d=
iv>=C2=A0 =C2=A0 case Etc:</div><div>=C2=A0 =C2=A0 =C2=A0 ...</div><div>=C2=
=A0 }</div><div>}</div><div>assume(expr) here is like MS version. It tells =
the compiler &#39;expr&#39; is true. The compiler accepts unless it can pro=
ve otherwise</div><div>What we gain here is an explicit easy to spot locati=
on in the code where undefined behavior is created. Allowing us to reason a=
bout the code and possible bugs, and a place to start refactor into more co=
rrect code with preconditions on handleMsg or postcondition on m.data()</di=
v><div>If that is not enough to help the compiler it may be better to split=
 the function into foo and foo_non_neg.</div><div><br></div><div>I can see =
that this might become arbitrarily complex. But so will the task of underst=
anding why the code didnt work. So I think that it will always be better to=
 refactor into more explicit code, and there are no reason why that would l=
ead to slower code.</div><div>=C2=A0</div><div>=C2=A0 / Jonas</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b5d36b24274ca05245f8bee--

.

--001a11443346d1e86205245fa9ca
Content-Type: text/plain; charset=UTF-8

On Thu, Nov 12, 2015 at 4:24 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> On Thu, Nov 12, 2015 at 1:16 PM, Jonas Persson <l.j.persson@gmail.com>
> wrote:
>
>>
>>
>> On Thu, Nov 12, 2015 at 1:10 PM, Giovanni Piero Deretta <
>> gpderetta@gmail.com> wrote:
>>
>>>
>>>
>>> On Thursday, November 12, 2015 at 9:49:11 AM UTC, Jonas Persson wrote:
>>> [...]
>>>
>>> Any UB from not fulfilling the precondition should only happen inside
>>>> the called function.
>>>> We would gain nothing from keeping a function call with a broken
>>>> precondition. It is better to be explicit and force the programmer to
>>>> correct his code.
>>>>
>>>
>>>
>>> the problem is that C++ doesn't really distinguish between different
>>> flavours of UB. C11 tried with Annex L, which I think that it is covered by
>>> the recent wave of 'sanitizer' support in compilers. It has a non-zero cost
>>> though as the additional checks are non-free and some optimizations are no
>>> longer possible.
>>>
>>> Constraining UB inside a function is also a lost cause. I'm not a
>>> compiler writer, but as far as I understand, under aggressive
>>> inter-procedural optimizations and inlining most compilers really do not
>>> track function boundaries.
>>>
>>> What you want is probably a 'santizer' version of preconditions: all
>>> violations are detected and will guarantee that the program will abort.
>>> That still allows optimizations as preconditions that have already been
>>> checked do not need to be checked over and over. I do not doubt that
>>> compilers will offer this option.
>>>
>>
>> I'm not a compiler writer either so I don't understand al details about
>> UB, but even if UB is allowed to propagare everywhere and do whatever to
>> the code,
>> in practice it is used for optimizations while keeping the bahavior of
>> the program as close to expected as possible.
>>
>> The problem of using a failed precondition to optimize away code is more
>> practical. Suppose I have a function with a precondition that is already
>> used in many places. I then make a slight modification to that
>> precondition, and now suddenly the compiler is able to figure out at
>> compile time that that precondition is false in some places. It then just
>> remove all the branches leading to those calls without telling.
>> This is very brittle.
>>
>> To reformulate. What I want is that a contract violation that the
>> compiler figure out at compile time should be ill-formed and not undefined.
>>
>
> If that's what you want, then pass the appropriate compiler flags; in this
> case -fsanitize=contract-conditions. Meanwhile, those of us who value speed
> over safety will omit those flags and instead pass
> -fassume-contract-conditions.
>
> Please understand: we're perfectly happy to allow a contract violation to
> result in a compile-time or runtime error; indeed we want that behavior for
> our debug builds. However, in order to permit the optimizer free rein in
> release builds, we need the standard to say that contract violation is UB.
> Since UB encompasses all possible behaviors including compile-time and
> run-time diagnostic termination, this permits your preferred behavior as
> well as code pruning.
>

In this case UB will not give you any better performance. If you get UB on
the caller side of a precondition, it is becase the code is incorrect. If
that causes the compiler to fail, you can remove the failing code, giving
you the same as UB code pruning would. But with fewer subtle bugs.

  / Jonas

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--001a11443346d1e86205245fa9ca
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, Nov 12, 2015 at 4:24 PM, &#39;Edward Catmur&#39; via ISO C++ St=
andard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-propo=
sals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gma=
il_extra"><div class=3D"gmail_quote"><span class=3D"">On Thu, Nov 12, 2015 =
at 1:16 PM, Jonas Persson <span dir=3D"ltr">&lt;<a href=3D"mailto:l.j.perss=
on@gmail.com" target=3D"_blank">l.j.persson@gmail.com</a>&gt;</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"><br><div class=3D"gmail=
_extra"><br><div class=3D"gmail_quote">On Thu, Nov 12, 2015 at 1:10 PM, Gio=
vanni Piero Deretta <span dir=3D"ltr">&lt;<a href=3D"mailto:gpderetta@gmail=
..com" target=3D"_blank">gpderetta@gmail.com</a>&gt;</span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding=
-left:1ex"><div dir=3D"ltr"><br><br>On Thursday, November 12, 2015 at 9:49:=
11 AM UTC, Jonas Persson wrote:<div dir=3D"ltr">[...]</div><span><div><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:so=
lid;padding-left:1ex"><div dir=3D"ltr">Any UB from not fulfilling the preco=
ndition should only happen inside the called function.<div><div class=3D"gm=
ail_quote"><div>We would gain nothing from keeping a function call with a b=
roken precondition. It is better to be explicit and force the programmer to=
 correct his code.</div><div></div></div></div></div></blockquote></span><d=
iv><br><br>the problem is that C++ doesn&#39;t really distinguish between d=
ifferent flavours of UB. C11 tried with Annex L, which I think that it is c=
overed by the recent wave of &#39;sanitizer&#39; support in compilers. It h=
as a non-zero cost though as the additional checks are non-free and some op=
timizations are no longer possible.<br><br>Constraining UB inside a functio=
n is also a lost cause. I&#39;m not a compiler writer, but as far as I unde=
rstand, under aggressive inter-procedural optimizations and inlining most c=
ompilers really do not track function boundaries.</div><br>What you want is=
 probably a &#39;santizer&#39; version of preconditions: all violations are=
 detected and will guarantee that the program will abort. That still allows=
 optimizations as preconditions that have already been checked do not need =
to be checked over and over. I do not doubt that compilers will offer this =
option.</div></blockquote><div>=C2=A0</div></div><div class=3D"gmail_extra"=
>I&#39;m not a compiler writer either so I don&#39;t understand al details =
about UB, but even if UB is allowed to propagare everywhere and do whatever=
 to the code,</div><div class=3D"gmail_extra">in practice it is used for op=
timizations while keeping the bahavior of the program as close to expected =
as possible.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_=
extra">The problem of using a failed precondition to optimize away code is =
more practical. Suppose I have a function with a precondition that is alrea=
dy used in many places. I then make a slight modification to that precondit=
ion, and now suddenly the compiler is able to figure out at compile time th=
at that precondition is false in some places. It then just remove all the b=
ranches leading to those calls without telling.</div><div class=3D"gmail_ex=
tra">This is very brittle.</div><div class=3D"gmail_extra"><br></div><div c=
lass=3D"gmail_extra">To reformulate. What I want is that a contract violati=
on that the compiler figure out at compile time should be ill-formed and no=
t undefined.</div></div></div></blockquote><div><br></div></span><div>If th=
at&#39;s what you want, then pass the appropriate compiler flags; in this c=
ase -fsanitize=3Dcontract-conditions. Meanwhile, those of us who value spee=
d over safety will omit those flags and instead pass -fassume-contract-cond=
itions.</div><div><br></div><div>Please understand: we&#39;re perfectly hap=
py to allow a contract violation to result in a compile-time or runtime err=
or; indeed we want that behavior for our debug builds. However, in order to=
 permit the optimizer free rein in release builds, we need the standard to =
say that contract violation is UB. Since UB encompasses all possible behavi=
ors including compile-time and run-time diagnostic termination, this permit=
s your preferred behavior as well as code pruning.</div></div></div></div><=
/blockquote><div><br></div><div>In this case UB will not give you any bette=
r performance. If you get UB on the caller side of a precondition, it is be=
case the code is incorrect. If that causes the compiler to fail, you can re=
move the failing code, giving you the same as UB code pruning would. But wi=
th fewer subtle bugs.=C2=A0</div><div><br></div><div>=C2=A0 / Jonas</div></=
div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11443346d1e86205245fa9ca--

.

--001a11442716f1460105245fcc40
Content-Type: text/plain; charset=UTF-8

On 12 Nov 2015 22:42, "Jonas Persson" <l.j.persson@gmail.com> wrote:
>
>
>
> On Thu, Nov 12, 2015 at 4:24 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
>>
>> On Thu, Nov 12, 2015 at 1:16 PM, Jonas Persson <l.j.persson@gmail.com>
wrote:
>>>
>>>
>>>
>>> On Thu, Nov 12, 2015 at 1:10 PM, Giovanni Piero Deretta <
gpderetta@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>> On Thursday, November 12, 2015 at 9:49:11 AM UTC, Jonas Persson wrote:
>>>> [...]
>>>>
>>>>> Any UB from not fulfilling the precondition should only happen inside
the called function.
>>>>> We would gain nothing from keeping a function call with a broken
precondition. It is better to be explicit and force the programmer to
correct his code.
>>>>
>>>>
>>>>
>>>> the problem is that C++ doesn't really distinguish between different
flavours of UB. C11 tried with Annex L, which I think that it is covered by
the recent wave of 'sanitizer' support in compilers. It has a non-zero cost
though as the additional checks are non-free and some optimizations are no
longer possible.
>>>>
>>>> Constraining UB inside a function is also a lost cause. I'm not a
compiler writer, but as far as I understand, under aggressive
inter-procedural optimizations and inlining most compilers really do not
track function boundaries.
>>>>
>>>> What you want is probably a 'santizer' version of preconditions: all
violations are detected and will guarantee that the program will abort.
That still allows optimizations as preconditions that have already been
checked do not need to be checked over and over. I do not doubt that
compilers will offer this option.
>>>
>>>
>>> I'm not a compiler writer either so I don't understand al details about
UB, but even if UB is allowed to propagare everywhere and do whatever to
the code,
>>> in practice it is used for optimizations while keeping the bahavior of
the program as close to expected as possible.
>>>
>>> The problem of using a failed precondition to optimize away code is
more practical. Suppose I have a function with a precondition that is
already used in many places. I then make a slight modification to that
precondition, and now suddenly the compiler is able to figure out at
compile time that that precondition is false in some places. It then just
remove all the branches leading to those calls without telling.
>>> This is very brittle.
>>>
>>> To reformulate. What I want is that a contract violation that the
compiler figure out at compile time should be ill-formed and not undefined.
>>
>>
>> If that's what you want, then pass the appropriate compiler flags; in
this case -fsanitize=contract-conditions. Meanwhile, those of us who value
speed over safety will omit those flags and instead pass
-fassume-contract-conditions.
>>
>> Please understand: we're perfectly happy to allow a contract violation
to result in a compile-time or runtime error; indeed we want that behavior
for our debug builds. However, in order to permit the optimizer free rein
in release builds, we need the standard to say that contract violation is
UB. Since UB encompasses all possible behaviors including compile-time and
run-time diagnostic termination, this permits your preferred behavior as
well as code pruning.
>
>
> In this case UB will not give you any better performance. If you get UB
on the caller side of a precondition, it is becase the code is incorrect.
If that causes the compiler to fail, you can remove the failing code,
giving you the same as UB code pruning would. But with fewer subtle bugs.

True, for hand-written code. But invalid or unreachable code paths can
easily crop up in template code, macro expansions, platform-, library- or
configuration-dependent code, generated code, and in edge cases such as
loop or recursion terminating conditions. Why should we have to contort our
code to remove the failing code when the compiler can easily do it for us?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--001a11442716f1460105245fcc40
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
On 12 Nov 2015 22:42, &quot;Jonas Persson&quot; &lt;<a href=3D"mailto:l.j.p=
ersson@gmail.com">l.j.persson@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Thu, Nov 12, 2015 at 4:24 PM, &#39;Edward Catmur&#39; via ISO C++ S=
tandard - Future Proposals &lt;<a href=3D"mailto:std-proposals@isocpp.org">=
std-proposals@isocpp.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Thu, Nov 12, 2015 at 1:16 PM, Jonas Persson &lt;<a href=3D"mail=
to:l.j.persson@gmail.com">l.j.persson@gmail.com</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On Thu, Nov 12, 2015 at 1:10 PM, Giovanni Piero Deretta &lt;<a=
 href=3D"mailto:gpderetta@gmail.com">gpderetta@gmail.com</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; On Thursday, November 12, 2015 at 9:49:11 AM UTC, Jonas Pe=
rsson wrote:<br>
&gt;&gt;&gt;&gt; [...]<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Any UB from not fulfilling the precondition should onl=
y happen inside the called function.<br>
&gt;&gt;&gt;&gt;&gt; We would gain nothing from keeping a function call wit=
h a broken precondition. It is better to be explicit and force the programm=
er to correct his code.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; the problem is that C++ doesn&#39;t really distinguish bet=
ween different flavours of UB. C11 tried with Annex L, which I think that i=
t is covered by the recent wave of &#39;sanitizer&#39; support in compilers=
.. It has a non-zero cost though as the additional checks are non-free and s=
ome optimizations are no longer possible.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Constraining UB inside a function is also a lost cause. I&=
#39;m not a compiler writer, but as far as I understand, under aggressive i=
nter-procedural optimizations and inlining most compilers really do not tra=
ck function boundaries.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; What you want is probably a &#39;santizer&#39; version of =
preconditions: all violations are detected and will guarantee that the prog=
ram will abort. That still allows optimizations as preconditions that have =
already been checked do not need to be checked over and over. I do not doub=
t that compilers will offer this option.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; =C2=A0<br>
&gt;&gt;&gt; I&#39;m not a compiler writer either so I don&#39;t understand=
 al details about UB, but even if UB is allowed to propagare everywhere and=
 do whatever to the code,<br>
&gt;&gt;&gt; in practice it is used for optimizations while keeping the bah=
avior of the program as close to expected as possible.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The problem of using a failed precondition to optimize away co=
de is more practical. Suppose I have a function with a precondition that is=
 already used in many places. I then make a slight modification to that pre=
condition, and now suddenly the compiler is able to figure out at compile t=
ime that that precondition is false in some places. It then just remove all=
 the branches leading to those calls without telling.<br>
&gt;&gt;&gt; This is very brittle.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; To reformulate. What I want is that a contract violation that =
the compiler figure out at compile time should be ill-formed and not undefi=
ned.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; If that&#39;s what you want, then pass the appropriate compiler fl=
ags; in this case -fsanitize=3Dcontract-conditions. Meanwhile, those of us =
who value speed over safety will omit those flags and instead pass -fassume=
-contract-conditions.<br>
&gt;&gt;<br>
&gt;&gt; Please understand: we&#39;re perfectly happy to allow a contract v=
iolation to result in a compile-time or runtime error; indeed we want that =
behavior for our debug builds. However, in order to permit the optimizer fr=
ee rein in release builds, we need the standard to say that contract violat=
ion is UB. Since UB encompasses all possible behaviors including compile-ti=
me and run-time diagnostic termination, this permits your preferred behavio=
r as well as code pruning.<br>
&gt;<br>
&gt;<br>
&gt; In this case UB will not give you any better performance. If you get U=
B on the caller side of a precondition, it is becase the code is incorrect.=
 If that causes the compiler to fail, you can remove the failing code, givi=
ng you the same as UB code pruning would. But with fewer subtle bugs.=C2=A0=
</p>
<p dir=3D"ltr">True, for hand-written code. But invalid or unreachable code=
 paths can easily crop up in template code, macro expansions, platform-, li=
brary- or configuration-dependent code, generated code, and in edge cases s=
uch as loop or recursion terminating conditions. Why should we have to cont=
ort our code to remove the failing code when the compiler can easily do it =
for us? </p>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11442716f1460105245fcc40--

.

--047d7b5d36b2d55d030524602fc5
Content-Type: text/plain; charset=UTF-8

On Thu, Nov 12, 2015 at 11:52 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

>
> On 12 Nov 2015 22:42, "Jonas Persson" <l.j.persson@gmail.com> wrote:
> >
> >
> > In this case UB will not give you any better performance. If you get UB
> on the caller side of a precondition, it is becase the code is incorrect.
> If that causes the compiler to fail, you can remove the failing code,
> giving you the same as UB code pruning would. But with fewer subtle bugs.
>
> True, for hand-written code. But invalid or unreachable code paths can
> easily crop up in template code, macro expansions, platform-, library- or
> configuration-dependent code, generated code, and in edge cases such as
> loop or recursion terminating conditions. Why should we have to contort our
> code to remove the failing code when the compiler can easily do it for us?
>
Note that I'm not talking about disallowing UB in general here, only for
precondition callers.
The reason to make the ill-formed is that
1) the primary reason to use contracts is to catch misuse. Here we are
detecting misuse, but we are not telling.
2) it is not evident from reading the code that it will fail or be pruned.
Only the compiler knows.
3) We cannot be sure to catch this error by rebuilding in debug mode or
with sanitisers, becase any change to the compile process might cause
changes in inlining or other things so that the
compiler fails to figure out the failed precondition at compile time.

  / Jonas

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--047d7b5d36b2d55d030524602fc5
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, Nov 12, 2015 at 11:52 PM, &#39;Edward Catmur&#39; via ISO C++ S=
tandard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-prop=
osals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-st=
yle:solid;padding-left:1ex"><span class=3D""><p dir=3D"ltr"><br>
On 12 Nov 2015 22:42, &quot;Jonas Persson&quot; &lt;<a href=3D"mailto:l.j.p=
ersson@gmail.com" target=3D"_blank">l.j.persson@gmail.com</a>&gt; wrote:<br=
>
&gt;<br>&gt;<br>
&gt; In this case UB will not give you any better performance. If you get U=
B on the caller side of a precondition, it is becase the code is incorrect.=
 If that causes the compiler to fail, you can remove the failing code, givi=
ng you the same as UB code pruning would. But with fewer subtle bugs.=C2=A0=
</p>
</span><p dir=3D"ltr">True, for hand-written code. But invalid or unreachab=
le code paths can easily crop up in template code, macro expansions, platfo=
rm-, library- or configuration-dependent code, generated code, and in edge =
cases such as loop or recursion terminating conditions. Why should we have =
to contort our code to remove the failing code when the compiler can easily=
 do it for us?</p></blockquote><div>Note that I&#39;m not talking about dis=
allowing UB in general here, only for precondition callers.=C2=A0</div><div=
>The reason to make the ill-formed is that=C2=A0</div><div>1) the primary r=
eason to use contracts is to catch misuse. Here we are detecting misuse, bu=
t we are not telling.=C2=A0</div><div>2) it is not evident from reading the=
 code that it will fail or be pruned. Only the compiler knows.=C2=A0</div><=
div>3) We cannot be sure to catch this error by rebuilding in debug mode or=
 with sanitisers, becase any change to the compile process might cause chan=
ges in inlining or other things so that the</div><div>compiler fails to fig=
ure out the failed precondition at compile time.</div><div>=C2=A0</div></di=
v>=C2=A0 / Jonas</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b5d36b2d55d030524602fc5--

.

--001a11497420ba554e0524608932
Content-Type: text/plain; charset=UTF-8

On Thu, Nov 12, 2015 at 11:20 PM, Jonas Persson <l.j.persson@gmail.com>
wrote:

>
>
> On Thu, Nov 12, 2015 at 11:52 PM, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>>
>> On 12 Nov 2015 22:42, "Jonas Persson" <l.j.persson@gmail.com> wrote:
>> >
>> >
>> > In this case UB will not give you any better performance. If you get UB
>> on the caller side of a precondition, it is becase the code is incorrect.
>> If that causes the compiler to fail, you can remove the failing code,
>> giving you the same as UB code pruning would. But with fewer subtle bugs.
>>
>> True, for hand-written code. But invalid or unreachable code paths can
>> easily crop up in template code, macro expansions, platform-, library- or
>> configuration-dependent code, generated code, and in edge cases such as
>> loop or recursion terminating conditions. Why should we have to contort our
>> code to remove the failing code when the compiler can easily do it for us?
>>
> Note that I'm not talking about disallowing UB in general here, only for
> precondition callers.
> The reason to make the ill-formed is that
> 1) the primary reason to use contracts is to catch misuse. Here we are
> detecting misuse, but we are not telling.
> 2) it is not evident from reading the code that it will fail or be pruned.
> Only the compiler knows.
> 3) We cannot be sure to catch this error by rebuilding in debug mode or
> with sanitisers, becase any change to the compile process might cause
> changes in inlining or other things so that the
> compiler fails to figure out the failed precondition at compile time.
>

Making precondition failure ill-formed excludes far too much otherwise
well-formed code:

void print_column(string s, int width) {
    for (int i = 0; i != width; ++i)
        cout << ((i < s.size()) ? s[i] : ' ');  // X
}
print_column("hello", 10);

The compiler can prove that the program reaches line *X* with *i = 5*. But
s[5] is a precondition violation! Do you really want this code to be
ill-formed?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--001a11497420ba554e0524608932
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thu, Nov 12, 2015 at 11:20 PM, Jonas Persson <span dir=
=3D"ltr">&lt;<a href=3D"mailto:l.j.persson@gmail.com" target=3D"_blank">l.j=
..persson@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><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"><br>=
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Nov 12, 2=
015 at 11:52 PM, &#39;Edward Catmur&#39; via ISO C++ Standard - Future Prop=
osals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocpp.org" tar=
get=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width=
:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-lef=
t:1ex"><span><p dir=3D"ltr"><br>
On 12 Nov 2015 22:42, &quot;Jonas Persson&quot; &lt;<a href=3D"mailto:l.j.p=
ersson@gmail.com" target=3D"_blank">l.j.persson@gmail.com</a>&gt; wrote:<br=
>
&gt;<br>&gt;<br>
&gt; In this case UB will not give you any better performance. If you get U=
B on the caller side of a precondition, it is becase the code is incorrect.=
 If that causes the compiler to fail, you can remove the failing code, givi=
ng you the same as UB code pruning would. But with fewer subtle bugs.=C2=A0=
</p>
</span><p dir=3D"ltr">True, for hand-written code. But invalid or unreachab=
le code paths can easily crop up in template code, macro expansions, platfo=
rm-, library- or configuration-dependent code, generated code, and in edge =
cases such as loop or recursion terminating conditions. Why should we have =
to contort our code to remove the failing code when the compiler can easily=
 do it for us?</p></blockquote><div>Note that I&#39;m not talking about dis=
allowing UB in general here, only for precondition callers.=C2=A0</div><div=
>The reason to make the ill-formed is that=C2=A0</div><div>1) the primary r=
eason to use contracts is to catch misuse. Here we are detecting misuse, bu=
t we are not telling.=C2=A0</div><div>2) it is not evident from reading the=
 code that it will fail or be pruned. Only the compiler knows.=C2=A0</div><=
div>3) We cannot be sure to catch this error by rebuilding in debug mode or=
 with sanitisers, becase any change to the compile process might cause chan=
ges in inlining or other things so that the</div><div>compiler fails to fig=
ure out the failed precondition at compile time.</div></div></div></div></b=
lockquote><div><br></div><div>Making precondition failure ill-formed exclud=
es far too much otherwise well-formed code:</div><div><br></div><div><font =
face=3D"monospace, monospace">void print_column(string s, int width) {</fon=
t></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 for (int i =
=3D 0; i !=3D width; ++i)</font></div><div><font face=3D"monospace, monospa=
ce">=C2=A0 =C2=A0 =C2=A0 =C2=A0 cout &lt;&lt; ((i &lt; s.size()) ? s[i] : &=
#39; &#39;); =C2=A0// X</font></div><div><font face=3D"monospace, monospace=
">}</font></div><div><font face=3D"monospace, monospace">print_column(&quot=
;hello&quot;, 10);</font></div><div><br></div><div>The compiler can prove t=
hat the program reaches line <i>X</i> with <i>i =3D 5</i>. But <font face=
=3D"monospace, monospace">s[5]</font> is a precondition violation! Do you r=
eally want this code to be ill-formed?</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11497420ba554e0524608932--

.

--001a1144334696786a052466f431
Content-Type: text/plain; charset=UTF-8

On Fri, Nov 13, 2015 at 12:45 AM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> On Thu, Nov 12, 2015 at 11:20 PM, Jonas Persson <l.j.persson@gmail.com>
> wrote:
>
>>
>>
>> On Thu, Nov 12, 2015 at 11:52 PM, 'Edward Catmur' via ISO C++ Standard -
>> Future Proposals <std-proposals@isocpp.org> wrote:
>>
>>>
>>> On 12 Nov 2015 22:42, "Jonas Persson" <l.j.persson@gmail.com> wrote:
>>> >
>>> >
>>> > In this case UB will not give you any better performance. If you get
>>> UB on the caller side of a precondition, it is becase the code is
>>> incorrect. If that causes the compiler to fail, you can remove the failing
>>> code, giving you the same as UB code pruning would. But with fewer subtle
>>> bugs.
>>>
>>> True, for hand-written code. But invalid or unreachable code paths can
>>> easily crop up in template code, macro expansions, platform-, library- or
>>> configuration-dependent code, generated code, and in edge cases such as
>>> loop or recursion terminating conditions. Why should we have to contort our
>>> code to remove the failing code when the compiler can easily do it for us?
>>>
>> Note that I'm not talking about disallowing UB in general here, only for
>> precondition callers.
>> The reason to make the ill-formed is that
>> 1) the primary reason to use contracts is to catch misuse. Here we are
>> detecting misuse, but we are not telling.
>> 2) it is not evident from reading the code that it will fail or be
>> pruned. Only the compiler knows.
>> 3) We cannot be sure to catch this error by rebuilding in debug mode or
>> with sanitisers, becase any change to the compile process might cause
>> changes in inlining or other things so that the
>> compiler fails to figure out the failed precondition at compile time.
>>
>
> Making precondition failure ill-formed excludes far too much otherwise
> well-formed code:
>
> void print_column(string s, int width) {
>     for (int i = 0; i != width; ++i)
>         cout << ((i < s.size()) ? s[i] : ' ');  // X
> }
> print_column("hello", 10);
>
> The compiler can prove that the program reaches line *X* with *i = 5*.
> But s[5] is a precondition violation! Do you really want this code to be
> ill-formed?
>

How is that precondition violation?  If operator[] has a precodition it
should be i < size(), which is what you are checking.

On the other hand:
void print_column(string s, int width) {
    for (int i = 0; i != width; ++i)
        cout << s[i];  // X
}
print_column("hello", 10);

would be a violation and I would rather have the compile fail than an
access violation or no output at runtime.
Properly fixing that with

void print_column(string s, int width) [expects:width<s.size()] {
    for (int i = 0; i != width; ++i)
        cout << s[i];  // X
}
print_column("hello", 10);

would let the compiler optimize the print_column function and tell you,
hopefully at compile time, that your call to print_column is wrong.

  / Jonas

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--001a1144334696786a052466f431
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, Nov 13, 2015 at 12:45 AM, &#39;Edward Catmur&#39; via ISO C++ S=
tandard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-prop=
osals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-st=
yle:solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On Thu, Nov 1=
2, 2015 at 11:20 PM, Jonas Persson <span dir=3D"ltr">&lt;<a href=3D"mailto:=
l.j.persson@gmail.com" target=3D"_blank">l.j.persson@gmail.com</a>&gt;</spa=
n> wrote:<br></span><div class=3D"gmail_extra"><div class=3D"gmail_quote"><=
span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_e=
xtra"><br><div class=3D"gmail_quote">On Thu, Nov 12, 2015 at 11:52 PM, &#39=
;Edward Catmur&#39; via ISO C++ Standard - Future Proposals <span dir=3D"lt=
r">&lt;<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-pr=
oposals@isocpp.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><p dir=
=3D"ltr"><br>
On 12 Nov 2015 22:42, &quot;Jonas Persson&quot; &lt;<a href=3D"mailto:l.j.p=
ersson@gmail.com" target=3D"_blank">l.j.persson@gmail.com</a>&gt; wrote:<br=
>
&gt;<br>&gt;<br>
&gt; In this case UB will not give you any better performance. If you get U=
B on the caller side of a precondition, it is becase the code is incorrect.=
 If that causes the compiler to fail, you can remove the failing code, givi=
ng you the same as UB code pruning would. But with fewer subtle bugs.=C2=A0=
</p>
</span><p dir=3D"ltr">True, for hand-written code. But invalid or unreachab=
le code paths can easily crop up in template code, macro expansions, platfo=
rm-, library- or configuration-dependent code, generated code, and in edge =
cases such as loop or recursion terminating conditions. Why should we have =
to contort our code to remove the failing code when the compiler can easily=
 do it for us?</p></blockquote><div>Note that I&#39;m not talking about dis=
allowing UB in general here, only for precondition callers.=C2=A0</div><div=
>The reason to make the ill-formed is that=C2=A0</div><div>1) the primary r=
eason to use contracts is to catch misuse. Here we are detecting misuse, bu=
t we are not telling.=C2=A0</div><div>2) it is not evident from reading the=
 code that it will fail or be pruned. Only the compiler knows.=C2=A0</div><=
div>3) We cannot be sure to catch this error by rebuilding in debug mode or=
 with sanitisers, becase any change to the compile process might cause chan=
ges in inlining or other things so that the</div><div>compiler fails to fig=
ure out the failed precondition at compile time.</div></div></div></div></b=
lockquote><div><br></div></span><div>Making precondition failure ill-formed=
 excludes far too much otherwise well-formed code:</div><div><br></div><div=
><font face=3D"monospace, monospace">void print_column(string s, int width)=
 {</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 for (=
int i =3D 0; i !=3D width; ++i)</font></div><div><font face=3D"monospace, m=
onospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 cout &lt;&lt; ((i &lt; s.size()) ? s[=
i] : &#39; &#39;); =C2=A0// X</font></div><div><font face=3D"monospace, mon=
ospace">}</font></div><div><font face=3D"monospace, monospace">print_column=
(&quot;hello&quot;, 10);</font></div><div><br></div><div>The compiler can p=
rove that the program reaches line <i>X</i> with <i>i =3D 5</i>. But <font =
face=3D"monospace, monospace">s[5]</font> is a precondition violation! Do y=
ou really want this code to be ill-formed?</div></div></div></div></blockqu=
ote><div><br></div><div>How is that precondition violation?=C2=A0 If operat=
or[] has a precodition it should be i &lt; size(), which is what you are ch=
ecking.</div><div><br></div><div>On the other hand:</div><div><font face=3D=
"monospace, monospace">void print_column(string s, int width) {</font></div=
><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 for (int i =3D 0; i=
 !=3D width; ++i)</font></div><div><font face=3D"monospace, monospace">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 cout &lt;&lt; s[i]; =C2=A0// X</font></div><div><f=
ont face=3D"monospace, monospace">}</font></div><div><font face=3D"monospac=
e, monospace">print_column(&quot;hello&quot;, 10);</font></div><div><font f=
ace=3D"monospace, monospace"><br></font></div><div><font face=3D"monospace,=
 monospace">would be a violation and I would rather have the compile fail t=
han an access violation or no output at runtime.</font></div><div><font fac=
e=3D"monospace, monospace">Properly fixing that with</font></div><div><font=
 face=3D"monospace, monospace"><br></font></div><div><font face=3D"monospac=
e, monospace">void print_column(string s, int width) [expects:width&lt;s.si=
ze()] {</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 =
for (int i =3D 0; i !=3D width; ++i)</font></div><div><font face=3D"monospa=
ce, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 cout &lt;&lt; s[i]; =C2=A0// X</=
font></div><div><font face=3D"monospace, monospace">}</font></div><div><fon=
t face=3D"monospace, monospace">print_column(&quot;hello&quot;, 10);</font>=
</div><div><font face=3D"monospace, monospace"><br></font></div><div>would =
let the compiler optimize the print_column function and tell you, hopefully=
 at compile time, that your call to print_column is wrong.=C2=A0</div></div=
><br></div><div class=3D"gmail_extra">=C2=A0 / Jonas</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1144334696786a052466f431--

.

--001a1142532c2a09750524697588
Content-Type: text/plain; charset=UTF-8

On Fri, Nov 13, 2015 at 7:24 AM, Jonas Persson <l.j.persson@gmail.com>
wrote:

>
>
> On Fri, Nov 13, 2015 at 12:45 AM, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>> On Thu, Nov 12, 2015 at 11:20 PM, Jonas Persson <l.j.persson@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Thu, Nov 12, 2015 at 11:52 PM, 'Edward Catmur' via ISO C++ Standard -
>>> Future Proposals <std-proposals@isocpp.org> wrote:
>>>
>>>>
>>>> On 12 Nov 2015 22:42, "Jonas Persson" <l.j.persson@gmail.com> wrote:
>>>> >
>>>> >
>>>> > In this case UB will not give you any better performance. If you get
>>>> UB on the caller side of a precondition, it is becase the code is
>>>> incorrect. If that causes the compiler to fail, you can remove the failing
>>>> code, giving you the same as UB code pruning would. But with fewer subtle
>>>> bugs.
>>>>
>>>> True, for hand-written code. But invalid or unreachable code paths can
>>>> easily crop up in template code, macro expansions, platform-, library- or
>>>> configuration-dependent code, generated code, and in edge cases such as
>>>> loop or recursion terminating conditions. Why should we have to contort our
>>>> code to remove the failing code when the compiler can easily do it for us?
>>>>
>>> Note that I'm not talking about disallowing UB in general here, only for
>>> precondition callers.
>>> The reason to make the ill-formed is that
>>> 1) the primary reason to use contracts is to catch misuse. Here we are
>>> detecting misuse, but we are not telling.
>>> 2) it is not evident from reading the code that it will fail or be
>>> pruned. Only the compiler knows.
>>> 3) We cannot be sure to catch this error by rebuilding in debug mode or
>>> with sanitisers, becase any change to the compile process might cause
>>> changes in inlining or other things so that the
>>> compiler fails to figure out the failed precondition at compile time.
>>>
>>
>> Making precondition failure ill-formed excludes far too much otherwise
>> well-formed code:
>>
>> void print_column(string s, int width) {
>>     for (int i = 0; i != width; ++i)
>>         cout << ((i < s.size()) ? s[i] : ' ');  // X
>> }
>> print_column("hello", 10);
>>
>> The compiler can prove that the program reaches line *X* with *i = 5*.
>> But s[5] is a precondition violation! Do you really want this code to be
>> ill-formed?
>>
>
> How is that precondition violation?  If operator[] has a precodition it
> should be i < size(), which is what you are checking.
>
> On the other hand:
> void print_column(string s, int width) {
>     for (int i = 0; i != width; ++i)
>         cout << s[i];  // X
> }
> print_column("hello", 10);
>
> would be a violation and I would rather have the compile fail than an
> access violation or no output at runtime.
>

 OK, so let's write line *X* as:

        cout << ((*e*) ? s[i] : ' ');  // X

where *e* is an arbitrary (concrete) expression. In my code *e* is i <
s.size(); in yours it's true. You're demanding the compiler be required to
determine whether an arbitrary expression is extensionally equivalent to
the precondition. But this is impossible; it's equivalent to the halting
problem.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--001a1142532c2a09750524697588
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, Nov 13, 2015 at 7:24 AM, Jonas Persson <span dir=3D"ltr">&lt;<a href=3D=
"mailto:l.j.persson@gmail.com" target=3D"_blank">l.j.persson@gmail.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bord=
er-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">On Fri, Nov 13, 2015 at 12:45 AM,=
 &#39;Edward Catmur&#39; via ISO C++ Standard - Future Proposals <span dir=
=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">=
std-proposals@isocpp.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=
=3D"ltr"><span>On Thu, Nov 12, 2015 at 11:20 PM, Jonas Persson <span dir=3D=
"ltr">&lt;<a href=3D"mailto:l.j.persson@gmail.com" target=3D"_blank">l.j.pe=
rsson@gmail.com</a>&gt;</span> wrote:<br></span><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><span><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2=
04,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><br><div=
 class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Nov 12, 2015 =
at 11:52 PM, &#39;Edward Catmur&#39; via ISO C++ Standard - Future Proposal=
s <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocpp.org" target=
=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p=
x;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1=
ex"><span><p dir=3D"ltr"><br>
On 12 Nov 2015 22:42, &quot;Jonas Persson&quot; &lt;<a href=3D"mailto:l.j.p=
ersson@gmail.com" target=3D"_blank">l.j.persson@gmail.com</a>&gt; wrote:<br=
>
&gt;<br>&gt;<br>
&gt; In this case UB will not give you any better performance. If you get U=
B on the caller side of a precondition, it is becase the code is incorrect.=
 If that causes the compiler to fail, you can remove the failing code, givi=
ng you the same as UB code pruning would. But with fewer subtle bugs.=C2=A0=
</p>
</span><p dir=3D"ltr">True, for hand-written code. But invalid or unreachab=
le code paths can easily crop up in template code, macro expansions, platfo=
rm-, library- or configuration-dependent code, generated code, and in edge =
cases such as loop or recursion terminating conditions. Why should we have =
to contort our code to remove the failing code when the compiler can easily=
 do it for us?</p></blockquote><div>Note that I&#39;m not talking about dis=
allowing UB in general here, only for precondition callers.=C2=A0</div><div=
>The reason to make the ill-formed is that=C2=A0</div><div>1) the primary r=
eason to use contracts is to catch misuse. Here we are detecting misuse, bu=
t we are not telling.=C2=A0</div><div>2) it is not evident from reading the=
 code that it will fail or be pruned. Only the compiler knows.=C2=A0</div><=
div>3) We cannot be sure to catch this error by rebuilding in debug mode or=
 with sanitisers, becase any change to the compile process might cause chan=
ges in inlining or other things so that the</div><div>compiler fails to fig=
ure out the failed precondition at compile time.</div></div></div></div></b=
lockquote><div><br></div></span><div>Making precondition failure ill-formed=
 excludes far too much otherwise well-formed code:</div><div><br></div><div=
><font face=3D"monospace, monospace">void print_column(string s, int width)=
 {</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 for (=
int i =3D 0; i !=3D width; ++i)</font></div><div><font face=3D"monospace, m=
onospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 cout &lt;&lt; ((i &lt; s.size()) ? s[=
i] : &#39; &#39;); =C2=A0// X</font></div><div><font face=3D"monospace, mon=
ospace">}</font></div><div><font face=3D"monospace, monospace">print_column=
(&quot;hello&quot;, 10);</font></div><div><br></div><div>The compiler can p=
rove that the program reaches line <i>X</i> with <i>i =3D 5</i>. But <font =
face=3D"monospace, monospace">s[5]</font> is a precondition violation! Do y=
ou really want this code to be ill-formed?</div></div></div></div></blockqu=
ote><div><br></div><div>How is that precondition violation?=C2=A0 If operat=
or[] has a precodition it should be i &lt; size(), which is what you are ch=
ecking.</div><div><br></div><div>On the other hand:</div><div><font face=3D=
"monospace, monospace">void print_column(string s, int width) {</font></div=
><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 for (int i =3D 0; i=
 !=3D width; ++i)</font></div><div><font face=3D"monospace, monospace">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 cout &lt;&lt; s[i]; =C2=A0// X</font></div><div><f=
ont face=3D"monospace, monospace">}</font></div><div><font face=3D"monospac=
e, monospace">print_column(&quot;hello&quot;, 10);</font></div><div><font f=
ace=3D"monospace, monospace"><br></font></div><div><font face=3D"monospace,=
 monospace">would be a violation and I would rather have the compile fail t=
han an access violation or no output at runtime.</font></div></div></div></=
div></blockquote><div><br></div><div>=C2=A0OK, so let&#39;s write line <i>X=
</i> as:</div><div><br></div><div><div><font face=3D"monospace, monospace">=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cout &lt;&lt; ((<i>e</i>) ? s[i] : &#39; &#39;)=
; =C2=A0// X</font></div></div><div><font face=3D"monospace, monospace"><br=
></font></div><div><span style=3D"font-family:arial,helvetica,sans-serif">w=
here <i>e</i> is an arbitrary (concrete) expression. In my code <i>e</i> is=
 </span><font face=3D"monospace, monospace">i &lt; s.size()</font><span sty=
le=3D"font-family:arial,helvetica,sans-serif">; in yours it&#39;s </span><f=
ont face=3D"monospace, monospace">true</font><span style=3D"font-family:ari=
al,helvetica,sans-serif">. You&#39;re demanding the compiler be required to=
 determine whether an arbitrary expression is extensionally equivalent to t=
he precondition. But this is impossible; it&#39;s equivalent to the halting=
 problem.</span><br></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1142532c2a09750524697588--

.

--089e01176623c77e3a052469e875
Content-Type: text/plain; charset=UTF-8

On Fri, Nov 13, 2015 at 11:23 AM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> On Fri, Nov 13, 2015 at 7:24 AM, Jonas Persson <l.j.persson@gmail.com>
> wrote:
>
>>
>>
>> On Fri, Nov 13, 2015 at 12:45 AM, 'Edward Catmur' via ISO C++ Standard -
>> Future Proposals <std-proposals@isocpp.org> wrote:
>>
>>> On Thu, Nov 12, 2015 at 11:20 PM, Jonas Persson <l.j.persson@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Nov 12, 2015 at 11:52 PM, 'Edward Catmur' via ISO C++ Standard
>>>> - Future Proposals <std-proposals@isocpp.org> wrote:
>>>>
>>>>>
>>>>> On 12 Nov 2015 22:42, "Jonas Persson" <l.j.persson@gmail.com> wrote:
>>>>> >
>>>>> >
>>>>> > In this case UB will not give you any better performance. If you get
>>>>> UB on the caller side of a precondition, it is becase the code is
>>>>> incorrect. If that causes the compiler to fail, you can remove the failing
>>>>> code, giving you the same as UB code pruning would. But with fewer subtle
>>>>> bugs.
>>>>>
>>>>> True, for hand-written code. But invalid or unreachable code paths can
>>>>> easily crop up in template code, macro expansions, platform-, library- or
>>>>> configuration-dependent code, generated code, and in edge cases such as
>>>>> loop or recursion terminating conditions. Why should we have to contort our
>>>>> code to remove the failing code when the compiler can easily do it for us?
>>>>>
>>>> Note that I'm not talking about disallowing UB in general here, only
>>>> for precondition callers.
>>>> The reason to make the ill-formed is that
>>>> 1) the primary reason to use contracts is to catch misuse. Here we are
>>>> detecting misuse, but we are not telling.
>>>> 2) it is not evident from reading the code that it will fail or be
>>>> pruned. Only the compiler knows.
>>>> 3) We cannot be sure to catch this error by rebuilding in debug mode or
>>>> with sanitisers, becase any change to the compile process might cause
>>>> changes in inlining or other things so that the
>>>> compiler fails to figure out the failed precondition at compile time.
>>>>
>>>
>>> Making precondition failure ill-formed excludes far too much otherwise
>>> well-formed code:
>>>
>>> void print_column(string s, int width) {
>>>     for (int i = 0; i != width; ++i)
>>>         cout << ((i < s.size()) ? s[i] : ' ');  // X
>>> }
>>> print_column("hello", 10);
>>>
>>> The compiler can prove that the program reaches line *X* with *i = 5*.
>>> But s[5] is a precondition violation! Do you really want this code to
>>> be ill-formed?
>>>
>>
>> How is that precondition violation?  If operator[] has a precodition it
>> should be i < size(), which is what you are checking.
>>
>> On the other hand:
>> void print_column(string s, int width) {
>>     for (int i = 0; i != width; ++i)
>>         cout << s[i];  // X
>> }
>> print_column("hello", 10);
>>
>> would be a violation and I would rather have the compile fail than an
>> access violation or no output at runtime.
>>
>
>  OK, so let's write line *X* as:
>
>         cout << ((*e*) ? s[i] : ' ');  // X
>
> where *e* is an arbitrary (concrete) expression. In my code *e* is i <
> s.size(); in yours it's true. You're demanding the compiler be required
> to determine whether an arbitrary expression is extensionally equivalent to
> the precondition. But this is impossible; it's equivalent to the halting
> problem.
>
> No, I'm not saying it has to figure out anything. I am saying that iff it
do find out, at compile time, that a function will be called with a broken
precondition, it must fail and not cause UB.
If it don't figure out at compile time, and s[i] is actually called with
out of range i , it is well-formed and can be UB.

  / Jonas

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--089e01176623c77e3a052469e875
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, Nov 13, 2015 at 11:23 AM, &#39;Edward Catmur&#39; via ISO C++ S=
tandard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-prop=
osals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span>=
 wrote:<br><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 class=3D"gm=
ail_extra"><div class=3D"gmail_quote"><div><div class=3D"h5">On Fri, Nov 13=
, 2015 at 7:24 AM, Jonas Persson <span dir=3D"ltr">&lt;<a href=3D"mailto:l.=
j.persson@gmail.com" target=3D"_blank">l.j.persson@gmail.com</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-st=
yle:solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote">On Fri, Nov 13, 2015 at 12:45 AM, &#39;Edwa=
rd Catmur&#39; via ISO C++ Standard - Future Proposals <span dir=3D"ltr">&l=
t;<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-proposa=
ls@isocpp.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb=
(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><s=
pan>On Thu, Nov 12, 2015 at 11:20 PM, Jonas Persson <span dir=3D"ltr">&lt;<=
a href=3D"mailto:l.j.persson@gmail.com" target=3D"_blank">l.j.persson@gmail=
..com</a>&gt;</span> wrote:<br></span><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><span><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo=
rder-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"=
gmail_extra"><br><div class=3D"gmail_quote">On Thu, Nov 12, 2015 at 11:52 P=
M, &#39;Edward Catmur&#39; via ISO C++ Standard - Future Proposals <span di=
r=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank"=
>std-proposals@isocpp.org</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><=
p dir=3D"ltr"><br>
On 12 Nov 2015 22:42, &quot;Jonas Persson&quot; &lt;<a href=3D"mailto:l.j.p=
ersson@gmail.com" target=3D"_blank">l.j.persson@gmail.com</a>&gt; wrote:<br=
>
&gt;<br>&gt;<br>
&gt; In this case UB will not give you any better performance. If you get U=
B on the caller side of a precondition, it is becase the code is incorrect.=
 If that causes the compiler to fail, you can remove the failing code, givi=
ng you the same as UB code pruning would. But with fewer subtle bugs.=C2=A0=
</p>
</span><p dir=3D"ltr">True, for hand-written code. But invalid or unreachab=
le code paths can easily crop up in template code, macro expansions, platfo=
rm-, library- or configuration-dependent code, generated code, and in edge =
cases such as loop or recursion terminating conditions. Why should we have =
to contort our code to remove the failing code when the compiler can easily=
 do it for us?</p></blockquote><div>Note that I&#39;m not talking about dis=
allowing UB in general here, only for precondition callers.=C2=A0</div><div=
>The reason to make the ill-formed is that=C2=A0</div><div>1) the primary r=
eason to use contracts is to catch misuse. Here we are detecting misuse, bu=
t we are not telling.=C2=A0</div><div>2) it is not evident from reading the=
 code that it will fail or be pruned. Only the compiler knows.=C2=A0</div><=
div>3) We cannot be sure to catch this error by rebuilding in debug mode or=
 with sanitisers, becase any change to the compile process might cause chan=
ges in inlining or other things so that the</div><div>compiler fails to fig=
ure out the failed precondition at compile time.</div></div></div></div></b=
lockquote><div><br></div></span><div>Making precondition failure ill-formed=
 excludes far too much otherwise well-formed code:</div><div><br></div><div=
><font face=3D"monospace, monospace">void print_column(string s, int width)=
 {</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 for (=
int i =3D 0; i !=3D width; ++i)</font></div><div><font face=3D"monospace, m=
onospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 cout &lt;&lt; ((i &lt; s.size()) ? s[=
i] : &#39; &#39;); =C2=A0// X</font></div><div><font face=3D"monospace, mon=
ospace">}</font></div><div><font face=3D"monospace, monospace">print_column=
(&quot;hello&quot;, 10);</font></div><div><br></div><div>The compiler can p=
rove that the program reaches line <i>X</i> with <i>i =3D 5</i>. But <font =
face=3D"monospace, monospace">s[5]</font> is a precondition violation! Do y=
ou really want this code to be ill-formed?</div></div></div></div></blockqu=
ote><div><br></div><div>How is that precondition violation?=C2=A0 If operat=
or[] has a precodition it should be i &lt; size(), which is what you are ch=
ecking.</div><div><br></div><div>On the other hand:</div><div><font face=3D=
"monospace, monospace">void print_column(string s, int width) {</font></div=
><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 for (int i =3D 0; i=
 !=3D width; ++i)</font></div><div><font face=3D"monospace, monospace">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 cout &lt;&lt; s[i]; =C2=A0// X</font></div><div><f=
ont face=3D"monospace, monospace">}</font></div><div><font face=3D"monospac=
e, monospace">print_column(&quot;hello&quot;, 10);</font></div><div><font f=
ace=3D"monospace, monospace"><br></font></div><div><font face=3D"monospace,=
 monospace">would be a violation and I would rather have the compile fail t=
han an access violation or no output at runtime.</font></div></div></div></=
div></blockquote><div><br></div></div></div><div>=C2=A0OK, so let&#39;s wri=
te line <i>X</i> as:</div><div><br></div><div><div><font face=3D"monospace,=
 monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 cout &lt;&lt; ((<i>e</i>) ? s[i] : =
&#39; &#39;); =C2=A0// X</font></div></div><div><font face=3D"monospace, mo=
nospace"><br></font></div><div><span style=3D"font-family:arial,helvetica,s=
ans-serif">where <i>e</i> is an arbitrary (concrete) expression. In my code=
 <i>e</i> is </span><font face=3D"monospace, monospace">i &lt; s.size()</fo=
nt><span style=3D"font-family:arial,helvetica,sans-serif">; in yours it&#39=
;s </span><font face=3D"monospace, monospace">true</font><span style=3D"fon=
t-family:arial,helvetica,sans-serif">. You&#39;re demanding the compiler be=
 required to determine whether an arbitrary expression is extensionally equ=
ivalent to the precondition. But this is impossible; it&#39;s equivalent to=
 the halting problem.</span><br></div></div></div></div><div class=3D"HOEnZ=
b"><div class=3D"h5">

<p></p></div></div></blockquote></div>No, I&#39;m not saying it has to figu=
re out anything. I am saying that iff it do find out, at compile time, that=
 a function will be called with a broken precondition, it must fail and not=
 cause UB.</div><div class=3D"gmail_extra">If it don&#39;t figure out at co=
mpile time, and s[i] is actually called with out of range i , it is well-fo=
rmed and can be UB.</div><div class=3D"gmail_extra"><br></div><div class=3D=
"gmail_extra">=C2=A0 / Jonas</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e01176623c77e3a052469e875--

.

------=_Part_50_1713347368.1447412281860
Content-Type: multipart/alternative;
 boundary="----=_Part_51_147641648.1447412281861"

------=_Part_51_147641648.1447412281861
Content-Type: text/plain; charset=UTF-8

On Friday, November 13, 2015 at 10:24:01 AM UTC, Edward Catmur wrote:
>
> On Fri, Nov 13, 2015 at 7:24 AM, Jonas Persson <l.j.p...@gmail.com
> <javascript:>> wrote:
>
>>
>>
>> On Fri, Nov 13, 2015 at 12:45 AM, 'Edward Catmur' via ISO C++ Standard -
>> Future Proposals <std-pr...@isocpp.org <javascript:>> wrote:
>>
>>> On Thu, Nov 12, 2015 at 11:20 PM, Jonas Persson <l.j.p...@gmail.com
>>> <javascript:>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Nov 12, 2015 at 11:52 PM, 'Edward Catmur' via ISO C++ Standard
>>>> - Future Proposals <std-pr...@isocpp.org <javascript:>> wrote:
>>>>
>>>>>
>>>>> On 12 Nov 2015 22:42, "Jonas Persson" <l.j.p...@gmail.com
>>>>> <javascript:>> wrote:
>>>>> >
>>>>> >
>>>>> > In this case UB will not give you any better performance. If you get
>>>>> UB on the caller side of a precondition, it is becase the code is
>>>>> incorrect. If that causes the compiler to fail, you can remove the failing
>>>>> code, giving you the same as UB code pruning would. But with fewer subtle
>>>>> bugs.
>>>>>
>>>>> True, for hand-written code. But invalid or unreachable code paths can
>>>>> easily crop up in template code, macro expansions, platform-, library- or
>>>>> configuration-dependent code, generated code, and in edge cases such as
>>>>> loop or recursion terminating conditions. Why should we have to contort our
>>>>> code to remove the failing code when the compiler can easily do it for us?
>>>>>
>>>> Note that I'm not talking about disallowing UB in general here, only
>>>> for precondition callers.
>>>> The reason to make the ill-formed is that
>>>> 1) the primary reason to use contracts is to catch misuse. Here we are
>>>> detecting misuse, but we are not telling.
>>>> 2) it is not evident from reading the code that it will fail or be
>>>> pruned. Only the compiler knows.
>>>> 3) We cannot be sure to catch this error by rebuilding in debug mode or
>>>> with sanitisers, becase any change to the compile process might cause
>>>> changes in inlining or other things so that the
>>>> compiler fails to figure out the failed precondition at compile time.
>>>>
>>>
>>> Making precondition failure ill-formed excludes far too much otherwise
>>> well-formed code:
>>>
>>> void print_column(string s, int width) {
>>>     for (int i = 0; i != width; ++i)
>>>         cout << ((i < s.size()) ? s[i] : ' ');  // X
>>> }
>>> print_column("hello", 10);
>>>
>>> The compiler can prove that the program reaches line *X* with *i = 5*.
>>> But s[5] is a precondition violation! Do you really want this code to
>>> be ill-formed?
>>>
>>
>> How is that precondition violation?  If operator[] has a precodition it
>> should be i < size(), which is what you are checking.
>>
>> On the other hand:
>> void print_column(string s, int width) {
>>     for (int i = 0; i != width; ++i)
>>         cout << s[i];  // X
>> }
>> print_column("hello", 10);
>>
>> would be a violation and I would rather have the compile fail than an
>> access violation or no output at runtime.
>>
>
>  OK, so let's write line *X* as:
>
>         cout << ((*e*) ? s[i] : ' ');  // X
>
> where *e* is an arbitrary (concrete) expression. In my code *e* is i <
> s.size(); in yours it's true. You're demanding the compiler be required
> to determine whether an arbitrary expression is extensionally equivalent to
> the precondition. But this is impossible; it's equivalent to the halting
> problem.
>

technically he is not requiring that fort the compiler to catch every
possible precondition violation at compile time; he is only asking that
*if* the compiler can determine it then it should be a compile error. The
problem is that there is no realistic way to specify this behaviour in the
standard; this is the job for a static analyzer, not the compiler.


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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_51_147641648.1447412281861
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Friday, November 13, 2015 at 10:24:01 AM UTC, Edward Catmur 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"><div><div class=3D"=
gmail_quote">On Fri, Nov 13, 2015 at 7:24 AM, Jonas Persson <span dir=3D"lt=
r">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"P=
FxrSMfAFwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#=
39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;=
">l.j.p...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-co=
lor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"=
ltr"><br><div><br><div class=3D"gmail_quote">On Fri, Nov 13, 2015 at 12:45 =
AM, &#39;Edward Catmur&#39; via ISO C++ Standard - Future Proposals <span d=
ir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mai=
lto=3D"PFxrSMfAFwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javas=
cript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;retu=
rn true;">std-pr...@isocpp.org</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<div dir=3D"ltr"><span>On Thu, Nov 12, 2015 at 11:20 PM, Jonas Persson <spa=
n dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"PFxrSMfAFwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;ja=
vascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;r=
eturn true;">l.j.p...@gmail.com</a>&gt;</span> wrote:<br></span><div><div c=
lass=3D"gmail_quote"><span><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204=
);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><br><div><br><=
div class=3D"gmail_quote">On Thu, Nov 12, 2015 at 11:52 PM, &#39;Edward Cat=
mur&#39; via ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a h=
ref=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"PFxrSMfAFwAJ=
" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return =
true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">std-pr...=
@isocpp.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;padding-left:1ex"><span><p dir=3D"ltr">=
<br>
On 12 Nov 2015 22:42, &quot;Jonas Persson&quot; &lt;<a href=3D"javascript:"=
 target=3D"_blank" gdf-obfuscated-mailto=3D"PFxrSMfAFwAJ" rel=3D"nofollow" =
onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"t=
his.href=3D&#39;javascript:&#39;;return true;">l.j.p...@gmail.com</a>&gt; w=
rote:<br>
&gt;<br>&gt;<br>
&gt; In this case UB will not give you any better performance. If you get U=
B on the caller side of a precondition, it is becase the code is incorrect.=
 If that causes the compiler to fail, you can remove the failing code, givi=
ng you the same as UB code pruning would. But with fewer subtle bugs.=C2=A0=
</p>
</span><p dir=3D"ltr">True, for hand-written code. But invalid or unreachab=
le code paths can easily crop up in template code, macro expansions, platfo=
rm-, library- or configuration-dependent code, generated code, and in edge =
cases such as loop or recursion terminating conditions. Why should we have =
to contort our code to remove the failing code when the compiler can easily=
 do it for us?</p></blockquote><div>Note that I&#39;m not talking about dis=
allowing UB in general here, only for precondition callers.=C2=A0</div><div=
>The reason to make the ill-formed is that=C2=A0</div><div>1) the primary r=
eason to use contracts is to catch misuse. Here we are detecting misuse, bu=
t we are not telling.=C2=A0</div><div>2) it is not evident from reading the=
 code that it will fail or be pruned. Only the compiler knows.=C2=A0</div><=
div>3) We cannot be sure to catch this error by rebuilding in debug mode or=
 with sanitisers, becase any change to the compile process might cause chan=
ges in inlining or other things so that the</div><div>compiler fails to fig=
ure out the failed precondition at compile time.</div></div></div></div></b=
lockquote><div><br></div></span><div>Making precondition failure ill-formed=
 excludes far too much otherwise well-formed code:</div><div><br></div><div=
><font face=3D"monospace, monospace">void print_column(string s, int width)=
 {</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 for (=
int i =3D 0; i !=3D width; ++i)</font></div><div><font face=3D"monospace, m=
onospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 cout &lt;&lt; ((i &lt; s.size()) ? s[=
i] : &#39; &#39;); =C2=A0// X</font></div><div><font face=3D"monospace, mon=
ospace">}</font></div><div><font face=3D"monospace, monospace">print_column=
(&quot;hello&quot;, 10);</font></div><div><br></div><div>The compiler can p=
rove that the program reaches line <i>X</i> with <i>i =3D 5</i>. But <font =
face=3D"monospace, monospace">s[5]</font> is a precondition violation! Do y=
ou really want this code to be ill-formed?</div></div></div></div></blockqu=
ote><div><br></div><div>How is that precondition violation?=C2=A0 If operat=
or[] has a precodition it should be i &lt; size(), which is what you are ch=
ecking.</div><div><br></div><div>On the other hand:</div><div><font face=3D=
"monospace, monospace">void print_column(string s, int width) {</font></div=
><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 for (int i =3D 0; i=
 !=3D width; ++i)</font></div><div><font face=3D"monospace, monospace">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 cout &lt;&lt; s[i]; =C2=A0// X</font></div><div><f=
ont face=3D"monospace, monospace">}</font></div><div><font face=3D"monospac=
e, monospace">print_column(&quot;hello&quot;, 10);</font></div><div><font f=
ace=3D"monospace, monospace"><br></font></div><div><font face=3D"monospace,=
 monospace">would be a violation and I would rather have the compile fail t=
han an access violation or no output at runtime.</font></div></div></div></=
div></blockquote><div><br></div><div>=C2=A0OK, so let&#39;s write line <i>X=
</i> as:</div><div><br></div><div><div><font face=3D"monospace, monospace">=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cout &lt;&lt; ((<i>e</i>) ? s[i] : &#39; &#39;)=
; =C2=A0// X</font></div></div><div><font face=3D"monospace, monospace"><br=
></font></div><div><span style=3D"font-family:arial,helvetica,sans-serif">w=
here <i>e</i> is an arbitrary (concrete) expression. In my code <i>e</i> is=
 </span><font face=3D"monospace, monospace">i &lt; s.size()</font><span sty=
le=3D"font-family:arial,helvetica,sans-serif">; in yours it&#39;s </span><f=
ont face=3D"monospace, monospace">true</font><span style=3D"font-family:ari=
al,helvetica,sans-serif">. You&#39;re demanding the compiler be required to=
 determine whether an arbitrary expression is extensionally equivalent to t=
he precondition. But this is impossible; it&#39;s equivalent to the halting=
 problem.</span><br></div></div></div></div></blockquote><div><br>technical=
ly he is not requiring that fort the compiler to catch every possible preco=
ndition violation at compile time; he  is only asking that *if* the compile=
r can determine it then it should be a compile error. The problem is that t=
here is no realistic way to specify this behaviour in the standard; this is=
 the job for a static analyzer, not the compiler.<br>=C2=A0</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_51_147641648.1447412281861--
------=_Part_50_1713347368.1447412281860--

.

------=_Part_1768_1658796419.1447413296823
Content-Type: multipart/alternative;
 boundary="----=_Part_1769_1801260416.1447413296823"

------=_Part_1769_1801260416.1447413296823
Content-Type: text/plain; charset=UTF-8

On Friday, November 13, 2015 at 10:58:02 AM UTC, Giovanni Piero Deretta
wrote:
>
> On Friday, November 13, 2015 at 10:24:01 AM UTC, Edward Catmur wrote:
>>
>> On Fri, Nov 13, 2015 at 7:24 AM, Jonas Persson <l.j.p...@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Fri, Nov 13, 2015 at 12:45 AM, 'Edward Catmur' via ISO C++ Standard -
>>> Future Proposals <std-pr...@isocpp.org> wrote:
>>>
>>>> On Thu, Nov 12, 2015 at 11:20 PM, Jonas Persson <l.j.p...@gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Nov 12, 2015 at 11:52 PM, 'Edward Catmur' via ISO C++ Standard
>>>>> - Future Proposals <std-pr...@isocpp.org> wrote:
>>>>>
>>>>>>
>>>>>> On 12 Nov 2015 22:42, "Jonas Persson" <l.j.p...@gmail.com> wrote:
>>>>>> >
>>>>>> >
>>>>>> > In this case UB will not give you any better performance. If you
>>>>>> get UB on the caller side of a precondition, it is becase the code is
>>>>>> incorrect. If that causes the compiler to fail, you can remove the failing
>>>>>> code, giving you the same as UB code pruning would. But with fewer subtle
>>>>>> bugs.
>>>>>>
>>>>>> True, for hand-written code. But invalid or unreachable code paths
>>>>>> can easily crop up in template code, macro expansions, platform-, library-
>>>>>> or configuration-dependent code, generated code, and in edge cases such as
>>>>>> loop or recursion terminating conditions. Why should we have to contort our
>>>>>> code to remove the failing code when the compiler can easily do it for us?
>>>>>>
>>>>> Note that I'm not talking about disallowing UB in general here, only
>>>>> for precondition callers.
>>>>> The reason to make the ill-formed is that
>>>>> 1) the primary reason to use contracts is to catch misuse. Here we are
>>>>> detecting misuse, but we are not telling.
>>>>> 2) it is not evident from reading the code that it will fail or be
>>>>> pruned. Only the compiler knows.
>>>>> 3) We cannot be sure to catch this error by rebuilding in debug mode
>>>>> or with sanitisers, becase any change to the compile process might cause
>>>>> changes in inlining or other things so that the
>>>>> compiler fails to figure out the failed precondition at compile time.
>>>>>
>>>>
>>>> Making precondition failure ill-formed excludes far too much otherwise
>>>> well-formed code:
>>>>
>>>> void print_column(string s, int width) {
>>>>     for (int i = 0; i != width; ++i)
>>>>         cout << ((i < s.size()) ? s[i] : ' ');  // X
>>>> }
>>>> print_column("hello", 10);
>>>>
>>>> The compiler can prove that the program reaches line *X* with *i = 5*.
>>>> But s[5] is a precondition violation! Do you really want this code to
>>>> be ill-formed?
>>>>
>>>
>>> How is that precondition violation?  If operator[] has a precodition it
>>> should be i < size(), which is what you are checking.
>>>
>>> On the other hand:
>>> void print_column(string s, int width) {
>>>     for (int i = 0; i != width; ++i)
>>>         cout << s[i];  // X
>>> }
>>> print_column("hello", 10);
>>>
>>> would be a violation and I would rather have the compile fail than an
>>> access violation or no output at runtime.
>>>
>>
>>  OK, so let's write line *X* as:
>>
>>         cout << ((*e*) ? s[i] : ' ');  // X
>>
>> where *e* is an arbitrary (concrete) expression. In my code *e* is i <
>> s.size(); in yours it's true. You're demanding the compiler be required
>> to determine whether an arbitrary expression is extensionally equivalent to
>> the precondition. But this is impossible; it's equivalent to the halting
>> problem.
>>
>
> technically he is not requiring that fort the compiler to catch every
> possible precondition violation at compile time; he is only asking that
> *if* the compiler can determine it then it should be a compile error. The
> problem is that there is no realistic way to specify this behaviour in the
> standard; this is the job for a static analyzer, not the compiler.
>
>

Oh, it would also be annoying that whether a program compile depends on the
optimization level or the optimization passes enabled, although it is not
necessarily a new thing.


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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_1769_1801260416.1447413296823
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Friday, November 13, 2015 at 10:58:02 AM UTC, Giovanni Piero Deretta wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">On Friday, November 13, 201=
5 at 10:24:01 AM UTC, Edward Catmur wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Fri, Nov 13, 201=
5 at 7:24 AM, Jonas Persson <span dir=3D"ltr">&lt;<a rel=3D"nofollow">l.j.p=
....@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb=
(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><b=
r><div><br><div class=3D"gmail_quote">On Fri, Nov 13, 2015 at 12:45 AM, &#3=
9;Edward Catmur&#39; via ISO C++ Standard - Future Proposals <span dir=3D"l=
tr">&lt;<a rel=3D"nofollow">std-pr...@isocpp.org</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex"><div dir=3D"ltr"><span>On Thu, Nov 12, 2015 at 11:20 PM, Jo=
nas Persson <span dir=3D"ltr">&lt;<a rel=3D"nofollow">l.j.p...@gmail.com</a=
>&gt;</span> wrote:<br></span><div><div class=3D"gmail_quote"><span><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-=
left:1ex"><div dir=3D"ltr"><br><div><br><div class=3D"gmail_quote">On Thu, =
Nov 12, 2015 at 11:52 PM, &#39;Edward Catmur&#39; via ISO C++ Standard - Fu=
ture Proposals <span dir=3D"ltr">&lt;<a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,20=
4);border-left-style:solid;padding-left:1ex"><span><p dir=3D"ltr"><br>
On 12 Nov 2015 22:42, &quot;Jonas Persson&quot; &lt;<a rel=3D"nofollow">l.j=
..p...@gmail.com</a>&gt; wrote:<br>
&gt;<br>&gt;<br>
&gt; In this case UB will not give you any better performance. If you get U=
B on the caller side of a precondition, it is becase the code is incorrect.=
 If that causes the compiler to fail, you can remove the failing code, givi=
ng you the same as UB code pruning would. But with fewer subtle bugs.=C2=A0=
</p>
</span><p dir=3D"ltr">True, for hand-written code. But invalid or unreachab=
le code paths can easily crop up in template code, macro expansions, platfo=
rm-, library- or configuration-dependent code, generated code, and in edge =
cases such as loop or recursion terminating conditions. Why should we have =
to contort our code to remove the failing code when the compiler can easily=
 do it for us?</p></blockquote><div>Note that I&#39;m not talking about dis=
allowing UB in general here, only for precondition callers.=C2=A0</div><div=
>The reason to make the ill-formed is that=C2=A0</div><div>1) the primary r=
eason to use contracts is to catch misuse. Here we are detecting misuse, bu=
t we are not telling.=C2=A0</div><div>2) it is not evident from reading the=
 code that it will fail or be pruned. Only the compiler knows.=C2=A0</div><=
div>3) We cannot be sure to catch this error by rebuilding in debug mode or=
 with sanitisers, becase any change to the compile process might cause chan=
ges in inlining or other things so that the</div><div>compiler fails to fig=
ure out the failed precondition at compile time.</div></div></div></div></b=
lockquote><div><br></div></span><div>Making precondition failure ill-formed=
 excludes far too much otherwise well-formed code:</div><div><br></div><div=
><font face=3D"monospace, monospace">void print_column(string s, int width)=
 {</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 for (=
int i =3D 0; i !=3D width; ++i)</font></div><div><font face=3D"monospace, m=
onospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 cout &lt;&lt; ((i &lt; s.size()) ? s[=
i] : &#39; &#39;); =C2=A0// X</font></div><div><font face=3D"monospace, mon=
ospace">}</font></div><div><font face=3D"monospace, monospace">print_column=
(&quot;hello&quot;, 10);</font></div><div><br></div><div>The compiler can p=
rove that the program reaches line <i>X</i> with <i>i =3D 5</i>. But <font =
face=3D"monospace, monospace">s[5]</font> is a precondition violation! Do y=
ou really want this code to be ill-formed?</div></div></div></div></blockqu=
ote><div><br></div><div>How is that precondition violation?=C2=A0 If operat=
or[] has a precodition it should be i &lt; size(), which is what you are ch=
ecking.</div><div><br></div><div>On the other hand:</div><div><font face=3D=
"monospace, monospace">void print_column(string s, int width) {</font></div=
><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 for (int i =3D 0; i=
 !=3D width; ++i)</font></div><div><font face=3D"monospace, monospace">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 cout &lt;&lt; s[i]; =C2=A0// X</font></div><div><f=
ont face=3D"monospace, monospace">}</font></div><div><font face=3D"monospac=
e, monospace">print_column(&quot;hello&quot;, 10);</font></div><div><font f=
ace=3D"monospace, monospace"><br></font></div><div><font face=3D"monospace,=
 monospace">would be a violation and I would rather have the compile fail t=
han an access violation or no output at runtime.</font></div></div></div></=
div></blockquote><div><br></div><div>=C2=A0OK, so let&#39;s write line <i>X=
</i> as:</div><div><br></div><div><div><font face=3D"monospace, monospace">=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cout &lt;&lt; ((<i>e</i>) ? s[i] : &#39; &#39;)=
; =C2=A0// X</font></div></div><div><font face=3D"monospace, monospace"><br=
></font></div><div><span style=3D"font-family:arial,helvetica,sans-serif">w=
here <i>e</i> is an arbitrary (concrete) expression. In my code <i>e</i> is=
 </span><font face=3D"monospace, monospace">i &lt; s.size()</font><span sty=
le=3D"font-family:arial,helvetica,sans-serif">; in yours it&#39;s </span><f=
ont face=3D"monospace, monospace">true</font><span style=3D"font-family:ari=
al,helvetica,sans-serif">. You&#39;re demanding the compiler be required to=
 determine whether an arbitrary expression is extensionally equivalent to t=
he precondition. But this is impossible; it&#39;s equivalent to the halting=
 problem.</span><br></div></div></div></div></blockquote><div><br>technical=
ly he is not requiring that fort the compiler to catch every possible preco=
ndition violation at compile time; he  is only asking that *if* the compile=
r can determine it then it should be a compile error. The problem is that t=
here is no realistic way to specify this behaviour in the standard; this is=
 the job for a static analyzer, not the compiler.<br>=C2=A0</div></blockquo=
te><div><br>Oh, it would also be annoying that whether a program compile de=
pends on the optimization level or the optimization passes enabled, althoug=
h it is not necessarily a new thing.<br>=C2=A0</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1769_1801260416.1447413296823--
------=_Part_1768_1658796419.1447413296823--

.

--001a1148ef1049c12005246a409a
Content-Type: text/plain; charset=UTF-8

On Fri, Nov 13, 2015 at 10:56 AM, Jonas Persson <l.j.persson@gmail.com>
wrote:

>
>
> On Fri, Nov 13, 2015 at 11:23 AM, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>> On Fri, Nov 13, 2015 at 7:24 AM, Jonas Persson <l.j.persson@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Fri, Nov 13, 2015 at 12:45 AM, 'Edward Catmur' via ISO C++ Standard -
>>> Future Proposals <std-proposals@isocpp.org> wrote:
>>>
>>>> On Thu, Nov 12, 2015 at 11:20 PM, Jonas Persson <l.j.persson@gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Nov 12, 2015 at 11:52 PM, 'Edward Catmur' via ISO C++ Standard
>>>>> - Future Proposals <std-proposals@isocpp.org> wrote:
>>>>>
>>>>>>
>>>>>> On 12 Nov 2015 22:42, "Jonas Persson" <l.j.persson@gmail.com> wrote:
>>>>>> >
>>>>>> >
>>>>>> > In this case UB will not give you any better performance. If you
>>>>>> get UB on the caller side of a precondition, it is becase the code is
>>>>>> incorrect. If that causes the compiler to fail, you can remove the failing
>>>>>> code, giving you the same as UB code pruning would. But with fewer subtle
>>>>>> bugs.
>>>>>>
>>>>>> True, for hand-written code. But invalid or unreachable code paths
>>>>>> can easily crop up in template code, macro expansions, platform-, library-
>>>>>> or configuration-dependent code, generated code, and in edge cases such as
>>>>>> loop or recursion terminating conditions. Why should we have to contort our
>>>>>> code to remove the failing code when the compiler can easily do it for us?
>>>>>>
>>>>> Note that I'm not talking about disallowing UB in general here, only
>>>>> for precondition callers.
>>>>> The reason to make the ill-formed is that
>>>>> 1) the primary reason to use contracts is to catch misuse. Here we are
>>>>> detecting misuse, but we are not telling.
>>>>> 2) it is not evident from reading the code that it will fail or be
>>>>> pruned. Only the compiler knows.
>>>>> 3) We cannot be sure to catch this error by rebuilding in debug mode
>>>>> or with sanitisers, becase any change to the compile process might cause
>>>>> changes in inlining or other things so that the
>>>>> compiler fails to figure out the failed precondition at compile time.
>>>>>
>>>>
>>>> Making precondition failure ill-formed excludes far too much otherwise
>>>> well-formed code:
>>>>
>>>> void print_column(string s, int width) {
>>>>     for (int i = 0; i != width; ++i)
>>>>         cout << ((i < s.size()) ? s[i] : ' ');  // X
>>>> }
>>>> print_column("hello", 10);
>>>>
>>>> The compiler can prove that the program reaches line *X* with *i = 5*.
>>>> But s[5] is a precondition violation! Do you really want this code to
>>>> be ill-formed?
>>>>
>>>
>>> How is that precondition violation?  If operator[] has a precodition it
>>> should be i < size(), which is what you are checking.
>>>
>>> On the other hand:
>>> void print_column(string s, int width) {
>>>     for (int i = 0; i != width; ++i)
>>>         cout << s[i];  // X
>>> }
>>> print_column("hello", 10);
>>>
>>> would be a violation and I would rather have the compile fail than an
>>> access violation or no output at runtime.
>>>
>>
>>  OK, so let's write line *X* as:
>>
>>         cout << ((*e*) ? s[i] : ' ');  // X
>>
>> where *e* is an arbitrary (concrete) expression. In my code *e* is i <
>> s.size(); in yours it's true. You're demanding the compiler be required
>> to determine whether an arbitrary expression is extensionally equivalent to
>> the precondition. But this is impossible; it's equivalent to the halting
>> problem.
>>
>> No, I'm not saying it has to figure out anything. I am saying that iff it
> do find out, at compile time, that a function will be called with a broken
> precondition, it must fail and not cause UB.
> If it don't figure out at compile time, and s[i] is actually called with
> out of range i , it is well-formed and can be UB.
>

For any non-trivial program there is always some input that will cause that
function not to be called and so prevent that precondition being violated.
(For example, invoking the program with --help command line option). Even a
program where main violates a precondition may still be valid if linked
against a translation unit containing a variable with static storage
duration and namespace scope whose constructor terminates the program
before main is entered:

int main() { vector<int>()[5]; }
int i = (exit(1), 42);

So there would be absolutely no point in a compiler implementing your
requirement, as in practice the antecedent does not obtain.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--001a1148ef1049c12005246a409a
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, Nov 13, 2015 at 10:56 AM, Jonas Persson <span dir=3D"ltr">&lt;<a href=
=3D"mailto:l.j.persson@gmail.com" target=3D"_blank">l.j.persson@gmail.com</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D=
"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Nov 13, 2015 at 11:23 =
AM, &#39;Edward Catmur&#39; via ISO C++ Standard - Future Proposals <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank=
">std-proposals@isocpp.org</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div d=
ir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><div>=
On Fri, Nov 13, 2015 at 7:24 AM, Jonas Persson <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:l.j.persson@gmail.com" target=3D"_blank">l.j.persson@gmail.com<=
/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);=
border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Nov 13, 2015 at 12:=
45 AM, &#39;Edward Catmur&#39; via ISO C++ Standard - Future Proposals <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_bl=
ank">std-proposals@isocpp.org</a>&gt;</span> wrote:<br><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde=
r-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><di=
v dir=3D"ltr"><span>On Thu, Nov 12, 2015 at 11:20 PM, Jonas Persson <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:l.j.persson@gmail.com" target=3D"_blank">l=
..j.persson@gmail.com</a>&gt;</span> wrote:<br></span><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote"><span><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(=
204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><br=
><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Nov 12, =
2015 at 11:52 PM, &#39;Edward Catmur&#39; via ISO C++ Standard - Future Pro=
posals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocpp.org" ta=
rget=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex"><span><p dir=3D"ltr"><br>
On 12 Nov 2015 22:42, &quot;Jonas Persson&quot; &lt;<a href=3D"mailto:l.j.p=
ersson@gmail.com" target=3D"_blank">l.j.persson@gmail.com</a>&gt; wrote:<br=
>
&gt;<br>&gt;<br>
&gt; In this case UB will not give you any better performance. If you get U=
B on the caller side of a precondition, it is becase the code is incorrect.=
 If that causes the compiler to fail, you can remove the failing code, givi=
ng you the same as UB code pruning would. But with fewer subtle bugs.=C2=A0=
</p>
</span><p dir=3D"ltr">True, for hand-written code. But invalid or unreachab=
le code paths can easily crop up in template code, macro expansions, platfo=
rm-, library- or configuration-dependent code, generated code, and in edge =
cases such as loop or recursion terminating conditions. Why should we have =
to contort our code to remove the failing code when the compiler can easily=
 do it for us?</p></blockquote><div>Note that I&#39;m not talking about dis=
allowing UB in general here, only for precondition callers.=C2=A0</div><div=
>The reason to make the ill-formed is that=C2=A0</div><div>1) the primary r=
eason to use contracts is to catch misuse. Here we are detecting misuse, bu=
t we are not telling.=C2=A0</div><div>2) it is not evident from reading the=
 code that it will fail or be pruned. Only the compiler knows.=C2=A0</div><=
div>3) We cannot be sure to catch this error by rebuilding in debug mode or=
 with sanitisers, becase any change to the compile process might cause chan=
ges in inlining or other things so that the</div><div>compiler fails to fig=
ure out the failed precondition at compile time.</div></div></div></div></b=
lockquote><div><br></div></span><div>Making precondition failure ill-formed=
 excludes far too much otherwise well-formed code:</div><div><br></div><div=
><font face=3D"monospace, monospace">void print_column(string s, int width)=
 {</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 for (=
int i =3D 0; i !=3D width; ++i)</font></div><div><font face=3D"monospace, m=
onospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 cout &lt;&lt; ((i &lt; s.size()) ? s[=
i] : &#39; &#39;); =C2=A0// X</font></div><div><font face=3D"monospace, mon=
ospace">}</font></div><div><font face=3D"monospace, monospace">print_column=
(&quot;hello&quot;, 10);</font></div><div><br></div><div>The compiler can p=
rove that the program reaches line <i>X</i> with <i>i =3D 5</i>. But <font =
face=3D"monospace, monospace">s[5]</font> is a precondition violation! Do y=
ou really want this code to be ill-formed?</div></div></div></div></blockqu=
ote><div><br></div><div>How is that precondition violation?=C2=A0 If operat=
or[] has a precodition it should be i &lt; size(), which is what you are ch=
ecking.</div><div><br></div><div>On the other hand:</div><div><font face=3D=
"monospace, monospace">void print_column(string s, int width) {</font></div=
><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 for (int i =3D 0; i=
 !=3D width; ++i)</font></div><div><font face=3D"monospace, monospace">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 cout &lt;&lt; s[i]; =C2=A0// X</font></div><div><f=
ont face=3D"monospace, monospace">}</font></div><div><font face=3D"monospac=
e, monospace">print_column(&quot;hello&quot;, 10);</font></div><div><font f=
ace=3D"monospace, monospace"><br></font></div><div><font face=3D"monospace,=
 monospace">would be a violation and I would rather have the compile fail t=
han an access violation or no output at runtime.</font></div></div></div></=
div></blockquote><div><br></div></div></div><div>=C2=A0OK, so let&#39;s wri=
te line <i>X</i> as:</div><div><br></div><div><div><font face=3D"monospace,=
 monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 cout &lt;&lt; ((<i>e</i>) ? s[i] : =
&#39; &#39;); =C2=A0// X</font></div></div><div><font face=3D"monospace, mo=
nospace"><br></font></div><div><span style=3D"font-family:arial,helvetica,s=
ans-serif">where <i>e</i> is an arbitrary (concrete) expression. In my code=
 <i>e</i> is </span><font face=3D"monospace, monospace">i &lt; s.size()</fo=
nt><span style=3D"font-family:arial,helvetica,sans-serif">; in yours it&#39=
;s </span><font face=3D"monospace, monospace">true</font><span style=3D"fon=
t-family:arial,helvetica,sans-serif">. You&#39;re demanding the compiler be=
 required to determine whether an arbitrary expression is extensionally equ=
ivalent to the precondition. But this is impossible; it&#39;s equivalent to=
 the halting problem.</span><br></div></div></div></div><div><div>

<p></p></div></div></blockquote></div>No, I&#39;m not saying it has to figu=
re out anything. I am saying that iff it do find out, at compile time, that=
 a function will be called with a broken precondition, it must fail and not=
 cause UB.</div><div class=3D"gmail_extra">If it don&#39;t figure out at co=
mpile time, and s[i] is actually called with out of range i , it is well-fo=
rmed and can be UB.</div></div></blockquote><div><br></div><div>For any non=
-trivial program there is always some input that will cause that function n=
ot to be called and so prevent that precondition being violated. (For examp=
le, invoking the program with <font face=3D"monospace, monospace">--help</f=
ont> command line option). Even a program where <font face=3D"monospace, mo=
nospace">main</font> violates a precondition may still be valid if linked a=
gainst a translation unit containing a variable with static storage duratio=
n and namespace scope whose constructor terminates the program before <font=
 face=3D"monospace, monospace">main</font> is entered:</div><div><br></div>=
<div><div><font face=3D"monospace, monospace">int main() { vector&lt;int&gt=
;()[5]; }</font></div><div><font face=3D"monospace, monospace">int i =3D (e=
xit(1), 42);</font></div></div><div><br></div><div>So there would be absolu=
tely no point in a compiler implementing your requirement, as in practice t=
he antecedent does not obtain.</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1148ef1049c12005246a409a--

.

--001a114b2d40b9ba1305246d235b
Content-Type: text/plain; charset=UTF-8

On Fri, Nov 13, 2015 at 12:14 PM, Giovanni Piero Deretta <
gpderetta@gmail.com> wrote:

> On Friday, November 13, 2015 at 10:58:02 AM UTC, Giovanni Piero Deretta
> wrote:
>>
>>
>> Oh, it would also be annoying that whether a program compile depends on
> the optimization level or the optimization passes enabled, although it is
> not necessarily a new thing.
>

I agree that would be annoying.

But it would be even more annoying if code I expected to run got randomly
removed depending on optimization level.

Actually the compile error is not the central point. That could be a QoI
issue. The main problem was the suggestion earlier  in this thread where an
empty funtion with a false precondition

void unreachable() [[expects:false]] {}

would have the same semantic as [[unreachable]] and be able to prune
branches.

if a call to this unreachable() do anything other that abort in some way or
be a noop, it would be a big problem.
Basically making large reliable programs with contracts an impossible task
to write.


  / Jonas

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--001a114b2d40b9ba1305246d235b
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, Nov 13, 2015 at 12:14 PM, Giovanni Piero Deretta <span dir=3D"l=
tr">&lt;<a href=3D"mailto:gpderetta@gmail.com" target=3D"_blank">gpderetta@=
gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div class=3D""><div c=
lass=3D"h5">On Friday, November 13, 2015 at 10:58:02 AM UTC, Giovanni Piero=
 Deretta wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><br></blockquote></div></div><div>Oh, it wo=
uld also be annoying that whether a program compile depends on the optimiza=
tion level or the optimization passes enabled, although it is not necessari=
ly a new thing.<br></div></blockquote><div><br></div><div>I agree that woul=
d be annoying.</div><div><br></div><div>But it would be even more annoying =
if code I expected to run got randomly removed depending on optimization le=
vel.</div><div><br></div><div>Actually the compile error is not the central=
 point. That could be a QoI issue. The main problem was the suggestion earl=
ier =C2=A0in this thread where an empty funtion with a false precondition</=
div><div><br></div><div>void unreachable() [[expects:false]] {}</div><div><=
br></div><div>would have the same semantic as [[unreachable]] and be able t=
o prune branches.</div><div><br></div><div>if a call to this unreachable() =
do anything other that abort in some way or be a noop, it would be a big pr=
oblem.</div><div>Basically making large reliable programs with contracts an=
 impossible task to write.</div><div><br></div><div><br></div><div>=C2=A0 /=
 Jonas</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a114b2d40b9ba1305246d235b--

.

--001a114449f00a623005246d95f7
Content-Type: text/plain; charset=UTF-8

On Fri, Nov 13, 2015 at 12:20 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> On Fri, Nov 13, 2015 at 10:56 AM, Jonas Persson <l.j.persson@gmail.com>
> wrote:
>
>>
>> For any non-trivial program there is always some input that will cause
> that function not to be called and so prevent that precondition being
> violated. (For example, invoking the program with --help command line
> option). Even a program where main violates a precondition may still be
> valid if linked against a translation unit containing a variable with
> static storage duration and namespace scope whose constructor terminates
> the program before main is entered:
>
> int main() { vector<int>()[5]; }
> int i = (exit(1), 42);
>
> So there would be absolutely no point in a compiler implementing your
> requirement, as in practice the antecedent does not obtain.
>

The same could be said for most ill-formed code. And still some compilers
find it useful to issue diagnostics.
The earlier you get notified of incorrect code the better IMHO.

  / Jonas

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--001a114449f00a623005246d95f7
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, Nov 13, 2015 at 12:20 PM, &#39;Edward Catmur&#39; via ISO C++ S=
tandard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-prop=
osals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-st=
yle:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote"><div><div class=3D"h5">On Fri, Nov 13, 2015 at 10:5=
6 AM, Jonas Persson <span dir=3D"ltr">&lt;<a href=3D"mailto:l.j.persson@gma=
il.com" target=3D"_blank">l.j.persson@gmail.com</a>&gt;</span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pad=
ding-left:1ex"><div dir=3D"ltr"><br></div></blockquote></div></div><div>For=
 any non-trivial program there is always some input that will cause that fu=
nction not to be called and so prevent that precondition being violated. (F=
or example, invoking the program with <font face=3D"monospace, monospace">-=
-help</font> command line option). Even a program where <font face=3D"monos=
pace, monospace">main</font> violates a precondition may still be valid if =
linked against a translation unit containing a variable with static storage=
 duration and namespace scope whose constructor terminates the program befo=
re <font face=3D"monospace, monospace">main</font> is entered:</div><div><b=
r></div><div><div><font face=3D"monospace, monospace">int main() { vector&l=
t;int&gt;()[5]; }</font></div><div><font face=3D"monospace, monospace">int =
i =3D (exit(1), 42);</font></div></div><div><br></div><div>So there would b=
e absolutely no point in a compiler implementing your requirement, as in pr=
actice the antecedent does not obtain.</div></div></div></div></blockquote>=
<div><br></div><div>The same could be said for most ill-formed code. And st=
ill some compilers find it useful to issue diagnostics.</div><div>The earli=
er you get notified of incorrect code the better IMHO.</div><div>=C2=A0</di=
v><div>=C2=A0 / Jonas</div></div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a114449f00a623005246d95f7--

.

--089e012292d097963405246dd5a5
Content-Type: text/plain; charset=UTF-8

On Fri, Nov 13, 2015 at 2:47 PM, Jonas Persson <l.j.persson@gmail.com>
wrote:

>
>
> On Fri, Nov 13, 2015 at 12:14 PM, Giovanni Piero Deretta <
> gpderetta@gmail.com> wrote:
>
>> On Friday, November 13, 2015 at 10:58:02 AM UTC, Giovanni Piero Deretta
>> wrote:
>>>
>>>
>>> Oh, it would also be annoying that whether a program compile depends on
>> the optimization level or the optimization passes enabled, although it is
>> not necessarily a new thing.
>>
>
> I agree that would be annoying.
>
> But it would be even more annoying if code I expected to run got randomly
> removed depending on optimization level.
>
> Actually the compile error is not the central point. That could be a QoI
> issue. The main problem was the suggestion earlier  in this thread where an
> empty funtion with a false precondition
>
> void unreachable() [[expects:false]] {}
>
> would have the same semantic as [[unreachable]] and be able to prune
> branches.
>
> if a call to this unreachable() do anything other that abort in some way
> or be a noop, it would be a big problem.
> Basically making large reliable programs with contracts an impossible task
> to write.
>

Why is it a problem to you how other people choose to compile their
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e012292d097963405246dd5a5
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, Nov 13, 2015 at 2:47 PM, Jonas Persson <span dir=3D"ltr">&lt;<a href=3D=
"mailto:l.j.persson@gmail.com" target=3D"_blank">l.j.persson@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"><br><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Nov 13, 201=
5 at 12:14 PM, Giovanni Piero Deretta <span dir=3D"ltr">&lt;<a href=3D"mail=
to:gpderetta@gmail.com" target=3D"_blank">gpderetta@gmail.com</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex"><div><div>On Friday, November 13, 2015 at 10:5=
8:02 AM UTC, Giovanni Piero Deretta wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:=
rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br></blockquote=
></div></div><div>Oh, it would also be annoying that whether a program comp=
ile depends on the optimization level or the optimization passes enabled, a=
lthough it is not necessarily a new thing.<br></div></blockquote><div><br><=
/div><div>I agree that would be annoying.</div><div><br></div><div>But it w=
ould be even more annoying if code I expected to run got randomly removed d=
epending on optimization level.</div><div><br></div><div>Actually the compi=
le error is not the central point. That could be a QoI issue. The main prob=
lem was the suggestion earlier =C2=A0in this thread where an empty funtion =
with a false precondition</div><div><br></div><div>void unreachable() [[exp=
ects:false]] {}</div><div><br></div><div>would have the same semantic as [[=
unreachable]] and be able to prune branches.</div><div><br></div><div>if a =
call to this unreachable() do anything other that abort in some way or be a=
 noop, it would be a big problem.</div><div>Basically making large reliable=
 programs with contracts an impossible task to write.</div></div></div></di=
v></blockquote><div><br></div><div>Why is it a problem to you how other peo=
ple choose to compile their programs?</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e012292d097963405246dd5a5--

.

On 2015-11-13 05:23, 'Edward Catmur' wrote:
> On Fri, Nov 13, 2015 at 12:45 AM, 'Edward Catmur' wrote:
>> Making precondition failure ill-formed excludes far too much otherwise
>> well-formed code:
>>
>> void print_column(string s, int width) {
>>     for (int i = 0; i != width; ++i)
>>         cout << ((i < s.size()) ? s[i] : ' ');  // X
>> }
>> print_column("hello", 10);
>>
>> The compiler can prove that the program reaches line *X* with *i = 5*.
>> But s[5] is a precondition violation! Do you really want this code to be
>> ill-formed?
>
>  OK, so let's write line *X* as:
>
>         cout << ((*e*) ? s[i] : ' ');  // X
>
> where *e* is an arbitrary (concrete) expression. In my code *e* is i <
> s.size(); in yours it's true. You're demanding the compiler be required to
> determine whether an arbitrary expression is extensionally equivalent to
> the precondition. But this is impossible; it's equivalent to the halting
> problem.

So... you've violated your own premise. You said that the compiler *can
prove* that s[i] with i==5 is executed. Now you're saying it can't.

If it can't prove it, then the code isn't ill-formed. If it *can* prove
it, then yes, IMO the code should be ill-formed, because the code *will*
cause UB when executed.

So, actually, in neither example can the compiler prove that a
precondition is violated. In the first case, the compiler ought to be
able to prove that it *isn't* violated, in the second case we just don't
know. So neither would be ill-formed.

--
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--047d7b414244cc969d05246de471
Content-Type: text/plain; charset=UTF-8

On Fri, Nov 13, 2015 at 3:19 PM, Jonas Persson <l.j.persson@gmail.com>
wrote:

>
>
> On Fri, Nov 13, 2015 at 12:20 PM, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>> On Fri, Nov 13, 2015 at 10:56 AM, Jonas Persson <l.j.persson@gmail.com>
>> wrote:
>>
>>>
>>> For any non-trivial program there is always some input that will cause
>> that function not to be called and so prevent that precondition being
>> violated. (For example, invoking the program with --help command line
>> option). Even a program where main violates a precondition may still be
>> valid if linked against a translation unit containing a variable with
>> static storage duration and namespace scope whose constructor terminates
>> the program before main is entered:
>>
>> int main() { vector<int>()[5]; }
>> int i = (exit(1), 42);
>>
>> So there would be absolutely no point in a compiler implementing your
>> requirement, as in practice the antecedent does not obtain.
>>
>
> The same could be said for most ill-formed code. And still some compilers
> find it useful to issue diagnostics.
> The earlier you get notified of incorrect code the better IMHO.
>

Sure, it's a QOI issue. Compilers can't issue diagnostics on all invalid
code, as much of it is not executed for reasons that are obvious to the
programmer but not to the compiler.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--047d7b414244cc969d05246de471
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, Nov 13, 2015 at 3:19 PM, Jonas Persson <span dir=3D"ltr">&lt;<a href=3D=
"mailto:l.j.persson@gmail.com" target=3D"_blank">l.j.persson@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"><br><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Nov 13, 201=
5 at 12:20 PM, &#39;Edward Catmur&#39; via ISO C++ Standard - Future Propos=
als <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocpp.org" targe=
t=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><div><div>On Fri, Nov 13, 2015 at 10:56 AM, Jonas Persson <span dir=3D"ltr=
">&lt;<a href=3D"mailto:l.j.persson@gmail.com" target=3D"_blank">l.j.persso=
n@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><br>=
</div></blockquote></div></div><div>For any non-trivial program there is al=
ways some input that will cause that function not to be called and so preve=
nt that precondition being violated. (For example, invoking the program wit=
h <font face=3D"monospace, monospace">--help</font> command line option). E=
ven a program where <font face=3D"monospace, monospace">main</font> violate=
s a precondition may still be valid if linked against a translation unit co=
ntaining a variable with static storage duration and namespace scope whose =
constructor terminates the program before <font face=3D"monospace, monospac=
e">main</font> is entered:</div><div><br></div><div><div><font face=3D"mono=
space, monospace">int main() { vector&lt;int&gt;()[5]; }</font></div><div><=
font face=3D"monospace, monospace">int i =3D (exit(1), 42);</font></div></d=
iv><div><br></div><div>So there would be absolutely no point in a compiler =
implementing your requirement, as in practice the antecedent does not obtai=
n.</div></div></div></div></blockquote><div><br></div><div>The same could b=
e said for most ill-formed code. And still some compilers find it useful to=
 issue diagnostics.</div><div>The earlier you get notified of incorrect cod=
e the better IMHO.</div></div></div></div></blockquote><div><br></div><div>=
Sure, it&#39;s a QOI issue. Compilers can&#39;t issue diagnostics on all in=
valid code, as much of it is not executed for reasons that are obvious to t=
he programmer but not to the compiler.</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b414244cc969d05246de471--

.

On 2015-11-13 17:47, Jonas Persson wrote:
>
> On Fri, Nov 13, 2015 at 12:14 PM, Giovanni Piero Deretta
> <gpderetta@gmail.com <mailto:gpderetta@gmail.com>> wrote:
>
>     On Friday, November 13, 2015 at 10:58:02 AM UTC, Giovanni Piero
>     Deretta wrote:
>
>
>     Oh, it would also be annoying that whether a program compile depends
>     on the optimization level or the optimization passes enabled,
>     although it is not necessarily a new thing.
>
>
> I agree that would be annoying.
>
> But it would be even more annoying if code I expected to run got
> randomly removed depending on optimization level.

I think if you expect this code to run you wouldn't mark it with
unreachable() or [[unreachable]]. Again, for making the code have a
defined behavior in case of a precondition violation you should spell
out that behavior (e.g. by using terminate() or throw or whatever). At
which point the precondition is removed and the failure reaction becomes
part of the effects of your code. That is possible with the current
language.

The __assume(false) intrinsic is an optimization hint and that is
exactly what is missing in the language now. By using intrinsics like
this I fully expect the program to crash and burn horribly if I turn out
to be wrong when using it. If I don't want to take that responsibility
then I don't use it.

The switch/case example that was presented earlier is not the only use
of a tool like this. For instance, there is __builtin_assume_aligned in
gcc which basically tells that a pointer has at least the specified
alignment. I think, it should also work with __assume, but I never
tried. As a result the compiler may be able to generate more efficient
code working with that pointer. If the pointer is actually not as
strongly aligned then the program will misbehave, and that is expected.
Again, if you want this violation to be diagnosed in run time then you
should spell that in the code. There are probably other examples as well.

I'm not familiar with the contracts proposal, but if it allows to
implement the compiler hints like the above, then great, that's what we
want. If not, that's fine as well - we just need a different tool for 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--047d7b414244d1d0cb05246e2d39
Content-Type: text/plain; charset=UTF-8

On Fri, Nov 13, 2015 at 3:40 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2015-11-13 05:23, 'Edward Catmur' wrote:
> > On Fri, Nov 13, 2015 at 12:45 AM, 'Edward Catmur' wrote:
> >> Making precondition failure ill-formed excludes far too much otherwise
> >> well-formed code:
> >>
> >> void print_column(string s, int width) {
> >>     for (int i = 0; i != width; ++i)
> >>         cout << ((i < s.size()) ? s[i] : ' ');  // X
> >> }
> >> print_column("hello", 10);
> >>
> >> The compiler can prove that the program reaches line *X* with *i = 5*.
> >> But s[5] is a precondition violation! Do you really want this code to be
> >> ill-formed?
> >
> >  OK, so let's write line *X* as:
> >
> >         cout << ((*e*) ? s[i] : ' ');  // X
> >
> > where *e* is an arbitrary (concrete) expression. In my code *e* is i <
> > s.size(); in yours it's true. You're demanding the compiler be required
> to
> > determine whether an arbitrary expression is extensionally equivalent to
> > the precondition. But this is impossible; it's equivalent to the halting
> > problem.
>
> So... you've violated your own premise. You said that the compiler *can
> prove* that s[i] with i==5 is executed. Now you're saying it can't.
>

It can prove that an expression containing s[i] with i==5 is evaluated; it
may not be able to prove whether or not the subexpression s[i] is
evaluated. These are different things.

If it helps, consider replacing the loop with a hand-unrolled equivalent.


> If it can't prove it, then the code isn't ill-formed. If it *can* prove
> it, then yes, IMO the code should be ill-formed, because the code *will*
> cause UB when executed.
>

But who's to say that the code invoking UB *will* be executed?


> So, actually, in neither example can the compiler prove that a
> precondition is violated. In the first case, the compiler ought to be
> able to prove that it *isn't* violated, in the second case we just don't
> know. So neither would be ill-formed.
>

Which is precisely my point; sure, issue a warning-level diagnostic if
you're reasonably certain that a contract precondition will be violated,
but a compiler has to accept the program (at least in its default
configuration, without -Werror etc.), because only the programmer knows for
sure whether it will actually be violated in the intended execution of the
program.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--047d7b414244d1d0cb05246e2d39
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, Nov 13, 2015 at 3:40 PM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex">On 2015-11-13 05:23, &#39;Ed=
ward Catmur&#39; wrote:<br>
&gt; On Fri, Nov 13, 2015 at 12:45 AM, &#39;Edward Catmur&#39; wrote:<br>
&gt;&gt; Making precondition failure ill-formed excludes far too much other=
wise<br>
&gt;&gt; well-formed code:<br>
&gt;&gt;<br>
&gt;&gt; void print_column(string s, int width) {<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0for (int i =3D 0; i !=3D width; ++i)<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cout &lt;&lt; ((i &lt; s.size()) =
? s[i] : &#39; &#39;);=C2=A0 // X<br>
&gt;&gt; }<br>
&gt;&gt; print_column(&quot;hello&quot;, 10);<br>
&gt;&gt;<br>
&gt;&gt; The compiler can prove that the program reaches line *X* with *i =
=3D 5*.<br>
&gt;&gt; But s[5] is a precondition violation! Do you really want this code=
 to be<br>
&gt;&gt; ill-formed?<br>
&gt;<br>
&gt;=C2=A0 OK, so let&#39;s write line *X* as:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cout &lt;&lt; ((*e*) ? s[i] : &#39; &=
#39;);=C2=A0 // X<br>
&gt;<br>
&gt; where *e* is an arbitrary (concrete) expression. In my code *e* is i &=
lt;<br>
&gt; s.size(); in yours it&#39;s true. You&#39;re demanding the compiler be=
 required to<br>
&gt; determine whether an arbitrary expression is extensionally equivalent =
to<br>
&gt; the precondition. But this is impossible; it&#39;s equivalent to the h=
alting<br>
&gt; problem.<br>
<br>
So... you&#39;ve violated your own premise. You said that the compiler *can=
<br>
prove* that s[i] with i=3D=3D5 is executed. Now you&#39;re saying it can&#3=
9;t.<br></blockquote><div><br></div><div>It can prove that an expression co=
ntaining s[i] with i=3D=3D5 is evaluated; it may not be able to prove wheth=
er or not the subexpression s[i] is evaluated. These are different things.<=
/div><div><br></div><div>If it helps, consider replacing the loop with a ha=
nd-unrolled equivalent.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-co=
lor:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
If it can&#39;t prove it, then the code isn&#39;t ill-formed. If it *can* p=
rove<br>
it, then yes, IMO the code should be ill-formed, because the code *will*<br=
>
cause UB when executed.<br></blockquote><div><br></div><div>But who&#39;s t=
o say that the code invoking UB *will* be executed?</div><div>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex">
So, actually, in neither example can the compiler prove that a<br>
precondition is violated. In the first case, the compiler ought to be<br>
able to prove that it *isn&#39;t* violated, in the second case we just don&=
#39;t<br>
know. So neither would be ill-formed.<br></blockquote><div><br></div><div>W=
hich is precisely my point; sure, issue a warning-level diagnostic if you&#=
39;re reasonably certain that a contract precondition will be violated, but=
 a compiler has to accept the program (at least in its default configuratio=
n, without -Werror etc.), because only the programmer knows for sure whethe=
r it will actually be violated in the intended execution of the program.</d=
iv></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b414244d1d0cb05246e2d39--

.

This is a multi-part message in MIME format.
--------------030802020600050601090609
Content-Type: text/plain; charset=UTF-8; format=flowed

Am 13.11.2015 um 15:47 schrieb Jonas Persson:
> On Fri, Nov 13, 2015 at 12:14 PM, Giovanni Piero Deretta
> <gpderetta@gmail.com <mailto:gpderetta@gmail.com>> wrote:
>
>     On Friday, November 13, 2015 at 10:58:02 AM UTC, Giovanni Piero
>     Deretta wrote:
>
>
>     Oh, it would also be annoying that whether a program compile
>     depends on the optimization level or the optimization passes
>     enabled, although it is not necessarily a new thing.
>
>
> I agree that would be annoying.
>
> But it would be even more annoying if code I expected to run got
> randomly removed depending on optimization level.
That already happens, though it is far from "random". The compiler will
happily remove code that depends on UB at higher optimization levels.
Whether you expected it to run or not, or whether that annoys you, it
does not care.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--------------030802020600050601090609
Content-Type: text/html; charset=UTF-8

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Am 13.11.2015 um 15:47 schrieb Jonas Persson:<br>
    <blockquote
cite="mid:CADqyrC2wd4JFDh9wOyBPK2bhKwsWOJt09Q16AhF0hge09RPpAQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">On Fri, Nov 13, 2015 at 12:14 PM, Giovanni Piero
        Deretta <span dir="ltr">&lt;<a moz-do-not-send="true"
            href="mailto:gpderetta@gmail.com" target="_blank">gpderetta@gmail.com</a>&gt;</span>
        wrote:<br>
        <div class="gmail_extra">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
              <div class="">
                <div class="h5">On Friday, November 13, 2015 at 10:58:02
                  AM UTC, Giovanni Piero Deretta wrote:
                  <blockquote class="gmail_quote" style="margin:0px 0px
                    0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
                  </blockquote>
                </div>
              </div>
              <div>Oh, it would also be annoying that whether a program
                compile depends on the optimization level or the
                optimization passes enabled, although it is not
                necessarily a new thing.<br>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>I agree that would be annoying.</div>
            <div><br>
            </div>
            <div>But it would be even more annoying if code I expected
              to run got randomly removed depending on optimization
              level.</div>
          </div>
        </div>
      </div>
    </blockquote>
    That already happens, though it is far from "random". The compiler
    will happily remove code that depends on UB at higher optimization
    levels. Whether you expected it to run or not, or whether that
    annoys you, it does not care.<br>
    <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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

--------------030802020600050601090609--

.

--089e0122893cfb6bda0524aa4b45
Content-Type: text/plain; charset=UTF-8

On Fri, Nov 13, 2015 at 4:47 PM, Andrey Semashev <andrey.semashev@gmail.com>
wrote:
>
>
> I think if you expect this code to run you wouldn't mark it with
> unreachable() or [[unreachable]]. Again, for making the code have a defined
> behavior in case of a precondition violation you should spell out that
> behavior (e.g. by using terminate() or throw or whatever). At which point
> the precondition is removed and the failure reaction becomes part of the
> effects of your code. That is possible with the current language.
>
The point was that didnt mark it unreachable, I violated a precondition.
And I don't want a runtime effect if I can catch the error at compile time.


>
> The __assume(false) intrinsic is an optimization hint and that is exactly
> what is missing in the language now. By using intrinsics like this I fully
> expect the program to crash and burn horribly if I turn out to be wrong
> when using it. If I don't want to take that responsibility then I don't use
> it.
>
> The switch/case example that was presented earlier is not the only use of
> a tool like this. For instance, there is __builtin_assume_aligned in gcc
> which basically tells that a pointer has at least the specified alignment.
> I think, it should also work with __assume, but I never tried. As a result
> the compiler may be able to generate more efficient code working with that
> pointer. If the pointer is actually not as strongly aligned then the
> program will misbehave, and that is expected. Again, if you want this
> violation to be diagnosed in run time then you should spell that in the
> code. There are probably other examples as well.
>
> I'm not familiar with the contracts proposal, but if it allows to
> implement the compiler hints like the above, then great, that's what we
> want. If not, that's fine as well - we just need a different tool for this.
>
>
 I'm not really familliar with the details of the proposal either, it is
supposed to appear in the post kona mailing IIUC. But I am familliar with
contracts in programming.

The main purpose of contracts is to enforce correct usage. The performace
improvements is just a lucky side effect.
Contracts are also  by definition something that are known at design time,
and ideally should be statically enforced. That would give the best safety
and runtime performace. But it probably is a bit tricky to specify in the
standard, and there is a cost in programmer effort and compile times.
But hopefully it can be introduced somewhere in the future.

Considering this, it would be really unfortunate to assign sematics that
prevent compile time checking.
It is far better to provide some more specialized tools, like assume().

Assume can then be used to avoid compile errors from the precondition:

void foo() [[expects: x>0]] {}

void bar() {
  ...
  assume(x>0);
  foo();
}

assume introduces the UB in a explicit way that is easy to spot and
understand when reading the code.

  / Jonas

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--089e0122893cfb6bda0524aa4b45
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, Nov 13, 2015 at 4:47 PM, Andrey Semashev <span dir=3D"ltr">&lt;=
<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semas=
hev@gmail.com</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex">
<br>
I think if you expect this code to run you wouldn&#39;t mark it with unreac=
hable() or [[unreachable]]. Again, for making the code have a defined behav=
ior in case of a precondition violation you should spell out that behavior =
(e.g. by using terminate() or throw or whatever). At which point the precon=
dition is removed and the failure reaction becomes part of the effects of y=
our code. That is possible with the current language.<br></blockquote><div>=
The point was that didnt mark it unreachable, I violated a precondition. An=
d I don&#39;t want a runtime effect if I can catch the error at compile tim=
e.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);=
border-left-style:solid;padding-left:1ex">
<br>
The __assume(false) intrinsic is an optimization hint and that is exactly w=
hat is missing in the language now. By using intrinsics like this I fully e=
xpect the program to crash and burn horribly if I turn out to be wrong when=
 using it. If I don&#39;t want to take that responsibility then I don&#39;t=
 use it.<br>
<br>
The switch/case example that was presented earlier is not the only use of a=
 tool like this. For instance, there is __builtin_assume_aligned in gcc whi=
ch basically tells that a pointer has at least the specified alignment. I t=
hink, it should also work with __assume, but I never tried. As a result the=
 compiler may be able to generate more efficient code working with that poi=
nter. If the pointer is actually not as strongly aligned then the program w=
ill misbehave, and that is expected. Again, if you want this violation to b=
e diagnosed in run time then you should spell that in the code. There are p=
robably other examples as well.<br>
<br>
I&#39;m not familiar with the contracts proposal, but if it allows to imple=
ment the compiler hints like the above, then great, that&#39;s what we want=
.. If not, that&#39;s fine as well - we just need a different tool for this.=
<div class=3D""><div class=3D"h5"><br></div></div></blockquote><div><br></d=
iv><div>=C2=A0I&#39;m not really familliar with the details of the proposal=
 either, it is supposed to appear in the post kona mailing IIUC. But I am f=
amilliar with contracts in programming.=C2=A0</div><div><br></div><div>The =
main purpose of contracts is to enforce correct usage. The performace impro=
vements is just a lucky side effect.</div><div>Contracts are also =C2=A0by =
definition something that are known at design time, and ideally should be s=
tatically enforced. That would give the best safety and runtime performace.=
 But it probably is a bit tricky to specify in the standard, and there is a=
 cost in programmer effort and compile times.</div><div>But hopefully it ca=
n be introduced somewhere in the future.</div><div><br></div><div>Consideri=
ng this, it would be really unfortunate to assign sematics that prevent com=
pile time checking.</div><div>It is far better to provide some more special=
ized tools, like assume().</div><div><br></div><div>Assume can then be used=
 to avoid compile errors from the precondition:</div><div><br></div><div>vo=
id foo() [[expects: x&gt;0]] {}</div><div><br></div><div>void bar() {</div>=
<div>=C2=A0 ...</div><div>=C2=A0 assume(x&gt;0);</div><div>=C2=A0 foo();</d=
iv><div>}</div><div><br></div><div>assume introduces the UB in a explicit w=
ay that is easy to spot and understand when reading the code.</div><div><br=
></div><div>=C2=A0 / Jonas</div><div><br></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0122893cfb6bda0524aa4b45--

.

--001a1145aa8caa790d0524aa5155
Content-Type: text/plain; charset=UTF-8

On Sat, Nov 14, 2015 at 2:38 AM, Miro Knejp <miro.knejp@gmail.com> wrote:
>
> That already happens, though it is far from "random". The compiler will
> happily remove code that depends on UB at higher optimization levels.
> Whether you expected it to run or not, or whether that annoys you, it does
> not care.
>

The issue was not if UB is allowed to remove code or not. I have no problem
with that. The issue was that a precondition validate should be ill-formed
rather that UB.

  / Jonas

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--001a1145aa8caa790d0524aa5155
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 Sat, Nov 14, 2015 at 2:38 AM, Miro Knejp <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:miro.knejp@gmail.com" target=3D"_blank">miro.knejp@gmail.com</=
a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#0000=
00"><span class=3D""><blockquote type=3D"cite"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote">
          </div>
        </div>
      </div>
    </blockquote></span>
    That already happens, though it is far from &quot;random&quot;. The com=
piler
    will happily remove code that depends on UB at higher optimization
    levels. Whether you expected it to run or not, or whether that
    annoys you, it does not care.<br></div></blockquote><div><br></div><div=
>The issue was not if UB is allowed to remove code or not. I have no proble=
m with that. The issue was that a precondition validate should be ill-forme=
d rather that UB.</div><div><br></div><div>=C2=A0 / Jonas</div><div>=C2=A0<=
/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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1145aa8caa790d0524aa5155--

.

------=_Part_828_169162992.1447721618083
Content-Type: multipart/alternative;
 boundary="----=_Part_829_885780470.1447721618084"

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

On Monday, November 16, 2015 at 7:46:59 AM UTC-8, Jonas Persson wrote:
>
> On Sat, Nov 14, 2015 at 2:38 AM, Miro Knejp <miro....@gmail.com=20
> <javascript:>> wrote:
>
>> That already happens, though it is far from "random". The compiler will=
=20
>> happily remove code that depends on UB at higher optimization levels.=20
>> Whether you expected it to run or not, or whether that annoys you, it do=
es=20
>> not care.
>>
>
> The issue was not if UB is allowed to remove code or not. I have no=20
> problem with that. The issue was that a precondition validate should be=
=20
> ill-formed rather that UB.
>

A contract violation can't be *ill-formed*; that's a term of art that=20
specifically refers to something compile-time diagnosable (except in cases=
=20
that are "ill-formed, no diagnostic required", about which the less said=20
the better). Contracts are by definition checkable only at runtime. If you=
=20
want to check something at compile-time, that's what the type system is for=
..
For a concrete example:

void compiletime(nn <https://github.com/dropbox/nn/blob/master/nn.hpp><int*=
>=20
ptr) { std::cout << *ptr; }
void runtime(int *ptr) [[expected: ptr !=3D nullptr]] { std::cout << *ptr; =
}

In the former case, we can document within the type system that "ptr" must=
=20
never be null, and the compiler can help check that invariant for us. This=
=20
is already a solved problem.

In the latter case, we're explicitly creating a function signature that (at=
=20
compile time) accepts a wide range of possible inputs =E2=80=94 and then we=
're=20
using the contract to narrow down the "acceptable" range of inputs at=20
runtime. So for example in the former case

    int i, *p =3D &i;
    compiletime(p);  // simply will not compile, because there is no=20
implicit conversion from int* to non_null<int*>
    nn<int*> p2 =3D NN_CHECK_ASSERT(p);
    compiletime(p2);  // will compile fine

    int *p =3D nullptr;
    runtime(p);  // will compile, but violates the contract at runtime

My understanding of the Kona "contracts" discussion is that when you=20
violate a contract, you get behavior that is defined (only) by the contract=
=20
handler that you have chosen to use in the current=20
(program/thread/context). If you've defined your contract-violation handler=
=20
to call std::terminate(), then a contract violation causes perfectly=20
well-defined program termination. If you've defined your contract-violation=
=20
handler to call __builtin_unreachable() or divide by zero or whatever, then=
=20
a contract violation causes undefined behavior.

If the implementation can detect at compile time that your=20
contract-violation handler unconditionally invokes undefined behavior, then=
=20
naturally the implementation is free to optimize based on that knowledge =
=E2=80=94=20
i.e., the knowledge that *contracts are never violated* by your program.=20
(Because if you ever violated any contract, you'd have UB, and valid C++=20
programs aren't allowed to have UB, so Q.E.D. your program can't violate=20
any contract.) However, this kind of optimization is possible only if the=
=20
implementation can detect that you want contract violations to have UB.=20
It's not something that the implementation can just do for the hell of it.

IMHO the hard part of specifying contracts (besides the syntax bikeshed) is=
=20
figuring out a way for the user to specify unambiguously and portably that=
=20
he *wants* contract violations to have UB. Otherwise, you end up with=20
stupid duplications of the form

void align(int y, int x) [[expected: ispowerof2(x)]]
{
    assume(ispowerof2(x));  // now let the compiler know that it should=20
actually be optimizing here
    return y / x * x;
}

It's super easy to implement the "assume-macro" form of contracts today.=20
You just write this:

#ifdef OPTIMIZE_HEAVILY
 #define assume(x) (!(x) && __builtin_unreachable())
#elsif DEBUG_BUILD
 #define assume(x) assert(x)
#elsif SAFETY_FIRST_HA_HA
 #define assume(x) (!(x) && throw my::contract_violation_error("Violated=20
contract " #x));
#else
 #define assume(x) (void)0
#endif

The hard parts IMHO are all involved with figuring out how to=20
"de-macro-ize" this idiom, while still enabling decent implementations to=
=20
"see through" whatever functions or builtins or whatever are being=20
introduced and optimize the code just as well as if it had been written in=
=20
the "assume-macro" idiom.

C++03's std::terminate has the problem that I think is hard to solve. I'd=
=20
love to be able to install my own terminate handler that has UB, in a way=
=20
that told the compiler unambiguously and portably "hey, you can safely=20
assume that my program never reaches std::terminate". However, the=20
std::set_terminate() mechanism really isn't conducive to that at all =E2=80=
=94 it's=20
super duper hard for the implementation to "see through". I'd hate to see=
=20
something equally sucky (say, "std::set_contract_violation()") get=20
standardized. However, there are enough smart people working on the problem=
=20
that I don't *think* that's likely to happen. I don't know what *is* likely=
=20
to happen, though.

my $.02,
=E2=80=93Arthur

>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_829_885780470.1447721618084
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Monday, November 16, 2015 at 7:46:59 AM UTC-8, Jonas Persson wrote:<bloc=
kquote 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">On Sat, Nov 14, 20=
15 at 2:38 AM, Miro Knejp <span dir=3D"ltr">&lt;<a href=3D"javascript:" tar=
get=3D"_blank" gdf-obfuscated-mailto=3D"G0xk21YLBAAJ" rel=3D"nofollow" onmo=
usedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.=
href=3D&#39;javascript:&#39;;return true;">miro....@gmail.com</a>&gt;</span=
> wrote:<br><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor=
=3D"#FFFFFF" text=3D"#000000"><span><blockquote type=3D"cite"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote">
          </div>
        </div>
      </div>
    </blockquote></span>
    That already happens, though it is far from &quot;random&quot;. The com=
piler
    will happily remove code that depends on UB at higher optimization
    levels. Whether you expected it to run or not, or whether that
    annoys you, it does not care.<br></div></blockquote><div><br></div><div=
>The issue was not if UB is allowed to remove code or not. I have no proble=
m with that. The issue was that a precondition validate should be ill-forme=
d rather that UB.</div></div></div></div></blockquote><div><br></div><div>A=
 contract violation can&#39;t be <i>ill-formed</i>; that&#39;s a term of ar=
t that specifically refers to something compile-time diagnosable (except in=
 cases that are &quot;ill-formed, no diagnostic required&quot;, about which=
 the less said the better). Contracts are by definition checkable only at r=
untime. If you want to check something at compile-time, that&#39;s what the=
 type system is for.</div><div>For a concrete example:</div><div><br></div>=
<div>void compiletime(<a href=3D"https://github.com/dropbox/nn/blob/master/=
nn.hpp">nn</a>&lt;int*&gt; ptr) { std::cout &lt;&lt; *ptr; }</div><div>void=
 runtime(int *ptr) [[expected: ptr !=3D nullptr]] { std::cout &lt;&lt; *ptr=
; }</div><div><br></div><div>In the former case, we can document within the=
 type system that &quot;ptr&quot; must never be null, and the compiler can =
help check that invariant for us. This is already a solved problem.</div><d=
iv><br></div><div>In the latter case, we&#39;re explicitly creating a funct=
ion signature that (at compile time) accepts a wide range of possible input=
s =E2=80=94 and then we&#39;re using the contract to narrow down the &quot;=
acceptable&quot; range of inputs at runtime. So for example in the former c=
ase</div><div><br></div><div>=C2=A0 =C2=A0 int i, *p =3D &amp;i;<br></div><=
div>=C2=A0 =C2=A0 compiletime(p); =C2=A0// simply will not compile, because=
 there is no implicit conversion from int* to non_null&lt;int*&gt;</div><di=
v>=C2=A0 =C2=A0 nn&lt;int*&gt; p2 =3D NN_CHECK_ASSERT(p);</div><div>=C2=A0 =
=C2=A0 compiletime(p2); =C2=A0// will compile fine</div><div><br></div><div=
>=C2=A0 =C2=A0 int *p =3D nullptr;</div><div>=C2=A0 =C2=A0 runtime(p); =C2=
=A0// will compile, but violates the contract at runtime</div><div><br></di=
v><div>My understanding of the Kona &quot;contracts&quot; discussion is tha=
t when you violate a contract, you get behavior that is defined (only) by t=
he contract handler that you have chosen to use in the current (program/thr=
ead/context). If you&#39;ve defined your contract-violation handler to call=
 std::terminate(), then a contract violation causes perfectly well-defined =
program termination. If you&#39;ve defined your contract-violation handler =
to call __builtin_unreachable() or divide by zero or whatever, then a contr=
act violation causes undefined behavior.</div><div><br></div><div>If the im=
plementation can detect at compile time that your contract-violation handle=
r unconditionally invokes undefined behavior, then naturally the implementa=
tion is free to optimize based on that knowledge =E2=80=94 i.e., the knowle=
dge that <i>contracts are never violated</i> by your program. (Because if y=
ou ever violated any contract, you&#39;d have UB, and valid C++ programs ar=
en&#39;t allowed to have UB, so Q.E.D. your program can&#39;t violate any c=
ontract.) However, this kind of optimization is possible only if the implem=
entation can detect that you want contract violations to have UB. It&#39;s =
not something that the implementation can just do for the hell of it.</div>=
<div><br></div><div>IMHO the hard part of specifying contracts (besides the=
 syntax bikeshed) is figuring out a way for the user to specify unambiguous=
ly and portably that he <i>wants</i> contract violations to have UB. Otherw=
ise, you end up with stupid duplications of the form</div><div><br></div><d=
iv><div>void align(int y, int x) [[expected: ispowerof2(x)]]</div><div>{</d=
iv><div>=C2=A0 =C2=A0 assume(ispowerof2(x)); =C2=A0// now let the compiler =
know that it should actually be optimizing here</div><div>=C2=A0 =C2=A0 ret=
urn y / x * x;</div><div>}</div></div><div><br></div><div>It&#39;s super ea=
sy to implement the &quot;assume-macro&quot; form of contracts today. You j=
ust write this:</div><div><br></div><div>#ifdef OPTIMIZE_HEAVILY</div><div>=
=C2=A0#define assume(x) (!(x) &amp;&amp; __builtin_unreachable())</div><div=
>#elsif DEBUG_BUILD</div><div>=C2=A0#define assume(x) assert(x)</div><div>#=
elsif SAFETY_FIRST_HA_HA<br></div><div>=C2=A0#define assume(x) (!(x) &amp;&=
amp; throw my::contract_violation_error(&quot;Violated contract &quot; #x))=
;</div><div>#else</div><div>=C2=A0#define assume(x) (void)0</div><div>#endi=
f</div><div><br></div><div>The hard parts IMHO are all involved with figuri=
ng out how to &quot;de-macro-ize&quot; this idiom, while still enabling dec=
ent implementations to &quot;see through&quot; whatever functions or builti=
ns or whatever are being introduced and optimize the code just as well as i=
f it had been written in the &quot;assume-macro&quot; idiom.</div><div><br>=
</div><div>C++03&#39;s std::terminate has the problem that I think is hard =
to solve. I&#39;d love to be able to install my own terminate handler that =
has UB, in a way that told the compiler unambiguously and portably &quot;he=
y, you can safely assume that my program never reaches std::terminate&quot;=
.. However, the std::set_terminate() mechanism really isn&#39;t conducive to=
 that at all =E2=80=94 it&#39;s super duper hard for the implementation to =
&quot;see through&quot;. I&#39;d hate to see something equally sucky (say, =
&quot;std::set_contract_violation()&quot;) get standardized. However, there=
 are enough smart people working on the problem that I don&#39;t <i>think</=
i> that&#39;s likely to happen. I don&#39;t know what <i>is</i> likely to h=
appen, though.</div><div><br></div><div>my $.02,</div><div>=E2=80=93Arthur<=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">
</blockquote>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_829_885780470.1447721618084--
------=_Part_828_169162992.1447721618083--

.