------=_Part_547_1189134843.1446943493289
Content-Type: multipart/alternative;
 boundary="----=_Part_548_1894502648.1446943493289"

------=_Part_548_1894502648.1446943493289
Content-Type: text/plain; charset=UTF-8

I know that the standard is removing the exception specification in favor
the noexcept keyword but I think that this still think that there is still
a uses case for exception specification. what I would like to propose in to
change the exception specification from being a run-time check to a
compile-time that can help static analysis tools and compilers determine how

suppose you have a function like below

bool checkData(dataVal& d) throws ()
{
      if(!check1(d))
              return false;
      if(!check2(d))
              return false;
      return true;
}

now before or when compiling checkData the compiler checks if either check1
or check2 throws an exception. If there is any way that either check1 or
check2 throws an exception then checkData generates a compiler error.

If the function check1 has no exception specification, then the code first
check the implementation of check1 determine if check1 throws. If check1 is
define in another library and there if no way to check if check one throws
this would be considered as undefined behavior. However, if check1 has some
exception throw declared then even if it cannot throw an expection then
this assume that its may throw

bool check1(dataVal& d) : throws (std:exception)
{
      return true;
}

this declaration is this stare will produce a compiler error

please comment on what you think as a future c++ proposal.

--

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

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

<div dir=3D"ltr">I know that the standard is removing the=C2=A0exception sp=
ecification in favor the noexcept keyword but I think that this still think=
 that there is still a uses case for exception specification. what I would =
like to propose in to change the exception specification from being a run-t=
ime check to a compile-time that can help static analysis tools and compile=
rs determine how<div><br></div><div>suppose you have a function like below<=
/div><div><br></div><div>bool checkData(dataVal&amp; d) throws ()</div><div=
>{</div><div>=C2=A0 =C2=A0 =C2=A0 if(!check1(d))</div><div>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return false;</div><div>=C2=A0 =C2=A0 =
=C2=A0 if(!check2(d))</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 return false;</div><div>=C2=A0 =C2=A0 =C2=A0 return true;</div><div>=
}</div><div><br></div><div>now before or when compiling checkData the compi=
ler checks if either check1 or check2 throws an exception. If there is any =
way that either check1 or check2 throws an exception then checkData generat=
es a compiler error.</div><div><br></div><div>If the function check1 has no=
 exception specification, then the code first check the implementation of c=
heck1 determine if check1 throws. If check1 is define in another library an=
d there if no way to check if check one throws this would be considered as =
undefined behavior. However, if check1 has some exception throw declared th=
en even if it cannot throw an expection then this assume that its may throw=
</div><div><br></div><div>bool check1(dataVal&amp; d) : throws (std:excepti=
on)</div><div>{</div><div>=C2=A0 =C2=A0 =C2=A0 return true;</div><div>}</di=
v><div><br></div><div>this declaration is this stare will produce a compile=
r error</div><div><br></div><div>please comment on what you think as a futu=
re c++ proposal.</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_548_1894502648.1446943493289--
------=_Part_547_1189134843.1446943493289--

.

------=_Part_3289_494253268.1446947557073
Content-Type: multipart/alternative;
 boundary="----=_Part_3290_1305414568.1446947557073"

------=_Part_3290_1305414568.1446947557073
Content-Type: text/plain; charset=UTF-8

On Saturday, November 7, 2015 at 7:44:53 PM UTC-5, Vishal Oza wrote:
>
> I know that the standard is removing the exception specification in favor
> the noexcept keyword but I think that this still think that there is still
> a uses case for exception specification. what I would like to propose in to
> change the exception specification from being a run-time check to a
> compile-time that can help static analysis tools and compilers determine how
>

.... "determine how" what?


>
> suppose you have a function like below
>
> bool checkData(dataVal& d) throws ()
> {
>       if(!check1(d))
>               return false;
>       if(!check2(d))
>               return false;
>       return true;
> }
>
> now before or when compiling checkData the compiler checks if either
> check1 or check2 throws an exception. If there is any way that either
> check1 or check2 throws an exception then checkData generates a compiler
> error.
>
> If the function check1 has no exception specification, then the code first
> check the implementation of check1 determine if check1 throws. If check1 is
> define in another library and there if no way to check if check one throws
> this would be considered as undefined behavior. However, if check1 has some
> exception throw declared then even if it cannot throw an expection then
> this assume that its may throw
>
> bool check1(dataVal& d) : throws (std:exception)
> {
>       return true;
> }
>
> this declaration is this stare will produce a compiler error
>
> please comment on what you think as a future c++ proposal.
>

This is what Java does, so it's nothing new. I also think Java has proven
that this is a really bad 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/.

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

<div dir=3D"ltr">On Saturday, November 7, 2015 at 7:44:53 PM UTC-5, Vishal =
Oza 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">I k=
now that the standard is removing the=C2=A0exception specification in favor=
 the noexcept keyword but I think that this still think that there is still=
 a uses case for exception specification. what I would like to propose in t=
o change the exception specification from being a run-time check to a compi=
le-time that can help static analysis tools and compilers determine how</di=
v></blockquote><div><br>... &quot;determine how&quot; what?<br>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></di=
v><div>suppose you have a function like below</div><div><br></div><div>bool=
 checkData(dataVal&amp; d) throws ()</div><div>{</div><div>=C2=A0 =C2=A0 =
=C2=A0 if(!check1(d))</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 return false;</div><div>=C2=A0 =C2=A0 =C2=A0 if(!check2(d))</div><di=
v>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return false;</div><div>=
=C2=A0 =C2=A0 =C2=A0 return true;</div><div>}</div><div><br></div><div>now =
before or when compiling checkData the compiler checks if either check1 or =
check2 throws an exception. If there is any way that either check1 or check=
2 throws an exception then checkData generates a compiler error.</div><div>=
<br></div><div>If the function check1 has no exception specification, then =
the code first check the implementation of check1 determine if check1 throw=
s. If check1 is define in another library and there if no way to check if c=
heck one throws this would be considered as undefined behavior. However, if=
 check1 has some exception throw declared then even if it cannot throw an e=
xpection then this assume that its may throw</div><div><br></div><div>bool =
check1(dataVal&amp; d) : throws (std:exception)</div><div>{</div><div>=C2=
=A0 =C2=A0 =C2=A0 return true;</div><div>}</div><div><br></div><div>this de=
claration is this stare will produce a compiler error</div><div><br></div><=
div>please comment on what you think as a future c++ proposal.</div></div><=
/blockquote><div><br>This is what Java does, so it&#39;s nothing new. I als=
o think Java has proven that this is a really bad idea.<br></div></div>

<p></p>

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

------=_Part_3290_1305414568.1446947557073--
------=_Part_3289_494253268.1446947557073--

.

------=_Part_4228_1453388718.1446956891254
Content-Type: multipart/alternative;
 boundary="----=_Part_4229_770209064.1446956891254"

------=_Part_4229_770209064.1446956891254
Content-Type: text/plain; charset=UTF-8



On Saturday, November 7, 2015 at 7:52:37 PM UTC-6, Nicol Bolas wrote:
>
> On Saturday, November 7, 2015 at 7:44:53 PM UTC-5, Vishal Oza wrote:
>>
>> I know that the standard is removing the exception specification in favor
>> the noexcept keyword but I think that this still think that there is still
>> a uses case for exception specification. what I would like to propose in to
>> change the exception specification from being a run-time check to a
>> compile-time that can help static analysis tools and compilers determine
>>
>
> ... "determine how" what?
>
sorry determine  if the function throws an uncaught exception the other
solution is to remove exception handling altogether this is to remove the
machinery of exception handling from run-time when not needed.

>
>
>>
>> suppose you have a function like below
>>
>> bool checkData(dataVal& d) throws ()
>> {
>>       if(!check1(d))
>>               return false;
>>       if(!check2(d))
>>               return false;
>>       return true;
>> }
>>
>> now before or when compiling checkData the compiler checks if either
>> check1 or check2 throws an exception. If there is any way that either
>> check1 or check2 throws an exception then checkData generates a compiler
>> error.
>>
>> If the function check1 has no exception specification, then the code
>> first check the implementation of check1 determine if check1 throws. If
>> check1 is define in another library and there if no way to check if check
>> one throws this would be considered as undefined behavior. However, if
>> check1 has some exception throw declared then even if it cannot throw an
>> expection then this assume that its may throw
>>
>> bool check1(dataVal& d) : throws (std:exception)
>> {
>>       return true;
>> }
>>
>> this declaration is this stare will produce a compiler error
>>
>> please comment on what you think as a future c++ proposal.
>>
>
> This is what Java does, so it's nothing new. I also think Java has proven
> that this is a really bad idea.
>
Java as far as I  does not have this feature

--

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

<div dir=3D"ltr"><br><br>On Saturday, November 7, 2015 at 7:52:37 PM UTC-6,=
 Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">On Saturday, November 7, 2015 at 7:44:53 PM UTC-5, Vishal Oza 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">I know that the sta=
ndard is removing the=C2=A0exception specification in favor the noexcept ke=
yword but I think that this still think that there is still a uses case for=
 exception specification. what I would like to propose in to change the exc=
eption specification from being a run-time check to a compile-time that can=
 help static analysis tools and compilers determine=C2=A0</div></blockquote=
><div><br>... &quot;determine how&quot; what?<br></div></div></blockquote><=
div>sorry determine =C2=A0if the function throws an uncaught exception the =
other solution is to remove exception handling altogether this is to remove=
 the machinery of exception handling from run-time when not needed.=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>=
</div><div>suppose you have a function like below</div><div><br></div><div>=
bool checkData(dataVal&amp; d) throws ()</div><div>{</div><div>=C2=A0 =C2=
=A0 =C2=A0 if(!check1(d))</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 return false;</div><div>=C2=A0 =C2=A0 =C2=A0 if(!check2(d))</div=
><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return false;</div><=
div>=C2=A0 =C2=A0 =C2=A0 return true;</div><div>}</div><div><br></div><div>=
now before or when compiling checkData the compiler checks if either check1=
 or check2 throws an exception. If there is any way that either check1 or c=
heck2 throws an exception then checkData generates a compiler error.</div><=
div><br></div><div>If the function check1 has no exception specification, t=
hen the code first check the implementation of check1 determine if check1 t=
hrows. If check1 is define in another library and there if no way to check =
if check one throws this would be considered as undefined behavior. However=
, if check1 has some exception throw declared then even if it cannot throw =
an expection then this assume that its may throw</div><div><br></div><div>b=
ool check1(dataVal&amp; d) : throws (std:exception)</div><div>{</div><div>=
=C2=A0 =C2=A0 =C2=A0 return true;</div><div>}</div><div><br></div><div>this=
 declaration is this stare will produce a compiler error</div><div><br></di=
v><div>please comment on what you think as a future c++ proposal.</div></di=
v></blockquote><div><br>This is what Java does, so it&#39;s nothing new. I =
also think Java has proven that this is a really bad idea.<br></div></div><=
/blockquote><div>Java as far as I =C2=A0does not have this feature</div></d=
iv>

<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_4229_770209064.1446956891254--
------=_Part_4228_1453388718.1446956891254--

.

------=_Part_3842_215621519.1446960836411
Content-Type: multipart/alternative;
 boundary="----=_Part_3843_1879500597.1446960836412"

------=_Part_3843_1879500597.1446960836412
Content-Type: text/plain; charset=UTF-8

