[diff] Prefer ill-formed to not compile #7296
Conversation
Addresses cplusplus#6901 that was opened following LWG wording review at the Tokyo 2024 meeting. Rather than say code may not compiler, prefer to say that code may become ill-formed. Applied the recommended change throughout the whole of Annex C.
| @@ -229,7 +229,7 @@ | |||
| The \tcode{shrink_to_fit} member function can be used instead. | |||
| \effect | |||
| A valid \CppXXIII{} program that calls \tcode{reserve()} | |||
| on a \tcode{basic_string} object may fail to compile. | |||
| on a \tcode{basic_string} object may become ill-formed. | |||
There was a problem hiding this comment.
Is it suitable to use "may" here (and possibly elsewhere)? Doesn't the program definitely become ill-formed?
There was a problem hiding this comment.
Yes, good point. It might fail to compile, but it might still be accepted by a given implementation as an extension. However, it's definitely ill-formed ... but might still compile with a given implementation.
I don't think this change is as simple as replacing "fail to compile" with "become ill-formed". The existing wording is a bit loose but that reflects the reality of what happens in practice.
There was a problem hiding this comment.
I think the cases that "might fail to compile or might change behaviour" are fine to change this way. The ones that can't change behaviour just become ill-formed, no there's no "may". (Implementations are still permitted to accept ill-formed programs with a diagnostic if they want to.)
Addresses #6901 that was opened following LWG wording review at the Tokyo 2024 meeting. Rather than say code may not compiler, prefer to say that code may become ill-formed.
Applied the recommended change throughout the whole of Annex C.