Rant after trying Rust a bit

[Andrei Alexandrescu via Digitalmars-d]

On 7/23/15 6:06 PM, H. S. Teoh via Digitalmars-d wrote:
> An uninstantiated template path is worse than a branch that's never
> taken, because the compiler can't help you find obvious problems before
> you ship it to the customer.

-cov does help, although indeed in a suboptimal way because you need to 
manually parse the listing. It would be nice if it marked lines that are 
supposed to be code yet are not instantiated in a specific way. 
(Currently it only marks lines that are compiled but not run.)

> A lot of Phobos bugs lurk in rarely-used template branches that are not
> covered by the unittests.

Hopefully not many are left. I consider that a historical problem caused 
by lack of good testing discipline. My perception is we got a lot better 
at that.

It's simple survival to not ship untested code, even if it does compile. 
In any language. We should never do it.

> If we had a Concepts-like construct in D, where template code is
> statically constrained to only use, e.g., range API when manipulating an
> incoming type, a lot of these bugs would've been caught.

We'd get to ship more untested code? No thanks. We need a different 
angle on this. Concepts support a scenario that fails basic software 
engineering quality assurance criteria.

> In fact, I'd argue that this should be done for *all* templates -- for
> example, a function like this ought to be statically rejected:
>
> 	auto myFunc(T)(T t) { return t + 1; }
>
> because it assumes the validity of the + operation on T, but T is not
> constrained in any way, so it can be *any* type, most of which,
> arguably, do not support the + operation.

That would be a bit much. myFunc is correct under static and dynamic 
assumptions about T. Dynamic assumptions cannot be checked save for 
documentation and unittesting. If the static assumptions fail, then well 
we have a less-than-nice compile-time error message, but still a 
compile-time error message. No disaster.

> Someone could easily introduce a bug:
>
> 	auto myFunc(T)(T t)
> 		if (is(typeof(T.init + 1)))
> 	{
> 		/* Oops, we checked that +1 is a valid operation on T,
> 		 * but here we're doing -1 instead, which may or may not
> 		 * be valid: */
> 		return t - 1;
>

Is that a bug or a suboptimal error message?

> The compiler still accepts this code as long as the unittests use types
> that support both + and -. So this dependency on the incidental
> characteristics of T remains as a latent bug.
>
> If the compiler outright rejected any operation on T that hasn't been
> explicitly tested for, *then* we will have eliminated a whole class of
> template bugs. Wrong code like the last example above would be caught as
> soon as the compiler compiles the body of myFunc.

Yah, I think this is off.


Andrei