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

[Atila Neves via Digitalmars-d]

On Thursday, 30 July 2015 at 19:12:27 UTC, jmh530 wrote:
> On Thursday, 30 July 2015 at 10:40:59 UTC, Atila Neves wrote:
>> [...]
>
> I might be overthinking this.
>
> You would still need to define something for checkInputRange. 
> Are you thinking something simple like
>
> template checkInputRange(R)
> {
>     enum bool checkInputRange = isInputRange!R;
> }
>
> In this case, the error message is still referring to 
> checkInputRange instead of isInputRange. So the user would 
> still need to refer to that and see what that functions 
> conditions are. Alternately, you could write checkInputRange to 
> provide the user information about which functions are not 
> implemented (like no pop, no popFront, no empty). That seems 
> more difficult, but would be convenient for the user.
>
> The benefit of something simple like
>
> template satisfies_alt(alias Constraint, R) {
>     static assert(Constraint!R);
> }
>
> is that at least you don't have to write extra functions. You 
> only need isInputRange. The downside is that the error message 
> references Constraint instead of isInputRange. That's less 
> intuitive.

Check the out the PR I mentioned:

https://github.com/D-Programming-Language/phobos/pull/3520

The idea would be to define a similar check function for each 
constraint. Without it, you don't get the nice error messages.

Atila