------=_Part_1526_1957752426.1431789945878
Content-Type: multipart/alternative;
 boundary="----=_Part_1527_200584448.1431789945878"

------=_Part_1527_200584448.1431789945878
Content-Type: text/plain; charset=UTF-8

All functions by default are noexcept(false) (except for destructors since
c++11?).

Is there a reason noexcept cannot be applied to a class like
__declspec(dllexport) or to a scope - like extern "C"?

It could be handy to set the default to true for a whole class and then set
it to false only for a few functions.

A (big?) benefit would be reduced binary size - less entries in the stack
unwinding stuff for exceptions...

Would such a proposal have any chance?

Also I'm not sure if the applicability of constexpr is also the same (only
on a per-function basis).

--

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

<div dir=3D"ltr"><div>All functions by default are noexcept(false) (except =
for destructors since c++11?).</div><div><br></div><div>Is there a reason n=
oexcept cannot be applied to a class like __declspec(dllexport) or to a sco=
pe - like extern "C"?</div><div><br></div><div>It could be handy to set the=
 default to true for a whole class and then set it to false only for a few =
functions.</div><div><br></div><div>A (big?) benefit would be reduced binar=
y size - less entries in the stack unwinding stuff for exceptions...</div><=
div><br></div><div>Would such a proposal have any chance?</div><div><br></d=
iv><div>Also I'm not sure if the applicability of constexpr is also the sam=
e (only on a per-function basis).</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_1527_200584448.1431789945878--
------=_Part_1526_1957752426.1431789945878--

.

--Apple-Mail=_664725D6-B86A-4E4F-A36C-86116E66F111
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9305=E2=80=9316, at 11:25 PM, Viktor Kirilov <vik.kirilov@g=
mail.com> wrote:
>=20
> All functions by default are noexcept(false) (except for destructors sinc=
e c++11?).

Implicitly-defined functions get computed noexcept specifications.

> Is there a reason noexcept cannot be applied to a class like __declspec(d=
llexport) or to a scope - like extern "C"?

extern "C++ noexcept" can fill this role. Those strings can be anything, an=
d modify the interpretation of the enclosed scope in any way. They=E2=80=99=
re mainly intended to modify the ABI in effect. It=E2=80=99s not too much o=
f a stretch to say that forbidding any function to propagate an exception i=
s just an alternate ABI.

Only problem is, it can only appear at namespace scope. However, it might b=
e more reasonable and better justified to mark an entire interface as noexc=
ept (or even constexpr) as opposed to just part of a class.

--=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=_664725D6-B86A-4E4F-A36C-86116E66F111
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9305=
=E2=80=9316, at 11:25 PM, Viktor Kirilov &lt;<a href=3D"mailto:vik.kirilov@=
gmail.com" class=3D"">vik.kirilov@gmail.com</a>&gt; wrote:</div><br class=
=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">=
<div class=3D"">All functions by default are noexcept(false) (except for de=
structors since c++11?).</div></div></div></blockquote><div><br class=3D"">=
</div><div>Implicitly-defined functions get computed <font face=3D"Courier"=
 class=3D"">noexcept</font> specifications.</div><br class=3D""><blockquote=
 type=3D"cite" class=3D""><div dir=3D"ltr" class=3D""><div class=3D"">Is th=
ere a reason noexcept cannot be applied to a class like __declspec(dllexpor=
t) or to a scope - like extern "C"?</div></div></blockquote><div><br class=
=3D""></div><div><font face=3D"Courier" class=3D"">extern&nbsp;"C++ noexcep=
t"</font>&nbsp;can fill this role. Those strings can be anything, and modif=
y the interpretation of the enclosed scope in any way. They=E2=80=99re main=
ly intended to modify the ABI in effect. It=E2=80=99s not too much of a str=
etch to say that forbidding any function to propagate an exception is just =
an alternate ABI.</div><div><br class=3D""></div><div>Only problem is, it c=
an only appear at namespace scope. However, it might be more reasonable and=
 better justified to mark an entire interface as <font face=3D"Courier" cla=
ss=3D"">noexcept</font> (or even <font face=3D"Courier" class=3D"">constexp=
r</font>) as opposed to just part of a class.</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=_664725D6-B86A-4E4F-A36C-86116E66F111--

.

------=_Part_1676_2133019735.1431794758518
Content-Type: multipart/alternative;
 boundary="----=_Part_1677_1718166774.1431794758518"

------=_Part_1677_1718166774.1431794758518
Content-Type: text/plain; charset=UTF-8



On Saturday, May 16, 2015 at 11:25:45 AM UTC-4, Viktor Kirilov wrote:
>
> All functions by default are noexcept(false) (except for destructors since
> c++11?).
>
> Is there a reason noexcept cannot be applied to a class like
> __declspec(dllexport) or to a scope - like extern "C"?
>
> It could be handy to set the default to true for a whole class and then
> set it to false only for a few functions.
>
> A (big?) benefit would be reduced binary size - less entries in the stack
> unwinding stuff for exceptions...
>