On Saturday, November 7, 2015 at 11:28:11 PM UTC-5, Vishal Oza wrote:
>
> On Saturday, November 7, 2015 at 7:52:37 PM UTC-6, Nicol Bolas wrote:
>>
>> On Saturday, November 7, 2015 at 7:44:53 PM UTC-5, Vishal Oza wrote:
>>>
>>> I know that the standard is removing the exception specification in
>>> favor the noexcept keyword but I think that this still think that there is
>>> still a uses case for exception specification. what I would like to propose
>>> in to change the exception specification from being a run-time check to a
>>> compile-time that can help static analysis tools and compilers determine
>>>
>>
>> ... "determine how" what?
>>
> sorry determine  if the function throws an uncaught exception the other
> solution is to remove exception handling altogether this is to remove the
> machinery of exception handling from run-time when not needed.
>
>>
>>
>>>
>>> suppose you have a function like below
>>>
>>> bool checkData(dataVal& d) throws ()
>>> {
>>>       if(!check1(d))
>>>               return false;
>>>       if(!check2(d))
>>>               return false;
>>>       return true;
>>> }
>>>
>>> now before or when compiling checkData the compiler checks if either
>>> check1 or check2 throws an exception. If there is any way that either
>>> check1 or check2 throws an exception then checkData generates a compiler
>>> error.
>>>
>>> If the function check1 has no exception specification, then the code
>>> first check the implementation of check1 determine if check1 throws. If
>>> check1 is define in another library and there if no way to check if check
>>> one throws this would be considered as undefined behavior. However, if
>>> check1 has some exception throw declared then even if it cannot throw an
>>> expection then this assume that its may throw
>>>
>>> bool check1(dataVal& d) : throws (std:exception)
>>> {
>>>       return true;
>>> }
>>>
>>> this declaration is this stare will produce a compiler error
>>>
>>> please comment on what you think as a future c++ proposal.
>>>
>>
>> This is what Java does, so it's nothing new. I also think Java has proven
>> that this is a really bad idea.
>>
> Java as far as I  does not have this feature
>

Sure it does. But first, allow me to clarify what you said, translating it
into something that C++ can actually *do*. You said:

> If check1 is define[sic] in another library

The translation into any meaningful standardese is:

> If check1 is not defined in this translation unit

The C++ standard doesn't have a concept of "another library". Either the
function's definition is available within this translation unit
(standard-speak for "C++ source file") or it is not. And if it is not, then
the compiler for this translation unit has no access to the definition of
that function. And link time is way too late to start catching errors like
this.

The only difference between what you want and what Java does is that you
allow the compiler to implicitly define the exception list. But this
requires that all code called by that function either has an exception
specification or is visible to that translation unit (ie: is inline).

Unless your entire codebase is inline, this isn't that much different from
Java. It makes it easier for template code to compose calling functions
with exception specifications, but that's about it. It still has all of the
other problems of checked exceptions.

Furthermore, it *breaks* existing code. It fundamentally changes the
meaning of exception specifications, turning an empty specification from "I
could throw anything" into either "if everything I call is inline, then I
throw what they throw" or "if everything I call is not inline, undefined
behavior."

That latter is not acceptable.

--

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

On Saturday, November 7, 2015 at 11:28:11 PM UTC-5, Vishal Oza 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">On Saturday, Novemb=
er 7, 2015 at 7:52:37 PM UTC-6, Nicol Bolas wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr">On Saturday, November 7, 2015 at 7:44:53 PM=
 UTC-5, Vishal Oza 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">I know that the standard is removing the=C2=A0exception specificat=
ion in favor the noexcept keyword but I think that this still think that th=
ere is still a uses case for exception specification. what I would like to =
propose in to change the exception specification from being a run-time chec=
k to a compile-time that can help static analysis tools and compilers deter=
mine=C2=A0</div></blockquote><div><br>... &quot;determine how&quot; what?<b=
r></div></div></blockquote><div>sorry determine =C2=A0if the function throw=
s an uncaught exception the other solution is to remove exception handling =
altogether this is to remove the machinery of exception handling from run-t=
ime when not needed.=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div><br></div><div>suppose you have a function like below</di=
v><div><br></div><div>bool checkData(dataVal&amp; d) throws ()</div><div>{<=
/div><div>=C2=A0 =C2=A0 =C2=A0 if(!check1(d))</div><div>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return false;</div><div>=C2=A0 =C2=A0 =C2=
=A0 if(!check2(d))</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 return false;</div><div>=C2=A0 =C2=A0 =C2=A0 return true;</div><div>}</=
div><div><br></div><div>now before or when compiling checkData the compiler=
 checks if either check1 or check2 throws an exception. If there is any way=
 that either check1 or check2 throws an exception then checkData generates =
a compiler error.</div><div><br></div><div>If the function check1 has no ex=
ception specification, then the code first check the implementation of chec=
k1 determine if check1 throws. If check1 is define in another library and t=
here if no way to check if check one throws this would be considered as und=
efined behavior. However, if check1 has some exception throw declared then =
even if it cannot throw an expection then this assume that its may throw</d=
iv><div><br></div><div>bool check1(dataVal&amp; d) : throws (std:exception)=
</div><div>{</div><div>=C2=A0 =C2=A0 =C2=A0 return true;</div><div>}</div><=
div><br></div><div>this declaration is this stare will produce a compiler e=
rror</div><div><br></div><div>please comment on what you think as a future =
c++ proposal.</div></div></blockquote><div><br>This is what Java does, so i=
t&#39;s nothing new. I also think Java has proven that this is a really bad=
 idea.<br></div></div></blockquote><div>Java as far as I =C2=A0does not hav=
e this feature</div></div></blockquote><div><br>Sure it does. But first, al=
low me to clarify what you said, translating it into something that C++ can=
 actually <i>do</i>. You said:<br><br>&gt; If check1 is define[sic] in anot=
her library <br><br>The translation into any meaningful standardese is:<br>=
<br>&gt; If check1 is not defined in this translation unit<br><br>The C++ s=
tandard doesn&#39;t have a concept of &quot;another library&quot;. Either t=
he function&#39;s definition is available within this translation unit (sta=
ndard-speak for &quot;C++ source file&quot;) or it is not. And if it is not=
, then the compiler for this translation unit has no access to the definiti=
on of that function. And link time is way too late to start catching errors=
 like this.<br><br>The only difference between what you want and what Java =
does is that you allow the compiler to implicitly define the exception list=
.. But this requires that all code called by that function either has an exc=
eption specification or is visible to that translation unit (ie: is inline)=
..<br><br>Unless your entire codebase is inline, this isn&#39;t that much di=
fferent from Java. It makes it easier for template code to compose calling =
functions with exception specifications, but that&#39;s about it. It still =
has all of the other problems of checked exceptions.<br><br>Furthermore, it=
 <i>breaks</i> existing code. It fundamentally changes the meaning of excep=
tion specifications, turning an empty specification from &quot;I could thro=
w anything&quot; into either &quot;if everything I call is inline, then I t=
hrow what they throw&quot; or &quot;if everything I call is not inline, und=
efined behavior.&quot;<br><br>That latter is not acceptable.<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_3843_1879500597.1446960836412--
------=_Part_3842_215621519.1446960836411--

.

------=_Part_477_1226400668.1447005938347
Content-Type: multipart/alternative;
 boundary="----=_Part_478_22525478.1447005938347"

------=_Part_478_22525478.1447005938347
Content-Type: text/plain; charset=UTF-8

the issue I am trying to bring up is how to deal with exception handling at
compile-time in my option both of the following code should not compile
because you are thrown when you say are not.

void checkData(dataVal& d) throws ()
{
      throw 1;
}

void checkData(dataVal& d) noexcept
{
      throw 1;
}

According to the c++ standard both are legal code the former being legal
with the older standard the latter being legal with the newer standard
meaning both will compile. Thinking about it further during the compile the
precompile stage the compile would mark all functions or methods as
throwing, no-throw, or do not know based on the exception. Before compiling
no-throw functions or methods the compiler could check it the do not know
functions or methods can throw if it has access to the implementation of
the the method. Also, I think that the throw exception specification is
already being removed from the next standard so I do not think I am
breaking anything that is not already broken or will be broken

On Saturday, November 7, 2015 at 11:33:56 PM UTC-6, Nicol Bolas wrote:
>
> On Saturday, November 7, 2015 at 11:28:11 PM UTC-5, Vishal Oza wrote:
>>
>> On Saturday, November 7, 2015 at 7:52:37 PM UTC-6, Nicol Bolas wrote:
>>>
>>> On Saturday, November 7, 2015 at 7:44:53 PM UTC-5, Vishal Oza wrote:
>>>>
>>>> I know that the standard is removing the exception specification in
>>>> favor the noexcept keyword but I think that this still think that there is
>>>> still a uses case for exception specification. what I would like to propose
>>>> in to change the exception specification from being a run-time check to a
>>>> compile-time that can help static analysis tools and compilers determine
>>>>
>>>
>>> ... "determine how" what?
>>>
>> sorry determine  if the function throws an uncaught exception the other
>> solution is to remove exception handling altogether this is to remove the
>> machinery of exception handling from run-time when not needed.
>>
>>>
>>>
>>>>
>>>> suppose you have a function like below
>>>>
>>>> bool checkData(dataVal& d) throws ()
>>>> {
>>>>       if(!check1(d))
>>>>               return false;
>>>>       if(!check2(d))
>>>>               return false;
>>>>       return true;
>>>> }
>>>>
>>>> now before or when compiling checkData the compiler checks if either
>>>> check1 or check2 throws an exception. If there is any way that either
>>>> check1 or check2 throws an exception then checkData generates a compiler
>>>> error.
>>>>
>>>> If the function check1 has no exception specification, then the code
>>>> first check the implementation of check1 determine if check1 throws. If
>>>> check1 is define in another library and there if no way to check if check
>>>> one throws this would be considered as undefined behavior. However, if
>>>> check1 has some exception throw declared then even if it cannot throw an
>>>> expection then this assume that its may throw
>>>>
>>>> bool check1(dataVal& d) : throws (std:exception)
>>>> {
>>>>       return true;
>>>> }
>>>>
>>>> this declaration is this stare will produce a compiler error
>>>>
>>>> please comment on what you think as a future c++ proposal.
>>>>
>>>
>>> This is what Java does, so it's nothing new. I also think Java has
>>> proven that this is a really bad idea.
>>>
>> Java as far as I  does not have this feature
>>
>
> Sure it does. But first, allow me to clarify what you said, translating it
> into something that C++ can actually *do*. You said:
>
> > If check1 is define[sic] in another library
>
> The translation into any meaningful standardese is:
>
> > If check1 is not defined in this translation unit
>
> The C++ standard doesn't have a concept of "another library". Either the
> function's definition is available within this translation unit
> (standard-speak for "C++ source file") or it is not. And if it is not, then
> the compiler for this translation unit has no access to the definition of
> that function. And link time is way too late to start catching errors like
> this.
>
> The only difference between what you want and what Java does is that you
> allow the compiler to implicitly define the exception list. But this
> requires that all code called by that function either has an exception
> specification or is visible to that translation unit (ie: is inline).
>
> Unless your entire codebase is inline, this isn't that much different from
> Java. It makes it easier for template code to compose calling functions
> with exception specifications, but that's about it. It still has all of the
> other problems of checked exceptions.
>
> Furthermore, it *breaks* existing code. It fundamentally changes the
> meaning of exception specifications, turning an empty specification from "I
> could throw anything" into either "if everything I call is inline, then I
> throw what they throw" or "if everything I call is not inline, undefined
> behavior."
>
> That latter is not acceptable.
>

--

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

