I am not sure there is a real need for this in C++.
Trying to put myself in the position of a designer who is looking for such a solution, I would say this kind of constraint would be needed to enforce some types to adhere to some syntactic convention.
Most likely, this is needed because a generic algorithm requires that syntactic convention: it cannot work with types that do not define such a type association.
For instance, the algorithm below requires the type of its argument to have an associated bar_type
:
template<typename T>
bool foo(T t)
{
typedef typename T::bar_type FT;
FT ft;
...
}
But if this is the case, there is no need for enforcing a typedef
to effectively constraint the input of foo<>()
: simply omitting a type definition for bar_type
won't make it possible to use that type with foo<>()
.
Of course, you would discover this only as soon as you actually try to do so, and not before. And being able to define a concept such as HasBarType
, and then to enforce some types to realize that concept would be nice; on the other hand, concepts are not yet part of C++ and, as much as they are desirable, it is possible to live without them.