Would it? I can't think of very many class interfaces where it would be a
legitimate idea to mark everything noexcept by default; it'd mostly be for
"leaf"-type classes. And even if you did, have you noticed that marking
functions noexcept makes the compiled result smaller?

Would such a proposal have any chance?
>

Personally, I don't like the idea of having vital attributes of a function
that are not specified locally to a function. Scoping for namespaces/class
membership is one thing. But programmers do still make mistakes with
public/private, accidentally using the wrong access class because the
function was declared in the wrong place. The possibility for users messing
this up is non-trivial.

Also, if I recall correctly, `noexcept` is actually part of the function's
signature, like the return type and so forth. So you'd be breaking new
ground by having scoping actually affect the very signature of a function
(outside of class/namespace membership).

Before making a formal proposal, I would suggest providing hard evidence
that:

1) This is something that provides an actual benefit. That is, wide-spread
noexcept function use leads to a significant reduction in code size across
multiple compilers.

2) This would be useful to many C++ programmers. That is, projects have a
lot of groups of functions which ought to be declared `noexcept`, yet are
not so designated due to having to specify it in the class signature.

That could help outweigh the negatives.

Also I'm not sure if the applicability of constexpr is also the same (only
> on a per-function basis).
>

Um, no. `constexpr` is far too integral to the very meaning of the function
to not have it specified locally with the function declaration/definition.
After all, `constexpr` forbids a lot of C++ syntax and types. You shouldn't
have to look hundreds of lines away to determine if a particular type is
legal in the class.

`noexcept` isn't quite as transformative to a function. You can still throw
and catch exceptions within `noexcept` functions; it's just that if it
escapes the function, the application terminates. All C++ is *legal* in
`noexcept`; that's not true of `constexpr`.

--

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

<div dir=3D"ltr"><br><br>On Saturday, May 16, 2015 at 11:25:45 AM UTC-4, Vi=
ktor Kirilov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div>All functions by default are noexcept(false) (except for destruc=
tors since c++11?).</div><div><br></div><div>Is there a reason noexcept can=
not be applied to a class like __declspec(dllexport) or to a scope - like e=
xtern "C"?</div><div><br></div><div>It could be handy to set the default to=
 true for a whole class and then set it to false only for a few functions.<=
/div><div><br></div><div>A (big?) benefit would be reduced binary size - le=
ss entries in the stack unwinding stuff for exceptions...</div></div></bloc=
kquote><div><br>Would it? I can't think of very many class interfaces where=
 it would be a legitimate idea to mark everything noexcept by default; it'd=
 mostly be for "leaf"-type classes. And even if you did, have you noticed t=
hat marking functions noexcept makes the compiled result smaller?<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></di=
v><div>Would such a proposal have any chance?</div></div></blockquote><div>=
<br>Personally, I don't like the idea of having vital attributes of a funct=
ion that are not specified locally to a function. Scoping for namespaces/cl=
ass membership is one thing. But programmers do still make mistakes with pu=
blic/private, accidentally using the wrong access class because the functio=
n was declared in the wrong place. The possibility for users messing this u=
p is non-trivial.<br><br>Also, if I recall correctly, `noexcept` is actuall=
y part of the function's signature, like the return type and so forth. So y=
ou'd be breaking new ground by having scoping actually affect the very sign=
ature of a function (outside of class/namespace membership).<br><br>Before =
making a formal proposal, I would suggest providing hard evidence that:<br>=
<br>1) This is something that provides an actual benefit. That is, wide-spr=
ead noexcept function use leads to a significant reduction in code size acr=
oss multiple compilers.<br><br>2) This would be useful to many C++ programm=
ers. That is, projects have a lot of groups of functions which ought to be =
declared `noexcept`, yet are not so designated due to having to specify it =
in the class signature.<br><br>That could help outweigh the negatives.<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><div>Also I'm not sure if the applicability of constexpr is also the=
 same (only on a per-function basis). <br></div></div></blockquote><div><br=
>Um, no. `constexpr` is far too integral to the very meaning of the functio=
n to not have it specified locally with the function declaration/definition=
.. After all, `constexpr` forbids a lot of C++ syntax and types. You shouldn=
't have to look hundreds of lines away to determine if a particular type is=
 legal in the class.<br><br>`noexcept` isn't quite as transformative to a f=
unction. You can still throw and catch exceptions within `noexcept` functio=
ns; it's just that if it escapes the function, the application terminates. =
All C++ is <i>legal</i> in `noexcept`; that's not true of `constexpr`.<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_1677_1718166774.1431794758518--
------=_Part_1676_2133019735.1431794758518--

.