P0619R4 Review of deprecated facilities #2210
Conversation
zygoloid
force-pushed
the
motions-2018-06-lwg-27
branch
2 times, most recently
from
e45db95
to
91112c9
Compare
|
@tkoeppe Can you review this please, particularly the synopses for the C headers left behind by the removal of the five C++ headers? |
zygoloid
force-pushed
the
motions-2018-06-lwg-27
branch
from
91112c9
to
5f002c2
Compare
|
Looking. |
|
The initial commit message is missing the revision number of the paper. Are you going to squash some of the amendment commits? |
|
Re [diff.cpp17.library]p2: I don't want to rain on anyone's parade, but if my program depends on Perhaps a slightly longer migration strategy could be advised: |
| Valid \CppIII{} code that replaces the global replaceable \tcode{operator new} | ||
| is ill-formed in this International Standard, | ||
| because the exception specification of \tcode{throw(std::bad_alloc)} | ||
| was removed. |
There was a problem hiding this comment.
Add a cross-reference to the Annex C entry describing the removal?
There was a problem hiding this comment.
This is the Annex C entry describing the removal.
There was a problem hiding this comment.
Oh, sorry, I somehow thought this should refer to the removal of dynamic exception specifications or of throw(), but you're right, that's not what matters here.
| \tcode{<ciso646>}, | ||
| \tcode{<cstdalign>}, or | ||
| \tcode{<cstdbool>} | ||
| can simply be removed. |
There was a problem hiding this comment.
(See comment on the main thread regarding the macros in the last two headers.)
There was a problem hiding this comment.
Technically, any code using the __* macros is ill-formed (no diagnostic required) by [lex.name]p3.
There was a problem hiding this comment.
Errr... unless we specify a name, right? We do specify things like __func__, which are not UB to use.
There was a problem hiding this comment.
some identifiers are reserved for use by C++ implementations and shall not be used otherwise; no diagnostic is required. [...] Each identifier that contains a double underscore
__or begins with an underscore followed by an uppercase letter is reserved to the implementation for any use.
... sure suggests to me that using __func__ is ill-formed, no diagnostic required. Sounds like we need a core issue.
There was a problem hiding this comment.
And what about __cplusplus and SD-6 feature test macros?
There was a problem hiding this comment.
@zygoloid: That cannot be the right reading. Not only do we have many macros with specified meaning, but also consider that C, which has similar wording, regularly introduces new keywords that use reserved names. It must be possible for the standard to specify names like that.
source/future.tex
Outdated
| \tcode{<stdint.h>} & | ||
| \tcode{<uchar.h>} & \\ | ||
| \pnum | ||
| The header \tcode{<ctgmath>} |
There was a problem hiding this comment.
Wait, this is weird -- why are we talking about <ctgmath> in the synopsis of <tgmath.h>?
There was a problem hiding this comment.
Oops, missed this one. Fixed.
|
To do once approved: merge fixup commit into previous commit, reword first commit message to include paper revision number. @tkoeppe I wasn't planning on flattening any of the commits here other than the one named 'fixup'. Let me know if there are more that you think should be folded together. |
|
@zygoloid: OK, I think it's fine to keep the commits. There are lots, but I suppose that's reflective of the challenging nature of this motion. |
zygoloid
changed the title
emphasize relationship between it and the converting constructors.
longer a possible change. It is not possible to write a global replacement operator new or operator delete in C++20 with code that is also valid C++03, because a) operator new must be declared 'throw(std::bad_alloc)' in C++03 and must be declared with no exception specification in C++11 onwards, and b) operator delete must be declared 'throw()' in C++03 and must be declared 'noexcept' in C++20 onwards. Therefore there is no code that is valid in C++03 and C++20 and changes meaning due to the change identified in this section. Instead, expand [diff.cpp03.language.support]p2 to explain that the affected programs are simply not valid in C++20.
code that is non-throwing in both C++20 and C++03.
"This was retained for one additional C++ standard to ease transition" is not a rationale for removing the feature now.
removal of <ccomplex> and <ctgmath>.
<cstdalign>, <cstdbool>, and <ctgmath>. Instead, repurpose these to be synopses for <complex.h>, <stdalign.h>, <stdbool.h>, and <tgmath.h>, and move them into [depr.c.headers]. Also introduce a synopsis for <iso646.h>. This avoids three of these five headers being specified as equivalent to a non-existent <cfoo> header, and the other two missing a synopsis.
zygoloid
force-pushed
the
motions-2018-06-lwg-27
branch
from
a27333d
to
16b35d6
Compare
Fixes #2144