In concept definitions, are substitution failures allowed outside of a requires expression?

Question

Consider this code:

#include <type_traits>                                           
#include <iostream>

template <class T> concept bool C1 = std::is_same<T, int>::value; 

template <class T> concept bool C2 =  
    C1<decltype(std::declval<T>() + std::declval<T>())>; 

struct A {};                   

int main() { 
  std::cout << C2<int>; 
  std::cout << C2<A>;                                                 
  return 0;                                                           
}

GCC compiles it fine and prints 10.

But §14.10.1.2 Predicate constraints [temp.constr.pred] of N4553 says

A predicate constraint is a constraint that evaluates a constant expression E (5.19).

and then

After substitution, E shall have type bool.

Since C1<decltype(std::declval<A>() + std::declval<A>())> is a substitution failure, rather than having type bool, does that mean the program should be ill-formed?

Answer 1

The Concepts TS only defines behavior for determining the satisfaction of the associated constraints of a declaration; there's no provision for referring to a concept name outside of associated constraints. So strictly speaking, std::cout << C<int> and std::cout << C<A> are both ill-formed.

EWG decided in Kona to allow this as a new feature:

Straw poll: SF | F | N | A | SA

• Should we allow evaluation of concepts anywhere? 8 | 6 | 2 | 0 | 0
• Should we allow the presence and evaluation of a requires-expression in any expression? 1 | 2 | 10 | 3 | 1
  • Note that without the first poll, the second poll would change.

but there is no wording yet to specify its behavior.

GCC currently allows concepts-as-expressions as an (I believe undocumented) extension. I find it quite likely that this feature will be specified so that C<X...> evaluates to false when substitution of X... into the initializer of C fails to produce a valid expression, and otherwise has the value of the expression so obtained. That seems like the sane way to do this, and is consistent with the implementation in GCC.