Reputation: 676
This page http://en.cppreference.com/w/cpp/language/constraints indicates that the the return type for a function concept must be bool. If there is only one option here, what is the rationale behind requiring a return type to be specified in the first place?
Why not just go with something like this syntax:
template <typename T>
concept DumbConcept() {
return requires( T a,T b ) {
requires std::is_same<decltype(a+b),bool>::value;
};
}
Upvotes: 3
Views: 1197
Reputation: 473537
If there is only one option here, what is the rationale behind requiring a return type to be specified in the first place?
Because it's a function and functions have return types. No, really, that was the justification for it.
The original concepts proposal for C++98 failed in large part because it tried to do too much. As such, the Concepts-lite proposal started with the absolute minimum-viable-feature: a way to constrain a template, and a way to define constraints. But as a minimum-viable-feature, the requires
clause was not limited to concepts; it could (and still can) accept any constant expression, not just a concept.
As such, a "concept" was just a fancy constant expression that could be used in certain special ways. Concepts needed to be able to be templates, and they needed to be able to evaluate expressions. Since C++11/14 didn't have variable templates, the minimum-viable-feature solution for a "concept" definition at the time was to make it be a constexpr
function. Indeed, version 1.0 of the concepts-lite feature didn't even have concept
as a keyword; a "concept" was just any constexpr
function that returned bool
.
Obviously the concepts design evolved significantly from there.
The version of concepts that was adopted into C++20 didn't include function concepts. And they also didn't include the bool
part of variable concepts. Because, as you point out, it's redundant.
Upvotes: 4