Rant after trying Rust a bit

[jmh530 via Digitalmars-d]

On Sunday, 26 July 2015 at 04:34:55 UTC, Jonathan M Davis wrote:
>
> I suggested the same in response to Walter earlier. It is one 
> way to combat the problem. However, it's really only going to 
> work in basic cases (at least, without getting ugly). What if 
> what you passed to bar wasn't t but was a result from calling a 
> function on t? Or maybe it was a result of calling a function 
> on the return value of a function that was called on t? Or 
> perhaps you passed t through a chain of free functions and 
> ended up with some other type from that, and it doesn't pass 
> bar's template constraint? In order to deal with that sort of 
> thing, pretty soon, you have to put most of the function inside 
> its own constraint. It's _far_ cleaner in general to just be 
> putting the sub-constraints in the top-level constraint - e.g. 
> maybe all that it means is using isForwardRange and hasLength 
> instead of just isInputRange rather than putting a whole chain 
> of function calls inside of __traits(compiles, ...) test in the 
> template constraint. It just gets ugly quickly to try and get 
> it to work for you automatically by putting the calls you're 
> making in the constraint so that the actual constraint 
> conditions are inferred.
>
> {snip}

I appreciate the thorough response. I think I agree with your 
point about error messages. Nevertheless, with respect to your 
point about a best effort to putting constraints at the 
top-level, there might be scope for making this easier for 
people. For instance, if there were a way to include the 
constraints from one template in another template. From your 
example, maybe something like

auto foo(T)(T t)
     if(template_constraints!bar && template_constraints!baz)
{
     ...
     auto b = bar(t);
     ...
     auto c = baz(t);
     ...
}

Ideally the template_constraints!bar would expand so that in an 
error message the user sees what the actual constraints are 
instead of the more nebulous template_constraints!bar. At least 
something like this would avoid your point with respect to 
__traits(compiles, x).