Concepts are an extension to the templates feature provided by the C++ programming language. Concepts are named Boolean predicates on template parameters, evaluated at compile time. A concept may be associated with a template (class template, function template, member function of a class template, variable template, or alias template), in which case it serves as a constraint: it limits the set of arguments that are accepted as template parameters.
Originally dating back to suggestions for C++11, the original concepts specification has been revised multiple times before formally being standardised in C++20.
The main uses of concepts are:
Traditionally, template type restrictions were expressed using substitution failure is not an error (SFINAE), but concepts allow for a clearer expression of restrictions.
There are five different places in a function template signature where a constraint can be used (labeled below from 1 through 5):
The constraint forms <code>Concept1</code> and <code>Concept2</code> can be used in all kinds of templates.
The following demonstrates using a concept as an upper bound for inheritance constraints on types, by creating a concept <code>ExtendsPlayer</code> satisfied only by classes which inherit from a base class <code>Player</code>, blocking any type that does not.
This is similar to constrained generics in Java, and is equivalent to the following example:
=== === The following is a possible definition of the concept <code>std::equality_comparable</code> from the <code><concepts></code> header of the C++ Standard Library. This concept is satisfied by any type <code>T</code> such that for lvalues <code>a</code> and <code>b</code> of type <code>T</code>, the expressions <code>a == b</code> and <code>a != b</code> as well as the reverse <code>b == a</code> and <code>b != a</code> compile, and their results are convertible to a type that satisfies the concept "boolean-testable":
A function template constrained on this concept may be declared as follows:
or
And may be called as usual:
In object-oriented programming, an interface defines a set of method signatures which the class must implement in order to satisfy it. A concept may be seen as similar to an interface, which can define that a type satisfies various requirements.
This would be roughly similar to the following in Java:
C++ concepts resemble Go interfaces very closely. Unlike Java interfaces, Go interfaces do not require a type to declare that it implements the interface, as types implicitly satisfy the interface as long as it implements all of its requirements. For example, this <code>Drawable</code> concept in C++ is roughly equivalent to the Go interface:
If a programmer attempts to use a template argument that does not satisfy the requirements of the template, the compiler will generate an error. When concepts are not used, such errors are often difficult to understand because the error is not reported in the context of the call, but rather in an internal, often deeply nested, implementation context where the type was used.
For example, requires that its first two arguments be random-access iterators. If an argument is not an iterator, or is an iterator of a different category, an error will occur when attempts to use its parameters as bidirectional iterators. Consider <code>std::list<T></code>, which implements a doubly-linked list, and is not random-access:
Typical compiler diagnostic without concepts is over 50 lines of output, beginning with a failure to compile an expression that attempts to subtract two iterators:
<pre> In instantiation of 'void std::__sort(_RandomAccessIterator, _RandomAccessIterator, _Compare) [with _RandomAccessIterator = std::_List_iterator<int>; _Compare = __gnu_cxx::__ops::_Iter_less_iter]': error: no match for 'operator-' (operand types are 'std::_List_iterator<int>' and 'std::_List_iterator<int>') std::__lg(__last - __first) * 2,
[..] </pre>
If concepts are used, the error can be detected and reported in the context of the call:
<pre> error: cannot call function 'void std::sort(_RAIter, _RAIter) [with _RAIter = std::_List_iterator<int>]' note: concept 'RandomAccessIterator()' was not satisfied </pre>
Concepts can be used to choose function template overloads and class template specializations based on properties of their template arguments, as an alternative to SFINAE and tag dispatching. If an argument satisfies more than one concept, the overload associated with the more constrained concept is chosen.
Concepts may be used instead of the unconstrained type deduction placeholder in variable declarations and function return types:
Concepts TS, as specified in ISO/IEC TS 19217:2015, are implemented as an experimental feature in GCC 6. C++20 concepts are fully implemented in GCC 10, MSVC 19.30, and Clang 10.
A different form of Concepts, popularly known as "C++0x Concepts", was temporarily accepted into the working paper for C++11 but was removed in 2009. In addition to concepts themselves, "C++0x Concepts" included concept maps (a feature that could make it possible, for example, for the concept <code>Stack</code> to accept , automatically mapping <code>Stack</code> operations such as to differently named operations on , such as ) and axioms (a facility to specify semantic properties such as associativity or commutativity, allowing the compiler to take advantage of these properties without proof). The proposed syntax looked something like the following:
The original proposal was ultimately abandoned due to resolution ambiguity in compilation as well as increased complexity in compile-time behavior, while axioms could not be verified during compilation. In contrast to this abandoned proposal, the C++20 version of Concepts is sometimes referred to as "Concepts Lite".
During the C++ standards committee meeting in March 2016, the evolution working group moved to merge Concepts into the mainline C++17 standard, but the motion was defeated in full committee.
Concepts v1 was merged into the C++20 draft.
"The One Range" version of Range feature that depend on concepts was also merged into C++20.
In C#, a generic type constraint is expressed with a <code>where</code> clause, which can be as expressive as concepts but are not named.
Java has wildcard generics, which are not as expressive as concepts but can represent bounds on types.
Kotlin, does not support Java-style type wildcards. However, it represents <code>?</code> instead represented as <code>*</code> (for example, <code>List<*></code>). It otherwise has C#-style <code>where</code> clauses:
Rust also uses <code>where</code> clauses to bound traits.