Concepts vs template constraints - the practical approach

[Norbert Nemec]

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);
> }