Interfaces, traits, concepts, and my idea for a DIP

[Biotronic via Digitalmars-d]

On Thursday, 30 July 2015 at 10:40:59 UTC, Atila Neves wrote:
> There's still the problem of having two names for each 
> constraint: checkInputRange and isInputRange. But... we could 
> also establish the convention of checkXXX and use string mixins 
> to turn this:
>
> @satifies!(isInputRange, MyRange)
>
> into (which works cos I just tried it):
>
> template satisfies(alias Constraint, R) {
>     enum check = "check" ~ Constraint.stringof[2..$-3] ~ "!(R)";
>     enum assert_ = "static assert("~ check ~ ");";
>     mixin(assert_); //mixes in "static 
> assert(checkInputRange!R)"
> }
>
>
> @satisfies!(isInputRange, Zeroes)
> struct Zeroes {
>     enum empty = false;
>     void popFront() {}
>     @property int front() { return 0; }
> }
>
>
> Now, _this_ I could go for.
>
> Atila

Why are there two different things in the first place?

@satisfies!(myConcept, T) should test the constraints and give a 
sensible error message. This you use to indicate that type T 
implements myConcept.

Why can't another template use the very same concept information 
to check if a type implements the concept?

e.g.:

@satisfies!(myConcept, MyStruct)
struct MyStruct { /* ... */ }

void foo(T)(T t) if (check!(myConcept, T))
{ /* ... */ }