13

According to this answer apparently there is no good reason why structured bindings are not allowed to be constexpr, yet the standard still forbids it. In this case, however, shouldn't the use of the structured bindings inside the constexpr function also be prohibited? Consider a simple snippet:

#include <utility>

constexpr int foo(std::pair<int, int> p) {
    auto [a, b] = p;
    return a;
}

int main() {
    constexpr int a = foo({1, 2});
    static_assert(a == 1);
}

Both gcc and clang does not cause trouble compiling the code. Is the code ill-formed either way or is this one actually allowed?

W.F.
  • 13,888
  • 2
  • 34
  • 81

2 Answers2

6

In the case of function declaration, the constexpr specifier is an assertion made to the compiler that the function being declared may be evaluated in a constant expression, i.e. an expression that can be evaluated at compile-time. Nevertheless the object initialization inside a declaration does not need to have constexpr inside its declaration specifier to be a constant expression.

Shorter: constexpr function may imply constant expression but constant expression initialization does not need that the associated declaration has a constexpr specifier.

You can check this in the C++ standard [dcl.constexpr]:

A call to a constexpr function produces the same result as a call to an equivalent non-constexpr function in all respects except that

— a call to a constexpr function can appear in a constant expression[...]

This is the evaluation of an expression that determines if an expression is a constant expression [expr.const]:

An expression e is a core constant expression unless the evaluation of e [...] would evaluate one of the following expression[...]

A declaration is not an expression, so an initialization of an object being declared is a constant expression irrespective of the presence or not of a constexpr specifier in the declaration.

Finally, in [dcl.constexpr], it is specified that a constexpr function must be such that there exist parameters for which its body can be evaluated as a constant expression:

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 constant expression (8.20), or, for a constructor, a constant initializer for some object (6.6.2), the program is ill-formed, no diagnostic required.

When you declare constexpr int a the compiler expects a to be inialized by a constant expression and the expression foo({1,2}) is a constant expression, so your code is well formed.

PS: Nevertheless, declaration specifiers (static, thread_local=>static) in the the declaration of function local variable implies that the function cannot be declared constexpr.

Oliv
  • 17,610
  • 1
  • 29
  • 72
  • Thanks! I hate inconsequences maybe this is why I was trapped in the thought that the case code is ill-formed, but making it ill-formed the inconsequences would be even bigger. – W.F. Sep 17 '17 at 08:39
  • oh I didn't mean your answer is inconsequent, just the standard in this matter. Think of it - when you don't want to let someone in through the door why on earth invite him through the window? – W.F. Sep 17 '17 at 12:50
  • @W.F. Oh, this is just when I read my answer few hours after having posted it, I was wondering myself how this could be an answer to your question! Actualy it took me sometime to feel the blank so I thought I need to post it. When I have read your comment I thought about reusing your vocabulary, but my english, out of technical context, is poor. I have certainly not understood you and I have probably not expressed what I wanted in the previous comment. I did not want to offend you. – Oliv Sep 17 '17 at 13:04
1

There are several requirements that a constexpr function must meet. There are some requirements for the body of a constexpr function, and the shown code does not appear to violate any of them. The key point is that there is no requirement that every statement in a function must be a constexpr. The only interesting requirement in question here, is this one:

there exists at least one set of argument values such that an invocation of the function could be an evaluated subexpression of a core constant expression (for constructors, use in a constant initializer is sufficient) (since C++14). No diagnostic is required for a violation of this bullet.

Note the last sentence. The compiler may, but is not required to, throw a red flag.

The key requirement is merely that there is some assortment of parameter values to the function that results in a constant result from the function (and the function body meets the listed requirements). For example, the function might use a structured binding conditionally; but for some set of parameter values do something else, producing a constant result. This would tick this checkbox for a constexpr function.

But, despite the sophistication of modern C++ compilers, they may not necessarily be capable of reaching this determination in every possible instance, so, in practice, it would be hard to enforce such a requirement, hence the compilers are permitted to just take this for granted.

Sam Varshavchik
  • 114,536
  • 5
  • 94
  • 148
  • So you mean that although the code is ill-formed the fact that no diagnostic is required the compiler may accept it? – W.F. Sep 16 '17 at 13:42
  • 6
    Since `foo({1, 2})` _is_ an invocation of the function that could be (and is) an evaluated subexpression of a core constant expression, I don't think this bullet is violated and so whether or not a diagnostic would be required for a violation of this bullet is moot. – Oktalist Sep 16 '17 at 13:43