<div dir=3D"ltr">the issue I am trying to bring up is how to deal with exce=
ption handling at compile-time in my option both of the following code shou=
ld not compile because you are thrown when you say are not.<div><div><br></=
div><div>void checkData(dataVal&amp; d) throws ()</div><div>{</div><div>=C2=
=A0 =C2=A0 =C2=A0 throw 1;</div><div>}<br></div><div><br></div><div><div>vo=
id=C2=A0checkData(dataVal&amp; d) noexcept</div><div>{</div><div>=C2=A0 =C2=
=A0 =C2=A0 throw 1;</div><div>}<br></div></div><div><br></div><div>Accordin=
g to the c++ standard both are legal code the former being legal with the o=
lder standard the latter being legal with the newer standard meaning both w=
ill compile. Thinking about it further during the compile the precompile st=
age the compile would mark all functions or methods as throwing, no-throw, =
or do not know based on the exception. Before compiling no-throw=C2=A0funct=
ions or methods=C2=A0the compiler could check it the do not know functions =
or methods can throw if it has access to the implementation of the the meth=
od. Also, I think that the throw exception specification is already being r=
emoved from the next standard so I do not think I am breaking anything that=
 is not already broken or will be broken<br></div><br>On Saturday, November=
 7, 2015 at 11:33:56 PM UTC-6, Nicol Bolas wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;">On Saturday, November 7, 2015 at 11:28:11 PM UTC-5, Vish=
al Oza wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Sa=
turday, November 7, 2015 at 7:52:37 PM UTC-6, Nicol Bolas wrote:<blockquote=
 class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr">On Saturday, November 7, 2015=
 at 7:44:53 PM UTC-5, Vishal Oza wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr">I know that the standard is removing the=C2=A0exceptio=
n specification in favor the noexcept keyword but I think that this still t=
hink that there is still a uses case for exception specification. what I wo=
uld like to propose in to change the exception specification from being a r=
un-time check to a compile-time that can help static analysis tools and com=
pilers determine=C2=A0</div></blockquote><div><br>... &quot;determine how&q=
uot; what?<br></div></div></blockquote><div>sorry determine =C2=A0if the fu=
nction throws an uncaught exception the other solution is to remove excepti=
on handling altogether this is to remove the machinery of exception handlin=
g from run-time when not needed.=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div><br></div><div>suppose you have a function li=
ke below</div><div><br></div><div>bool checkData(dataVal&amp; d) throws ()<=
/div><div>{</div><div>=C2=A0 =C2=A0 =C2=A0 if(!check1(d))</div><div>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return false;</div><div>=C2=A0 =
=C2=A0 =C2=A0 if(!check2(d))</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 return false;</div><div>=C2=A0 =C2=A0 =C2=A0 return true;</di=
v><div>}</div><div><br></div><div>now before or when compiling checkData th=
e compiler checks if either check1 or check2 throws an exception. If there =
is any way that either check1 or check2 throws an exception then checkData =
generates a compiler error.</div><div><br></div><div>If the function check1=
 has no exception specification, then the code first check the implementati=
on of check1 determine if check1 throws. If check1 is define in another lib=
rary and there if no way to check if check one throws this would be conside=
red as undefined behavior. However, if check1 has some exception throw decl=
ared then even if it cannot throw an expection then this assume that its ma=
y throw</div><div><br></div><div>bool check1(dataVal&amp; d) : throws (std:=
exception)</div><div>{</div><div>=C2=A0 =C2=A0 =C2=A0 return true;</div><di=
v>}</div><div><br></div><div>this declaration is this stare will produce a =
compiler error</div><div><br></div><div>please comment on what you think as=
 a future c++ proposal.</div></div></blockquote><div><br>This is what Java =
does, so it&#39;s nothing new. I also think Java has proven that this is a =
really bad idea.<br></div></div></blockquote><div>Java as far as I =C2=A0do=
es not have this feature</div></div></blockquote><div><br>Sure it does. But=
 first, allow me to clarify what you said, translating it into something th=
at C++ can actually <i>do</i>. You said:<br><br>&gt; If check1 is define[si=
c] in another library <br><br>The translation into any meaningful standarde=
se is:<br><br>&gt; If check1 is not defined in this translation unit<br><br=
>The C++ standard doesn&#39;t have a concept of &quot;another library&quot;=
.. Either the function&#39;s definition is available within this translation=
 unit (standard-speak for &quot;C++ source file&quot;) or it is not. And if=
 it is not, then the compiler for this translation unit has no access to th=
e definition of that function. And link time is way too late to start catch=
ing errors like this.<br><br>The only difference between what you want and =
what Java does is that you allow the compiler to implicitly define the exce=
ption list. But this requires that all code called by that function either =
has an exception specification or is visible to that translation unit (ie: =
is inline).<br><br>Unless your entire codebase is inline, this isn&#39;t th=
at much different from Java. It makes it easier for template code to compos=
e calling functions with exception specifications, but that&#39;s about it.=
 It still has all of the other problems of checked exceptions.<br><br>Furth=
ermore, it <i>breaks</i> existing code. It fundamentally changes the meanin=
g of exception specifications, turning an empty specification from &quot;I =
could throw anything&quot; into either &quot;if everything I call is inline=
, then I throw what they throw&quot; or &quot;if everything I call is not i=
nline, undefined behavior.&quot;<br><br>That latter is not acceptable.<br><=
/div></blockquote></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_478_22525478.1447005938347--
------=_Part_477_1226400668.1447005938347--

.

------=_Part_4522_1808892659.1447006999891
Content-Type: multipart/alternative;
 boundary="----=_Part_4523_2134203639.1447006999892"

------=_Part_4523_2134203639.1447006999892
Content-Type: text/plain; charset=UTF-8

On Sunday, November 8, 2015 at 1:05:38 PM UTC-5, Vishal Oza wrote:
>
> the issue I am trying to bring up is how to deal with exception handling
> at compile-time in my option both of the following code should not compile
> because you are thrown when you say are not.
>

> void checkData(dataVal& d) throws ()
> {
>       throw 1;
> }
>
> void checkData(dataVal& d) noexcept
> {
>       throw 1;
> }
>

No, this is perfectly valid code with well-defined results. Specifically,
when the exception reaches the top of a `noexcept` function,
`std::terminate` is called. `throw()` calls `std::unexpected`.

I don't see a reason why this should be expressly forbidden from compiling.


> According to the c++ standard both are legal code the former being legal
> with the older standard the latter being legal with the newer standard
> meaning both will compile.
>

If I recall correctly, `throw()` isn't slated for removal. Just non-empty
throw lists.


> Thinking about it further during the compile the precompile stage the
> compile would mark all functions or methods as throwing, no-throw, or do
> not know based on the exception. Before compiling no-throw functions or
> methods the compiler could check it the do not know functions or methods
> can throw if it has access to the implementation of the the method.
>

But that's not what you asked about. You were talking about all functions
everywhere. You were talking about investigating all available functions
that could be called to find out what they really throw.

That's not possible. There is no "precompile stage" in C++ that could allow
such a thing.

Also, I think that the throw exception specification is already being
> removed from the next standard so I do not think I am breaking anything
> that is not already broken or will be broken
>

You're changing the meaning of existing functions. You stated, "If check1
is define in another library and there if no way to check if check one
throws this would be considered as undefined behavior." That *used* to be
well-defined behavior: if it throws an uncaught exception up to
`checkData`, `std::terminate` will be called. Making it undefined is a
breaking change.

--

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

<div dir=3D"ltr">On Sunday, November 8, 2015 at 1:05:38 PM UTC-5, Vishal Oz=
a 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">the i=
ssue I am trying to bring up is how to deal with exception handling at comp=
ile-time in my option both of the following code should not compile because=
 you are thrown when you say are not.</div></blockquote><div></div><blockqu=
ote 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><br></div><=
div>void checkData(dataVal&amp; d) throws ()</div><div>{</div><div>=C2=A0 =
=C2=A0 =C2=A0 throw 1;</div><div>}<br></div><div><br></div><div><div>void=
=C2=A0checkData(dataVal&amp; d) noexcept</div><div>{</div><div>=C2=A0 =C2=
=A0 =C2=A0 throw 1;</div><div>}<br></div></div></div></div></blockquote><di=
v><br>No, this is perfectly valid code with well-defined results. Specifica=
lly, when the exception reaches the top of a `noexcept` function, `std::ter=
minate` is called. `throw()` calls `std::unexpected`.<br><br>I don&#39;t se=
e a reason why this should be expressly forbidden from compiling.<br>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><d=
iv><div></div></div><div></div><div>According to the c++ standard both are =
legal code the former being legal with the older standard the latter being =
legal with the newer standard meaning both will compile.</div></div></div><=
/blockquote><div><br>If I recall correctly, `throw()` isn&#39;t slated for =
removal. Just non-empty throw lists.<br>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr"><div><div>Thinking about it further =
during the compile the precompile stage the compile would mark all function=
s or methods as throwing, no-throw, or do not know based on the exception. =
Before compiling no-throw=C2=A0functions or methods=C2=A0the compiler could=
 check it the do not know functions or methods can throw if it has access t=
o the implementation of the the method.</div></div></div></blockquote><div>=
<br>But that&#39;s not what you asked about. You were talking about all fun=
ctions everywhere. You were talking about investigating all available funct=
ions that could be called to find out what they really throw.<br><br>That&#=
39;s not possible. There is no &quot;precompile stage&quot; in C++ that cou=
ld allow such a thing.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div><div> Also, I think that the throw exception sp=
ecification is already being removed from the next standard so I do not thi=
nk I am breaking anything that is not already broken or will be broken</div=
></div></div></blockquote><div><br>You&#39;re changing the meaning of exist=
ing functions. You stated, &quot;If check1 is define in another library and=
 there if no way to check if check one throws this would be considered as u=
ndefined behavior.&quot; That <i>used</i> to be well-defined behavior: if i=
t throws an uncaught exception up to `checkData`, `std::terminate` will be =
called. Making it undefined is a breaking change.<br></div></div>

<p></p>

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

------=_Part_4523_2134203639.1447006999892--
------=_Part_4522_1808892659.1447006999891--

.

------=_Part_167_1721311669.1447012491047
Content-Type: multipart/alternative;
 boundary="----=_Part_168_1074351904.1447012491047"

------=_Part_168_1074351904.1447012491047
Content-Type: text/plain; charset=UTF-8

I believe throw is either may removed or deprecated with c++ 17 according
to the doc number P0003R0. The proposed change that I see
would initial generate an exception table during the preprocessor stage
before compiling to determined which functions to check if they can throw
do not knows. If the is no source code is available and it
cannot determining because it cannot find it from its implementation for
example it uses some 3rd party library then how it should treat this case
is undefined behavior and the compiler writers should determine how to
treat this case. This case is something I do know if from a compiled
library you can determine if a function throws
On Sunday, November 8, 2015 at 12:23:20 PM UTC-6, Nicol Bolas wrote:
>
> On Sunday, November 8, 2015 at 1:05:38 PM UTC-5, Vishal Oza wrote:
>>
>> the issue I am trying to bring up is how to deal with exception handling
>> at compile-time in my option both of the following code should not compile
>> because you are thrown when you say are not.
>>
>
>> void checkData(dataVal& d) throws ()
>> {
>>       throw 1;
>> }
>>
>> void checkData(dataVal& d) noexcept
>> {
>>       throw 1;
>> }
>>
>
> No, this is perfectly valid code with well-defined results. Specifically,
> when the exception reaches the top of a `noexcept` function,
> `std::terminate` is called. `throw()` calls `std::unexpected`.
>
> I don't see a reason why this should be expressly forbidden from compiling.
>
>
>> According to the c++ standard both are legal code the former being legal
>> with the older standard the latter being legal with the newer standard
>> meaning both will compile.
>>
>
> If I recall correctly, `throw()` isn't slated for removal. Just non-empty
> throw lists.
>
>
>> Thinking about it further during the compile the precompile stage the
>> compile would mark all functions or methods as throwing, no-throw, or do
>> not know based on the exception. Before compiling no-throw functions or
>> methods the compiler could check it the do not know functions or methods
>> can throw if it has access to the implementation of the the method.
>>
>
> But that's not what you asked about. You were talking about all functions
> everywhere. You were talking about investigating all available functions
> that could be called to find out what they really throw.
>
> That's not possible. There is no "precompile stage" in C++ that could
> allow such a thing.
>
> Also, I think that the throw exception specification is already being
>> removed from the next standard so I do not think I am breaking anything
>> that is not already broken or will be broken
>>
>
> You're changing the meaning of existing functions. You stated, "If check1
> is define in another library and there if no way to check if check one
> throws this would be considered as undefined behavior." That *used* to be
> well-defined behavior: if it throws an uncaught exception up to
> `checkData`, `std::terminate` will be called. Making it undefined is a
> breaking change.
>

