Rant after trying Rust a bit

[Jonathan M Davis via Digitalmars-d]

On Saturday, 25 July 2015 at 10:01:43 UTC, Walter Bright wrote:
> On 7/24/2015 10:59 PM, Jonathan M Davis wrote:
>> In any case, looking at this, I have to agree with you that 
>> this is the same
>> problem you get with checked exceptions / exceptions 
>> specifications - only worse
>> really, because you can't do "throws Exception" and be done 
>> with it like you can
>> in Java (as hideous as that is). Rather, you're forced to do 
>> the equivalent of
>> listing all of the exception types being thrown and maintain 
>> that list as the
>> code changes - i.e. you have to make the top-level template 
>> constraint list all
>> of the sub-constraints and keep that list up-to-date as the 
>> sub-constraints
>> change, which is a mess, especially with deep call stacks of 
>> templated functions.
>
> Phew, finally, someone understands what I'm talking about! I'm 
> really bad at explaining things to people that they aren't 
> already familiar with.
>
> I'm not sure, but I suspect this problem may cripple writing 
> generic library functions that do one operation and then 
> forward to the next (unknown in advance) operation in a chain.

Well, the caller then has to do deal with the fact that the 
result doesn't work with the next call in the chain, and at least 
in that case, the failures are at their level, not buried inside 
of calls that they're making. And this is exactly the sort of 
problem that we've had for quite a while where you try and do 
something like

auto result = rndGen().map!(a % 10).take(10).sort();

The result of take isn't random-access, but sort requires 
random-access, so you get a compilation failure - but it's 
clearly on this line and not inside of one of the calls that 
you're making, so it's pretty straightforward.

I guess that where the problem might come in (and maybe this is 
what you meant) is when you try and do a chain like that inside 
of a templated function, and you end up with a compilation 
failure, because the argument to that function resulted in one of 
the items in the chain failing. But I'm not sure that that's any 
different really from a line with a single function call failing 
due to the outer function's argument not working with it.

> It also may completely torpedo Andrei's Design By Introspection 
> technique.

I'm not sure what you mean here. Design by Introspection seems to 
be primarily for implementing optional functionality, and it 
couldn't be in the outer template constraint regardless, because 
it's optional. So, I don't really see how whether or not we put 
all of the sub-constraints in the main template constraint really 
affects DbI.

I do have to wonder about what Andrei means to do with DbI 
though, since he keeps bringing it up like it solves everything 
and should be used everywhere, whereas it seems like it would 
only to apply to certain areas where you're dealing with optional 
functionality, and a lot of code wouldn't benefit from it all. 
We're essentially using it with ranges already when we're 
implementing algorithms differently based on what type of range 
we're given or what extra capabilities the range has, so it 
obviously is showing its usefulness there, but the allocators is 
the only other case that I can think of at the moment where it 
would make sense to use it heavily. He sounds like he wants to 
use it everywhere, which I don't get at all.

- Jonathan M Davis