Rant after trying Rust a bit

jmh530 via Digitalmars-d digitalmars-d at puremagic.com
Sun Jul 26 09:39:21 PDT 2015


On Sunday, 26 July 2015 at 06:54:17 UTC, Jonathan M Davis wrote:
>
> That's certainly an interesting idea, though if we're going 
> that route, it might be better to simply have the compiler do 
> that automatically for you, since it can see what functions are 
> being called and what they're constraints are. Still, part of 
> the problem is that the constraints for bar or baz may not be 
> directly related to the argument to foo but rather to a result 
> of operating on it. So, bar and baz's constraints can't 
> necessarily be moved up into foo's constraint like that in a 
> meaningful way. It would require the code that generates the 
> arguments to bar and baz as well in order to make that clear. 
> For instance, it might be that T needs to be an input range for 
> the code that's directly in foo. However, if you do something 
> like
>
> auto u = t.f1().f2().f3();
> auto b = bar(u);
>

Yeah, I can see how something like that's going to get 
complicated. My best guess would be something like
auto foo(T)(T t)
{
     static if ( template_constraints!f1(t) && 
template_constraints!f2(f1(t)) && 
template_constraints!f3(f2(f1(t))) )
         auto u = t.f1().f2().f3();
         static if (template_constraints!bar(u))
             auto b = bar(u);
}

I guess the key would be that the template_constraints should be 
able to take whatever inputs the function can take so that you 
can use it with static if at any point in the function body if 
needed. It may not work for everything, but I imagine it would 
probably cover most cases, albeit awkwardly for the chained range 
operations. Ideally, there could be a way so that only the last 
condition in that first static if is required, but I'm not sure 
how easy something like that would be.

Nevertheless, I honestly don't know how big of an issue something 
like this is. I'm sort of talking out of ignorance at this point. 
I haven't had the need to program anything like this.

My biggest problem with your point about including everything in 
the top-level is that if you make a change to the constraints in 
the bottom level then you have to remember to make the changes 
everywhere else. If you only allow one template constraint for 
each function, then it might be easier to remember (b/c multiple 
conditions would need to be defined in auxiliary functions), but 
it would also be much less flexible.


More information about the Digitalmars-d mailing list