Topic: noexcept(auto)
Author: Daryle Walker <darylew@gmail.com>
Date: Sat, 26 Oct 2013 12:52:57 -0700 (PDT)
Raw View
------=_Part_96_3393886.1382817177672
Content-Type: text/plain; charset=ISO-8859-1
[This sometimes pops up on other threads, but now with a thread of its own,
it's searchable for the next person who wants to discuss it.]
I think there's going to be a "decltype(auto)" in an upcoming standard. Use
that text in place of a function return type, and the compiler will fill in
that type with whatever the function actually returns. It requires that the
first declaration of the function is the actual definition, since its pure
declaration would never be complete and therefore couldn't be used like
other function pure-declarations.
The "noexcept(auto)" construct works in a similar fashion. When declaring a
function, and that first declaration is also the definition, you can use "
auto" as the expression inside the noexcept clause. And then the compiler
will compute the noexcept status of the function's internal code and use
that result as the function's noexcept status. It'll probably be used in
short functions that already use decltype(auto).
Has this second construct already been proposed?
Daryle W.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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_96_3393886.1382817177672
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">[This sometimes pops up on other threads, but now with a t=
hread of its own, it's searchable for the next person who wants to discuss =
it.]<div><br></div><div>I think there's going to be a "<font face=3D"courie=
r new, monospace">decltype(auto)</font>" in an upcoming standard. Use that =
text in place of a function return type, and the compiler will fill in that=
type with whatever the function actually returns. It requires that the fir=
st declaration of the function is the actual definition, since its pure dec=
laration would never be complete and therefore couldn't be used like other =
function pure-declarations.</div><div><br></div><div>The "<font face=3D"cou=
rier new, monospace">noexcept(auto)</font>" construct works in a similar fa=
shion. When declaring a function, and that first declaration is also the de=
finition, you can use "<font face=3D"courier new, monospace">auto</font>" a=
s the expression inside the noexcept clause. And then the compiler will com=
pute the noexcept status of the function's internal code and use that resul=
t as the function's noexcept status. It'll probably be used in short functi=
ons that already use <font face=3D"courier new, monospace">decltype(auto)</=
font>.</div><div><br></div><div>Has this second construct already been prop=
osed?</div><div><br></div><div>Daryle W.</div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_96_3393886.1382817177672--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Sat, 26 Oct 2013 22:18:45 +0200
Raw View
2013/10/26 Daryle Walker <darylew@gmail.com>:
> [This sometimes pops up on other threads, but now with a thread of its own,
> it's searchable for the next person who wants to discuss it.]
>
> I think there's going to be a "decltype(auto)" in an upcoming standard. Use
> that text in place of a function return type, and the compiler will fill in
> that type with whatever the function actually returns. It requires that the
> first declaration of the function is the actual definition, since its pure
> declaration would never be complete and therefore couldn't be used like
> other function pure-declarations.
>
> The "noexcept(auto)" construct works in a similar fashion. When declaring a
> function, and that first declaration is also the definition, you can use
> "auto" as the expression inside the noexcept clause. And then the compiler
> will compute the noexcept status of the function's internal code and use
> that result as the function's noexcept status. It'll probably be used in
> short functions that already use decltype(auto).
>
> Has this second construct already been proposed?
Do you mean a second time?
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3207.htm
That being said I believe that its worth to reconsider that now,
hopefully we have now experience enough to give some good answers to
the problems mentioned in the proposal. At the time where the original
proposal had been made (and was rejected) the C++11 standard was
supposed to be finished.
- Daniel
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 26 Oct 2013 23:58:17 +0300
Raw View
--047d7bdc9c524ade4104e9ab20df
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 26 October 2013 23:18, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wrot=
e:
> 2013/10/26 Daryle Walker <darylew@gmail.com>:
> > [This sometimes pops up on other threads, but now with a thread of its
> own,
> > it's searchable for the next person who wants to discuss it.]
> >
> > I think there's going to be a "decltype(auto)" in an upcoming standard.
> Use
> > that text in place of a function return type, and the compiler will fil=
l
> in
> > that type with whatever the function actually returns. It requires that
> the
> > first declaration of the function is the actual definition, since its
> pure
> > declaration would never be complete and therefore couldn't be used like
> > other function pure-declarations.
> >
> > The "noexcept(auto)" construct works in a similar fashion. When
> declaring a
> > function, and that first declaration is also the definition, you can us=
e
> > "auto" as the expression inside the noexcept clause. And then the
> compiler
> > will compute the noexcept status of the function's internal code and us=
e
> > that result as the function's noexcept status. It'll probably be used i=
n
> > short functions that already use decltype(auto).
> >
> > Has this second construct already been proposed?
>
> Do you mean a second time?
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3207.htm
>
Or a third time, since noexcept(auto) was requested by the NB comment
FI 5 for C++14. That NB comment was rejected, so we'll likely try again for
C++17.
>
> That being said I believe that its worth to reconsider that now,
> hopefully we have now experience enough to give some good answers to
> the problems mentioned in the proposal. At the time where the original
> proposal had been made (and was rejected) the C++11 standard was
> supposed to be finished.
>
>
>
Most of the problems in the proposal aren't much different from potential
problems
that arise when deducing a function return type, I think.
--=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/.
--047d7bdc9c524ade4104e9ab20df
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 26 October 2013 23:18, Daniel Kr=FCgler <span dir=3D"ltr"><<a=
href=3D"mailto:daniel.kruegler@gmail.com" target=3D"_blank">daniel.kruegle=
r@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">2013/10/26 Daryle Walker <<a href=3D"mail=
to:darylew@gmail.com">darylew@gmail.com</a>>:<br>
<div class=3D"im">> [This sometimes pops up on other threads, but now wi=
th a thread of its own,<br>
> it's searchable for the next person who wants to discuss it.]<br>
><br>
> I think there's going to be a "decltype(auto)" in an upc=
oming standard. Use<br>
> that text in place of a function return type, and the compiler will fi=
ll in<br>
> that type with whatever the function actually returns. It requires tha=
t the<br>
> first declaration of the function is the actual definition, since its =
pure<br>
> declaration would never be complete and therefore couldn't be used=
like<br>
> other function pure-declarations.<br>
><br>
> The "noexcept(auto)" construct works in a similar fashion. W=
hen declaring a<br>
> function, and that first declaration is also the definition, you can u=
se<br>
> "auto" as the expression inside the noexcept clause. And the=
n the compiler<br>
> will compute the noexcept status of the function's internal code a=
nd use<br>
> that result as the function's noexcept status. It'll probably =
be used in<br>
> short functions that already use decltype(auto).<br>
><br>
> Has this second construct already been proposed?<br>
<br>
</div>Do you mean a second time?<br>
<br>
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3207.ht=
m" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/201=
0/n3207.htm</a><br></blockquote><div><br></div><div>Or a third time, since =
noexcept(auto) was requested by the NB comment<br>
</div><div>FI 5 for C++14. That NB comment was rejected, so we'll likel=
y try again for<br></div><div>C++17.<br>=A0<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
<br>
That being said I believe that its worth to reconsider that now,<br>
hopefully we have now experience enough to give some good answers to<br>
the problems mentioned in the proposal. At the time where the original<br>
proposal had been made (and was rejected) the C++11 standard was<br>
supposed to be finished.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br><br></font></span></bloc=
kquote><div><br></div><div>Most of the problems in the proposal aren't =
much different from potential problems<br></div><div>that arise when deduci=
ng a function return type, I think.=A0 <br>
</div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--047d7bdc9c524ade4104e9ab20df--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sat, 04 Apr 2015 11:50:34 -0700
Raw View
I find that we're often adding a lot of code in the following pattern:
T functionName(args) noexcept(noexcept(<block of code>))
{
return <block of code>
}
Where the block of code is repeated. For example, in a commit I've just
reviewed:
template <typename T, int Prealloc1, int Prealloc2>
bool operator<(const QVarLengthArray<T, Prealloc1> &lhs, const
QVarLengthArray<T, Prealloc2> &rhs)
noexcept(noexcept(std::lexicographical_compare(lhs.begin(), lhs.end(),
rhs.begin(), rhs.end())))
{
return std::lexicographical_compare(lhs.begin(), lhs.end(),
rhs.begin(), rhs.end());
}
The first question that comes to mind is why we have to do that? If the
compiler can tell that the block of code is noexcept and the function is
clearly inline, why do we need to add the noexcept declaration in the first
place?
A good reason for that is that you can't guarantee that the function will
always be inline. Binary compatibility aside, a new version of the codebase
could de-inline the code, so the declaration should still contain the
necessary bits for noexcept.
So I'd like to propose we add the ability to write "noexcept(auto)" in
addition to "noexcept(true)' and "noexcept(false)" to indicate to the compiler
that it should calculate whether the body of the inline function is noexcept
or not.
More specifically, to [except.spec]/1, add:
noexcept-specification:
noexcept ( constant-expression )
+ noexcept (auto)
noexcept
Then add a new paragraph after paragraph 1, before paragraph 2, explaining
that the "noexcept(auto)" specification may only appear in function definitions
and what it is equivalent of.
Does this seem reasonable?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Vittorio Romeo <vittorio.romeo.vee@gmail.com>
Date: Sat, 4 Apr 2015 12:31:51 -0700 (PDT)
Raw View
------=_Part_1466_1894749134.1428175911784
Content-Type: multipart/alternative;
boundary="----=_Part_1467_13693775.1428175911784"
------=_Part_1467_13693775.1428175911784
Content-Type: text/plain; charset=UTF-8
I definitely have a lot of occurrences in my code where I repeat the body
of small functions in the noexcept qualifier.
Something like this would help a lot.
Would there be any issue in expanding this feature proposal to non-one-line
functions?
Wouldn't the compiler be able to convert something like:
void func() noexcept(auto)
{
int a;
SomeClass b;
auto c = b + a;
std::cout << c;
}
to
void func() noexcept
(
noexcept(int{}) &&
noexcept(SomeClass{}) &&
noexcept(b + a) &&
noexcept(std::cout << c)
)
{
int a;
SomeClass b;
auto c = b + a;
std::cout << c;
}
?
On Saturday, 4 April 2015 20:50:38 UTC+2, Thiago Macieira wrote:
>
> I find that we're often adding a lot of code in the following pattern:
>
> T functionName(args) noexcept(noexcept(<block of code>))
> {
> return <block of code>
> }
>
> Where the block of code is repeated. For example, in a commit I've just
> reviewed:
>
> template <typename T, int Prealloc1, int Prealloc2>
> bool operator<(const QVarLengthArray<T, Prealloc1> &lhs, const
> QVarLengthArray<T, Prealloc2> &rhs)
> noexcept(noexcept(std::lexicographical_compare(lhs.begin(), lhs.end(),
> rhs.begin(), rhs.end())))
> {
> return std::lexicographical_compare(lhs.begin(), lhs.end(),
> rhs.begin(), rhs.end());
> }
>
> The first question that comes to mind is why we have to do that? If the
> compiler can tell that the block of code is noexcept and the function is
> clearly inline, why do we need to add the noexcept declaration in the
> first
> place?
>
> A good reason for that is that you can't guarantee that the function will
> always be inline. Binary compatibility aside, a new version of the
> codebase
> could de-inline the code, so the declaration should still contain the
> necessary bits for noexcept.
>
> So I'd like to propose we add the ability to write "noexcept(auto)" in
> addition to "noexcept(true)' and "noexcept(false)" to indicate to the
> compiler
> that it should calculate whether the body of the inline function is
> noexcept
> or not.
>
> More specifically, to [except.spec]/1, add:
> noexcept-specification:
> noexcept ( constant-expression )
> + noexcept (auto)
> noexcept
>
> Then add a new paragraph after paragraph 1, before paragraph 2, explaining
> that the "noexcept(auto)" specification may only appear in function
> definitions
> and what it is equivalent of.
>
> Does this seem reasonable?
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1467_13693775.1428175911784
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I definitely have a lot of occurrences in my code where I =
repeat the body of small functions in the noexcept qualifier. <br>Some=
thing like this would help a lot.<br><br>Would there be any issue in expand=
ing this feature proposal to non-one-line functions?<br><br>Wouldn't the co=
mpiler be able to convert something like:<br><br>void func() noexcept(auto)=
<br>{<div> int a;<br> SomeClass b;</div><div>&nbs=
p; auto c =3D b + a;<br> std::cout << c;<br>}<br>=
<br>to<br><br>void func() noexcept</div><div>(</div><div> noex=
cept(int{}) &&</div><div> noexcept(SomeClass{}) &&=
amp;</div><div> noexcept(b + a) &&</div><div> &n=
bsp; noexcept(std::cout << c)</div><div>)</div><div>{<div> &nbs=
p; int a;<br> SomeClass b;</div><div> auto c =3D =
b + a;<br> std::cout << c;<br>}<br><br>?<br><br></div><b=
r>On Saturday, 4 April 2015 20:50:38 UTC+2, Thiago Macieira wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">I find that we're often adding a lot o=
f code in the following pattern:
<br>
<br>T functionName(args) noexcept(noexcept(<block of code>))
<br>{
<br> return <block of cod=
e>
<br>}
<br>
<br>Where the block of code is repeated. For example, in a commit I've just=
=20
<br>reviewed:
<br>
<br>template <typename T, int Prealloc1, int Prealloc2>
<br>bool operator<(const QVarLengthArray<T, Prealloc1> &lhs, c=
onst=20
<br>QVarLengthArray<T, Prealloc2> &rhs)
<br> noexcept(noexcept(std::<wbr>lexicographical_compare(lhs.<=
wbr>begin(), lhs.end(),
<br> &=
nbsp; =
rhs.begin(), rhs.end())))
<br>{
<br> return std::lexicographical_compare(<wbr>lhs.begin(), lhs=
..end(),
<br> &=
nbsp; rhs.be=
gin(), rhs.end());
<br>}
<br>
<br>The first question that comes to mind is why we have to do that? If the=
=20
<br>compiler can tell that the block of code is noexcept and the function i=
s=20
<br>clearly inline, why do we need to add the noexcept declaration in the f=
irst=20
<br>place?
<br>
<br>A good reason for that is that you can't guarantee that the function wi=
ll=20
<br>always be inline. Binary compatibility aside, a new version of the code=
base=20
<br>could de-inline the code, so the declaration should still contain the=
=20
<br>necessary bits for noexcept.
<br>
<br>So I'd like to propose we add the ability to write "noexcept(auto)" in=
=20
<br>addition to "noexcept(true)' and "noexcept(false)" to indicate to the c=
ompiler=20
<br>that it should calculate whether the body of the inline function is noe=
xcept=20
<br>or not.
<br>
<br>More specifically, to [except.spec]/1, add:
<br> noexcept-<wbr>specifica=
tion:
<br>  =
; noexcept ( constant-expression )
<br>+ &nbs=
p; noexcept (auto)
<br>  =
; noexcept
<br>
<br>Then add a new paragraph after paragraph 1, before paragraph 2, explain=
ing=20
<br>that the "noexcept(auto)" specification may only appear in function def=
initions=20
<br>and what it is equivalent of.
<br>
<br>Does this seem reasonable?
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNE=
swDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=3D'http://w=
ww.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg=
\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - th=
iago (AT) <a href=3D"http://kde.org" target=3D"_blank" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.org=
\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return tr=
ue;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde=
..org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';retur=
n true;">kde.org</a>
<br> Software Architect - Intel Open Source Technology Center
<br> PGP/GPG: 0x6EF45358; fingerprint:
<br> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1467_13693775.1428175911784--
------=_Part_1466_1894749134.1428175911784--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sat, 04 Apr 2015 12:54:58 -0700
Raw View
On Saturday 04 April 2015 12:31:51 Vittorio Romeo wrote:
> I definitely have a lot of occurrences in my code where I repeat the body
> of small functions in the noexcept qualifier.
> Something like this would help a lot.
>
> Would there be any issue in expanding this feature proposal to non-one-line
> functions?
>
> Wouldn't the compiler be able to convert something like:
>
> void func() noexcept(auto)
> {
> int a;
> SomeClass b;
> auto c = b + a;
> std::cout << c;
> }
>
> to
>
> void func() noexcept
> (
> noexcept(int{}) &&
> noexcept(SomeClass{}) &&
> noexcept(b + a) &&
> noexcept(std::cout << c)
> )
> {
> int a;
> SomeClass b;
> auto c = b + a;
> std::cout << c;
> }
>
> ?
I don't see why not. And it's probably better than what you wrote, since you
probably forgot the c assignment:
noexcept(decltype(SomeClass{} + int{}) = decltype(SomeClass{} + int{}))
It would also allow you to verify whether your code is really noexcept or not
like you meant it to be:
void func() noexcept;
void func() noexcept(auto)
{
int a;
SomeClass b;
auto c = b + a;
std::cout << c;
}
Since all declarations of the same function need to have the same noexcept
specifier, the compiler needs to provide a diagnostic if the auto case expands
to a different result from the other declaration.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Vittorio Romeo <vittorio.romeo.vee@gmail.com>
Date: Sat, 4 Apr 2015 13:07:36 -0700 (PDT)
Raw View
------=_Part_1533_1373248836.1428178056317
Content-Type: multipart/alternative;
boundary="----=_Part_1534_1186432343.1428178056318"
------=_Part_1534_1186432343.1428178056318
Content-Type: text/plain; charset=UTF-8
I didn't strive for correctness, just wanted to make a simple example :)
In a real-life implementation even `~int()`, `~SomeClass()` and
`~decltype(a + b)` have to be checked for noexcept compliancy.
(...and probably some more stuff that I'm missing now.)
On Saturday, 4 April 2015 21:55:03 UTC+2, Thiago Macieira wrote:
>
> On Saturday 04 April 2015 12:31:51 Vittorio Romeo wrote:
> > I definitely have a lot of occurrences in my code where I repeat the
> body
> > of small functions in the noexcept qualifier.
> > Something like this would help a lot.
> >
> > Would there be any issue in expanding this feature proposal to
> non-one-line
> > functions?
> >
> > Wouldn't the compiler be able to convert something like:
> >
> > void func() noexcept(auto)
> > {
> > int a;
> > SomeClass b;
> > auto c = b + a;
> > std::cout << c;
> > }
> >
> > to
> >
> > void func() noexcept
> > (
> > noexcept(int{}) &&
> > noexcept(SomeClass{}) &&
> > noexcept(b + a) &&
> > noexcept(std::cout << c)
> > )
> > {
> > int a;
> > SomeClass b;
> > auto c = b + a;
> > std::cout << c;
> > }
> >
> > ?
>
> I don't see why not. And it's probably better than what you wrote, since
> you
> probably forgot the c assignment:
> noexcept(decltype(SomeClass{} + int{}) = decltype(SomeClass{} +
> int{}))
>
> It would also allow you to verify whether your code is really noexcept or
> not
> like you meant it to be:
>
> void func() noexcept;
> void func() noexcept(auto)
> {
> int a;
> SomeClass b;
> auto c = b + a;
> std::cout << c;
> }
>
> Since all declarations of the same function need to have the same noexcept
> specifier, the compiler needs to provide a diagnostic if the auto case
> expands
> to a different result from the other declaration.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1534_1186432343.1428178056318
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I didn't strive for correctness, just wanted to make a sim=
ple example :)<br>In a real-life implementation even `~int()`, `~SomeClass(=
)` and `~decltype(a + b)` have to be checked for noexcept compliancy.<br>(.=
...and probably some more stuff that I'm missing now.)<br><br>On Saturday, 4=
April 2015 21:55:03 UTC+2, Thiago Macieira wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;">On Saturday 04 April 2015 12:31:51 Vittorio Romeo wrot=
e:
<br>> I definitely have a lot of occurrences in my code where I repeat t=
he body
<br>> of small functions in the noexcept qualifier.
<br>> Something like this would help a lot.
<br>>=20
<br>> Would there be any issue in expanding this feature proposal to non=
-one-line
<br>> functions?
<br>>=20
<br>> Wouldn't the compiler be able to convert something like:
<br>>=20
<br>> void func() noexcept(auto)
<br>> {
<br>> int a;
<br>> SomeClass b;
<br>> auto c =3D b + a;
<br>> std::cout << c;
<br>> }
<br>>=20
<br>> to
<br>>=20
<br>> void func() noexcept
<br>> (
<br>> noexcept(int{}) &&
<br>> noexcept(SomeClass{}) &&
<br>> noexcept(b + a) &&
<br>> noexcept(std::cout << c)
<br>> )
<br>> {
<br>> int a;
<br>> SomeClass b;
<br>> auto c =3D b + a;
<br>> std::cout << c;
<br>> }
<br>>=20
<br>> ?
<br>
<br>I don't see why not. And it's probably better than what you wrote, sinc=
e you=20
<br>probably forgot the c assignment:
<br> noexcept(decltype(<wbr>=
SomeClass{} + int{}) =3D decltype(SomeClass{} + int{}))
<br>
<br>It would also allow you to verify whether your code is really noexcept =
or not=20
<br>like you meant it to be:
<br>
<br>void func() noexcept;
<br>void func() noexcept(auto)
<br>{
<br> int a;
<br> SomeClass b;
<br> auto c =3D b + a;
<br> std::cout << c;
<br>}
<br>
<br>Since all declarations of the same function need to have the same noexc=
ept=20
<br>specifier, the compiler needs to provide a diagnostic if the auto case =
expands=20
<br>to a different result from the other declaration.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNE=
swDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=3D'http://w=
ww.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg=
\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - th=
iago (AT) <a href=3D"http://kde.org" target=3D"_blank" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.org=
\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return tr=
ue;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde=
..org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';retur=
n true;">kde.org</a>
<br> Software Architect - Intel Open Source Technology Center
<br> PGP/GPG: 0x6EF45358; fingerprint:
<br> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1534_1186432343.1428178056318--
------=_Part_1533_1373248836.1428178056317--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Sat, 4 Apr 2015 16:00:31 -0700 (PDT)
Raw View
------=_Part_2333_1693434078.1428188431457
Content-Type: multipart/alternative;
boundary="----=_Part_2334_945775255.1428188431457"
------=_Part_2334_945775255.1428188431457
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, April 4, 2015 at 12:31:51 PM UTC-7, Vittorio Romeo wrote:
>
> I definitely have a lot of occurrences in my code where I repeat the body=
=20
> of small functions in the noexcept qualifier.=20
> Something like this would help a lot.
>
> Would there be any issue in expanding this feature proposal to=20
> non-one-line functions?
>
In fact, before we get too far into the syntax bikeshed, could someone=20
knowledgeable please explain why noexcept(...) declarations are required at=
=20
all?
I.e., why was it not made a rule in C++11 that
void foo() { some-stuff; }
should *invariably* be interpreted by the compiler as
void foo() noexcept(some-stuff) { some-stuff; }
? This is directly related to a point in my upcoming C++Now presentation,=
=20
in which I'm investigating the ramifications of non-noexcept=20
move-constructors. It's my understanding that if I write
struct ThirdParty {
ThirdParty(const ThirdParty&) { puts("copy-ctor"); } // this=20
declaration is not controlled by me, and they forgot the "noexcept"
ThirdParty(ThirdParty&&) { puts("move-ctor"); } // this declaration is=
=20
not controlled by me, and they forgot the "noexcept"
};
struct Foo : ThirdParty {
Foo() =3D default;
Foo(const Foo&) =3D default;
Foo(Foo&&) =3D default; // this declaration is implicitly=20
noexcept(false), and I cannot manually override that
};
int main() {
std::vector<Foo> vfoo;
for (int i=3D0; i < 100; ++i) vfoo.emplace_back();
}
then std::vector<Foo> is required to pessimize my code into "copy-ctor"=20
when what I want is "move-ctor". Since I cannot override the implicitly=20
wrong noexcept(...) specification on Foo's move-ctor, I must always=20
implement my own move-ctor from scratch (i.e., =3Ddefault is hardly ever=20
useful for move-ctors, and this is before we even get into the problems=20
with self-swap that my C++Now presentation will also cover).
There are two obvious solutions, which are not mutually exclusive: One=20
solution is to remove the restriction that explicit "noexcept"=20
specifications on defaulted methods must match the calculated "noexcept"=20
specifications, so that we could manually annotate every defaulted method=
=20
with the correct specification
*x.cc:15:5: **error: **exception specification of explicitly defaulted move=
=20
constructor does not match the calculated one*
Foo(Foo&&) noexcept(true) =3D default; // this should work, but doesn't
* ^*
1 error generated.
and the other solution is to specify that any function with no explicit=20
"noexcept" specification will in C++1z have its "noexcept" specification=20
implicitly calculated =C3=A0 la the proposed "noexcept(auto)".
But surely the second solution would have made it into C++11, if there were=
=20
no downsides to it. Therefore, I'm asking whether anyone knows the=20
downsides. :)
(Back in the bikeshed: I see no reason for a "noexcept(auto)" syntax, given=
=20
that we want that behavior on *all* functions. Forcing people to type out=
=20
"noexcept(auto)" every time just penalizes slow typers and people who don't=
=20
read the Standard for a living.)
=E2=80=93Arthur
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_2334_945775255.1428188431457
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, April 4, 2015 at 12:31:51 PM UTC-7, Vittorio =
Romeo 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">I=
definitely have a lot of occurrences in my code where I repeat the body of=
small functions in the noexcept qualifier. <br>Something like this wo=
uld help a lot.<br><br>Would there be any issue in expanding this feature p=
roposal to non-one-line functions?<br></div></blockquote><div><br></div><di=
v>In fact, before we get too far into the syntax bikeshed, could someone kn=
owledgeable please explain why noexcept(...) declarations are required at a=
ll?</div><div>I.e., why was it not made a rule in C++11 that</div><div><br>=
</div><div> void foo() { some-stuff; }</div><div><br></div><di=
v>should *invariably* be interpreted by the compiler as</div><div><br></div=
><div> void foo() noexcept(some-stuff) { some-stuff; }</div><d=
iv><br></div><div>? This is directly related to a point in my upcoming C++N=
ow presentation, in which I'm investigating the ramifications of non-noexce=
pt move-constructors. It's my understanding that if I write</div><div><br><=
/div><div>struct ThirdParty {</div><div> ThirdParty(const Thir=
dParty&) { puts("copy-ctor"); } // this declaration is not contro=
lled by me, and they forgot the "noexcept"</div><div> ThirdPar=
ty(ThirdParty&&) { puts("move-ctor"); } // this declaration i=
s not controlled by me, and they forgot the "noexcept"</div><div>};<br></di=
v><div>struct Foo : ThirdParty {</div><div> Foo() =3D default;=
</div><div> Foo(const Foo&) =3D default;</div><div> =
Foo(Foo&&) =3D default; // this declaration is implici=
tly noexcept(false), and I cannot manually override that</div><div>};</div>=
<div>int main() {</div><div> std::vector<Foo> vfoo;</div=
><div> for (int i=3D0; i < 100; ++i) vfoo.emplace_back();</=
div><div>}</div><div><br></div><div>then std::vector<Foo> is required=
to pessimize my code into "copy-ctor" when what I want is "move-ctor". &nb=
sp;Since I cannot override the implicitly wrong noexcept(...) specification=
on Foo's move-ctor, I must always implement my own move-ctor from scratch =
(i.e., =3Ddefault is hardly ever useful for move-ctors, and this is before =
we even get into the problems with self-swap that my C++Now presentation wi=
ll also cover).</div><div><br></div><div>There are two obvious solutions, w=
hich are not mutually exclusive: One solution is to remove the restriction =
that explicit "noexcept" specifications on defaulted methods must match the=
calculated "noexcept" specifications, so that we could manually annotate e=
very defaulted method with the correct specification</div><div><br></div><d=
iv><p style=3D"margin-bottom: 0px; font-size: 11px; line-height: normal; fo=
nt-family: Menlo;"><b>x.cc:15:5: </b><span style=3D"color: #c33720"><b>erro=
r: </b></span><b>exception specification of explicitly defaulted move const=
ructor does not match the calculated one</b></p>
<p style=3D"margin-bottom: 0px; font-size: 11px; line-height: normal; font-=
family: Menlo;"> Foo(Foo&&) noexcept(true) =3D default=
; // this should work, but doesn't</p>
<p style=3D"margin-bottom: 0px; font-size: 11px; line-height: normal; font-=
family: Menlo; color: rgb(52, 189, 38);"><b> ^</b></p>
<p style=3D"margin-bottom: 0px; font-size: 11px; line-height: normal; font-=
family: Menlo;">1 error generated.</p><p style=3D"margin-bottom: 0px; font-=
size: 11px; line-height: normal; font-family: Menlo;"><br></p></div><div>an=
d the other solution is to specify that any function with no explicit "noex=
cept" specification will in C++1z have its "noexcept" specification implici=
tly calculated =C3=A0 la the proposed "noexcept(auto)".</div><div><br></div=
><div><br></div><div>But surely the second solution would have made it into=
C++11, if there were no downsides to it. Therefore, I'm asking whether any=
one knows the downsides. :)</div><div><br></div><div>(Back in the bikeshed:=
I see no reason for a "noexcept(auto)" syntax, given that we want that beh=
avior on *all* functions. Forcing people to type out "noexcept(auto)" every=
time just penalizes slow typers and people who don't read the Standard for=
a living.)</div><div><br></div><div>=E2=80=93Arthur<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</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_2334_945775255.1428188431457--
------=_Part_2333_1693434078.1428188431457--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 5 Apr 2015 02:24:53 +0300
Raw View
On 5 April 2015 at 02:00, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:
> (Back in the bikeshed: I see no reason for a "noexcept(auto)" syntax, given
> that we want that behavior on *all* functions. Forcing people to type out
I don't agree we want that behavior on all functions. That would be a breaking
change for existing code that relies on not-annotating a function to
mean noexcept(false),
first of all. Second, the usual counter-argument for noexcept(auto) is
that adding/removing
eg. logging code changes that outcome, and is an ABI change; thus
going further than
noexcept(auto) and making it all automatic would result in even more
brittle code.
To Thiago: yes, this has been proposed, see
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3207.htm
It was also filed as the national body comment FI 5 on the C++14
draft. I know the
submitter of that NB comment very well. ;)
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sat, 04 Apr 2015 16:44:28 -0700
Raw View
On Sunday 05 April 2015 02:24:53 Ville Voutilainen wrote:
> To Thiago: yes, this has been proposed, see
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3207.htm
>
> It was also filed as the national body comment FI 5 on the C++14
> draft. I know the
> submitter of that NB comment very well.
Ah, yes, the Finland national body :-)
A Google web search reveals this thread:
https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/n3207/std-proposals/jMTNqrKgQMw/3e92-VXdobUJ
And it ends in a comment from you:
"That NB comment was rejected, so we'll likely try again for
C++17."
Ok, so this is in good hands.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 5 Apr 2015 03:06:56 +0300
Raw View
On 5 April 2015 at 02:44, Thiago Macieira <thiago@macieira.org> wrote:
> And it ends in a comment from you:
>
> "That NB comment was rejected, so we'll likely try again for
> C++17."
>
> Ok, so this is in good hands.
It doesn't hurt if you author a paper outlining the cases in Qt where
the boiler-plate
that the current rules require appears; I am fairly busy, and I wasn't
exactly planning
to write a noexcept(auto) paper for the next meeting. I may try, but I
might not make it.
The deadline is April 10th, so there's not a lot of 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/.
.
Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Sat, 4 Apr 2015 19:40:05 -0700
Raw View
--089e0153868861f71b0512f11997
Content-Type: text/plain; charset=UTF-8
On Sat, Apr 4, 2015 at 4:00 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:
> On Saturday, April 4, 2015 at 12:31:51 PM UTC-7, Vittorio Romeo wrote:
>>
>> I definitely have a lot of occurrences in my code where I repeat the body
>> of small functions in the noexcept qualifier.
>> Something like this would help a lot.
>>
>> Would there be any issue in expanding this feature proposal to
>> non-one-line functions?
>>
>
> In fact, before we get too far into the syntax bikeshed, could someone
> knowledgeable please explain why noexcept(...) declarations are required at
> all?
> I.e., why was it not made a rule in C++11 that
>
> void foo() { some-stuff; }
>
> should *invariably* be interpreted by the compiler as
>
> void foo() noexcept(some-stuff) { some-stuff; }
>
In order for that to work you'd need the definition to be there. What
happens if someone just has a function declaration? Here, I imagine you'd
say it just shouldn't have a noexcept specification (rather than auto).
Okay, then what happens if the function is defined later on in the
translation unit and it turns out there are no non-noexcept operations? You
can't change the exception specification of that function. What happens if
another translation unit sees just the definition without the declaration
-- in that case the function would have an auto noexcept specification just
in that translation unit. What happens if someone uses the noexcept
operator at a point where only the declaration is visible, then uses the
noexcept operator on it after the definition is visible in the same
translation unit and/or another translation unit where the definition is
available, etc.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.
--089e0153868861f71b0512f11997
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Apr 4, 2015 at 4:00 PM, Arthur O'Dwyer <span dir=3D"ltr"><<a hre=
f=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@gm=
ail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2=
04,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><span cl=
ass=3D"">On Saturday, April 4, 2015 at 12:31:51 PM UTC-7, Vittorio Romeo wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:sol=
id;padding-left:1ex"><div dir=3D"ltr">I definitely have a lot of occurrence=
s in my code where I repeat the body of small functions in the noexcept qua=
lifier.=C2=A0<br>Something like this would help a lot.<br><br>Would there b=
e any issue in expanding this feature proposal to non-one-line functions?<b=
r></div></blockquote><div><br></div></span><div>In fact, before we get too =
far into the syntax bikeshed, could someone knowledgeable please explain wh=
y noexcept(...) declarations are required at all?</div><div>I.e., why was i=
t not made a rule in C++11 that</div><div><br></div><div>=C2=A0 =C2=A0 void=
foo() { some-stuff; }</div><div><br></div><div>should *invariably* be inte=
rpreted by the compiler as</div><div><br></div><div>=C2=A0 =C2=A0 void foo(=
) noexcept(some-stuff) { some-stuff; }</div></div></blockquote><div><br></d=
iv><div>In order for that to work you'd need the definition to be there=
.. What happens if someone just has a function declaration? Here, I imagine =
you'd say it just shouldn't have a noexcept specification (rather t=
han auto). Okay, then what happens if the function is defined later on in t=
he translation unit and it turns out there are no non-noexcept operations? =
You can't change the exception specification of that function. What hap=
pens if another translation unit sees just the definition without the decla=
ration -- in that case the function would have an auto noexcept specificati=
on just in that translation unit. What happens if someone uses the noexcept=
operator at a point where only the declaration is visible, then uses the n=
oexcept operator on it after the definition is visible in the same translat=
ion unit and/or another translation unit where the definition is available,=
etc.</div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e0153868861f71b0512f11997--
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 5 Apr 2015 12:36:50 +0800
Raw View
--Apple-Mail=_A82D5F99-3CCA-4437-90DD-7E614EDE6BAC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9304=E2=80=9305, at 10:40 AM, 'Matt Calabrese' via ISO C++ =
Standard - Future Proposals <std-proposals@isocpp.org> wrote:
>=20
> In order for that to work you'd need the definition to be there. What hap=
pens if someone just has a function declaration? Here, I imagine you'd say =
it just shouldn't have a noexcept specification (rather than auto).
Or, don=E2=80=99t allow an undefined exception-specification to be used, si=
milar to a placeholder return type.
Already the compiler has to detect circular exception-specification definit=
ions:
void foo() noexcept(noexcept( foo() ));
This is best done by marking the exception-specification as incomplete whil=
e evaluating it, which would nicely handle noexcept(auto) too.
--=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=_A82D5F99-3CCA-4437-90DD-7E614EDE6BAC
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=9304=
=E2=80=9305, at 10:40 AM, 'Matt Calabrese' via ISO C++ Standard - Future Pr=
oposals <<a href=3D"mailto:std-proposals@isocpp.org" class=3D"">std-prop=
osals@isocpp.org</a>> wrote:</div><br class=3D"Apple-interchange-newline=
"><div class=3D""><div dir=3D"ltr" style=3D"font-family: Helvetica; font-si=
ze: 12px; font-style: normal; font-variant: normal; font-weight: normal; le=
tter-spacing: normal; line-height: normal; orphans: auto; text-align: start=
; text-indent: 0px; text-transform: none; white-space: normal; widows: auto=
; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"">In order for th=
at to work you'd need the definition to be there. What happens if someone j=
ust has a function declaration? Here, I imagine you'd say it just shouldn't=
have a noexcept specification (rather than auto).</div></div></div></div><=
/div></blockquote><div><br class=3D""></div><div>Or, don=E2=80=99t allow an=
undefined exception-specification to be used, similar to a placeholder ret=
urn type.</div><div><br class=3D""></div><div>Already the compiler has to d=
etect circular exception-specification definitions:</div><div><br class=3D"=
"></div><div><font face=3D"Courier" class=3D"">void foo() noexcept(noexcept=
( foo() ));</font></div><div><br class=3D""></div><div>This is best done by=
marking the exception-specification as incomplete while evaluating it, whi=
ch would nicely handle <font face=3D"Courier" class=3D"">noexcept(auto=
)</font> too.</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</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=_A82D5F99-3CCA-4437-90DD-7E614EDE6BAC--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 5 Apr 2015 14:00:09 +0300
Raw View
On 5 April 2015 at 07:36, David Krauss <potswa@gmail.com> wrote:
> Or, don=E2=80=99t allow an undefined exception-specification to be used, =
similar to
> a placeholder return type.
>
> Already the compiler has to detect circular exception-specification
> definitions:
>
> void foo() noexcept(noexcept( foo() ));
Well, the way compilers "detect" such circularities is that foo is not in s=
cope
in its own declarator, so that's ill-formed as far as I can see.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 5 Apr 2015 19:28:17 +0800
Raw View
> On 2015=E2=80=9304=E2=80=9305, at 7:00 PM, Ville Voutilainen <ville.vouti=
lainen@gmail.com> wrote:
>=20
> Well, the way compilers "detect" such circularities is that foo is not in=
scope
> in its own declarator, so that's ill-formed as far as I can see.
Eh, I neglected to test that example, but it can happen with ADL.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 5 Apr 2015 19:50:58 +0800
Raw View
--Apple-Mail=_00BBBC75-8FFB-4ECF-9787-24CFA7A2B118
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9304=E2=80=9305, at 7:28 PM, David Krauss <potswa@gmail.com=
> wrote:
>=20
>=20
>> On 2015=E2=80=9304=E2=80=9305, at 7:00 PM, Ville Voutilainen <ville.vout=
ilainen@gmail.com> wrote:
>>=20
>> Well, the way compilers "detect" such circularities is that foo is not i=
n scope
>> in its own declarator, so that's ill-formed as far as I can see.
>=20
> Eh, I neglected to test that example, but it can happen with ADL.
=E2=80=A6 Hmm, perhaps not. I do have a testcase on file which produces inf=
inite template recursion within just one specialization, by circular noexce=
pt:
template< typename >
struct literal {
void e() noexcept(noexcept( literal().e() )) {}
};
template struct literal< void >;
Not sure the significance of it being a literal type, just pulled this from=
some archives. This is probably an unrelated, known defect anyway.
Anyhoo, the notion of placeholder incomplete exception-specification is ele=
gant enough even if it=E2=80=99s not needed for something else.
--=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=_00BBBC75-8FFB-4ECF-9787-24CFA7A2B118
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=9304=
=E2=80=9305, at 7:28 PM, David Krauss <<a href=3D"mailto:potswa@gmail.co=
m" class=3D"">potswa@gmail.com</a>> wrote:</div><br class=3D"Apple-inter=
change-newline"><div class=3D""><br class=3D""><blockquote type=3D"cite" cl=
ass=3D"">On 2015=E2=80=9304=E2=80=9305, at 7:00 PM, Ville Voutilainen <<=
a href=3D"mailto:ville.voutilainen@gmail.com" class=3D"">ville.voutilainen@=
gmail.com</a>> wrote:<br class=3D""><br class=3D"">Well, the way compile=
rs "detect" such circularities is that foo is not in scope<br class=3D"">in=
its own declarator, so that's ill-formed as far as I can see.<br class=3D"=
"></blockquote><br class=3D"">Eh, I neglected to test that example, but it =
can happen with ADL.</div></blockquote></div><br class=3D""><div class=3D""=
>=E2=80=A6 Hmm, perhaps not. I do have a testcase on file which produces in=
finite template recursion within just one specialization, by circular noexc=
ept:</div><div class=3D""><br class=3D""></div><div class=3D""><font face=
=3D"Courier" class=3D"">template< typename ><br class=3D"">struct lit=
eral {<br class=3D""> void e() noexcept(noexcept( literal=
().e() )) {}<br class=3D"">};</font></div><div class=3D""><font face=3D"Cou=
rier" class=3D""><br class=3D""></font></div><div class=3D""><font face=3D"=
Courier" class=3D"">template struct literal< void >;</font></div><div=
class=3D""><br class=3D""></div><div class=3D"">Not sure the significance =
of it being a literal type, just pulled this from some archives. This is pr=
obably an unrelated, known defect anyway.</div><div class=3D""><br class=3D=
""></div><div class=3D"">Anyhoo, the notion of placeholder incomplete excep=
tion-specification is elegant enough even if it=E2=80=99s not needed for so=
mething else.</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</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=_00BBBC75-8FFB-4ECF-9787-24CFA7A2B118--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 5 Apr 2015 15:10:18 +0300
Raw View
On 5 April 2015 at 14:50, David Krauss <potswa@gmail.com> wrote:
> Anyhoo, the notion of placeholder incomplete exception-specification is
> elegant enough even if it=E2=80=99s not needed for something else.
Yep, and I think we already have parts of that notion for member
functions - I don't
think noexcept(auto) is vastly different in that regard. The validity
of a noexcept(auto)
should probably be checked at the point of use rather than at the
point of declaration.
We allow forward-declarations of functions with deduced return types,
so I suppose
we should allow forward-declarations of functions with noexcept(auto) as we=
ll.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Jonathan <jonathanbcoe@gmail.com>
Date: Sun, 5 Apr 2015 13:43:19 +0100
Raw View
I'd be keen to see noexcept(auto) extended with the ability to write 'noexc=
ept(auto=3Dtrue)' meaning that the compiler must deduce the noexcept status=
and it must deduce it to be true.=20
Jon
> On 5 Apr 2015, at 13:10, Ville Voutilainen <ville.voutilainen@gmail.com> =
wrote:
>=20
>> On 5 April 2015 at 14:50, David Krauss <potswa@gmail.com> wrote:
>> Anyhoo, the notion of placeholder incomplete exception-specification is
>> elegant enough even if it=E2=80=99s not needed for something else.
>=20
>=20
> Yep, and I think we already have parts of that notion for member
> functions - I don't
> think noexcept(auto) is vastly different in that regard. The validity
> of a noexcept(auto)
> should probably be checked at the point of use rather than at the
> point of declaration.
> We allow forward-declarations of functions with deduced return types,
> so I suppose
> we should allow forward-declarations of functions with noexcept(auto) as =
well.
>=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.
> 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-propo=
sals/.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 5 Apr 2015 16:22:42 +0300
Raw View
On 5 April 2015 at 15:43, Jonathan <jonathanbcoe@gmail.com> wrote:
> I'd be keen to see noexcept(auto) extended with the ability to write 'noexcept(auto=true)' meaning that the compiler must deduce the noexcept status and it must deduce it to be true.
I must say it's not immediately obvious to me why you'd want to do
that instead of using plain noexcept.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 5 Apr 2015 16:28:25 +0300
Raw View
On 5 April 2015 at 16:22, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> On 5 April 2015 at 15:43, Jonathan <jonathanbcoe@gmail.com> wrote:
>> I'd be keen to see noexcept(auto) extended with the ability to write 'noexcept(auto=true)' meaning that the compiler must deduce the noexcept status and it must deduce it to be true.
>
>
> I must say it's not immediately obvious to me why you'd want to do
> that instead of using plain noexcept.
And before you say "..to SFINAE on it", I don't think you're supposed
to be able to SFINAE
on a noexcept-specification.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Jonathan Coe <jonathanbcoe@gmail.com>
Date: Sun, 5 Apr 2015 14:39:41 +0100
Raw View
Roughly:
noexcept means that I know no exceptions will be thrown.
noexcept auto means that the compiler should work out if exceptions can be thrown.
noexcept(auto=true) means that I believe no exceptions will be thrown but I'd like the compiler to be able to guarantee this rather than provide such a guarantee myself.
I can imagine using this where I can't tolerate sudden program termination if my desired noexcept guarantee is wrong. Runtime may not be the best time to discover that my beliefs are incorrect.
Jon
> On 5 Apr 2015, at 14:28, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>
>> On 5 April 2015 at 16:22, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>>> On 5 April 2015 at 15:43, Jonathan <jonathanbcoe@gmail.com> wrote:
>>> I'd be keen to see noexcept(auto) extended with the ability to write 'noexcept(auto=true)' meaning that the compiler must deduce the noexcept status and it must deduce it to be true.
>>
>>
>> I must say it's not immediately obvious to me why you'd want to do
>> that instead of using plain noexcept.
>
> And before you say "..to SFINAE on it", I don't think you're supposed
> to be able to SFINAE
> on a noexcept-specification.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving 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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 5 Apr 2015 21:48:49 +0800
Raw View
--Apple-Mail=_34DA2611-AB60-4B8A-A9A5-EDE0407539C9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9304=E2=80=9305, at 9:39 PM, Jonathan Coe <jonathanbcoe@gma=
il.com> wrote:
>=20
> noexcept(auto=3Dtrue) means that I believe no exceptions will be thrown b=
ut I'd like the compiler to be able to guarantee this rather than provide s=
uch a guarantee myself.
Just use noexcept(auto) followed by a static_assert(noexcept(foo(), "invali=
d exception safety").
For a function template, you=E2=80=99d need a wrapper to contain the static=
_assert, which is a little inconvenient, but not IMHO motivation for syntax=
like auto=3Dtrue. It would be just as well to decree that the exception-sp=
ecification of the enclosing function is complete in a static_assert declar=
ation.
--=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=_34DA2611-AB60-4B8A-A9A5-EDE0407539C9
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=9304=
=E2=80=9305, at 9:39 PM, Jonathan Coe <<a href=3D"mailto:jonathanbcoe@gm=
ail.com" class=3D"">jonathanbcoe@gmail.com</a>> wrote:</div><br class=3D=
"Apple-interchange-newline"><div class=3D"">noexcept(auto=3Dtrue) means tha=
t I believe no exceptions will be thrown but I'd like the compiler to be ab=
le to guarantee this rather than provide such a guarantee myself.<br class=
=3D""></div></blockquote><div><br class=3D""></div><div>Just use <font face=
=3D"Courier" class=3D"">noexcept(auto)</font> followed by a <font face=3D"C=
ourier" class=3D"">static_assert(noexcept(foo(), "invalid exception safety"=
)</font>.</div></div><br class=3D""><div class=3D"">For a function template=
, you=E2=80=99d need a wrapper to contain the <font face=3D"Courier" class=
=3D"">static_assert</font>, which is a little inconvenient, but not IMHO mo=
tivation for syntax like <font face=3D"Courier" class=3D"">auto=3Dtrue</fon=
t>. It would be just as well to decree that the exception-specification of =
the enclosing function is complete in a <span style=3D"font-family: Co=
urier;" class=3D"">static_assert</span> declaration.</div></body></htm=
l>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_34DA2611-AB60-4B8A-A9A5-EDE0407539C9--
.
Author: Jonathan Coe <jonathanbcoe@gmail.com>
Date: Sun, 5 Apr 2015 15:11:15 +0100
Raw View
--Apple-Mail-F6D208A5-6F1B-41B1-A07A-EDCD06D2AD6A
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
If we are proposing new syntax with noexcept(auto) is it much work to add n=
oexcept(auto=3Dtrue)?
The static_assert approach is nice but if it's likely to get much use then =
I prefer the briefer syntax of noexcept(auto=3Dtrue).
Jon
> On 5 Apr 2015, at 14:48, David Krauss <potswa@gmail.com> wrote:
>=20
>=20
>> On 2015=E2=80=9304=E2=80=9305, at 9:39 PM, Jonathan Coe <jonathanbcoe@gm=
ail.com> wrote:
>>=20
>> noexcept(auto=3Dtrue) means that I believe no exceptions will be thrown =
but I'd like the compiler to be able to guarantee this rather than provide =
such a guarantee myself.
>=20
> Just use noexcept(auto) followed by a static_assert(noexcept(foo(), "inva=
lid exception safety").
>=20
> For a function template, you=E2=80=99d need a wrapper to contain the stat=
ic_assert, which is a little inconvenient, but not IMHO motivation for synt=
ax like auto=3Dtrue. It would be just as well to decree that the exception-=
specification of the enclosing function is complete in a static_assert decl=
aration.
> --=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.
> 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-propo=
sals/.
--=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-F6D208A5-6F1B-41B1-A07A-EDCD06D2AD6A
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div>If we are proposing new syntax wit=
h noexcept(auto) is it much work to add noexcept(auto=3Dtrue)?</div><div><b=
r></div><div>The static_assert approach is nice but if it's likely to get m=
uch use then I prefer the briefer syntax of noexcept(auto=3Dtrue).</div><di=
v><br></div><div>Jon<br><br><br></div><div><br>On 5 Apr 2015, at 14:48, Dav=
id Krauss <<a href=3D"mailto:potswa@gmail.com">potswa@gmail.com</a>> =
wrote:<br><br></div><blockquote type=3D"cite"><div><meta http-equiv=3D"Cont=
ent-Type" content=3D"text/html charset=3Dutf-8"><br class=3D""><div><blockq=
uote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9304=E2=80=9305=
, at 9:39 PM, Jonathan Coe <<a href=3D"mailto:jonathanbcoe@gmail.com" cl=
ass=3D"">jonathanbcoe@gmail.com</a>> wrote:</div><br class=3D"Apple-inte=
rchange-newline"><div class=3D"">noexcept(auto=3Dtrue) means that I believe=
no exceptions will be thrown but I'd like the compiler to be able to guara=
ntee this rather than provide such a guarantee myself.<br class=3D""></div>=
</blockquote><div><br class=3D""></div><div>Just use <font face=3D"Courier"=
class=3D"">noexcept(auto)</font> followed by a <font face=3D"Courier" clas=
s=3D"">static_assert(noexcept(foo(), "invalid exception safety")</font>.</d=
iv></div><br class=3D""><div class=3D"">For a function template, you=E2=80=
=99d need a wrapper to contain the <font face=3D"Courier" class=3D"">static=
_assert</font>, which is a little inconvenient, but not IMHO motivation for=
syntax like <font face=3D"Courier" class=3D"">auto=3Dtrue</font>. It would=
be just as well to decree that the exception-specification of the enclosin=
g function is complete in a <span style=3D"font-family: Courier;" clas=
s=3D"">static_assert</span> declaration.</div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</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>
</div></blockquote></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail-F6D208A5-6F1B-41B1-A07A-EDCD06D2AD6A--
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 5 Apr 2015 22:14:49 +0800
Raw View
--Apple-Mail=_BE490888-E2D1-4D9C-97D7-7DE4E175288F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9304=E2=80=9305, at 10:11 PM, Jonathan Coe <jonathanbcoe@gm=
ail.com> wrote:
>=20
> If we are proposing new syntax with noexcept(auto) is it much work to add=
noexcept(auto=3Dtrue)?
My beef with auto=3Dtrue isn=E2=80=99t implementation difficulty, it=E2=80=
=99s the quirkiness of the syntax.
> The static_assert approach is nice but if it's likely to get much use the=
n I prefer the briefer syntax of noexcept(auto=3Dtrue).
With both alternatives illustrated side-by-side in a proposal, it can be pu=
t to a vote.
--=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=_BE490888-E2D1-4D9C-97D7-7DE4E175288F
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=9304=
=E2=80=9305, at 10:11 PM, Jonathan Coe <<a href=3D"mailto:jonathanbcoe@g=
mail.com" class=3D"">jonathanbcoe@gmail.com</a>> wrote:</div><br class=
=3D"Apple-interchange-newline"><div class=3D""><meta http-equiv=3D"content-=
type" content=3D"text/html; charset=3Dutf-8" class=3D""><div dir=3D"auto" c=
lass=3D""><div class=3D"">If we are proposing new syntax with noexcept(auto=
) is it much work to add noexcept(auto=3Dtrue)?</div></div></div></blockquo=
te><div><br class=3D""></div><div>My beef with <font face=3D"Courier" class=
=3D"">auto=3Dtrue</font> isn=E2=80=99t implementation difficulty, it=E2=80=
=99s the quirkiness of the syntax.</div><br class=3D""><blockquote type=3D"=
cite" class=3D""><div dir=3D"auto" class=3D""><div class=3D"">The static_as=
sert approach is nice but if it's likely to get much use then I prefer the =
briefer syntax of noexcept(auto=3Dtrue).</div></div></blockquote><br class=
=3D""></div><div>With both alternatives illustrated side-by-side in a propo=
sal, it can be put to a vote.</div><br class=3D""></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_BE490888-E2D1-4D9C-97D7-7DE4E175288F--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 05 Apr 2015 10:40:07 -0700
Raw View
On Sunday 05 April 2015 03:06:56 Ville Voutilainen wrote:
> It doesn't hurt if you author a paper outlining the cases in Qt where
> the boiler-plate
> that the current rules require appears; I am fairly busy, and I wasn't
> exactly planning
> to write a noexcept(auto) paper for the next meeting. I may try, but I
> might not make it.
> The deadline is April 10th, so there's not a lot of time.
We're not very good at using noexcept, especially because all but three
modules are compiled wih -fno-exceptions or equivalent anyway.
Marc has been pushing some modifications and might comment a little more.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 05 Apr 2015 10:51:19 -0700
Raw View
On Sunday 05 April 2015 15:11:15 Jonathan Coe wrote:
> If we are proposing new syntax with noexcept(auto) is it much work to add
> noexcept(auto=true)?
>
> The static_assert approach is nice but if it's likely to get much use then I
> prefer the briefer syntax of noexcept(auto=true).
Or my suggestion. Write:
void func() noexcept;
void func() noexcept(auto)
{
...
}
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Sun, 5 Apr 2015 12:01:44 -0700
Raw View
--047d7ba97384010b080512fed072
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sat, Apr 4, 2015 at 7:40 PM, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> On Sat, Apr 4, 2015 at 4:00 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com
> wrote:
>> On Saturday, April 4, 2015 at 12:31:51 PM UTC-7, Vittorio Romeo wrote:
>>>
>>> I definitely have a lot of occurrences in my code where I repeat the
body
>>> of small functions in the noexcept qualifier.
>>> Something like this would help a lot.
>>>
>>> Would there be any issue in expanding this feature proposal to
>>> non-one-line functions?
>>
>> In fact, before we get too far into the syntax bikeshed, could someone
>> knowledgeable please explain why noexcept(...) declarations are required
at all?
>> I.e., why was it not made a rule in C++11 that
>>
>> void foo() { some-stuff; }
>>
>> should *invariably* be interpreted by the compiler as
>>
>> void foo() noexcept(some-stuff) { some-stuff; }
>
> In order for that to work you'd need the definition to be there. What
> happens if someone just has a function declaration? Here, I imagine you'd
> say it just shouldn't have a noexcept specification (rather than auto).
> Okay, then what happens if the function is defined later on in the
> translation unit and it turns out there are no non-noexcept operations?
You
> can't change the exception specification of that function. What happens i=
f
> another translation unit sees just the definition without the declaration
--
> in that case the function would have an auto noexcept specification just
in
> that translation unit. What happens if someone uses the noexcept operator
at
> a point where only the declaration is visible, then uses the noexcept
> operator on it after the definition is visible in the same translation
unit
> and/or another translation unit where the definition is available, etc.
These are all good points.
However, the compiler does have a few cases already where it automatically
deduces noexcept-specifications: namely, on =3Ddefault'ed member
functions[*], which are a special case of "inline member functions", which
are a special case of "inline functions". Inline functions are nice
because they must be defined in all TUs that use them, and because it's
undefined behavior to give them different definitions in different TUs. Do
inline functions therefore successfully dodge all the above objections?
What happens if we broaden the scope of automatically deduced
noexcept-specifications from "defaulted members" to "all inline functions,
and also all lambdas"?
Alternatively, derailing the original proposal but still addressing the
only reason noexcept matters to me personally, what happens if we remove
the requirements [vector.capacity]/9, /14, /17, etc., that prohibit
std::vector<T>::resize() from using T's move-ctor in cases where T's
move-ctor has not been explicitly specified as noexcept? If we did that,
there wouldn't be any reason for normal (non-guru) programmers to care
about noexcept, and the feature could quietly get as complicated as it
wanted, in the background, without harming anyone. :)
[* =E2=80=93 I originally wrote "...and destructors", but that's not really=
true.
Destructors are assumed to have a certain noexcept-specification per
[except.spec]/16.3, but *assuming* a noexcept-specification is not the same
thing as *deducing* it. Here's a demonstration of the current behavior:
struct S {
S() noexcept =3D default;
~S() { throw 42; }
};
static_assert(noexcept(S()), "this static_assert succeeds");
If I understand the proposal correctly, replacing ~S() here with ~S()
noexcept(auto) would change the semantics of the code, in that the
static_assert would start failing.]
=E2=80=93Arthur
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--047d7ba97384010b080512fed072
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sat, Apr 4, 2015 at 7:40 PM, 'Matt Calabrese' v=
ia ISO C++ Standard - Future Proposals <<a href=3D"mailto:std-proposals@=
isocpp.org">std-proposals@isocpp.org</a>> wrote:<br>> On Sat, Apr 4, =
2015 at 4:00 PM, Arthur O'Dwyer <<a href=3D"mailto:arthur.j.odwyer@g=
mail.com">arthur.j.odwyer@gmail.com</a>>=C2=A0wrote:<br>>> On Satu=
rday, April 4, 2015 at 12:31:51 PM UTC-7, Vittorio Romeo wrote:<br>>>=
><br>>>> I definitely have a lot of occurrences in my code wher=
e I repeat the body<br>>>> of small functions in the noexcept qual=
ifier. <br>>>> Something like this would help a lot.<br>>>&g=
t;<br>>>> Would there be any issue in expanding this feature propo=
sal to<br>>>> non-one-line functions?<br>>><br>>> In f=
act, before we get too far into the syntax bikeshed, could someone<br>>&=
gt; knowledgeable please explain why noexcept(...) declarations are require=
d at=C2=A0all?<br>>> I.e., why was it not made a rule in C++11 that<b=
r>>><br>>> =C2=A0 =C2=A0 void foo() { some-stuff; }<br>>>=
<br>>> should *invariably* be interpreted by the compiler as<br>>&=
gt;<br>>> =C2=A0 =C2=A0 void foo() noexcept(some-stuff) { some-stuff;=
}<br>><br>> In order for that to work you'd need the definition =
to be there. What<br>> happens if someone just has a function declaratio=
n? Here, I imagine you'd<br>> say it just shouldn't have a noexc=
ept specification (rather than auto).<br>> Okay, then what happens if th=
e function is defined later on in the<br>> translation unit and it turns=
out there are no non-noexcept operations? You<br>> can't change the=
exception specification of that function. What happens if<br>> another =
translation unit sees just the definition without the declaration --<br>>=
; in that case the function would have an auto noexcept specification just =
in<br>> that translation unit. What happens if someone uses the noexcept=
operator at<br>> a point where only the declaration is visible, then us=
es the noexcept<br>> operator on it after the definition is visible in t=
he same translation unit<br>> and/or another translation unit where the =
definition is available, etc.<br><br>These are all good points.<div>However=
, the compiler does have a few cases already where it automatically deduces=
noexcept-specifications: namely, on =3Ddefault'ed member functions[*],=
which are a special case of "inline member functions", which are=
a special case of "inline functions".=C2=A0 Inline functions are=
nice because they must be defined in all TUs that use them, and because it=
's undefined behavior to give them different definitions in different T=
Us. Do inline functions therefore successfully dodge all the above objectio=
ns?</div><div><br></div><div>What happens if we broaden the scope of automa=
tically deduced noexcept-specifications from "defaulted members" =
to "all inline functions, and also all lambdas"?</div><div><br></=
div><div>Alternatively, derailing the original proposal but still addressin=
g the only reason noexcept matters to me personally, what happens if we rem=
ove the requirements [vector.capacity]/9, /14, /17, etc., that prohibit <fo=
nt face=3D"monospace, monospace">std::vector<T>::resize()</font> from=
using T's move-ctor in cases where T's move-ctor has not been expl=
icitly specified as noexcept?=C2=A0 If we did that, there wouldn't be a=
ny reason for normal (non-guru) programmers to care about noexcept, and the=
feature could quietly get as complicated as it wanted, in the background, =
without harming anyone. :)<br></div><div><br></div><div>[* =E2=80=93 I orig=
inally wrote "...and destructors", but that's not really true=
.. Destructors are assumed to have a certain noexcept-specification per [exc=
ept.spec]/16.3, but <i>assuming</i>=C2=A0a noexcept-specification is not th=
e same thing as <i>deducing</i>=C2=A0it. Here's a demonstration of the =
current behavior:</div><div><br></div><div><font face=3D"monospace, monospa=
ce">=C2=A0 struct S {</font></div><div><font face=3D"monospace, monospace">=
=C2=A0 =C2=A0 =C2=A0 S() noexcept =3D default;</font></div><div><font face=
=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 ~S() { throw 42; }</font></d=
iv><div><font face=3D"monospace, monospace">=C2=A0 };</font></div><div><fon=
t face=3D"monospace, monospace">=C2=A0 static_assert(noexcept(S()), "t=
his static_assert succeeds");</font></div><div><br>If I understand the=
proposal correctly, replacing <font face=3D"monospace, monospace">~S()</fo=
nt> here with <font face=3D"monospace, monospace">~S() noexcept(auto)</font=
> would change the semantics of the code, in that the static_assert would s=
tart failing.]<br></div><div><br></div><div>=E2=80=93Arthur</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7ba97384010b080512fed072--
.
Author: Marc Mutz <marc.mutz@kdab.com>
Date: Mon, 6 Apr 2015 02:32:40 +0200
Raw View
On Sunday 05 April 2015 19:40:07 Thiago Macieira wrote:
> On Sunday 05 April 2015 03:06:56 Ville Voutilainen wrote:
> > It doesn't hurt if you author a paper outlining the cases in Qt where
> > the boiler-plate
> > that the current rules require appears; I am fairly busy, and I wasn't
> > exactly planning
> > to write a noexcept(auto) paper for the next meeting. I may try, but I
> > might not make it.
> > The deadline is April 10th, so there's not a lot of time.
>
> We're not very good at using noexcept, especially because all but three
> modules are compiled wih -fno-exceptions or equivalent anyway.
>
> Marc has been pushing some modifications and might comment a little more.
There are three aspects I'd comment on:
1. We use the noexcept operator because it is more convenient than using
<type_traits>, esp. in the shared C++98/11 codebase that Qt still is, where
every use of the header requires ifdef'ery (whereas noexcept is abstracted
behind a function-like macro that gets centrally redefined to nothing if
noexcept is not supported).
2. the noexecpt operator, when being applied to the whole expression of the
function body, is, however, useless when the expression passed doesn't
compile, so for constrained templates, you need to use some other form of
conditional noexcept (ie. type_traits). A noexcept(auto) would have to
change the rules here; it should work on constrained templates, too.
3. Personally, I'd be ok if the noexcept specification of a function would
change from noexcept(false) in debug mode to noexcept(true) in release
mode. It's a quality-of-implementation issue to not use the noexcept
operator in such a way as to create binary incompatibility between
noexcept(true) and noexcept(false). AFAIK, the GCC STL debug mode can e.g.
interoperate in the same executable with non-debug-mode containers, which
is basically the same thing.
3a. We're basically adding noexcept because we want Qt types to be fast in
std::vector, too, and not fall back on copying. However, the
vector/move_if_noexcept discussions are missing the point that a
vector should use neither copy nor move to grow its capacity, but realloc.
The vast majority of types are trivially relocatable (in EASTL terms),
those that aren't are probably better not held in containers directly
anyway (if a type is self-referential, it internally depends on its
identity (address), and the STL's requirement that element types be semi-
regular is already violated). The earlier something like Howard's allocator
and malloc changes are put into the standard, the shorter the time we have
to live with a move_if_noexcept vector, and the shorter the time where we
have to discuss throwing move constructors.
Thanks,
Marc
--
Marc Mutz <marc.mutz@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 05 Apr 2015 20:13:57 -0700
Raw View
On Sunday 05 April 2015 12:01:44 Arthur O'Dwyer wrote:
> However, the compiler does have a few cases already where it automatically
> deduces noexcept-specifications: namely, on =default'ed member
> functions[*], which are a special case of "inline member functions", which
> are a special case of "inline functions". Inline functions are nice
> because they must be defined in all TUs that use them, and because it's
> undefined behavior to give them different definitions in different TUs. Do
> inline functions therefore successfully dodge all the above objections?
>
> What happens if we broaden the scope of automatically deduced
> noexcept-specifications from "defaulted members" to "all inline functions,
> and also all lambdas"?
That might be nice, but I'd say it's insufficient since it will still require
repetition for non-inline functions. If we want to fix those, then we need
noexcept(auto), which in turn means we don't have to change the rules for
inlines.
As for lambdas, I agree, since you can't really add the noexcept there.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 6 Apr 2015 11:33:12 +0800
Raw View
--Apple-Mail=_1B3BC0B0-52F7-4158-BADE-CCDE934888F6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9304=E2=80=9306, at 11:13 AM, Thiago Macieira <thiago@macie=
ira.org> wrote:
>=20
> That might be nice, but I'd say it's insufficient since it will still req=
uire=20
> repetition for non-inline functions. If we want to fix those, then we nee=
d=20
> noexcept(auto), which in turn means we don't have to change the rules for=
=20
> inlines.
How would noexcept(auto) work on a non-inline function? If you mean to refe=
r to functions with internal linkage, those can simply be included in the s=
ame category as inline functions. The interesting property is that the defi=
nition must occur within the TU.
The difference between special member functions and other inline functions =
is that the definition of a special member is available at a known point, t=
he closing brace of the class scope. Other inline functions may yet be unde=
fined. Also, special member functions are simple and never (co-)recursive.
Applying deduction without the noexcept(auto) opt-in would break usage of t=
he noexcept operator between the declaration and the end of the definition =
of the function. Might not sound so bad, but consider that the semantics in=
clude implicit application of the noexcept operator. So any call from an in=
line function body to an undefined inline function, including simple recurs=
ive calls, demands an explicit exception-specification. Major breakage and =
inconvenience.
> As for lambdas, I agree, since you can't really add the noexcept there.
Not sure what you mean. The exception-specification of a lambda is grammati=
cally after the optional mutable qualifier.
--=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=_1B3BC0B0-52F7-4158-BADE-CCDE934888F6
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=9304=
=E2=80=9306, at 11:13 AM, Thiago Macieira <<a href=3D"mailto:thiago@maci=
eira.org" class=3D"">thiago@macieira.org</a>> wrote:</div><br class=3D"A=
pple-interchange-newline"><div class=3D"">That might be nice, but I'd say i=
t's insufficient since it will still require <br class=3D"">repetition for =
non-inline functions. If we want to fix those, then we need <br class=3D"">=
noexcept(auto), which in turn means we don't have to change the rules for <=
br class=3D"">inlines.<br class=3D""></div></blockquote><div><br class=3D""=
></div><div>How would <font face=3D"Courier" class=3D"">noexcept(auto)</fon=
t> work on a non-<font face=3D"Courier" class=3D"">inline</font> function? =
If you mean to refer to functions with internal linkage, those can simply b=
e included in the same category as inline functions. The interesting proper=
ty is that the definition must occur within the TU.</div><div><br class=3D"=
"></div><div>The difference between special member functions and other inli=
ne functions is that the definition of a special member is available at a k=
nown point, the closing brace of the class scope. Other inline functions ma=
y yet be undefined. Also, special member functions are simple and never (co=
-)recursive.</div><div><br class=3D""></div><div>Applying deduction without=
the <span style=3D"font-family: Courier;" class=3D"">noexcept(auto)</=
span> opt-in would break usage of the <span style=3D"font-family:=
Courier;" class=3D"">noexcept</span> operator between the declaration=
and the end of the definition of the function. Might not sound so bad, but=
consider that the semantics include implicit application of the <span=
style=3D"font-family: Courier;" class=3D"">noexcept</span> operator. =
So any call from an inline function body to an undefined inline function, i=
ncluding simple recursive calls, demands an explicit exception-specificatio=
n. Major breakage and inconvenience.</div><br class=3D""><blockquote type=
=3D"cite" class=3D""><div class=3D"">As for lambdas, I agree, since you can=
't really add the noexcept there.<br class=3D""></div></blockquote><br clas=
s=3D""></div><div>Not sure what you mean. The exception-specification of a =
lambda is grammatically after the optional <font face=3D"Courier" class=3D"=
">mutable</font> qualifier.</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</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=_1B3BC0B0-52F7-4158-BADE-CCDE934888F6--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Sun, 5 Apr 2015 20:35:36 -0700
Raw View
--089e0122f374c7d390051305fd9e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sun, Apr 5, 2015 at 8:13 PM, Thiago Macieira <thiago@macieira.org> wrote=
:
> On Sunday 05 April 2015 12:01:44 Arthur O'Dwyer wrote:
> > However, the compiler does have a few cases already where it
> automatically
> > deduces noexcept-specifications: namely, on =3Ddefault'ed member
> > functions[*], which are a special case of "inline member functions",
> which
> > are a special case of "inline functions". Inline functions are nice
> > because they must be defined in all TUs that use them, and because it's
> > undefined behavior to give them different definitions in different TUs.
> Do
> > inline functions therefore successfully dodge all the above objections?
> >
> > What happens if we broaden the scope of automatically deduced
> > noexcept-specifications from "defaulted members" to "all inline
> functions,
> > and also all lambdas"?
>
> That might be nice, but I'd say it's insufficient since it will still
> require
> repetition for non-inline functions. If we want to fix those, then we nee=
d
> noexcept(auto), which in turn means we don't have to change the rules for
> inlines.
>
If noexcept(auto) exists, then the rule for inline functions is "Always
type the magic 14 characters noexcept(auto) after the closing parenthesis
of an inline function declarator. If you forget to do this, your code will
be silently pessimized by the compiler." I'm arguing that this is a dumb
hoop to jump through, and that the proper thing for the language to do is
simply *assume that the magic 14 characters are there*, without forcing the
user to type them out.
> As for lambdas, I agree, since you can't really add the noexcept there.
There actually is a syntax for adding noexcept-specifications to lambdas
already: you simply add it in the natural place.
// The following lambda invariably returns 42... but not only that,
// it manages to do it without throwing any exceptions!
// This surprising behavior requires special syntax.
auto lambda =3D [](int) noexcept { return 42; };
=E2=80=93Arthur
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--089e0122f374c7d390051305fd9e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sun, Apr 5, 2015 at 8:13 PM, Thiago Macieira <span dir=
=3D"ltr"><<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiag=
o@macieira.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Sunda=
y 05 April 2015 12:01:44 Arthur O'Dwyer wrote:<br>
> However, the compiler does have a few cases already where it automatic=
ally<br>
> deduces noexcept-specifications: namely, on =3Ddefault'ed member<b=
r>
> functions[*], which are a special case of "inline member function=
s", which<br>
> are a special case of "inline functions".=C2=A0 Inline funct=
ions are nice<br>
> because they must be defined in all TUs that use them, and because it&=
#39;s<br>
> undefined behavior to give them different definitions in different TUs=
.. Do<br>
> inline functions therefore successfully dodge all the above objections=
?<br>
><br>
> What happens if we broaden the scope of automatically deduced<br>
> noexcept-specifications from "defaulted members" to "al=
l inline functions,<br>
> and also all lambdas"?<br>
<br>
</span>That might be nice, but I'd say it's insufficient since it w=
ill still require<br>
repetition for non-inline functions. If we want to fix those, then we need<=
br>
noexcept(auto), which in turn means we don't have to change the rules f=
or<br>
inlines.<br></blockquote><div><br></div><div>If noexcept(auto) exists, then=
the rule for inline functions is "Always type the magic 14 characters=
<font face=3D"monospace, monospace">noexcept(auto)</font> after the closin=
g parenthesis of an inline function declarator. If you forget to do this, y=
our code will be silently pessimized by the compiler." =C2=A0I'm a=
rguing that this is a dumb hoop to jump through, and that the proper thing =
for the language to do is simply <i>assume that the magic 14 characters are=
there</i>, without forcing the user to type them out.</div><div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">As for lambdas, I agree, since you can'=
;t really add the noexcept there.</blockquote><div><br></div><div>=C2=A0The=
re actually is a syntax for adding noexcept-specifications to lambdas alrea=
dy: you simply add it in the natural place.</div><div><br></div><div><font =
face=3D"monospace, monospace">=C2=A0 =C2=A0 // The following lambda invaria=
bly returns 42... but not only that,</font></div><div><font face=3D"monospa=
ce, monospace">=C2=A0 =C2=A0 // it manages to do it without throwing any ex=
ceptions!</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=
=A0 // This surprising behavior requires special syntax.</font></div><div><=
font face=3D"monospace, monospace">=C2=A0 =C2=A0 auto lambda =3D [](int) no=
except { return 42; };</font></div><div><br></div></div>=E2=80=93Arthur</di=
v></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</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 />
--089e0122f374c7d390051305fd9e--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 6 Apr 2015 11:47:22 +0800
Raw View
--Apple-Mail=_5243EABC-0FFB-4D18-ACDD-25B188C5D4BF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9304=E2=80=9306, at 11:35 AM, Arthur O'Dwyer <arthur.j.odwy=
er@gmail.com> wrote:
>=20
> If noexcept(auto) exists, then the rule for inline functions is "Always t=
ype the magic 14 characters noexcept(auto) after the closing parenthesis of=
an inline function declarator.
Unless it=E2=80=99s recursive or it calls another undefined noexcept(auto) =
function.
> If you forget to do this, your code will be silently pessimized by the co=
mpiler."=20
noexcept is not often related to performance. Is there any connection besid=
es move constructors? The appropriate solution there is for the implementat=
ion to optionally warn when those are implicitly noexcept(false). And, we=
=E2=80=99re specifically not talking about special member functions here.
There=E2=80=99s also exception table generation, but those are mainly a con=
cern to embedded applications, and there=E2=80=99s a lot of other work to b=
e done in that area.
--=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=_5243EABC-0FFB-4D18-ACDD-25B188C5D4BF
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=9304=
=E2=80=9306, at 11:35 AM, Arthur O'Dwyer <<a href=3D"mailto:arthur.j.odw=
yer@gmail.com" class=3D"">arthur.j.odwyer@gmail.com</a>> wrote:</div><br=
class=3D"Apple-interchange-newline"><div class=3D""><span style=3D"font-fa=
mily: Helvetica; font-size: 12px; font-style: normal; font-variant: normal;=
font-weight: normal; letter-spacing: normal; line-height: normal; orphans:=
auto; text-align: start; text-indent: 0px; text-transform: none; white-spa=
ce: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px=
; float: none; display: inline !important;" class=3D"">If noexcept(auto) ex=
ists, then the rule for inline functions is "Always type the magic 14 chara=
cters<span class=3D"Apple-converted-space"> </span></span><font face=
=3D"monospace, monospace" style=3D"font-size: 12px; font-style: normal; fon=
t-variant: normal; font-weight: normal; letter-spacing: normal; line-height=
: normal; orphans: auto; text-align: start; text-indent: 0px; text-transfor=
m: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text=
-stroke-width: 0px;" class=3D"">noexcept(auto)</font><span style=3D"font-fa=
mily: Helvetica; font-size: 12px; font-style: normal; font-variant: normal;=
font-weight: normal; letter-spacing: normal; line-height: normal; orphans:=
auto; text-align: start; text-indent: 0px; text-transform: none; white-spa=
ce: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px=
; float: none; display: inline !important;" class=3D""><span class=3D"Apple=
-converted-space"> </span>after the closing parenthesis of an inline f=
unction declarator. </span></div></blockquote><div><br class=3D""></div><di=
v>Unless it=E2=80=99s recursive or it calls another undefined <font face=3D=
"Courier" class=3D"">noexcept(auto)</font> function.</div><br class=3D""><b=
lockquote type=3D"cite" class=3D""><div class=3D""><span style=3D"font-fami=
ly: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; f=
ont-weight: normal; letter-spacing: normal; line-height: normal; orphans: a=
uto; text-align: start; text-indent: 0px; text-transform: none; white-space=
: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
float: none; display: inline !important;" class=3D"">If you forget to do th=
is, your code will be silently pessimized by the compiler."<span class=3D"A=
pple-converted-space"> </span></span></div></blockquote></div><br clas=
s=3D""><div class=3D""><span style=3D"font-family: Courier;" class=3D"">noe=
xcept</span> is not often related to performance. Is there any connect=
ion besides move constructors? The appropriate solution there is for the im=
plementation to optionally warn when those are implicitly <font face=3D"Cou=
rier" class=3D"">noexcept(false)</font>. And, we=E2=80=99re specifically no=
t talking about special member functions here.</div><div class=3D""><br cla=
ss=3D""></div><div class=3D"">There=E2=80=99s also exception table generati=
on, but those are mainly a concern to embedded applications, and there=E2=
=80=99s a lot of other work to be done in that area.</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</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=_5243EABC-0FFB-4D18-ACDD-25B188C5D4BF--
.
Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Sun, 5 Apr 2015 21:08:16 -0700
Raw View
--047d7bb0485290809905130672a3
Content-Type: text/plain; charset=UTF-8
On Sun, Apr 5, 2015 at 12:01 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:
> These are all good points.
> However, the compiler does have a few cases already where it automatically
> deduces noexcept-specifications: namely, on =default'ed member
> functions[*], which are a special case of "inline member functions", which
> are a special case of "inline functions". Inline functions are nice
> because they must be defined in all TUs that use them, and because it's
> undefined behavior to give them different definitions in different TUs. Do
> inline functions therefore successfully dodge all the above objections?
>
No, they wouldn't dodge the objections. You can declare a function and then
define it inline later in the same translation unit, which exhibits the
problem. So an implicit noexcept(auto) would basically only be feasible for
member functions that are defined in the class definition and that is it.
Rather than only doing it in that case, which would be oddly inconsistent,
confusing, and error prone, it's probably best to just do as others
suggested in the thread, which is to say that at the point of declaration
the programmer must write noexcept(auto), and if the function is used and
not defined in that translation unit, then it should be an error. It should
be a lot like declaring functions with automatically deduced return types.
This also has the benefit of not drastically changing behavior between
standards if it were adopted -- the alternative makes it a nonstarter.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.
--047d7bb0485290809905130672a3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Apr 5, 2015 at 12:01 PM, Arthur O'Dwyer <span dir=3D"ltr"><<a hr=
ef=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@g=
mail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div><div class=3D"h5"><span style=3D"color:rgb(34,34,34)">These a=
re all good points.</span><br></div></div><div>However, the compiler does h=
ave a few cases already where it automatically deduces noexcept-specificati=
ons: namely, on =3Ddefault'ed member functions[*], which are a special =
case of "inline member functions", which are a special case of &q=
uot;inline functions".=C2=A0 Inline functions are nice because they mu=
st be defined in all TUs that use them, and because it's undefined beha=
vior to give them different definitions in different TUs. Do inline functio=
ns therefore successfully dodge all the above objections?</div></div></bloc=
kquote><div><br></div><div>No, they wouldn't dodge the objections. You =
can declare a function and then define it inline later in the same translat=
ion unit, which exhibits the problem. So an implicit noexcept(auto) would b=
asically only be feasible for member functions that are defined in the clas=
s definition and that is it. Rather than only doing it in that case, which =
would be oddly inconsistent, confusing, and error prone, it's probably =
best to just do as others suggested in the thread, which is to say that at =
the point of declaration the programmer must write noexcept(auto), and if t=
he function is used and not defined in that translation unit, then it shoul=
d be an error. It should be a lot like declaring functions with automatical=
ly deduced return types. This also has the benefit of not drastically chang=
ing behavior between standards if it were adopted -- the alternative makes =
it a nonstarter.</div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7bb0485290809905130672a3--
.
Author: Marshall Clow <mclow.lists@gmail.com>
Date: Mon, 6 Apr 2015 13:38:57 -0700
Raw View
--047d7bfcf2fa8b3c3e05131449d0
Content-Type: text/plain; charset=UTF-8
On Sat, Apr 4, 2015 at 11:50 AM, Thiago Macieira <thiago@macieira.org>
wrote:
> I find that we're often adding a lot of code in the following pattern:
>
> T functionName(args) noexcept(noexcept(<block of code>))
> {
> return <block of code>
> }
>
> Where the block of code is repeated.
>
Actually, it's frequently worse than that, with *3* repetitions of the same
code.
auto functionName(args)
noexcept(noexcept(<code block))
-> decltype (<code block>)
{
return <code block>;
}
-- Marshall
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.
--047d7bfcf2fa8b3c3e05131449d0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Apr 4, 2015 at 11:50 AM, Thiago Macieira <span dir=3D"ltr"><<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex">I find that we're often adding a l=
ot of code in the following pattern:<br>
<br>
T functionName(args) noexcept(noexcept(<block of code>))<br>
{<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return <block of code><br>
}<br>
<br>
Where the block of code is repeated.<br></blockquote><div><br></div><div>Ac=
tually, it's frequently worse than that, with *3* repetitions of the sa=
me code.</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0 auto functionName(ar=
gs)</div><div>=C2=A0 =C2=A0 =C2=A0 noexcept(noexcept(<code block))<br></=
div><div>=C2=A0 =C2=A0 =C2=A0 -> decltype (<code block>)</div><div=
>=C2=A0 =C2=A0 =C2=A0=C2=A0{</div><div>=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 =C2=
=A0 =C2=A0=C2=A0return <code block>;</div><div>=C2=A0 =C2=A0 =C2=A0=
=C2=A0}</div></div><br></div><div class=3D"gmail_extra">-- Marshall</div><d=
iv class=3D"gmail_extra"><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</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 />
--047d7bfcf2fa8b3c3e05131449d0--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 6 Apr 2015 23:41:53 +0300
Raw View
On 6 April 2015 at 23:38, Marshall Clow <mclow.lists@gmail.com> wrote:
> On Sat, Apr 4, 2015 at 11:50 AM, Thiago Macieira <thiago@macieira.org>
> wrote:
>>
>> I find that we're often adding a lot of code in the following pattern:
>>
>> T functionName(args) noexcept(noexcept(<block of code>))
>> {
>> return <block of code>
>> }
>>
>> Where the block of code is repeated.
>
>
> Actually, it's frequently worse than that, with *3* repetitions of the same
> code.
>
> auto functionName(args)
> noexcept(noexcept(<code block))
> -> decltype (<code block>)
> {
> return <code block>;
> }
In C++11, yes, but in C++14, probably not.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Mon, 6 Apr 2015 13:49:07 -0700
Raw View
--001a11c2a8ace201d70513146d8f
Content-Type: text/plain; charset=UTF-8
On Mon, Apr 6, 2015 at 1:38 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
>
> Actually, it's frequently worse than that, with *3* repetitions of the
> same code.
>
> auto functionName(args)
> noexcept(noexcept(<code block))
> -> decltype (<code block>)
> {
> return <code block>;
> }
>
Yeah! It's really, really nasty. In practice, I have a variety of macros
that I use to minimize the code duplication surrounding the different
combinations of "automatically deduced" noexcept and return type
declarations, including one that expands to what you've shown. Often,
well-designed generic code ends up either being loaded with macros or
loaded with explicit code duplication and IMO it's sort of an embarrassment
of the language.
Also, before anyone says otherwise, automatically deduced function return
types of C++14 don't always help things either, since you frequently want
to exploit SFINAE.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.
--001a11c2a8ace201d70513146d8f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Apr 6, 2015 at 1:38 PM, Marshall Clow <span dir=3D"ltr"><<a href=3D"=
mailto:mclow.lists@gmail.com" target=3D"_blank">mclow.lists@gmail.com</a>&g=
t;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra=
"><div class=3D"gmail_quote"><div>Actually, it's frequently worse than =
that, with *3* repetitions of the same code.</div><div><br></div><div>=C2=
=A0 =C2=A0 =C2=A0 auto functionName(args)</div><div>=C2=A0 =C2=A0 =C2=A0 no=
except(noexcept(<code block))<br></div><div>=C2=A0 =C2=A0 =C2=A0 -> d=
ecltype (<code block>)</div><div>=C2=A0 =C2=A0 =C2=A0=C2=A0{</div><di=
v>=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0return <code block=
>;</div><div>=C2=A0 =C2=A0 =C2=A0=C2=A0}</div></div></div></div></blockq=
uote></div></div><div class=3D"gmail_extra"><div class=3D"gmail_extra"><br>=
</div><div class=3D"gmail_extra">Yeah! It's really, really nasty. In pr=
actice, I have a variety of macros that I use to minimize the code duplicat=
ion surrounding the different combinations of "automatically deduced&q=
uot; noexcept and return type declarations, including one that expands to w=
hat you've shown. Often, well-designed generic code ends up either bein=
g loaded with macros or loaded with explicit code duplication and IMO it=
9;s sort of an embarrassment of the language.</div><div class=3D"gmail_extr=
a"><br></div><div class=3D"gmail_extra">Also, before anyone says otherwise,=
automatically deduced function return types of C++14 don't always help=
things either, since you frequently want to exploit SFINAE.</div></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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</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 />
--001a11c2a8ace201d70513146d8f--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 06 Apr 2015 15:53:55 -0700
Raw View
On Monday 06 April 2015 13:49:07 'Matt Calabrese' via ISO C++ Standard -
Future Proposals wrote:
> Also, before anyone says otherwise, automatically deduced function return
> types of C++14 don't always help things either, since you frequently want
> to exploit SFINAE.
Those are to be better solved by concepts, later. Using the return type to
enable or disable a function should be considered a workaround/hack, not the
proper solution to the problem.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Mon, 6 Apr 2015 16:10:12 -0700
Raw View
--047d7b41ce5a764c0d0513166681
Content-Type: text/plain; charset=UTF-8
On Mon, Apr 6, 2015 at 3:53 PM, Thiago Macieira <thiago@macieira.org> wrote:
> On Monday 06 April 2015 13:49:07 'Matt Calabrese' via ISO C++ Standard -
> Future Proposals wrote:
> > Also, before anyone says otherwise, automatically deduced function return
> > types of C++14 don't always help things either, since you frequently want
> > to exploit SFINAE.
>
> Those are to be better solved by concepts, later. Using the return type to
> enable or disable a function should be considered a workaround/hack, not
> the
> proper solution to the problem.
I *might* accept that when we actually have [good] concepts support in the
language -- it's been around 15 years or so that language support has been
talked about and I'm not confident in even concepts-lite being in the
language by C++17, either. Even with the current flavor of concepts that is
being pursued, automatically deducing requirements in the manner presented
here still has its benefits in certain cases, as this method of requirement
specification has no chance of under/over-specification. Concepts-lite
style concepts provide no help here.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.
--047d7b41ce5a764c0d0513166681
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Apr 6, 2015 at 3:53 PM, Thiago Macieira <span dir=3D"ltr"><<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">On Monday 06 April 2015 =
13:49:07 'Matt Calabrese' via ISO C++ Standard -<br>
<span class=3D"">Future Proposals wrote:<br>
> Also, before anyone says otherwise, automatically deduced function ret=
urn<br>
> types of C++14 don't always help things either, since you frequent=
ly want<br>
> to exploit SFINAE.<br>
<br>
</span>Those are to be better solved by concepts, later. Using the return t=
ype to<br>
enable or disable a function should be considered a workaround/hack, not th=
e<br>
proper solution to the problem.</blockquote><div><br></div><div>I <i>might<=
/i> accept that when we actually have [good] concepts support in the langua=
ge -- it's been around 15 years or so that language support has been ta=
lked about and I'm not confident in even concepts-lite being in the lan=
guage by C++17, either. Even with the current flavor of concepts that is be=
ing pursued, automatically deducing requirements in the manner presented he=
re still has its benefits in certain cases, as this method of requirement s=
pecification has no chance of under/over-specification. Concepts-lite style=
concepts provide no help here.</div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b41ce5a764c0d0513166681--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 6 Apr 2015 16:40:50 -0700
Raw View
--001a1134b63a01a28e051316d44c
Content-Type: text/plain; charset=UTF-8
On Mon, Apr 6, 2015 at 3:53 PM, Thiago Macieira <thiago@macieira.org> wrote:
> On Monday 06 April 2015 13:49:07 'Matt Calabrese' via ISO C++ Standard -
> Future Proposals wrote:
> > Also, before anyone says otherwise, automatically deduced function return
> > types of C++14 don't always help things either, since you frequently want
> > to exploit SFINAE.
>
> Those are to be better solved by concepts, later. Using the return type to
> enable or disable a function should be considered a workaround/hack, not
> the
> proper solution to the problem.
If you want to constrain the template on particular concepts rather than on
"the function body should be valid", then enable_if would be the right tool
to use today, rather than "decltype(<returned expression>)".
So in an apples-to-apples comparison, and following the pattern of "the
exception specification / return type / constraints should be deduced from
the function body", the Concepts TS gives us:
decltype(auto) functionName(args) noexcept(noexcept(<returned expression>))
requires requires { <returned expression>; }
{
return <returned expression>;
}
.... which doesn't seem to be any better.
--
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.
--001a1134b63a01a28e051316d44c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Apr 6, 2015 at 3:53 PM, Thiago Macieira <span dir=3D"ltr"><<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex">On Monday 06 April 2015 13:49:07 '=
Matt Calabrese' via ISO C++ Standard -<br>
<span class=3D"">Future Proposals wrote:<br>
> Also, before anyone says otherwise, automatically deduced function ret=
urn<br>
> types of C++14 don't always help things either, since you frequent=
ly want<br>
> to exploit SFINAE.<br>
<br>
</span>Those are to be better solved by concepts, later. Using the return t=
ype to<br>
enable or disable a function should be considered a workaround/hack, not th=
e<br>
proper solution to the problem.</blockquote><div><br></div><div>If you want=
to constrain the template on particular concepts rather than on "the =
function body should be valid", then enable_if would be the right tool=
to use today, rather than "decltype(<returned expression>)"=
;.<br></div><div><br></div><div>So in an apples-to-apples comparison, and f=
ollowing the pattern of "the exception specification / return type / c=
onstraints should be deduced from the function body", the Concepts TS =
gives us:</div><div><br></div><div>decltype(auto) functionName(args) noexce=
pt(noexcept(<returned expression>))</div><div>=C2=A0 requires require=
s { <returned expression>; }</div><div>{</div><div>=C2=A0 return <=
returned expression>;</div><div>}</div><div><br></div><div>... which doe=
sn't seem to be any better.</div><div><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span =
class=3D"im">
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=3D"_b=
lank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F005 6EF4 535=
8<br>
<br>
</span><div class=3D""><div class=3D"h5">--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</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 />
--001a1134b63a01a28e051316d44c--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 06 Apr 2015 17:34:33 -0700
Raw View
On Monday 06 April 2015 16:40:50 Richard Smith wrote:
> If you want to constrain the template on particular concepts rather than on
> "the function body should be valid", then enable_if would be the right tool
> to use today, rather than "decltype(<returned expression>)".
>
> So in an apples-to-apples comparison, and following the pattern of "the
> exception specification / return type / constraints should be deduced from
> the function body", the Concepts TS gives us:
>
> decltype(auto) functionName(args) noexcept(noexcept(<returned expression>))
> requires requires { <returned expression>; }
> {
> return <returned expression>;
> }
>
> ... which doesn't seem to be any better.
While I understand why some people may want to use that feature, I'd say that
they shouldn't. That's a circular definition: if this function fails to
compile, don't try to compile it.
Functions should exist or not based on the concepts. If that fails to compile,
either the concept or the function body is bad or under-constrained.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Mon, 6 Apr 2015 17:54:37 -0700
Raw View
--089e01184098dff98e051317dbec
Content-Type: text/plain; charset=UTF-8
On Mon, Apr 6, 2015 at 5:34 PM, Thiago Macieira <thiago@macieira.org> wrote:
> Functions should exist or not based on the concepts. If that fails to
> compile,
> either the concept or the function body is bad or under-constrained.
While I agree in principle, with the currently pursued concepts approach we
would not get an error if a function were under-constrained (though,
notably, the proposed C++0x concepts were able to do this...). It is very
easy to incorrectly constrain your templates because of this. Also, on a
practical level, "automatically constraining" is simply more concise and
just as clear for many one-liner function templates.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.
--089e01184098dff98e051317dbec
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Apr 6, 2015 at 5:34 PM, Thiago Macieira <span dir=3D"ltr"><<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">Functions should exist o=
r not based on the concepts. If that fails to compile,<br>
either the concept or the function body is bad or under-constrained.</block=
quote><div><br></div><div>While I agree in principle, with the currently pu=
rsued concepts approach we would not get an error if a function were under-=
constrained (though, notably, the proposed C++0x concepts were able to do t=
his...). It is very easy to incorrectly constrain your templates because of=
this. Also, on a practical level, "automatically constraining" i=
s simply more concise and just as clear for many one-liner function templat=
es.</div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e01184098dff98e051317dbec--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 6 Apr 2015 17:57:31 -0700
Raw View
--001a1134bfb042ba78051317e67e
Content-Type: text/plain; charset=UTF-8
On Mon, Apr 6, 2015 at 5:34 PM, Thiago Macieira <thiago@macieira.org> wrote:
> On Monday 06 April 2015 16:40:50 Richard Smith wrote:
> > If you want to constrain the template on particular concepts rather than
> on
> > "the function body should be valid", then enable_if would be the right
> tool
> > to use today, rather than "decltype(<returned expression>)".
> >
> > So in an apples-to-apples comparison, and following the pattern of "the
> > exception specification / return type / constraints should be deduced
> from
> > the function body", the Concepts TS gives us:
> >
> > decltype(auto) functionName(args) noexcept(noexcept(<returned
> expression>))
> > requires requires { <returned expression>; }
> > {
> > return <returned expression>;
> > }
> >
> > ... which doesn't seem to be any better.
>
> While I understand why some people may want to use that feature, I'd say
> that
> they shouldn't. That's a circular definition: if this function fails to
> compile, don't try to compile it.
>
> Functions should exist or not based on the concepts. If that fails to
> compile,
> either the concept or the function body is bad or under-constrained.
That all applies equally to the 'decltype(<returned expression>)' case,
which was my point. If you would use concepts later, you should be using
enable_if now, not ad-hoc SFINAE tricks.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.
--001a1134bfb042ba78051317e67e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Apr 6, 2015 at 5:34 PM, Thiago Macieira <span dir=3D"ltr"><<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Mond=
ay 06 April 2015 16:40:50 Richard Smith wrote:<br>
> If you want to constrain the template on particular concepts rather th=
an on<br>
> "the function body should be valid", then enable_if would be=
the right tool<br>
> to use today, rather than "decltype(<returned expression>)&=
quot;.<br>
><br>
> So in an apples-to-apples comparison, and following the pattern of &qu=
ot;the<br>
> exception specification / return type / constraints should be deduced =
from<br>
> the function body", the Concepts TS gives us:<br>
><br>
> decltype(auto) functionName(args) noexcept(noexcept(<returned expre=
ssion>))<br>
>=C2=A0 =C2=A0requires requires { <returned expression>; }<br>
> {<br>
>=C2=A0 =C2=A0return <returned expression>;<br>
> }<br>
><br>
> ... which doesn't seem to be any better.<br>
<br>
</span>While I understand why some people may want to use that feature, I&#=
39;d say that<br>
they shouldn't. That's a circular definition: if this function fail=
s to<br>
compile, don't try to compile it.<br>
<br>
Functions should exist or not based on the concepts. If that fails to compi=
le,<br>
either the concept or the function body is bad or under-constrained.</block=
quote><div><br></div><div>That all applies equally to the 'decltype(<=
;returned expression>)' case, which was my point. If you would use c=
oncepts later, you should be using enable_if now, not ad-hoc SFINAE tricks.=
</div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1134bfb042ba78051317e67e--
.
Author: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= <dibeas@ieee.org>
Date: Tue, 7 Apr 2015 11:41:35 +0100
Raw View
--001a11c3c1b80c304d0513200f08
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Two comments:
Currently the 'noexcept' is *not* really deduced, but assumed in a couple
of places. AFAIK the compiler will *not* look into the body of the function
for a copy-constructor/destructor. In the case of the copy-constructor,
since it is the compiler generating the code, you can consider that it kind
of looks into the body. In the case of destructors, though, the 'noexcept'
specification is injected based on the member's destructor declarations
without looking at the body:
struct U {};
struct T {
U u;
~T() { throw 1; } // compiler assumes ~T() noexcept { throw 1; }
};
I don't think that you want the compiler to inject those "magic 14
characters". There might be quite a few of cases where the compiler will
get those wrong. For example:
void reset_element(std::vector<int> & v, size_t index) {
if (index < v.size()) v.at(index) =3D 0;
}
The compiler sees the call to 'v.at' and would assume the function to be
'noexcept(false)', but it is really 'noexcept(true)', it is guaranteed not
to throw. While the example is crappy, it represents a whole family of
functions that can call on 'noexcept(false)' functions but for which the
code ensures that no exception will be really thrown.
I am in favor of using 'auto' as a short hand for "deduce it for me" (or at
the very least not against it), but I don't really think that the compiler
should be injecting noexcept declarations for the programmer implictly.
Those "magic 14 characters" are really the user requesting that the
compiler to do it.
David
On Mon, Apr 6, 2015 at 4:35 AM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:
> On Sun, Apr 5, 2015 at 8:13 PM, Thiago Macieira <thiago@macieira.org>
> wrote:
>
>> On Sunday 05 April 2015 12:01:44 Arthur O'Dwyer wrote:
>> > However, the compiler does have a few cases already where it
>> automatically
>> > deduces noexcept-specifications: namely, on =3Ddefault'ed member
>> > functions[*], which are a special case of "inline member functions",
>> which
>> > are a special case of "inline functions". Inline functions are nice
>> > because they must be defined in all TUs that use them, and because it'=
s
>> > undefined behavior to give them different definitions in different TUs=
..
>> Do
>> > inline functions therefore successfully dodge all the above objections=
?
>> >
>> > What happens if we broaden the scope of automatically deduced
>> > noexcept-specifications from "defaulted members" to "all inline
>> functions,
>> > and also all lambdas"?
>>
>> That might be nice, but I'd say it's insufficient since it will still
>> require
>> repetition for non-inline functions. If we want to fix those, then we ne=
ed
>> noexcept(auto), which in turn means we don't have to change the rules fo=
r
>> inlines.
>>
>
> If noexcept(auto) exists, then the rule for inline functions is "Always
> type the magic 14 characters noexcept(auto) after the closing parenthesis
> of an inline function declarator. If you forget to do this, your code wil=
l
> be silently pessimized by the compiler." I'm arguing that this is a dumb
> hoop to jump through, and that the proper thing for the language to do is
> simply *assume that the magic 14 characters are there*, without forcing
> the user to type them out.
>
>
>> As for lambdas, I agree, since you can't really add the noexcept there.
>
>
> There actually is a syntax for adding noexcept-specifications to lambdas
> already: you simply add it in the natural place.
>
> // The following lambda invariably returns 42... but not only that,
> // it manages to do it without throwing any exceptions!
> // This surprising behavior requires special syntax.
> auto lambda =3D [](int) noexcept { return 42; };
>
> =E2=80=93Arthur
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c3c1b80c304d0513200f08
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Two comments:<br><br>Currently the 'noexcept' is *=
not* really deduced, but assumed in a couple of places. AFAIK the compiler =
will *not* look into the body of the function for a copy-constructor/destru=
ctor.=C2=A0 In the case of the copy-constructor, since it is the compiler g=
enerating the code, you can consider that it kind of looks into the body.=
=C2=A0 In the case of destructors, though, the 'noexcept' specifica=
tion is injected based on the member's destructor declarations without =
looking at the body:<br><br>struct U {};<br>struct T {<br>=C2=A0 =C2=A0U u;=
<br>=C2=A0 =C2=A0~T() { throw 1; } // compiler assumes ~T() noexcept { thro=
w 1; }<br>};<br><br>I don't think that you want the compiler to inject =
those "magic 14 characters". There might be quite a few of cases =
where the compiler will get those wrong. For example:<br><br>void reset_ele=
ment(std::vector<int> & v, size_t index) {<br>=C2=A0 =C2=A0 if (i=
ndex < v.size()) <a href=3D"http://v.at">v.at</a>(index) =3D 0;<br>}<br>=
<br>The compiler sees the call to '<a href=3D"http://v.at">v.at</a>'=
; and would assume the function to be 'noexcept(false)', but it is =
really 'noexcept(true)', it is guaranteed not to throw. While the e=
xample is crappy, it represents a whole family of functions that can call o=
n 'noexcept(false)' functions but for which the code ensures that n=
o exception will be really thrown.<br><br>I am in favor of using 'auto&=
#39; as a short hand for "deduce it for me" (or at the very least=
not against it), but I don't really think that the compiler should be =
injecting noexcept declarations for the programmer implictly. =C2=A0 Those =
"magic 14 characters" are really the user requesting that the com=
piler to do it.<br><br>=C2=A0 =C2=A0 David<br>=C2=A0 =C2=A0=C2=A0</div><div=
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Apr 6, 2015 a=
t 4:35 AM, Arthur O'Dwyer <span dir=3D"ltr"><<a href=3D"mailto:arthu=
r.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@gmail.com</a>></=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=
=3D"">On Sun, Apr 5, 2015 at 8:13 PM, Thiago Macieira <span dir=3D"ltr"><=
;<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.o=
rg</a>></span> wrote:<br></span><div class=3D"gmail_extra"><div class=3D=
"gmail_quote"><span class=3D""><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Sund=
ay 05 April 2015 12:01:44 Arthur O'Dwyer wrote:<br>
> However, the compiler does have a few cases already where it automatic=
ally<br>
> deduces noexcept-specifications: namely, on =3Ddefault'ed member<b=
r>
> functions[*], which are a special case of "inline member function=
s", which<br>
> are a special case of "inline functions".=C2=A0 Inline funct=
ions are nice<br>
> because they must be defined in all TUs that use them, and because it&=
#39;s<br>
> undefined behavior to give them different definitions in different TUs=
.. Do<br>
> inline functions therefore successfully dodge all the above objections=
?<br>
><br>
> What happens if we broaden the scope of automatically deduced<br>
> noexcept-specifications from "defaulted members" to "al=
l inline functions,<br>
> and also all lambdas"?<br>
<br>
</span>That might be nice, but I'd say it's insufficient since it w=
ill still require<br>
repetition for non-inline functions. If we want to fix those, then we need<=
br>
noexcept(auto), which in turn means we don't have to change the rules f=
or<br>
inlines.<br></blockquote><div><br></div></span><div>If noexcept(auto) exist=
s, then the rule for inline functions is "Always type the magic 14 cha=
racters <font face=3D"monospace, monospace">noexcept(auto)</font> after the=
closing parenthesis of an inline function declarator. If you forget to do =
this, your code will be silently pessimized by the compiler." =C2=A0I&=
#39;m arguing that this is a dumb hoop to jump through, and that the proper=
thing for the language to do is simply <i>assume that the magic 14 charact=
ers are there</i>, without forcing the user to type them out.</div><span cl=
ass=3D""><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As for lambdas, I =
agree, since you can't really add the noexcept there.</blockquote><div>=
<br></div></span><div>=C2=A0There actually is a syntax for adding noexcept-=
specifications to lambdas already: you simply add it in the natural place.<=
/div><div><br></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 =
// The following lambda invariably returns 42... but not only that,</font><=
/div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 // it manages t=
o do it without throwing any exceptions!</font></div><div><font face=3D"mon=
ospace, monospace">=C2=A0 =C2=A0 // This surprising behavior requires speci=
al syntax.</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=
=A0 auto lambda =3D [](int) noexcept { return 42; };</font></div><div><br><=
/div></div>=E2=80=93Arthur</div></div><div class=3D"HOEnZb"><div class=3D"h=
5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c3c1b80c304d0513200f08--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 07 Apr 2015 08:01:16 -0700
Raw View
On Tuesday 07 April 2015 11:41:35 David Rodr=C3=ADguez Ibeas wrote:
> void reset_element(std::vector<int> & v, size_t index) {
> if (index < v.size()) v.at(index) =3D 0;
> }
>=20
> The compiler sees the call to 'v.at' and would assume the function to be
> 'noexcept(false)', but it is really 'noexcept(true)', it is guaranteed no=
t
> to throw. While the example is crappy, it represents a whole family of
> functions that can call on 'noexcept(false)' functions but for which the
> code ensures that no exception will be really thrown.
>=20
> I am in favor of using 'auto' as a short hand for "deduce it for me" (or =
at
> the very least not against it), but I don't really think that the compile=
r
> should be injecting noexcept declarations for the programmer implictly.
> Those "magic 14 characters" are really the user requesting that the
> compiler to do it.
In this example, without the magic, the code is noexcept(false). So if the=
=20
compiler deduces as false again, there's no loss.
If you need to tell the compiler otherwise, you still can.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Mon, 13 Apr 2015 03:15:33 -0700 (PDT)
Raw View
------=_Part_131_698756157.1428920133156
Content-Type: multipart/alternative;
boundary="----=_Part_132_1554148903.1428920133156"
------=_Part_132_1554148903.1428920133156
Content-Type: text/plain; charset=UTF-8
On Monday, April 6, 2015 at 2:27:22 AM UTC+2, Marc Mutz wrote:
>
> 1. We use the noexcept operator because it is more convenient than using
> <type_traits>, esp. in the shared C++98/11 codebase that Qt still is,
> where
> every use of the header requires ifdef'ery (whereas noexcept is
> abstracted
> behind a function-like macro that gets centrally redefined to nothing
> if
> noexcept is not supported).
>
What's stopping you from moving to C++11?
IMO a big source of exceptions is new. Wouldn't it make sense to have a
noexcept new?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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_132_1554148903.1428920133156
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, April 6, 2015 at 2:27:22 AM UTC+2, Marc Mutz wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">1. We use the noexcept ope=
rator because it is more convenient than using
<br> <type_traits>, esp. in the shared C++98/11 codebase =
that Qt still is, where
<br> every use of the header requires ifdef'ery (whereas noexce=
pt is abstracted
<br> behind a function-like macro that gets centrally redefined=
to nothing if
<br> noexcept is not supported).
<br></blockquote><div><br></div><div>What's stopping you from moving to C++=
11?</div><div><br></div><div>IMO a big source of exceptions is new. Wouldn'=
t it make sense to have a noexcept new?</div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</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_132_1554148903.1428920133156--
------=_Part_131_698756157.1428920133156--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 13 Apr 2015 08:35:11 -0700
Raw View
On Monday 13 April 2015 03:15:33 Olaf van der Spek wrote:
> On Monday, April 6, 2015 at 2:27:22 AM UTC+2, Marc Mutz wrote:
> > 1. We use the noexcept operator because it is more convenient than using
> > <type_traits>, esp. in the shared C++98/11 codebase that Qt still is,
> > where
> > every use of the header requires ifdef'ery (whereas noexcept is
> > abstracted
> > behind a function-like macro that gets centrally redefined to nothing
> > if
> > noexcept is not supported).
>
> What's stopping you from moving to C++11?
Compiler support. Until someone convinces Microsoft to get a compiler that has
C++11 to support Windows Embedded Compact 7 and 8, we can't do anything about
it. Similarly for QNX 6.5 (compiler based on GCC 4.4).
Note especially that any C++11 feature from the Standard Library are almost
completely forbidden in Qt source code because there's no good way to detect
when they are supported by the compiler / standard library combination.
libstdc++ for example does not have a monotonically-increasing version number
we could rely on.
> IMO a big source of exceptions is new. Wouldn't it make sense to have a
> noexcept new?
I didn't get the question.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.