Helpers for writing unittests

[Idan Arye via Digitalmars-d]

The "Rant after trying Rust a bit" 
thread(http://forum.dlang.org/thread/ckjukjfkgrguhfhkdhhj@forum.dlang.org) talks mostly about traits, and how people want Rust's traits(or C++'s Concepts) in D. As a general rule, I believe that taking a feature from one language and sticking it in another works just as nicely as taking off a leg from one chair and using it to replace a broken leg from a different firm's chair. You'd be lucky if they have similar length, and even if you sand the legs to have exact same length the balance will be off. You might be able to sit on it, but it won't be as comfortable as a chair that all it's parts fit together.

Instead, it's better to look at the problem the feature solves, 
and how the language without that feature approaches the problem. 
In our case, the problem is that compile-time errors in the 
templates only pop up once the template is instantiated. Rust's 
solution is to use Traits, and Walter made it pretty clear that 
the D way to solve this problem is to instantiate the template in 
a unittest.

As seen in that thread, many people find this solution lacking. 
Writing 100% coverage tests for instantiating templates is a long 
and tiring process. In response, the anti-traits camp accuses 
these people of being lazy.

Well, I say - programmers should be lazy! That's why we are 
programming - because we are lazy and want the computers to do 
our work for us. So the current D solution is not enough - but 
that doesn't mean a feature transplant from Rust is a good 
solution - we need to find a D style solution, that'll fit with 
the rest of the language.


What I'm thinking about is a unittest helper that'll help in 
checking different instantiations of the template. A quick proof 
of concept - http://dpaste.dzfl.pl/8907c3a7d54c - shows how the 
unittest found that foo doesn't work with long and ulong, and 
printed easy-to-understand errors.

Just like IntegerTypes we can have many more lists of types for 
different categories of types we want to test - string types, 
range types etc. With this in Phobos, writing unittests with full 
coverage(compile-time only) will be much easier.

Note that we just want to see that it compiles - we don't want to 
actually run it, because than we'd have to supply templated test 
data and test results to compare with, which is a much harder 
problem. These are compile-time mocks - the problem they solve is 
limited to compilation so they will be able to solve it well and 
elegantly. This does not come instead of tests that actually run 
- a unittest can test compilation on all the relavant types and 
actually run and check the results only for a subset of these 
types.

Thoughts?