Paragraph 10.1.5 says that a program is ill-formed, no diagnostic required, if a function is declared constexpr but no set of arguments exist that make it evaluable at compile-time.
What's the rationale behind this?
Since it's not feasible for the compiler to check that precondition, how can it benefit from this rule?
However, the only alternative I would see is to declare such programs well-formed (and so barely enforcing constexpr at all, making it rather a kind of hint to the compiler and reader). But wouldn't this still be preferable to having more UB in C++, with all its undesirable consequences? Maybe constexpr is indeed going in the wrong direction...
Related
To the best of my knowledge, the inline keyword in c++ can be traced back to old compilers (then known as "optimizing compilers") not being able to optimize as well as modern ones, so marking a function as inline told the compiler that this should be inlined, and as a side effect prevented ODR issues. As compilers got better, someone realized that the compilers can do a much better job of optimizing than the programmer, and so the inline requirement of the compiler became more of a 'hint' that most (all?) modern compilers ignore.
Enter C++11 and subsequent versions. constexpr seems to me to be in a similar situation, at least for some of its uses, specifically functions and variables. As I understand it, it tells the compiler that a certain function may be evaluated at compile time. But that is something the compiler should be able to figure out on its own. Is this feature also going to become a 'hint' once compilers get better at optimizing?
Note: I am not asking about other uses of constexpr, such as with if statements. I understand those are needed.
As I understand it, it tells the compiler that a certain function may be evaluated at compile time.
Not "may", but "can". The constexpr keyword does not tell the compiler what it is allowed to do (it may evaluate anything it wants at compile time). Rather the keyword tells the compiler a desired quality of the variable or function, specifically that it can be used in constant expressions. The compiler will complain (error or warning) if the program fails to live up to that desire. You get a more relevant error message than you would have gotten otherwise – the compiler can tell you why your entity does not qualify for compile-time evaluation since it knows that your intent was for the entity to be a compile-time constant.
For example, if you defined const unsigned a, it is an error to use std::array<int, a> if the value of a is not known at compile time. The error might be in the initialization of a, or it might be that the template parameter was supposed to be b instead of a. The compiler would have to report the error as "a is not a constant expression" and let the programmer investigate. On the other hand, if a was declared constexpr, the compiler would instead complain about the reason the value of a is not known at compile time, leading to less time debugging.
Without constexpr, the following code produces a possibly weak error message.
{
const unsigned a = foo();
const unsigned b = 42;
std::array<int, a> stuff; // Error: 'a' is not a constant expression.
// ...
}
After declaring both a and foo() to be constexpr, the error disappears. Why? Because last week when you wrote foo(), the compiler was told that the function had to be usable in constant expressions. As a result, the compiler pointed out why foo() could not be evaluated at compile time, and you fixed the bug right away. That was last week, while the implementation of foo() was still fresh in your mind. Not this week, after doing a dozen other things, including the hour spent arguing with the compiler because you believed a had to be a constant expression since it was initialized with foo().
An ideal compiler could maybe figure out which functions are actually constexprand in that sense one could view that keyword as a hint to the compiler.
But I think it makes more sense to compare const and constexpr in terms of what they tell the compiler and the human reader. An ideal compiler could also figure out, which variables and member functions should be const. As you probably know, there are other good reasons to mark everything possible const (compiler finds bugs for you, much easier to read, helps the compiler in optimization).
The same is true for constexpr. If you declare a variable constexpr, that cannot be computed at compile time, you get an error, you have documented that the variable can be computed at compile time and it helps the compiler in optimization.
Also note that ignoring constexpr does not make sense for runtime performance, which is not true for inline.
But that is something the compiler should be able to figure out on its
own. Is this feature also going to become a 'hint' once compilers get
better at optimizing?
constexpr is not merely an optimization - without
it, the compiler is not allowed to use a function in contexts where a constant expression is required, e.g. in non-type template arguments.
But I am sure you already know that much. The real question is: should a future C++ standard allow using a function in constant expression context even though it is not explicitly marked constexpr - in case if it satisfies contexpr requirements?
No, I think it is the opposite direction from C++ development. Consider C++20 concept. One of its major goals is to improve error messages: instead of going through nested template definitions, the compiler knows early that the template argument does not meet a requirement. Keyword constexpr serves the same goal: the compiler, instead of going through a function call tree and finding that a function deep in the call stack cannot be evaluated at compile-time, reports the error early.
To the best of my knowledge, the inline keyword in c++ can be traced back to old compilers (then known as "optimizing compilers") not being able to optimize as well as modern ones, so marking a function as inline told the compiler that this should be inlined, and as a side effect prevented ODR issues. As compilers got better, someone realized that the compilers can do a much better job of optimizing than the programmer, and so the inline requirement of the compiler became more of a 'hint' that most (all?) modern compilers ignore.
Enter C++11 and subsequent versions. constexpr seems to me to be in a similar situation, at least for some of its uses, specifically functions and variables. As I understand it, it tells the compiler that a certain function may be evaluated at compile time. But that is something the compiler should be able to figure out on its own. Is this feature also going to become a 'hint' once compilers get better at optimizing?
Note: I am not asking about other uses of constexpr, such as with if statements. I understand those are needed.
As I understand it, it tells the compiler that a certain function may be evaluated at compile time.
Not "may", but "can". The constexpr keyword does not tell the compiler what it is allowed to do (it may evaluate anything it wants at compile time). Rather the keyword tells the compiler a desired quality of the variable or function, specifically that it can be used in constant expressions. The compiler will complain (error or warning) if the program fails to live up to that desire. You get a more relevant error message than you would have gotten otherwise – the compiler can tell you why your entity does not qualify for compile-time evaluation since it knows that your intent was for the entity to be a compile-time constant.
For example, if you defined const unsigned a, it is an error to use std::array<int, a> if the value of a is not known at compile time. The error might be in the initialization of a, or it might be that the template parameter was supposed to be b instead of a. The compiler would have to report the error as "a is not a constant expression" and let the programmer investigate. On the other hand, if a was declared constexpr, the compiler would instead complain about the reason the value of a is not known at compile time, leading to less time debugging.
Without constexpr, the following code produces a possibly weak error message.
{
const unsigned a = foo();
const unsigned b = 42;
std::array<int, a> stuff; // Error: 'a' is not a constant expression.
// ...
}
After declaring both a and foo() to be constexpr, the error disappears. Why? Because last week when you wrote foo(), the compiler was told that the function had to be usable in constant expressions. As a result, the compiler pointed out why foo() could not be evaluated at compile time, and you fixed the bug right away. That was last week, while the implementation of foo() was still fresh in your mind. Not this week, after doing a dozen other things, including the hour spent arguing with the compiler because you believed a had to be a constant expression since it was initialized with foo().
An ideal compiler could maybe figure out which functions are actually constexprand in that sense one could view that keyword as a hint to the compiler.
But I think it makes more sense to compare const and constexpr in terms of what they tell the compiler and the human reader. An ideal compiler could also figure out, which variables and member functions should be const. As you probably know, there are other good reasons to mark everything possible const (compiler finds bugs for you, much easier to read, helps the compiler in optimization).
The same is true for constexpr. If you declare a variable constexpr, that cannot be computed at compile time, you get an error, you have documented that the variable can be computed at compile time and it helps the compiler in optimization.
Also note that ignoring constexpr does not make sense for runtime performance, which is not true for inline.
But that is something the compiler should be able to figure out on its
own. Is this feature also going to become a 'hint' once compilers get
better at optimizing?
constexpr is not merely an optimization - without
it, the compiler is not allowed to use a function in contexts where a constant expression is required, e.g. in non-type template arguments.
But I am sure you already know that much. The real question is: should a future C++ standard allow using a function in constant expression context even though it is not explicitly marked constexpr - in case if it satisfies contexpr requirements?
No, I think it is the opposite direction from C++ development. Consider C++20 concept. One of its major goals is to improve error messages: instead of going through nested template definitions, the compiler knows early that the template argument does not meet a requirement. Keyword constexpr serves the same goal: the compiler, instead of going through a function call tree and finding that a function deep in the call stack cannot be evaluated at compile-time, reports the error early.
The [[nodiscard]] attribute introduced in C++17 standard, and in case of the
... potentially-evaluated discarded-value expression,..., implementations are encouraged to issue a warning in such cases.
Source: n4659, C++17 final working draft.
Similar phrasing is used on cppreference, that in case of "violation":
the compiler is encouraged to issue a warning.
Why is the word encouraged used instead of required? Are there situations (except, the explicit cast to void) when a compiler is better off not issuing a warning? What is the reason behind softening the standard language in the particular case of relatively safe requirement to issue a warning no matter what (again, except, say, explicit cast to void)?
The C++ standard specifies the behavior of a valid C++ program. In so doing, it also defines what "valid C++ program" means.
Diagnostics are only required for code which is ill-formed, code which is syntactically or semantically incorrect (and even then, there are some ill-formed circumstances that don't require diagnostics). Either the code is well-formed, or it is ill-formed and (usually) a diagnostic is displayed.
So the very idea of a "warning" is just not something the C++ standard recognizes, or is meant to recognize. Notice that even the "implementations are encouraged to issue a warning" statement is in a non-normative notation, rather than a legitimate specification of behavior.
What is the rationale for [dcl.constexpr]p5 (http://eel.is/c++draft/dcl.constexpr#5)?
For a non-template, non-defaulted constexpr function or a
non-template, non-defaulted, non-inheriting constexpr constructor, if
no argument values exist such that an invocation of the function or
constructor could be an evaluated subexpression of a core constant
expression ([expr.const]), or, for a constructor, a constant
initializer for some object ([basic.start.init]), the program is
ill-formed; no diagnostic required.
If a program violated this rule, declaring the offending function constexpr was useless. So what? Isn't it better to accept useless uses of the decl-specifier constexpr instead of triggering undefined behaviour (by no diagnostics required)? In addition to the problem with undefined behaviour we also have the additional complexity of having the rule [dcl.constexpr]p5 in the standard.
An implementation can still provide useful diagnostic messages in some cases that it is able to detect (warnings by convention). Just like in the following case:
int main() { 0; }
The expression in main there is well-formed but useless. Some compilers issue a diagnostic message anyway (and they are allowed to) in the form of a warning.
I understand that [dcl.constexpr]p5 cannot require diagnostics, so i'm not asking about that. I'm just asking about why this rule is even in the standard.
The reason it's ill-formed is because making it ill-formed allows implementations to reject constexpr function definitions that cannot possibly form constant expressions. Rejecting them early means getting more useful diagnostics.
The reason no diagnostic is required is because it may be unrealistic for an implementation to determine that for each and every possible combination of arguments, the result is not a constant expression.
The fact that ill-formed, no diagnostic required, effectively means the same thing as making the behaviour undefined seems to me as if it's unfortunate, but merely picked for lack of a better option. I'd be highly surprised if the intent would actually be to allow any arbitrary run-time behaviour, but there is no concept of "may be diagnosed as an error, but if not, must behave as specified" for any language feature in C++.
This question already has answers here:
Why do we need to mark functions as constexpr?
(4 answers)
Closed 2 years ago.
As far as I understand it, constexpr can be seen as a hint to the compiler to check whether given expressions can be evaluated at compile-time and do so if possible.
I know that it also imposes some restriction on the function or initialization declared as constexpr but the final goal is compile-time evaluation, isn't it?
So my question is, why can't we leave that at the compiler? It is obviously capable of checking the pre-conditions, so why doesn't it do for each expression and evaluate at compile-time where possible?
I have two ideas on why this might be the case but I am not yet convinced that they hit the point:
a) It might take too long during compile-time.
b) Since my code can use constexpr functions in locations where normale functions would not be allowed the specifier is also kind of part of the declaration. If the compiler did everything by itself, one could use a function in a C-array definition with one version of the function but with the next version there might be a compiler-error, because the pre-conditions for compile-time evaluation are no more satisfied.
constexpr is not a "hint" to the compiler about anything; constexpr is a requirement. It doesn't require that an expression actually be executed at compile time; it requires that it could.
What constexpr does (for functions) is restrict what you're allowed to put into function definition, so that the compiler can easily execute that code at compile time where possible. It's a contract between you the programmer and the compiler. If your function violates the contract, the compiler will error immediately.
Once the contract is established, you are now able to use these constexpr functions in places where the language requires a compile time constant expression. The compiler can then check the elements of a constant expression to see that all function calls in the expression call constexpr functions; if they don't, again a compiler error results.
Your attempt to make this implicit would result in two problems. First, without an explicit contract as defined by the language, how would I know what I can and cannot do in a constexpr function? How do I know what will make a function not constexpr?
And second, without the contract being in the compiler, via a declaration of my intent to make the function constexpr, how would the compiler be able to verify that my function conforms to that contract? It couldn't; it would have to wait until I use it in a constant expression before I find that it isn't actually a proper constexpr function.
Contracts are best stated explicitly and up-front.
constexpr can be seen as a hint to the compiler to check whether given expressions can be evaluated at compile-time and do so if possible
No, see below
the final goal is compile-time evaluation
No, see below.
so why doesn't it do for each expression and evaluate at compile-time where possible?
Optimizers do things like that, as allowed under the as-if rule.
constexpr is not used to make things faster, it is used to allow usage of the result in context where a runtime-variable expression is illegal.
This is only my evaluation, but I believe your (b) reason is correct (that it forms part of the interface that the compiler can enforce). The interface requirement serves both for the writer of the code and the client of the code.
The writer may intend something to be usable in a compile-time context, but not actually use it in this way. If the writer violates the rules for constexpr, they might not find out until after publication when clients who try to use it constexpr fail. Or, more realistically, the library might use the code in a constexpr sense in version 1, refactor this usage out in version 2, and break constexpr compatibility in version 3 without realizing it. By checking constexpr-compliance, the breakage in version 3 will be caught before deployment.
The interface for the client is more obvious --- an inline function won't silently become constexpr-required because it happened to work and someone used that way.
I don't believe your (a) reason (that it could take too long for the compiler) is applicable because (1) the compiler has to check much of the constexpr constraints anyway when the code is marked, (2) without the annotation, the compiler would only have to do the checking when used in a constexpr way (so most functions wouldn't have to be checked), and (3) IIUC the D programming language actually does allow functions to be compile-time evaluated if they meet requirements without any declaration assistance, so apparently it can be done.
I think I remember watching an early talk by Bjarne Stroustrup where he mentioned that programmers wanted fine grained control on this "dangerous" feature, from which I understand that they don't want things "accidentally" executed at compile time without them knowing. (Even if that sound like a good thing.)
There can be many reasons for that, but the only valid one is ultimatelly compilation speed I think ( (a) in your list ).
It would be too much burden on the compiler to determine for every function if it could be computed at compile time.
This argument is weaker as compilation times in general go down.
Like many other features of C++ what end up happening is that we end up with the "wrong defaults".
So you have to tell when you want constexpr instead of when you don't want constexpr (runtimeexpr); you have to tell when you want const intead of where you want mutable, etc.
Admitedly, you can imagine functions that take an absurd amount of time to run at compile time and that cannot be amortized (with other kind of machine resources) at runtime.
(I am not aware that "time-out" can be a criterion in a compiler for constexpr, but it could be so.)
Or it could be that one is compiling in a system that is always expected to finish compilation in a finite time but an unbounded runtime is admissible (or debuggable).
I know that this question is old, but time has illuminated that it actually makes sense to have constexpr as default:
In C++17, for example, you can declare a lambda constexpr but more importantly they are constexpr by default if they can be so.
https://learn.microsoft.com/en-us/cpp/cpp/lambda-expressions-constexpr
Note that lambda has all the "right" (opposite) defaults, members (captures) are const by default, arguments are templates by default auto, and now these functions are constexpr by default.