--

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

<div dir=3D"ltr">I believe throw is either may removed or deprecated with c=
++ 17 according to the doc number<font face=3D"arial, sans-serif" size=3D"2=
">=C2=A0<span style=3D"color: rgb(0, 0, 0);">P0003R0.=C2=A0</span></font><f=
ont color=3D"#000000" face=3D"arial, sans-serif" size=3D"2">The proposed ch=
ange that I see would=C2=A0initial=C2=A0generate an=C2=A0exception=C2=A0tab=
le during the preprocessor stage before compiling to=C2=A0determined=C2=A0w=
hich=C2=A0functions=C2=A0to check if they can throw do not knows. If the is=
 no source code is=C2=A0available=C2=A0and it cannot=C2=A0determining=C2=A0=
because it cannot find it from its=C2=A0implementation=C2=A0for example it =
uses some 3rd party library then how it should treat this case is undefined=
 behavior and the compiler writers should determine how to treat this case.=
 This case is something I do know if from a compiled library you can=C2=A0d=
etermine if a function throws=C2=A0</font><div>On Sunday, November 8, 2015 =
at 12:23:20 PM UTC-6, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr">On Sunday, November 8, 2015 at 1:05:38 PM UTC-5,=
 Vishal Oza wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
the issue I am trying to bring up is how to deal with exception handling at=
 compile-time in my option both of the following code should not compile be=
cause you are thrown when you say are not.</div></blockquote><div></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><br></div><=
div>void checkData(dataVal&amp; d) throws ()</div><div>{</div><div>=C2=A0 =
=C2=A0 =C2=A0 throw 1;</div><div>}<br></div><div><br></div><div><div>void=
=C2=A0checkData(dataVal&amp; d) noexcept</div><div>{</div><div>=C2=A0 =C2=
=A0 =C2=A0 throw 1;</div><div>}<br></div></div></div></div></blockquote><di=
v><br>No, this is perfectly valid code with well-defined results. Specifica=
lly, when the exception reaches the top of a `noexcept` function, `std::ter=
minate` is called. `throw()` calls `std::unexpected`.<br><br>I don&#39;t se=
e a reason why this should be expressly forbidden from compiling.<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 dir=3D"ltr"><div><div><d=
iv></div></div><div></div><div>According to the c++ standard both are legal=
 code the former being legal with the older standard the latter being legal=
 with the newer standard meaning both will compile.</div></div></div></bloc=
kquote><div><br>If I recall correctly, `throw()` isn&#39;t slated for remov=
al. Just non-empty throw lists.<br>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr"><div><div>Thinking about it further during the=
 compile the precompile stage the compile would mark all functions or metho=
ds as throwing, no-throw, or do not know based on the exception. Before com=
piling no-throw=C2=A0functions or methods=C2=A0the compiler could check it =
the do not know functions or methods can throw if it has access to the impl=
ementation of the the method.</div></div></div></blockquote><div><br>But th=
at&#39;s not what you asked about. You were talking about all functions eve=
rywhere. You were talking about investigating all available functions that =
could be called to find out what they really throw.<br><br>That&#39;s not p=
ossible. There is no &quot;precompile stage&quot; in C++ that could allow s=
uch a thing.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div><div> Also, I think that the throw exception specification is=
 already being removed from the next standard so I do not think I am breaki=
ng anything that is not already broken or will be broken</div></div></div><=
/blockquote><div><br>You&#39;re changing the meaning of existing functions.=
 You stated, &quot;If check1 is define in another library and there if no w=
ay to check if check one throws this would be considered as undefined behav=
ior.&quot; That <i>used</i> to be well-defined behavior: if it throws an un=
caught exception up to `checkData`, `std::terminate` will be called. Making=
 it undefined is a breaking change.<br></div></div></blockquote></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_168_1074351904.1447012491047--
------=_Part_167_1721311669.1447012491047--

.

------=_Part_4716_1042979980.1447017198429
Content-Type: multipart/alternative;
 boundary="----=_Part_4717_1212785001.1447017198429"

------=_Part_4717_1212785001.1447017198429
Content-Type: text/plain; charset=UTF-8

On Sunday, November 8, 2015 at 2:54:51 PM UTC-5, Vishal Oza wrote:
>
> I believe throw is either may removed or deprecated with c++ 17 according
> to the doc number P0003R0.
>

P0003 clearly says, "However, the syntax of the throw() specification
should be retained, but no longer as a dyanmic exception specification." So
like I said, non-empty `throw` lists would be removed.


> The proposed change that I see would initial generate an exception table
> during the preprocessor stage before compiling
> to determined which functions to check if they can throw do not knows.
>

Functions don't exist "during the preprocessor stage". At that point, it's
just a stream of tokens. It is not possible to determine anything about any
function at that point.


> If the is no source code is available and it cannot determining because it
> cannot find it from its implementation for example it uses some 3rd party
> library then how it should treat this case is undefined behavior and the
> compiler writers should determine how to treat this case. This case is
> something I do know if from a compiled library you can determine if a
> function throws
>

There is functionally no difference between "some 3rd party library" and
some other source file in your project. They're all just compiled object
files to the linker. As such, it has no more ability to figure out what
exceptions can be thrown in another .cpp file than it does in "some 3rd
party library".

What you want seems very confused next to how C++ works.

--

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

<div dir=3D"ltr">On Sunday, November 8, 2015 at 2:54:51 PM UTC-5, Vishal Oz=
a 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">I bel=
ieve throw is either may removed or deprecated with c++ 17 according to the=
 doc number<font size=3D"2" face=3D"arial, sans-serif">=C2=A0<span style=3D=
"color:rgb(0,0,0)">P0003R0.</span></font></div></blockquote><div><br>P0003 =
clearly says, &quot;However, the syntax of the <tt>throw()</tt> specificati=
on should be
retained, but no longer as a dyanmic exception specification.&quot; So like=
 I said, non-empty `throw` lists would be removed.<br>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><font color=3D"#000000=
" size=3D"2" face=3D"arial, sans-serif">The proposed change that I see woul=
d=C2=A0initial=C2=A0generate an=C2=A0exception=C2=A0table during the prepro=
cessor stage before compiling to=C2=A0determined=C2=A0which=C2=A0functions=
=C2=A0<wbr>to check if they can throw do not knows.</font></div></blockquot=
e><div><br>Functions don&#39;t exist &quot;during the preprocessor stage&qu=
ot;. At that point, it&#39;s just a stream of tokens. It is not possible to=
 determine anything about any function at that point.<br>=C2=A0</div><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"><font color=3D"#000=
000" size=3D"2" face=3D"arial, sans-serif">If the is no source code is=C2=
=A0available=C2=A0and it cannot=C2=A0determining=C2=A0because it cannot fin=
d it from its=C2=A0implementation=C2=A0for example it uses some 3rd party l=
ibrary then how it should treat this case is undefined behavior and the com=
piler writers should determine how to treat this case. This case is somethi=
ng I do know if from a compiled library you can=C2=A0determine if a functio=
n throws</font></div></blockquote><div><br>There is functionally no differe=
nce between &quot;some 3rd party library&quot; and some other source file i=
n your project. They&#39;re all just compiled object files to the linker. A=
s such, it has no more ability to figure out what exceptions can be thrown =
in another .cpp file than it does in &quot;some 3rd party library&quot;.<br=
></div><br>What you want seems very confused next to how C++ works.<br></di=
v>

<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_4717_1212785001.1447017198429--
------=_Part_4716_1042979980.1447017198429--

.

------=_Part_320_1947565824.1447022408549
Content-Type: multipart/alternative;
 boundary="----=_Part_321_974863945.1447022408549"

------=_Part_321_974863945.1447022408549
Content-Type: text/plain; charset=UTF-8

then should exception handling be removed as it is a burden to performance?
Or is there any language feature that  turn off exception handling? While
exception handling simplifies exception condition there is also the
run-time cost of checking if the exception is thrown how do you negate this
cost is a question so that you only have exception handling if you need it?

On Sunday, November 8, 2015 at 3:13:18 PM UTC-6, Nicol Bolas wrote:
>
> On Sunday, November 8, 2015 at 2:54:51 PM UTC-5, Vishal Oza wrote:
>>
>> I believe throw is either may removed or deprecated with c++ 17 according
>> to the doc number P0003R0.
>>
>
> P0003 clearly says, "However, the syntax of the throw() specification
> should be retained, but no longer as a dyanmic exception specification." So
> like I said, non-empty `throw` lists would be removed.
>
>
>> The proposed change that I see would initial generate an exception table
>> during the preprocessor stage before compiling
>> to determined which functions to check if they can throw do not knows.
>>
>
> Functions don't exist "during the preprocessor stage". At that point, it's
> just a stream of tokens. It is not possible to determine anything about any
> function at that point.
>
>
>> If the is no source code is available and it cannot determining because
>> it cannot find it from its implementation for example it uses some 3rd
>> party library then how it should treat this case is undefined behavior and
>> the compiler writers should determine how to treat this case. This case is
>> something I do know if from a compiled library you can determine if a
>> function throws
>>
>
> There is functionally no difference between "some 3rd party library" and
> some other source file in your project. They're all just compiled object
> files to the linker. As such, it has no more ability to figure out what
> exceptions can be thrown in another .cpp file than it does in "some 3rd
> party library".
>
> What you want seems very confused next to how C++ works.
>

--

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

<div dir=3D"ltr">then should exception handling be removed as it is a burde=
n to performance? Or is there any language feature that =C2=A0turn off exce=
ption handling? While exception handling simplifies exception condition the=
re is also the run-time cost of checking if the exception is thrown how do =
you negate this cost is a question so that you only have=C2=A0exception han=
dling if you need it?<br><br>On Sunday, November 8, 2015 at 3:13:18 PM UTC-=
6, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Sunday, November 8, 2015 at 2:54:51 PM UTC-5, Vishal Oza 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">I believe throw is=
 either may removed or deprecated with c++ 17 according to the doc number<f=
ont size=3D"2" face=3D"arial, sans-serif">=C2=A0<span style=3D"color:rgb(0,=
0,0)">P0003R0.</span></font></div></blockquote><div><br>P0003 clearly says,=
 &quot;However, the syntax of the <tt>throw()</tt> specification should be
retained, but no longer as a dyanmic exception specification.&quot; So like=
 I said, non-empty `throw` lists would be removed.<br>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><font color=3D"#000000" siz=
