Rant after trying Rust a bit

[Walter Bright via Digitalmars-d]

On 7/26/2015 3:53 PM, deadalnix wrote:
> On Sunday, 26 July 2015 at 19:54:28 UTC, Walter Bright wrote:
>> Unit tests are also not exclusively about runtime. Using a unit test to
>> instantiate a template is a compile time test.
>
> Yes, it test the instantiation to some extent. It tests that the instantiate
> works granted you pass it what is expected.
>
> It does not test that the instantiation will fail if you pass it anything else,
> or worse, do random unexpected stuff.

If the template constraint is 'isInputRange', and you pass it an 'InputRange' 
that is nothing beyond an input range, and it compiles, it is JUST AS GOOD as 
Rust traits, without needing to add 'isInputRange' to every template up the call 
tree.

In fact, I do just this in my D dev projects. I have a set of mock ranges that 
match each of the range types.


> The problem is the exact same as for dynamic typing and unitests. A dynamically
> typed function that expect a string can be test exhaustively with warious string
> passed as arguments. Still, none knows what happen when passed an int, float,
> array, object or whatever. Worse, it is either going to blow up in some
> unexpected way or not explode and do random stuff.

Flatly no, it is not at all the same. Dynamic typing systems do not have 
constraints. Furthermore, dynamic typed languages tend to do random s**t when 
presented with the wrong type rather than fail. (Such as concatenating strings 
when the code was intended to do an arithmetic add.) D does not, it presents the 
user with a compilation error.


> The same way, instantiate your template with something it doesn't expect and you
> get absurdly complex errors (and it is getting worse as phobos get more and more
> "enterprise" with Foo forwarding to FooImpl and 25 different helpers).

This is incorrect. In my D project development, when I send the wrong thing, I 
get a list of the template instantiation stack. The bottom gives the method not 
found, and the stack gives how it got there. I find it adequate in that it 
doesn't take much effort to figure out where things went wrong.

BTW, when you discover that a constraint is wrong on a Phobos template, please 
file a bug report on it.


> The problem is the same, will it fail at call site/instanciation site with "I
> expected X you gave me Y" or will it fail randomly somewhere down the road in
> some unrelated part of the code, or worse, not fail at all when it should have ?

If the constraint is InputRange, and the body assumes ForwardRange, and I pass 
it a ForwardRange, and it works, how is that 'worse'?