Hi Ali,
indeed, defining individual named sub-concepts makes the thing somewhat
more readable.
However, my approach with individual static assertions was very
intentional:
Collecting individual requirements as an AND expression of booleans does
not allow any helpful error message. If just one of the requirements is
not met, there is just one failure of the global assertion.
I had also toyed with boolean wrappers for the "__traits(compiles,...)"
construct. It does work, but still it feels way more hacky than anything
I would want to use at the foundation of a general library.
Greetings,
Norbert
On 20.11.2011 19:47, Ali Çehreli wrote:
On 11/20/2011 08:41 AM, Norbert Nemec wrote:
> Hi there,
>
> back in the discussions about C++-"concepts" it was argued that
> D-template-parameter constraints allow you to achieve the same goal.
Have a look at std.range.hasLength, std.range.isInputRange, and friends.
[...]
Here is something:
template hasType(T)
{
enum bool hasType = is(T.type);
}
template hasNonNegativeLength(T)
{
enum bool hasNonNegativeLength = T.len >= 0;
}
template firstElementSameType(T)
{
enum bool firstElementSameType = is(typeof(T.init[0]) == T.type);
}
template matchesMyConcept(T)
{
enum bool matchesMyConcept = (hasType!T &&
hasNonNegativeLength!T &&
firstElementSameType!T);
}
