On Fri, 16 May 2014 20:42:34 -0400, Phil Lavoie <[email protected]>
wrote:
On Friday, 16 May 2014 at 23:14:13 UTC, Idan Arye wrote:
How about if instead these constraint could be used in `is` expressions
like type specializations?
void myTemplateFunction(T)(T r) if(is(T : InputRange!int)) {
foreach(elt; r) { ... }
}
True, the syntax is less elegant, but it's more flexible, you can
easily tell that it's a template, and you can use the same syntax in
static branching.
It's interesting. But would it warrant a change from the usual syntax,
which would probably be:
void myTemplateFunction(T)(T r) if( isInputRange!(T, int)) {
foreach(elt; r) { ... }
}
I just want to say, these two do not look very different.
There are a couple things I want to say about these ideas without saying I
agree or disagree with the proposals. These are the problems with the
current system:
1. The template constraint is all or nothing. If you have a complex
if-statement, and one bit fails, it's often difficult to determine what
happened.
2. The template constraint is decoupled from the parameters themselves. If
you have 5 parameters, you have to match the parameters to how they are
constrained, and that isn't always straightforward.
I agree that the original proposal does not look template-ish enough.
I think we can do a lot with the existing trait templates to solve these 2
major problems. A possible solution:
template interface isInputRange(T, E) { .. No change in implementation .. }
void myTemplateFunction(T : isInputRange!int)(T t)
{
}
would basically change this into the equivalent of today's constraints.
however, given that the template parameter is coupled with the constraint
more directly, a better error message could be created, e.g. "Type
MyNonRangeType does not satisfy template interface isInputRange!int."
I'm not sure the above doesn't conflict with current syntax, but I like it
a hell of a lot better than the decoupled constraint afterward.
-Steve
