[PATCH] C++11: noexcept should check whether the expression is a constant expression

[Richard Smith]

On Tue, Mar 26, 2013 at 4:04 AM, Ismail Pazarbasi <
ismail.pazarbasi at gmail.com> wrote:

> On Tue, Mar 26, 2013 at 1:03 AM, Richard Smith <richard at metafoo.co.uk>
> wrote:
> > On Mon, Mar 25, 2013 at 4:21 PM, Ismail Pazarbasi
> > <ismail.pazarbasi at gmail.com> wrote:
> >>
> >>
> >>   I have read the resolution for the issue 1351, and I was curious about
> >> aligning this with the removal of dynamic exception specifications as
> well.
> >
> >
> > I've started working on implementing core issue 1351. We discussed this
> > issue in a CWG teleconference today, and there are some tweaks to the
> > wording coming...
> >
> >> Could you please confirm whether I understood this part correctly; given
> >> the example in issue 1351, in the move constructor declaration,
> "noexcept"
> >> is represented with an empty set:
> >>   `B(B&&, int = (throw Y(), 0)) throw(Y) noexcept;`
> >
> >
> > This is ill-formed. A function declaration can only have one
> > exception-specification.
> Reading the issue 1351 didn't give a hint to me either, and I was
> confused. That's why I have asked whether I *imagined it* correct :)
>
> >
> >>
> >>   The union of set of potential exceptions is: {Y} U {Y} U {} = {Y};
> >>   Likewise, if it was:
> >>   `B(B&&, int = (throw Y(), 0)) throw(Z) noexcept;`
> >>   The union of set of potential exceptions: {Y} U {Z} U {} = {Y, Z}
> >>
> >>   Could you please explain the purpose of having throw(E) and noexcept
> on
> >> the same declarator? I understand throw(E) and noexcept(false) would be
> >> compatible.
> >
> >
> > throw(E) and noexcept(false) are not compatible exception-specifications;
> > see 15.4/3.
> I have read entire except.spec yesterday. I was drifted to the "set"
> too much, and thinking of exception specification as merely a set,
> completely ignoring the meaning of noexcept. Sorry for the noise!
>
> Since you are doing the whole implementation shall we drop this review
> then?
>

I think that makes sense.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130326/7ebf997f/attachment.html>