包扩展用作概念的非包参数的参数

Question

template<typename T>    concept A = true;
template<typename... T> concept B = A<T...>;

Clang and gcc complains 'pack expansion used as argument for non-pack parameter of concept' at the 2nd line. MSVC compiles. Are the code well-formed or not?

---

Here is a more concrete example showing why the question matters. Say we want to define a concept with parameter pack called single_integral_or_all_floating_point . It is true if the pack has single integral type or all floating point types. It is false otherwise.

template<typename... T>
concept single_integral_or_all_floating_point =
    std::is_integral<T...>::value ||
    (... && std::is_floating_point<T>::value);

If sizeof...(T) is not 1 , there is a substitution failure on std::is_integral and the 1st constraint is not satisfied.

Let's say we want to get rid of the old type traits and switch to concepts. Clang and gcc do not compile with a drop-in replacement like below because of 'pack expansion used as argument for non-pack parameter of concept'. MSVC compiles.

template<typename... T>
concept single_integral_or_all_floating_point =
    std::integral<T...> || // error: pack expansion used as argument for non-pack parameter of concept
    (... && std::floating_point<T>);

We have to come up a workaround for clang/gcc.

template<typename... T>
struct only {};

template<typename T>
struct only<T> {
    using type = T;
};

template<typename... T>
concept single_integral_or_all_floating_point =
    std::integral<typename only<T...>::type> ||
    (... && std::floating_point<T>);

So if clang and gcc are correct, it is pretty awkward to use concepts in the similar cases.

Answer 1

The main issue with your first snippet is that concepts must be able to be normalized, and normalization requires a parameter mapping of each template parameter of an atomic constraint. The fact that the prototype parameter of A is not used in its constraint seems to be irrelevant to GCC/Clang; they apparently attempt to create some kind of temporary mapping anyway, which fails since a non-pack cannot map to a pack. Which makes sense IMO, because that would be incompatible in whatever internal system normal forms are expressed in.

Regarding your broader use case, there are certainly more sensible ways to express your constraint, eg explicitly checking sizeof... . You could also use a variable template, whose template-id would be an atomic constraint and thus not prone to the same problem:

template<typename... T>
concept single_integral_or_all_floating_point =
    std::is_integral_v<T...> ||
    (... && std::floating_point<T>);

Demo .

Answer 2

Your code appears to be well-formed

I am able to compile without issue on GCC trunk and Clang trunk (-std=c++20)

It also supports an empty parameter pack without issue. ( test() in the godbolt.)

If this is ill-formed, then GCC, Clang, and MSVC are all wrong, which I am hesitant to believe; The compiler issue you are encountering is likely poor support for concepts in whichever bundled GCC and Clang version you have installed.

See: https://godbolt.org/z/frcdc7PTY