Rant after trying Rust a bit

[Dicebot via Digitalmars-d]

Sorry for somewhat delayed answer - not sure if anyone has 
answered to your questions in the meanwhile.

On Friday, 24 July 2015 at 00:19:50 UTC, Walter Bright wrote:
> On 7/23/2015 2:08 PM, Dicebot wrote:
>> It does not protect from errors in definition
>>
>> void foo (R) (Range r)
>>      if (isInputRange!Range)
>> { r.save(); }
>>
>> unittest
>> {
>>      SomeForwardRange r;
>>      foo(r);
>> }
>>
>> This will compile and show 100% test coverage. Yet when user 
>> will try using it
>> with real input range, it will fail.
>
> That is correct. Some care must be taken that the mock types 
> used in the unit tests actually match what the constraint is, 
> rather than being a superset of them.

This is absolutely impractical. I will never even consider such 
attitude as a solution for production projects. If test coverage 
can't be verified automatically, it is garbage, period. No one 
will ever manually verify thousands lines of code after some 
trivial refactoring just to make sure compiler does its job.

By your attitude `-cov` is not necessary at all - you can do the 
same manually anyway, with some help of 3d party tool. Yet you 
advertise it as crucial D feature (and are being totally right 
about it).

>> There is quite a notable difference in clarity between error 
>> message coming from
>> some arcane part of function body and referring to wrong usage 
>> (or even totally
>> misleading because of UFCS) and simple and straightforward 
>> "Your type X does not
>> implement method X necessary for trait Y"
>
> I believe they are the same. "method X does not exist for type 
> Y".

Well, the difference is that you "believe" and I actually write 
code and read those error messages. They are not the same at all. 
In D error message gets evaluated in context of function body and 
is likely to be completely misleading in all but most trivial 
methods. For example, if there is a global UFCS function 
available with the same name but different argument list, you 
will get an error about wrong arguments and not about missing 
methods.

>> Coverage does not work with conditional compilation:
>>
>> void foo (T) ()
>> {
>>      import std.stdio;
>>      static if (is(T == int))
>>          writeln("1");
>>      else
>>          writeln("2");
>> }
>>
>> unittest
>> {
>>      foo!int();
>> }
>>
>> $ dmd -cov=100 -unittest -main ./sample.d
>
> Let's look at the actual coverage report:
> ===============================
>        |void foo (T) ()
>        |{
>        |    import std.stdio;
>        |    static if (is(T == int))
>       1|        writeln("1");
>        |    else
>        |        writeln("2");
>        |}
>        |
>        |unittest
>        |{
>       1|    foo!int();
>        |}
>        |
> foo.d is 100% covered
> ============================
>
> I look at these all the time. It's pretty obvious that the 
> second writeln is not being compiled in.

Again, this is impractical. You may be capable of reading with 
speed of light but this not the normal industry case. Programs 
are huge, changesets are big, time pressure is real. If something 
can't be verified in automated way at least for basic sanity, it 
is simply not good enough. This is the whole point of CI 
revolution.

In practice I will only look into .cov files when working on 
adding new tests to improve the coverage and will never be able 
to do it more often (unless compiler notifies me to do so). This 
is real-world constraint one needs to deal with, not matter what 
your personal preferences about good development process are.

> Now, if I make a mistake in the second writeln such that it is 
> syntactically correct yet semantically wrong, and I ship it, 
> and it blows up when the customer actually instantiates that 
> line of code,
>
>    -- where is the advantage to me? --
>
> How am I, the developer, better off? How does "well, it looks 
> syntactically like D code, so ship it!" pass any sort of 
> professional quality assurance?

?

If compiler would actually show 0 coverage for non-instantiated 
lines, than automatic coverage control check in CI would complain 
and code would never be shipped unless it gets covered with tests 
(which check the semantics). Your are putting it totally 
backwards.