Should validity of noexcept definitions be checked earlier?
Opened this issue · 1 comments
lewissbaker commented
In cases where the declaration is declared unconditionally noexcept(true)
should it be ill-formed to declare a generic default implementation that is unconditionally noexcept(false)
?
Should this example at least demonstrate that declaring a non-generic override/default that has mismatching noexcept should be diagnosed as ill-formed at point of declaration?
atomgalaxy commented
Yeah, probably. I'll fix it.
…On Fri, Feb 18, 2022 at 7:54 AM Lewis Baker ***@***.***> wrote:
https://github.com/atomgalaxy/wg21-cust-points/blob/cb4c9d1963adbaad157a95133afe3d14689440e9/tests/002_noexcept.cpp#L5
In cases where the declaration is declared unconditionally noexcept(true)
should it be ill-formed to declare a generic default implementation that is
unconditionally noexcept(false)?
Should this example at least demonstrate that declaring a non-generic
override/default that has mismatching noexcept should be diagnosed as
ill-formed at point of declaration?
—
Reply to this email directly, view it on GitHub
<#22>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAA5R5LKFF6RGGORC6B64N3U3X3LRANCNFSM5OXCTH5A>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>