e=3D"2" face=3D"arial, sans-serif">The proposed change that I see would=C2=
=A0initial=C2=A0generate an=C2=A0exception=C2=A0table during the preprocess=
or stage before compiling to=C2=A0determined=C2=A0which=C2=A0functions=C2=
=A0<wbr>to check if they can throw do not knows.</font></div></blockquote><=
div><br>Functions don&#39;t exist &quot;during the preprocessor stage&quot;=
.. At that point, it&#39;s just a stream of tokens. It is not possible to de=
termine anything about any function at that point.<br>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><font color=3D"#000000" siz=
e=3D"2" face=3D"arial, sans-serif">If the is no source code is=C2=A0availab=
le=C2=A0and it cannot=C2=A0determining=C2=A0because it cannot find it from =
its=C2=A0implementation=C2=A0for example it uses some 3rd party library the=
n how it should treat this case is undefined behavior and the compiler writ=
ers should determine how to treat this case. This case is something I do kn=
ow if from a compiled library you can=C2=A0determine if a function throws</=
font></div></blockquote><div><br>There is functionally no difference betwee=
n &quot;some 3rd party library&quot; and some other source file in your pro=
ject. They&#39;re all just compiled object files to the linker. As such, it=
 has no more ability to figure out what exceptions can be thrown in another=
 .cpp file than it does in &quot;some 3rd party library&quot;.<br></div><br=
>What you want seems very confused next to how C++ works.<br></div></blockq=
uote></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_321_974863945.1447022408549--
------=_Part_320_1947565824.1447022408549--

.

On Sat, Nov 07, 2015 at 04:44:53PM -0800, Vishal Oza wrote:
> I know that the standard is removing the exception specification in favor
> the noexcept keyword but I think that this still think that there is still
> a uses case for exception specification. what I would like to propose in to
> change the exception specification from being a run-time check to a
> compile-time that can help static analysis tools and compilers determine how

