New syntax proposal for template type parameter contraints

[Idan Arye via Digitalmars-d]

On Saturday, 17 May 2014 at 01:53:46 UTC, Steven Schveighoffer 
wrote:
> On Fri, 16 May 2014 20:42:34 -0400, Phil Lavoie 
> <maidenphil at hotmail.com> 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.