[dcl.dcl] Replace 'could' and 'might' #4362
Conversation
source/declarations.tex
Outdated
| @@ -927,7 +927,7 @@ | |||
| For a constexpr function or constexpr constructor | |||
| that is neither defaulted nor a template, | |||
| if no argument values exist such that | |||
| an invocation of the function or constructor could be an evaluated subexpression of a core | |||
| an invocation of the function or constructor would be an evaluated subexpression of a core | |||
There was a problem hiding this comment.
I find this very hard to understand with "would" here. I think part of the problem is that the original wording is unclear. What we mean is:
"For a constexpr function or constexpr constructor that is neither defaulted nor a template, if there does not exist a valid core constant expression whose evaluation would evaluate an invocation of the function or constructor, and, for a constructor, there does not exist a valid declaration of a constant-initialized variable whose evaluation would evaluate an invocation of the function or constructor."
That is, this is really "for all possible core constant expressions", not "for all possible argument values".
I think we can simplify and clarify that:
"A constexpr function that is neither defaulted nor a template is ill-formed, no diagnostic required, if it is not possible for an evaluation of an invocation of the function to be performed while evaluating any valid manifestly constant-evaluated expression."
source/declarations.tex
Outdated
| char c1 = x; // OK, though it might narrow (in this case, it does narrow) | ||
| char c2{x}; // error: might narrow | ||
| char c1 = x; // OK, though it can narrow (in this case, it does narrow) | ||
| char c2{x}; // error: can narrow |
There was a problem hiding this comment.
I don't think "can" makes sense here, because the code is ill-formed, so it can't do anything. How about "error: potentially narrows"?
source/declarations.tex
Outdated
| @@ -5878,7 +5878,7 @@ | |||
| signed int si1 = | |||
| { (unsigned int)-1 }; // error: narrows | |||
| int ii = {2.0}; // error: narrows | |||
| float f1 { x }; // error: might narrow | |||
| float f1 { x }; // error: can narrow | |||
source/declarations.tex
Outdated
| @@ -8793,7 +8793,7 @@ | |||
| Function \tcode{g}'s second parameter has a \tcode{carries_dependency} attribute, | |||
| but its first parameter does not. Therefore, function \tcode{h}'s first call to | |||
| \tcode{g} carries a dependency into \tcode{g}, but its second call does not. The | |||
| implementation might need to insert a fence prior to the second call to | |||
| implementation can be required to insert a fence prior to the second call to | |||
There was a problem hiding this comment.
"can be required" sounds like the programmer can cause the implementation to be required to do this, which isn't really right. This solves that problem but I'm still not overjoyed by it:
| implementation can be required to insert a fence prior to the second call to | |
| implementation can need to insert a fence prior to the second call to |
There was a problem hiding this comment.
"can need"?
ugh
"It is possible that the implementation needs to insert a fence..."
as directed by ISO/CS.
|
applied, squashed, and force-pushed |
as directed by ISO/CS.
Partially addresses #4319