On Saturday, 17 May 2014 at 01:53:46 UTC, Steven Schveighoffer
wrote:
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
Good point! This is also the way you use regular interfaces(or
classes) for constraints, so it shouldn't conflict with current
syntax.
