Defining Concepts with Requires Expressions

The following concept Addable is a simple requirement:

template<typename T>
concept Addable = requires (T a, T b) {
    a + b;
};

The concept Addable requires that the addition a + b of two values of the same type T is possible.

 

Before I continue with type requirements, I want to add. This concept has only one purpose: exemplifying simple requirements. Writing a concept that just checks a type for its support of the + operator is bad. A concept should model an idea, such as Arithmetic.

In a type requirement, you have to use the keyword typename together with a type name.

template<typename T>
concept TypeRequirement = requires {
    typename T::value_type;
    typename Other<T>;    
};

The concept TypeRequirement requires that type T has a nested member value_type, and that the class template Other can be instantiated with T.

Let's try this out:

#include <iostream>
#include <vector>

template <typename>
struct Other;  

template <>
struct Other<std::vector<int>> {};

template<typename T>
concept TypeRequirement = requires {
    typename T::value_type;             // (2)
    typename Other<T>;                  // (3)
};                         

int main() {

    TypeRequirement auto myVec= std::vector<int>{1, 2, 3};  // (1)

}

The expression TypeRequirement auto myVec = std::vector<int>{1, 2, 3} (line 1) is valid. A std::vector has an inner member value_type (line 2) and the class template Other (line 2) can be instantiated with std::vector<int> (line 3).

 

The concept TypeRequirement in combination with auto in line 1 is called a constrained placeholder. Read more about constrained and unconstrained placeholders in my previous post "C++20: Concepts, the Placeholder Syntax".

A compound requirement has the form

{expression} noexcept(optional) return-type-requirement(optional);    

In addition to a simple requirement, a compound requirement can have a noexcept specifier and a requirement on its return type. You essentially express with the noexcept specifier that this expression does not throw an exception, and if it throw, you do not care and let the program just crash. Read more about the noexcept specifier in my previous post: C++ Core Guidelines: The noexcept specifier and operator.

The concept Equal, demonstrated in the following example, uses compound requirements.

// conceptsDefinitionEqual.cpp

#include <concepts>
#include <iostream>

template<typename T>                                     // (1)
concept Equal = requires(T a, T b) {
    { a == b } -> std::convertible_to<bool>;
    { a != b } -> std::convertible_to<bool>;
};

bool areEqual(Equal auto a, Equal auto b){
  return a == b;
}

struct WithoutEqual{                                       // (2)
  bool operator==(const WithoutEqual& other) = delete;
};

struct WithoutUnequal{                                     // (3)
  bool operator!=(const WithoutUnequal& other) = delete;
};

int main() {
 
    std::cout << std::boolalpha << '\n';
    std::cout << "areEqual(1, 5): " << areEqual(1, 5) << '\n';
 
    /*
 
    bool res = areEqual(WithoutEqual(),  WithoutEqual());    // (4)
    bool res2 = areEqual(WithoutUnequal(),  WithoutUnequal());
 
    */

    std::cout << '\n';
 
}

The concept Equal (line 1) requires that its type parameter T supports the equal and not-equal operator. Additionally, both operators have to return a value that is convertible to a boolean. Of course, int supports the concept Equal, but this does not hold for the types WithoutEqual (line 2) and WithoutUnequal (line 3). Consequently, when I use the type WithoutEqual (line 4), I get the following error message when using the GCC compiler.

A nested requirement has the form

requires constraint-expression;   

Nested requirements are used to specify requirements on type parameters.

In my previous post "Define Concepts", I defined the concept UnsignedIntegral using logical combinations of existing concepts and compile-time predicates. Now, I define it using nested requirements:

// nestedRequirements.cpp

#include <type_traits>

template <typename T>
concept Integral = std::is_integral<T>::value;

template <typename T>
concept SignedIntegral = Integral<T> && std::is_signed<T>::value;

// template <typename T>                               // (2)
// concept UnsignedIntegral = Integral<T> && !SignedIntegral<T>;

template <typename T>                                  // (1)
concept UnsignedIntegral = Integral<T> &&
requires(T) {
    requires !SignedIntegral<T>;
};

int main() {

    UnsignedIntegral auto n = 5u;  // works
    // UnsignedIntegral auto m = 5;   // compile time error, 5 is a signed literal

}

Line (1) uses the concept SignedIntegral as a nested requirement to refine the concept Integral. Honestly, the commented-out concept UnsignedIntegral in line (2) is more convenient to read.

Typically, you use a requires expressions to define a concept, but they can also be used as a standalone feature when a compile-time predicate is required. Therefore, use cases for requires expression can be a requires clause, static_assertor constexpr if. I will write in my next post about these special use cases of requires expressions.