Yes, constraints can have helpful error messages!

[Marvin Hannott]

On Saturday, 9 April 2022 at 05:01:51 UTC, vit wrote:
> Many constraitns are one use only and crating special templates 
> for them is cumbersome.

Obviously, this is meant for (non trivial) public constraints. 
What you do privately is no one's business. But public 
constraints should always be helpful instead of confusing. That's 
at least my opinion, for what it's worth. I would still claim 
that this approach is reasonably convenient. And when it becomes 
too hard to bother about good user experience because of language 
barriers, well... But I could certainly think of a few ways 
(involving string mixins) to make this approach really shine. 
When I got some time to experiment I might release it as 
(experimental) library.

I don't know what's "special" about my template. Aren't all 
constraints necessarily templates? At least they must be 
computable at compile-time.

>It create template bloat and for
> example your code doesn't work with templates or generic 
> lambdas:

Well, I never expected this example to be water tight. It was 
merely an experiment. But I would daresay that being restrictive 
instead of allowing everything isn't a bad thing. Some interfaces 
in Phobos are really obscure because they overdid it, trying to 
be as general as possible. And if it becomes hard to test your 
interface, then maybe it is wrong. (Apologies for sounding like a 
smartass.)

But I am curious: why wouldn't the caller instantiate the 
template first? I don't think there is more meta-magic necessary, 
or at least it shouldn't be. And generic lambdas are a mess, and 
I am not sure they should exist. The error messages when 
something goes wrong are unhelpful to say the least. Which is the 
exact point that brings us here. But sorry, for going off-topic. 
Wouldn't want to go down a different rabbit whole.

But on your point on template bloat: isn't that only the case in 
the debug version?

>interface of isFilter
> break because parameters must be variadic...

I am not sure I understand this point. Do you mean functions with 
more than one parameter should be accepted? Why would that be 
useful? Like I said, I think being restrictive isn't a bad thing. 
But sure, that is only my opinion.

>There is another big problem with your solution:

```D
template isInt(T){
   static assert(is(T == int), "T is not int" );

   enum isInt = is(T == int);
}

void test(T)(T val)
if(isInt!T){

}

void test(double val){

}

void main() {
    test(int.init);
    test(double.init);
}
```
>Function overloading doesn't work .

Well, `isInt` always asserts, which is the complete opposite of 
what I was suggesting. Of course it *shouldn't* assert when used 
as constraint in an `if()`-statement like in `test`, but it 
should assert at "implementation"-site inside a 
class/struct/function to make certain it fulfills some constraint 
/ implements some interface, and to give helpful error messages 
when it doesn't.