If I understand you correctly you want static checking of throw specifiers,
is that correct? (Your automatic throw specifiers have already been througly
rejected by others so I won't mention them)

If I remember correctly then both throw specifiers and noexcept did have
static checking in their initial incarnations, but somehow that got lost
during standardization both times around.

Sadly I fail to remember why that happened but I do think it could be a
useful feature even if it would have to be pretty heavy weight (Would the
list of possible exceptions need to be part of the mangled name of the
function? Should we then allow overloading on throw specifiers? Is this
can of worms really worth opening? Was that why static checking died?).
In any case I think you need to invent some new syntax fo statically checked
exceptions.

/MF

--

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

.

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

FWIW, I don't think we need to standardize a static analysis check for
exception specifications -- I suspect you can still implement a static
analysis of exception propagation for statically-known paths. The hard part
here is when you have lambdas being called in other threads, propagated
through std::future/std::promise, and other dynamic mechanisms (like when a
function comes from a dynamically loaded library, JIT'ed runtime code,
etc.). Requiring compilers to do specific diagnosis for these kinds of
things sounds like a non-starter already in the past few decades of C++
implementation experience.

On Mon, Nov 9, 2015 at 9:48 AM Magnus Fromreide <magfr@lysator.liu.se>
wrote:

> On Sat, Nov 07, 2015 at 04:44:53PM -0800, Vishal Oza wrote:
> > I know that the standard is removing the exception specification in favor
> > the noexcept keyword but I think that this still think that there is
> still
> > a uses case for exception specification. what I would like to propose in
> to
> > change the exception specification from being a run-time check to a
> > compile-time that can help static analysis tools and compilers determine
> how
>
> If I understand you correctly you want static checking of throw specifiers,
> is that correct? (Your automatic throw specifiers have already been
> througly
> rejected by others so I won't mention them)
>
> If I remember correctly then both throw specifiers and noexcept did have
> static checking in their initial incarnations, but somehow that got lost
> during standardization both times around.
>
> Sadly I fail to remember why that happened but I do think it could be a
> useful feature even if it would have to be pretty heavy weight (Would the
> list of possible exceptions need to be part of the mangled name of the
> function? Should we then allow overloading on throw specifiers? Is this
> can of worms really worth opening? Was that why static checking died?).
> In any case I think you need to invent some new syntax fo statically
> checked
> exceptions.
>
> /MF
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving 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/.

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

<div dir=3D"ltr">FWIW, I don&#39;t think we need to standardize a static an=
alysis check for exception specifications -- I suspect you can still implem=
ent a static analysis of exception propagation for statically-known paths. =
The hard part here is when you have lambdas being called in other threads, =
propagated through std::future/std::promise, and other dynamic mechanisms (=
like when a function comes from a dynamically loaded library, JIT&#39;ed ru=
ntime code, etc.). Requiring compilers to do specific diagnosis for these k=
inds of things sounds like a non-starter already in the past few decades of=
 C++ implementation experience.</div><br><div class=3D"gmail_quote"><div di=
r=3D"ltr">On Mon, Nov 9, 2015 at 9:48 AM Magnus Fromreide &lt;<a href=3D"ma=
ilto:magfr@lysator.liu.se">magfr@lysator.liu.se</a>&gt; wrote:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">On Sat, Nov 07, 2015 at 04:44:53PM -0800, Visha=
l Oza wrote:<br>
&gt; I know that the standard is removing the exception specification in fa=
vor<br>
&gt; the noexcept keyword but I think that this still think that there is s=
till<br>
&gt; a uses case for exception specification. what I would like to propose =
in to<br>
&gt; change the exception specification from being a run-time check to a<br=
>
&gt; compile-time that can help static analysis tools and compilers determi=
ne how<br>
<br>
If I understand you correctly you want static checking of throw specifiers,=
<br>
is that correct? (Your automatic throw specifiers have already been througl=
y<br>
rejected by others so I won&#39;t mention them)<br>
<br>
If I remember correctly then both throw specifiers and noexcept did have<br=
>
static checking in their initial incarnations, but somehow that got lost<br=
>
during standardization both times around.<br>
<br>
Sadly I fail to remember why that happened but I do think it could be a<br>
useful feature even if it would have to be pretty heavy weight (Would the<b=
r>
list of possible exceptions need to be part of the mangled name of the<br>
function? Should we then allow overloading on throw specifiers? Is this<br>
can of worms really worth opening? Was that why static checking died?).<br>
In any case I think you need to invent some new syntax fo statically checke=
d<br>
exceptions.<br>
<br>
/MF<br>
<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" 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/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote></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 />

--001a1140dbb435bdcd05240f7e72--

.

------=_Part_4621_1900230803.1447032795822
Content-Type: multipart/alternative;
 boundary="----=_Part_4622_1441552021.1447032795823"

------=_Part_4622_1441552021.1447032795823
Content-Type: text/plain; charset=UTF-8

On Sunday, November 8, 2015 at 5:40:09 PM UTC-5, Vishal Oza wrote:
>
> then should exception handling be removed as it is a burden to
> performance? Or is there any language feature that  turn off exception
> handling? While exception handling simplifies exception condition there is
> also the run-time cost of checking if the exception is thrown how do you
> negate this cost is a question so that you only have exception handling if
> you need it?
>

Um, since when is the fact that a function could throw an exception "a
burden to performance"? Last time I checked, many compilers implement
zero-overhead versions of exception handling, where cost is only paid when
the exception is actually thrown. And even for those that don't, the
overhead is hardly burdensome.

`noexcept` does not exist for performance reasons. Or rather, it's not
there to signal to the *compiler* that a function doesn't throw exceptions,
so that the compiler can emit special code for any calling functions. It's
not there to deal with throwing overhead.

`noexcept` exists to allow code to do different things, to have different
behavior, based on whether exceptions could be thrown or not. Being able to
detect when an exception cannot occur is useful in template
metaprogramming, as it allows the client template code to do different
things based on whether the function could throw.

So while it can improve performance, it would only be due to implementing
an operation more efficiently at the source code level. Not from the
compiler optimizing away some tiny exception support.

Also, please stop top-posting (putting your reply above the text you're
replying to).

--

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

<div dir=3D"ltr">On Sunday, November 8, 2015 at 5:40:09 PM UTC-5, Vishal Oz=
a 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">then =
should exception handling be removed as it is a burden to performance? Or i=
s there any language feature that =C2=A0turn off exception handling? While =
exception handling simplifies exception condition there is also the run-tim=
e cost of checking if the exception is thrown how do you negate this cost i=
s a question so that you only have=C2=A0exception handling if you need it?<=
br></div></blockquote><div><br>Um, since when is the fact that a function c=
ould throw an exception &quot;a burden to performance&quot;? Last time I ch=
ecked, many compilers implement zero-overhead versions of exception handlin=
g, where cost is only paid when the exception is actually thrown. And even =
for those that don&#39;t, the overhead is hardly burdensome.<br><br>`noexce=
pt` does not exist for performance reasons. Or rather, it&#39;s not there t=
o signal to the <i>compiler</i> that a function doesn&#39;t throw exception=
s, so that the compiler can emit special code for any calling functions. It=
&#39;s not there to deal with throwing overhead.<br><br>`noexcept` exists t=
o allow code to do different things, to have different behavior, based on w=
hether exceptions could be thrown or not. Being able to detect when an exce=
ption cannot occur is useful in template metaprogramming, as it allows the =
client template code to do different things based on whether the function c=
ould throw.<br><br>So while it can improve performance, it would only be du=
e to implementing an operation more efficiently at the source code level. N=
ot from the compiler optimizing away some tiny exception support.<br></div>=
<br>Also, please stop top-posting (putting your reply above the text you&#3=
9;re replying to).<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_4622_1441552021.1447032795823--
------=_Part_4621_1900230803.1447032795822--

.

------=_Part_703_1816344278.1447037445899
Content-Type: multipart/alternative;
 boundary="----=_Part_704_2105503713.1447037445899"

------=_Part_704_2105503713.1447037445899
Content-Type: text/plain; charset=UTF-8

The static analysis result the exception path analysis could tell the
compiler to build the code without any exception mechanism and exception
checking

On Sunday, November 8, 2015 at 4:48:40 PM UTC-6, Magnus Fromreide wrote:
>
> On Sat, Nov 07, 2015 at 04:44:53PM -0800, Vishal Oza wrote:
> > I know that the standard is removing the exception specification in
> favor
> > the noexcept keyword but I think that this still think that there is
> still
> > a uses case for exception specification. what I would like to propose in
> to
> > change the exception specification from being a run-time check to a
> > compile-time that can help static analysis tools and compilers determine
> how
>
> If I understand you correctly you want static checking of throw
> specifiers,
> is that correct? (Your automatic throw specifiers have already been
> througly
> rejected by others so I won't mention them)
>
> If I remember correctly then both throw specifiers and noexcept did have
> static checking in their initial incarnations, but somehow that got lost
> during standardization both times around.
>
> Sadly I fail to remember why that happened but I do think it could be a
> useful feature even if it would have to be pretty heavy weight (Would the
> list of possible exceptions need to be part of the mangled name of the
> function? Should we then allow overloading on throw specifiers? Is this
> can of worms really worth opening? Was that why static checking died?).
> In any case I think you need to invent some new syntax fo statically
> checked
> exceptions.
>
> /MF
>

--

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

<div dir=3D"ltr">The static analysis result the exception path analysis cou=
ld tell the compiler to build the code without any=C2=A0exception=C2=A0mech=
anism=C2=A0and exception checking<br><br>On Sunday, November 8, 2015 at 4:4=
8:40 PM UTC-6, Magnus Fromreide wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;">On Sat, Nov 07, 2015 at 04:44:53PM -0800, Vishal Oza wrote:
<br>&gt; I know that the standard is removing the exception specification i=
n favor=20
<br>&gt; the noexcept keyword but I think that this still think that there =
is still=20
<br>&gt; a uses case for exception specification. what I would like to prop=
ose in to=20
<br>&gt; change the exception specification from being a run-time check to =
a=20
<br>&gt; compile-time that can help static analysis tools and compilers det=
ermine how
<br>
<br>If I understand you correctly you want static checking of throw specifi=
ers,
<br>is that correct? (Your automatic throw specifiers have already been thr=
ougly
<br>rejected by others so I won&#39;t mention them)
<br>
<br>If I remember correctly then both throw specifiers and noexcept did hav=
e
<br>static checking in their initial incarnations, but somehow that got los=
t
<br>during standardization both times around.
<br>
<br>Sadly I fail to remember why that happened but I do think it could be a
<br>useful feature even if it would have to be pretty heavy weight (Would t=
he
<br>list of possible exceptions need to be part of the mangled name of the
<br>function? Should we then allow overloading on throw specifiers? Is this
<br>can of worms really worth opening? Was that why static checking died?).
<br>In any case I think you need to invent some new syntax fo statically ch=
ecked
<br>exceptions.
<br>
<br>/MF
<br></blockquote></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_704_2105503713.1447037445899--
------=_Part_703_1816344278.1447037445899--

.

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

On 8 November 2015 at 20:50, Vishal Oza <vickoza@gmail.com> wrote:

> The static analysis result the exception path analysis could tell the
> compiler to build the code without any exception mechanism and exception
> checking
>

This idea does not help static analysis tools, because you are asking the
compiler to do the static analysis itself.  If the static analysis has to
go through the body of the code anyway to figure it out you don't actually
need any kind of exception specification...
--
 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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 8 November 2015 at 20:50, Vishal Oza <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:vickoza@gmail.com" target=3D"_blank">vickoza@gmail.com</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">The static analys=
is result the exception path analysis could tell the compiler to build the =
code without any=C2=A0exception=C2=A0mechanism=C2=A0and exception checking<=
/div></blockquote><div><br></div><div>This idea does not help static analys=
is tools, because you are asking the compiler to do the static analysis its=
elf.=C2=A0 If the static analysis has to go through the body of the code an=
yway to figure it out you don&#39;t actually need any kind of exception spe=
cification...</div></div>-- <br><div class=3D"gmail_signature">=C2=A0Nevin =
&quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord=
..com" target=3D"_blank">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 />

--001a114920a04cb1ec052412b8cc--

.

------=_Part_3950_409888280.1447037751528
Content-Type: multipart/alternative;
 boundary="----=_Part_3951_1711982876.1447037751528"

------=_Part_3951_1711982876.1447037751528
Content-Type: text/plain; charset=UTF-8


On Sunday, November 8, 2015 at 7:33:16 PM UTC-6, Nicol Bolas wrote:
>
> On Sunday, November 8, 2015 at 5:40:09 PM UTC-5, Vishal Oza wrote:
>>
>> then should exception handling be removed as it is a burden to
>> performance? Or is there any language feature that  turn off exception
>> handling? While exception handling simplifies exception condition there is
>> also the run-time cost of checking if the exception is thrown how do you
>> negate this cost is a question so that you only have exception handling if
>> you need it?
>>
>
> Um, since when is the fact that a function could throw an exception "a
> burden to performance"? Last time I checked, many compilers implement
> zero-overhead versions of exception handling, where cost is only paid when
> the exception is actually thrown. And even for those that don't, the
> overhead is hardly burdensome.
>
> `noexcept` does not exist for performance reasons. Or rather, it's not
> there to signal to the *compiler* that a function doesn't throw
> exceptions, so that the compiler can emit special code for any calling
> functions. It's not there to deal with throwing overhead.
>
> `noexcept` exists to allow code to do different things, to have different
> behavior, based on whether exceptions could be thrown or not. Being able to
> detect when an exception cannot occur is useful in template
> metaprogramming, as it allows the client template code to do different
> things based on whether the function could throw.
>
> So while it can improve performance, it would only be due to implementing
> an operation more efficiently at the source code level. Not from the
> compiler optimizing away some tiny exception support.
>
> Also, please stop top-posting (putting your reply above the text you're
> replying to).
>

have you measured the impact of exception handling is the case of a
function that does not throw? Yes, in theory, there might be zero-overhead
versions of exception handling, but that does not mean there is no run-time
check because how should a try statement or a noexcept determine if it goes
into the exception path.

--

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

<br>On Sunday, November 8, 2015 at 7:33:16 PM UTC-6, Nicol Bolas 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">On Sunday, Novemb=
er 8, 2015 at 5:40:09 PM UTC-5, Vishal Oza wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">then should exception handling be removed as=
 it is a burden to performance? Or is there any language feature that =C2=
=A0turn off exception handling? While exception handling simplifies excepti=
on condition there is also the run-time cost of checking if the exception i=
s thrown how do you negate this cost is a question so that you only have=C2=
=A0exception handling if you need it?<br></div></blockquote><div><br>Um, si=
nce when is the fact that a function could throw an exception &quot;a burde=
n to performance&quot;? Last time I checked, many compilers implement zero-=
overhead versions of exception handling, where cost is only paid when the e=
xception is actually thrown. And even for those that don&#39;t, the overhea=
d is hardly burdensome.<br><br>`noexcept` does not exist for performance re=
asons. Or rather, it&#39;s not there to signal to the <i>compiler</i> that =
a function doesn&#39;t throw exceptions, so that the compiler can emit spec=
ial code for any calling functions. It&#39;s not there to deal with throwin=
g overhead.<br><br>`noexcept` exists to allow code to do different things, =
to have different behavior, based on whether exceptions could be thrown or =
not. Being able to detect when an exception cannot occur is useful in templ=
ate metaprogramming, as it allows the client template code to do different =
things based on whether the function could throw.<br><br>So while it can im=
prove performance, it would only be due to implementing an operation more e=
fficiently at the source code level. Not from the compiler optimizing away =
some tiny exception support.<br></div><br>Also, please stop top-posting (pu=
tting your reply above the text you&#39;re replying to).<br></div></blockqu=
ote><div><br></div><div>have you measured the impact of exception handling =
is the case of a function that does not throw? Yes, in theory, there might =
be zero-overhead versions of exception handling, but that does not mean the=
re is no run-time check because how should a try statement or a noexcept de=
termine if it goes into the exception path.</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_3951_1711982876.1447037751528--
------=_Part_3950_409888280.1447037751528--

.

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

On 8 November 2015 at 20:55, Vishal Oza <vickoza@gmail.com> wrote:

>
> On Sundayhave you measured the impact of exception handling is the case
> of a function that does not throw?


You, not Nicol, is the one proposing getting rid of them, so the burden of
benchmarking is on you, not him.


> Yes, in theory, there might be zero-overhead versions of exception
> handling, but that does not mean there is no run-time check because how
> should a try statement or a noexcept determine if it goes into the
> exception path.


It executes a statement starting with the keyword "throw".  I have no idea
what you mean by run time check here, other than user code having an "if"
statement looking for the exceptional condition that would also be present
if you were using something more C-ish like return codes.

Show us your benchmark code and results...
--
 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/.

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

<div dir=3D"ltr">On 8 November 2015 at 20:55, Vishal Oza <span dir=3D"ltr">=
&lt;<a href=3D"mailto:vickoza@gmail.com" target=3D"_blank">vickoza@gmail.co=
m</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><span class=3D""><br>On Sunday</span>h=
ave you measured the impact of exception handling is the case of a function=
 that does not throw? </blockquote><div><br></div><div>You, not Nicol, is t=
he one proposing getting rid of them, so the burden of benchmarking is on y=
ou, not him.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes, in =
theory, there might be zero-overhead versions of exception handling, but th=
at does not mean there is no run-time check because how should a try statem=
ent or a noexcept determine if it goes into the exception path.</blockquote=
><div><br></div><div>It executes a statement starting with the keyword &quo=
t;throw&quot;.=C2=A0 I have no idea what you mean by run time check here, o=
ther than user code having an &quot;if&quot; statement looking for the exce=
ptional condition that would also be present if you were using something mo=
re C-ish like return codes.</div><div><br></div><div>Show us your benchmark=
 code and results...</div></div>-- <br><div class=3D"gmail_signature">=C2=
=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@evi=
loverlord.com" target=3D"_blank">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 />

--001a114921d20af7fa052412ea79--

.

------=_Part_648_94431618.1447038871105
Content-Type: multipart/alternative;
 boundary="----=_Part_649_992445944.1447038871105"

------=_Part_649_992445944.1447038871105
Content-Type: text/plain; charset=UTF-8

On Sunday, November 8, 2015 at 8:55:09 PM UTC-6, Nevin ":-)" Liber wrote:
>
>
> On 8 November 2015 at 20:50, Vishal Oza <vic...@gmail.com <javascript:>>
> wrote:
>
>> The static analysis result the exception path analysis could tell the
>> compiler to build the code without any exception mechanism and exception
>> checking
>>
>
> This idea does not help static analysis tools, because you are asking the
> compiler to do the static analysis itself.  If the static analysis has to
> go through the body of the code anyway to figure it out you don't actually
> need any kind of exception specification...
> --
>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com <javascript:>>  (847)
> 691-1404
>

what I think the proper path is to create pre-compile or pre-build stage
where an exeception

--

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

On Sunday, November 8, 2015 at 8:55:09 PM UTC-6, Nevin &quot;:-)&quot; Libe=
r 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>=
<br><div class=3D"gmail_quote">On 8 November 2015 at 20:50, Vishal Oza <spa=
n dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"faxvbfZtFgAJ" 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;">vic...@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">The static analysis result the exception path a=
nalysis could tell the compiler to build the code without any=C2=A0exceptio=
n=C2=A0mechanism=C2=A0and exception checking</div></blockquote><div><br></d=
iv><div>This idea does not help static analysis tools, because you are aski=
ng the compiler to do the static analysis itself.=C2=A0 If the static analy=
sis has to go through the body of the code anyway to figure it out you don&=
#39;t actually need any kind of exception specification...</div></div>-- <b=
r><div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"javasc=
ript:" target=3D"_blank" gdf-obfuscated-mailto=3D"faxvbfZtFgAJ" 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;">ne...@eviloverlord.com=
</a><wbr>&gt;=C2=A0 (847) 691-1404</div></div></div></blockquote><div><br><=
/div><div>what I think the proper path is to create pre-compile or pre-buil=
d stage where an exeception=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_649_992445944.1447038871105--
------=_Part_648_94431618.1447038871105--

.

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

On 8 November 2015 at 21:14, Vishal Oza <vickoza@gmail.com> wrote:

> what I think the proper path is to create pre-compile or pre-build stage
> where an exeception
>

You basically want to double compile times, because you need everything
except the codegen to figure this out.

And it only works for trivial programs that never, say, call an OS function
(C linkage does not imply no exceptions).

How would this work with templates?

How would this work with someone wanting to use std::function to store a
callback?  Do they have to implement their own version of std::function for
each set of exception specifications?

The whole point of exceptions is that intermediate code between the throw
and the catch doesn't have to know or care what exceptions are being
thrown.  You want *all* intermediate code to have to know what exceptions
are being thrown (which, as Nicol pointed out earlier, is the same as Java
checked exceptions in this regard, with all the same problems).
--
 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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 8 November 2015 at 21:14, Vishal Oza <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:vickoza@gmail.com" target=3D"_blank">vickoza@gmail.com</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>what I think the proper path =
is to create pre-compile or pre-build stage where an exeception=C2=A0</div>=
</blockquote><div><br></div><div>You basically want to double compile times=
, because you need everything except the codegen to figure this out.</div><=
div><br></div><div>And it only works for trivial programs that never, say, =
call an OS function (C linkage does not imply no exceptions).</div><div><br=
></div><div>How would this work with templates?</div><div><br></div><div>Ho=
w would this work with someone wanting to use std::function to store a call=
back?=C2=A0 Do they have to implement their own version of std::function fo=
r each set of exception specifications?</div><div><br></div><div>The whole =
point of exceptions is that intermediate code between the throw and the cat=
ch doesn&#39;t have to know or care what exceptions are being thrown.=C2=A0=
 You want <i>all</i> intermediate code to have to know what exceptions are =
being thrown (which, as Nicol pointed out earlier, is the same as Java chec=
ked exceptions in this regard, with all the same problems).</div></div>-- <=
br><div class=3D"gmail_signature">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &=
lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">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 />

--001a114921d22151390524131903--

.

------=_Part_4915_2049391617.1447039785426
Content-Type: multipart/alternative;
 boundary="----=_Part_4916_862474540.1447039785427"

------=_Part_4916_862474540.1447039785427
Content-Type: text/plain; charset=UTF-8



On Sunday, November 8, 2015 at 9:55:51 PM UTC-5, Vishal Oza wrote:
>
>
> On Sunday, November 8, 2015 at 7:33:16 PM UTC-6, Nicol Bolas wrote:
>>
>> On Sunday, November 8, 2015 at 5:40:09 PM UTC-5, Vishal Oza wrote:
>>>
>>> then should exception handling be removed as it is a burden to
>>> performance? Or is there any language feature that  turn off exception
>>> handling? While exception handling simplifies exception condition there is
>>> also the run-time cost of checking if the exception is thrown how do you
>>> negate this cost is a question so that you only have exception handling if
>>> you need it?
>>>
>>
>> Um, since when is the fact that a function could throw an exception "a
>> burden to performance"? Last time I checked, many compilers implement
>> zero-overhead versions of exception handling, where cost is only paid when
>> the exception is actually thrown. And even for those that don't, the
>> overhead is hardly burdensome.
>>
>> `noexcept` does not exist for performance reasons. Or rather, it's not
>> there to signal to the *compiler* that a function doesn't throw
>> exceptions, so that the compiler can emit special code for any calling
>> functions. It's not there to deal with throwing overhead.
>>
>> `noexcept` exists to allow code to do different things, to have different
>> behavior, based on whether exceptions could be thrown or not. Being able to
>> detect when an exception cannot occur is useful in template
>> metaprogramming, as it allows the client template code to do different
>> things based on whether the function could throw.
>>
>> So while it can improve performance, it would only be due to implementing
>> an operation more efficiently at the source code level. Not from the
>> compiler optimizing away some tiny exception support.
>>
>> Also, please stop top-posting (putting your reply above the text you're
>> replying to).
>>
>
> have you measured the impact of exception handling is the case of a
> function that does not throw?
>

No. But this person has
<http://preshing.com/20110807/the-cost-of-enabling-exception-handling/>.
The worst case performance difference was 4%. In one case, the performance
difference was so negligible that the way the compiler laid out the
functions caused enough of a cache performance difference to make the
exception-enabled version *faster*.


> Yes, in theory, there might be zero-overhead versions of exception
> handling,
>

No, zero-overhead exceptions are not something that exists "in theory".
They are a real thing and they really have zero overhead unless an
exception is actually thrown.


> but that does not mean there is no run-time check because how should a try
> statement or a noexcept determine if it goes into the exception path.
>

Maybe you should use Google to see how zero-overhead exception systems
work.

--

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

<br><br>On Sunday, November 8, 2015 at 9:55:51 PM UTC-5, Vishal Oza wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><br>On Sunday, November 8, 2015=
 at 7:33:16 PM UTC-6, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr">On Sunday, November 8, 2015 at 5:40:09 PM UTC-5, Vish=
al Oza wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">then =
should exception handling be removed as it is a burden to performance? Or i=
s there any language feature that =C2=A0turn off exception handling? While =
exception handling simplifies exception condition there is also the run-tim=
e cost of checking if the exception is thrown how do you negate this cost i=
s a question so that you only have=C2=A0exception handling if you need it?<=
br></div></blockquote><div><br>Um, since when is the fact that a function c=
ould throw an exception &quot;a burden to performance&quot;? Last time I ch=
ecked, many compilers implement zero-overhead versions of exception handlin=
g, where cost is only paid when the exception is actually thrown. And even =
for those that don&#39;t, the overhead is hardly burdensome.<br><br>`noexce=
pt` does not exist for performance reasons. Or rather, it&#39;s not there t=
o signal to the <i>compiler</i> that a function doesn&#39;t throw exception=
s, so that the compiler can emit special code for any calling functions. It=
&#39;s not there to deal with throwing overhead.<br><br>`noexcept` exists t=
o allow code to do different things, to have different behavior, based on w=
hether exceptions could be thrown or not. Being able to detect when an exce=
ption cannot occur is useful in template metaprogramming, as it allows the =
client template code to do different things based on whether the function c=
ould throw.<br><br>So while it can improve performance, it would only be du=
e to implementing an operation more efficiently at the source code level. N=
ot from the compiler optimizing away some tiny exception support.<br></div>=
<br>Also, please stop top-posting (putting your reply above the text you&#3=
9;re replying to).<br></div></blockquote><div><br></div><div>have you measu=
red the impact of exception handling is the case of a function that does no=
t throw?</div></blockquote><div><br>No. <a href=3D"http://preshing.com/2011=
0807/the-cost-of-enabling-exception-handling/">But this person has</a>. The=
 worst case performance difference was 4%. In one case, the performance dif=
ference was so negligible that the way the compiler laid out the functions =
caused enough of a cache performance difference to make the exception-enabl=
ed version <i>faster</i>.<br>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div>Yes, in theory, there might be zero-overhead versions of ex=
ception handling,</div></blockquote><div><br>No, zero-overhead exceptions a=
re not something that exists &quot;in theory&quot;. They are a real thing a=
nd they really have zero overhead unless an exception is actually thrown.<b=
r>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div> but that d=
oes not mean there is no run-time check because how should a try statement =
or a noexcept determine if it goes into the exception path.</div></blockquo=
te><div><br>Maybe you should use Google to see how zero-overhead exception =
systems work. <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_4916_862474540.1447039785427--
------=_Part_4915_2049391617.1447039785426--

.

------=_Part_111_1673666272.1447057748814
Content-Type: multipart/alternative;
 boundary="----=_Part_112_453522339.1447057748815"

------=_Part_112_453522339.1447057748815
Content-Type: text/plain; charset=UTF-8

Is that even possible? How should the compiler check that, if I use a
function-pointer, which's value is not known at compile-time?

--

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

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

<div dir=3D"ltr">Is that even possible? How should the compiler check that,=
 if I use a function-pointer, which&#39;s value is not known at compile-tim=
e?=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_112_453522339.1447057748815--
------=_Part_111_1673666272.1447057748814--

.

------=_Part_2_310919463.1447075314104
Content-Type: multipart/alternative;
 boundary="----=_Part_3_448511275.1447075314105"

------=_Part_3_448511275.1447075314105
Content-Type: text/plain; charset=UTF-8

On Monday, November 9, 2015 at 3:29:08 AM UTC-5, Klemens Morgenstern wrote:
>
> Is that even possible? How should the compiler check that, if I use a
> function-pointer, which's value is not known at compile-time?
>

Why does the compiler need to check that at all? Or to put it another way,
zero overhead exceptions are implemented in such a way that the compiler
doesn't need to care what a function pointer emits.

--

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

<div dir=3D"ltr">On Monday, November 9, 2015 at 3:29:08 AM UTC-5, Klemens M=
orgenstern wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">Is that even possible? How should the compiler check that, if I use a f=
unction-pointer, which&#39;s value is not known at compile-time?=C2=A0</div=
></blockquote><div><br>Why does the compiler need to check that at all? Or =
to put it another way, zero overhead exceptions are implemented in such a w=
ay that the compiler doesn&#39;t need to care what a function pointer emits=
..<br></div></div>

<p></p>

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

------=_Part_3_448511275.1447075314105--
------=_Part_2_310919463.1447075314104--

.

------=_Part_120_1835273501.1447080395239
Content-Type: multipart/alternative;
 boundary="----=_Part_121_1378594830.1447080395239"

------=_Part_121_1378594830.1447080395239
Content-Type: text/plain; charset=UTF-8

Am Montag, 9. November 2015 14:21:54 UTC+1 schrieb Nicol Bolas:
>
> On Monday, November 9, 2015 at 3:29:08 AM UTC-5, Klemens Morgenstern wrote:
>>
>> Is that even possible? How should the compiler check that, if I use a
>> function-pointer, which's value is not known at compile-time?
>>
>
> Why does the compiler need to check that at all? Or to put it another way,
> zero overhead exceptions are implemented in such a way that the compiler
> doesn't need to care what a function pointer emits.
>

Well according to this idea, the compiler would need to do that. That is,
if it shall statically check which exceptions can be thrown,

--

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

<div dir=3D"ltr">Am Montag, 9. November 2015 14:21:54 UTC+1 schrieb Nicol B=
olas:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Monda=
y, November 9, 2015 at 3:29:08 AM UTC-5, Klemens Morgenstern 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">Is that even possible? How=
 should the compiler check that, if I use a function-pointer, which&#39;s v=
alue is not known at compile-time?=C2=A0</div></blockquote><div><br>Why doe=
s the compiler need to check that at all? Or to put it another way, zero ov=
erhead exceptions are implemented in such a way that the compiler doesn&#39=
;t need to care what a function pointer emits.<br></div></div></blockquote>=
<div><br></div><div>Well according to this idea, the compiler would need to=
 do that. That is, if it shall statically check which exceptions can be thr=
own,</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_121_1378594830.1447080395239--
------=_Part_120_1835273501.1447080395239--

.

--Apple-Mail=_97A519C5-B91F-4C83-A886-0044455DD489
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

It seems like a lot of the problems raised as unsolvable philosophical issu=
es in C++ are actually addressed fairly elegantly, at least IMO, in Swift. =
 Of course I=E2=80=99m sure there are C++-specific standardese/concerns tha=
t would prevent adoption (a fair one would be do we need to annotate everyt=
hing correctly to see benefit).

I don=E2=80=99t think it would be an unfair statement to state that the cur=
rent state of C++ exceptions suffers adoption & approach-ability because it=
=E2=80=99s trivial to write code that accidentally forgets to handle an exc=
eption leading to silent runtime failures which would seem undesirable to m=
e.  It seems like people would tend to, rightly or wrongly, rather ignore e=
rror codes due to missing code than crash due to missing exception handlers=
 & so error codes persist in cases they shouldn=E2=80=99t which is one of t=
he reasons the community seems to be so fragmented on exceptions.

You can also see this (easy to write code that doesn=E2=80=99t error-handle=
 correctly) as being a pain-point that people in the industry are attemptin=
g to solve anyway through compiler switches (Google=E2=80=99s contribution =
of switches to generate warnings/errors about unused return codes) or new l=
anguages (Swift, Rust).

I could be wrong but it seems like the starting premise & argument for a lo=
t of people is that compiler-checked exceptions are inherently bad & there=
=E2=80=99s no way to get it right solely due to the shadow of Java.  Learni=
ng from mistakes is how the industry moves forward but it would be a shame =
to wholesale abandonment any amount of checked exceptions out of fear.  Let=
=E2=80=99s take the parts that are good (compiler protection against missin=
g error-handling codepaths) from the parts that didn=E2=80=99t pan out (enc=
oding the full exception signature in the ABI & not providing an easy-out f=
or =E2=80=9CI don=E2=80=99t care if this throws").

-Vitali


For those unfamiliar with Swift, any function that could throw an exception=
 is marked with the `throws` keyword.  Any statement that could throw an ex=
ception must have the `try` keyword in front of it & must either be wrapped=
 in a do/catch that handles all exceptions, be in a function itself marked =
throws, or marked instead as try! which aborts on exception.  There=E2=80=
=99s a little bit more complexity than this but it covers the basics.  std:=
:function could be implemented elegantly where you have a non-throwing & a =
potentially throwing implementation or you could have a single one that is =
always potentially throwing to simplify the API (probably the second one to=
 avoid complexity).  Also, the majority of code is not dynamic in the way s=
td::function is & it=E2=80=99s a non-issue the majority of the time.

> On Nov 9, 2015, at 6:46 AM, Klemens Morgenstern <klemens.morgenstern@gmx.=
net> wrote:
>=20
> Am Montag, 9. November 2015 14:21:54 UTC+1 schrieb Nicol Bolas:
> On Monday, November 9, 2015 at 3:29:08 AM UTC-5, Klemens Morgenstern wrot=
e:
> Is that even possible? How should the compiler check that, if I use a fun=
ction-pointer, which's value is not known at compile-time?=20
>=20
> Why does the compiler need to check that at all? Or to put it another way=
, zero overhead exceptions are implemented in such a way that the compiler =
doesn't need to care what a function pointer emits.
>=20
> Well according to this idea, the compiler would need to do that. That is,=
 if it shall statically check which exceptions can be thrown,
>=20
> --=20
>=20
> ---=20
> You received this message because you are subscribed to the Google Groups=
 "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
 email to std-proposals+unsubscribe@isocpp.org <mailto:std-proposals+unsubs=
cribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org <mailto:std=
-proposals@isocpp.org>.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propo=
sals/ <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/.

--Apple-Mail=_97A519C5-B91F-4C83-A886-0044455DD489
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""><div class=3D"">It=
 seems like a lot of the problems raised as unsolvable philosophical issues=
 in C++ are actually addressed fairly elegantly, at least IMO, in Swift. &n=
bsp;Of course I=E2=80=99m sure there are C++-specific standardese/concerns =
that would prevent adoption (a fair one would be do we need to annotate eve=
rything correctly to see benefit).</div><div class=3D""><br class=3D""></di=
v><div class=3D"">I don=E2=80=99t think it would be an unfair statement to =
state that the current state of C++ exceptions suffers adoption &amp; appro=
ach-ability because it=E2=80=99s trivial to write code that accidentally fo=
rgets to handle an exception leading to silent runtime failures which would=
 seem undesirable to me. &nbsp;It seems like people would tend to, rightly =
or wrongly, rather ignore error codes due to missing code than crash due to=
 missing exception handlers &amp; so error codes persist in cases they shou=
ldn=E2=80=99t which is one of the reasons the community seems to be so frag=
mented on exceptions.</div><div class=3D""><br class=3D""></div><div class=
=3D""><div class=3D"">You can also see this (easy to write code that doesn=
=E2=80=99t error-handle correctly) as being a pain-point that people in the=
 industry are attempting to solve anyway through compiler switches (Google=
=E2=80=99s contribution of switches to generate warnings/errors about unuse=
d return codes) or new languages (Swift, Rust).</div><div class=3D""><br cl=
ass=3D""></div><div class=3D""><div class=3D"">I could be wrong but it seem=
s like the starting premise &amp; argument for a lot of people is that comp=
iler-checked exceptions are inherently bad &amp; there=E2=80=99s no way to =
get it right solely due to the shadow of Java. &nbsp;Learning from mistakes=
 is how the industry moves forward but it would be a shame to wholesale aba=
ndonment any amount of checked exceptions out of fear. &nbsp;Let=E2=80=99s =
take the parts that are good (compiler protection against missing error-han=
dling codepaths) from the parts that didn=E2=80=99t pan out (encoding the f=
ull exception signature in the ABI &amp; not providing an easy-out for =E2=
=80=9CI don=E2=80=99t care if this throws").</div></div><div class=3D""><br=
 class=3D""></div><div class=3D"">-Vitali</div><div class=3D""><br class=3D=
""></div><div class=3D""><br class=3D""></div><div class=3D"">For those unf=
amiliar with Swift, any function that could throw an exception is marked wi=
th the `throws` keyword. &nbsp;Any statement that could throw an exception =
must have the `try` keyword in front of it &amp; must either be wrapped in =
a do/catch that handles all exceptions, be in a function itself marked thro=
ws, or marked instead as try! which aborts on exception. &nbsp;There=E2=80=
=99s a little bit more complexity than this but it covers the basics. &nbsp=
;std::function could be implemented elegantly where you have a non-throwing=
 &amp; a potentially throwing implementation or you could have a single one=
 that is always potentially throwing to simplify the API (probably the seco=
nd one to avoid complexity). &nbsp;Also, the majority of code is not dynami=
c in the way std::function is &amp; it=E2=80=99s a non-issue the majority o=
f the time.<br class=3D""><div class=3D""><br class=3D""><div><blockquote t=
ype=3D"cite" class=3D""><div class=3D"">On Nov 9, 2015, at 6:46 AM, Klemens=
 Morgenstern &lt;<a href=3D"mailto:klemens.morgenstern@gmx.net" class=3D"">=
klemens.morgenstern@gmx.net</a>&gt; wrote:</div><br class=3D"Apple-intercha=
nge-newline"><div class=3D""><div dir=3D"ltr" class=3D"">Am Montag, 9. Nove=
mber 2015 14:21:54 UTC+1 schrieb Nicol Bolas:<blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr" class=3D"">On Monday, November 9, 2015 at 3=
:29:08 AM UTC-5, Klemens Morgenstern 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" class=3D"">Is that even possible? How should the c=
ompiler check that, if I use a function-pointer, which's value is not known=
 at compile-time?&nbsp;</div></blockquote><div class=3D""><br class=3D"">Wh=
y does the compiler need to check that at all? Or to put it another way, ze=
ro overhead exceptions are implemented in such a way that the compiler does=
n't need to care what a function pointer emits.<br class=3D""></div></div><=
/blockquote><div class=3D""><br class=3D""></div><div class=3D"">Well accor=
ding to this idea, the compiler would need to do that. That is, if it shall=
 statically check which exceptions can be thrown,</div></div><div class=3D"=
"><br class=3D"webkit-block-placeholder"></div>

-- <br class=3D"">
<br class=3D"">
--- <br class=3D"">
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br class=3D"">
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" class=3D"">=
std-proposals+unsubscribe@isocpp.org</a>.<br class=3D"">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"">std-proposals@isocpp.org</a>.<br class=3D"">
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" class=3D"">http://groups.google.com/a/isocpp.org/group/std-=
proposals/</a>.<br class=3D"">
</div></blockquote></div><br class=3D""></div></div></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=_97A519C5-B91F-4C83-A886-0044455DD489--

.

------=_Part_762_718284475.1447093330091
Content-Type: multipart/alternative;
 boundary="----=_Part_763_601655916.1447093330091"

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



On Monday, November 9, 2015 at 12:44:24 PM UTC-5, vlovich wrote:
>
> It seems like a lot of the problems raised as unsolvable philosophical=20
> issues in C++ are actually addressed fairly elegantly, at least IMO, in=
=20
> Swift.  Of course I=E2=80=99m sure there are C++-specific standardese/con=
cerns that=20
> would prevent adoption (a fair one would be do we need to annotate=20
> everything correctly to see benefit).
>
> I don=E2=80=99t think it would be an unfair statement to state that the c=
urrent=20
> state of C++ exceptions suffers adoption & approach-ability because it=E2=
=80=99s=20
> trivial to write code that accidentally forgets to handle an exception=20
> leading to silent runtime failures which would seem undesirable to me.  I=
t=20
> seems like people would tend to, rightly or wrongly, rather ignore error=
=20
> codes due to missing code than crash due to missing exception handlers & =
so=20
> error codes persist in cases they shouldn=E2=80=99t which is one of the r=
easons the=20
> community seems to be so fragmented on exceptions.
>
> You can also see this (easy to write code that doesn=E2=80=99t error-hand=
le=20
> correctly) as being a pain-point that people in the industry are attempti=
ng=20
> to solve anyway through compiler switches (Google=E2=80=99s contribution =
of=20
> switches to generate warnings/errors about unused return codes) or new=20
> languages (Swift, Rust).
>
> I could be wrong but it seems like the starting premise & argument for a=
=20
> lot of people is that compiler-checked exceptions are inherently bad &=20
> there=E2=80=99s no way to get it right solely due to the shadow of Java. =
 Learning=20
> from mistakes is how the industry moves forward but it would be a shame t=
o=20
> wholesale abandonment any amount of checked exceptions out of fear.  Let=
=E2=80=99s=20
> take the parts that are good (compiler protection against missing=20
> error-handling codepaths) from the parts that didn=E2=80=99t pan out (enc=
oding the=20
> full exception signature in the ABI & not providing an easy-out for =E2=
=80=9CI=20
> don=E2=80=99t care if this throws").
>

Nobody said anything about being against any checking whatsoever. The=20
specific proposal was for Java-style checked exceptions, with some confused=
=20
compiler stuff about being able to automatically detect exceptions from=20
other functions. That's what we were talking about.

That being said, having to double-mark everything that may emit an=20
exception the way Swift requires is also bad. Oh, and it's really=20
un-backwards compatible too. So it's kind of a non-starter.

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

<br><br>On Monday, November 9, 2015 at 12:44:24 PM UTC-5, vlovich wrote:<bl=
ockquote 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-wor=
d"><div>It seems like a lot of the problems raised as unsolvable philosophi=
cal issues in C++ are actually addressed fairly elegantly, at least IMO, in=
 Swift. =C2=A0Of course I=E2=80=99m sure there are C++-specific standardese=
/concerns that would prevent adoption (a fair one would be do we need to an=
notate everything correctly to see benefit).</div><div><br></div><div>I don=
=E2=80=99t think it would be an unfair statement to state that the current =
state of C++ exceptions suffers adoption &amp; approach-ability because it=
=E2=80=99s trivial to write code that accidentally forgets to handle an exc=
eption leading to silent runtime failures which would seem undesirable to m=
e. =C2=A0It seems like people would tend to, rightly or wrongly, rather ign=
ore error codes due to missing code than crash due to missing exception han=
dlers &amp; so error codes persist in cases they shouldn=E2=80=99t which is=
 one of the reasons the community seems to be so fragmented on exceptions.<=
/div><div><br></div><div><div>You can also see this (easy to write code tha=
t doesn=E2=80=99t error-handle correctly) as being a pain-point that people=
 in the industry are attempting to solve anyway through compiler switches (=
Google=E2=80=99s contribution of switches to generate warnings/errors about=
 unused return codes) or new languages (Swift, Rust).</div><div><br></div><=
div><div>I could be wrong but it seems like the starting premise &amp; argu=
ment for a lot of people is that compiler-checked exceptions are inherently=
 bad &amp; there=E2=80=99s no way to get it right solely due to the shadow =
of Java. =C2=A0Learning from mistakes is how the industry moves forward but=
 it would be a shame to wholesale abandonment any amount of checked excepti=
ons out of fear. =C2=A0Let=E2=80=99s take the parts that are good (compiler=
 protection against missing error-handling codepaths) from the parts that d=
idn=E2=80=99t pan out (encoding the full exception signature in the ABI &am=
p; not providing an easy-out for =E2=80=9CI don=E2=80=99t care if this thro=
ws&quot;).</div></div></div></div></blockquote><div><br>Nobody said anythin=
g about being against any checking whatsoever. The specific proposal was fo=
r Java-style checked exceptions, with some confused compiler stuff about be=
ing able to automatically detect exceptions from other functions. That&#39;=
s what we were talking about.<br><br>That being said, having to double-mark=
 everything that may emit an exception the way Swift requires is also bad. =
Oh, and it&#39;s really un-backwards compatible too. So it&#39;s kind of a =
non-starter.</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_763_601655916.1447093330091--
------=_Part_762_718284475.1447093330091--

.