On Friday, 31 July 2015 at 00:54:30 UTC, Idan Arye wrote:
The resulting compilation errors are extremely different. With
your method we get:
/d391/f994.d(31): Error: static assert (is(typeof(__error))) is
false
which doesn't tell us what the problem is. With my method we
get:
/d433/f500.d(25): Error: cannot implicitly convert expression
(x) of type ulong to int /d433/f500.d(31): Error: template
instance f500.foo!ulong error instantiating
And yes, a lot of "static stack trace" after that, but these
too lines tells us what the problem is and which template
parameters caused it.
True enough, but you can simply add T.stringof to the static
assertion, and you'll know which instantiation is failing. And
maybe what you're suggesting is worth having, but you can get
pretty much the same thing easily without creating a template to
do the test for you.
Of course, if you just ran the function inside the foreach loop
you'd get nice error messages as well - but then you'd have to
write tests that actually run. Which is easy for numbers,
because they are all the same type of data with different
sizes, but can get tricky when you have more complex types,
that differ more in their behavior.
Yes. It's generally hard to write tests which work with a variety
of template instantiations, but the point is that knowing that
the template instantiates with a particular type really doesn't
tell you much. If you actually want to be testing the template
with those types, you should be writing tests with those types
whether you can templatize the tests or whether each
instantiation needs to be tested separately. That being the case,
I don't think that unit tests should normally be testing
explicitly that a template instantiates with a type. Doing that
is so insufficient that there isn't much point.
- Jonathan M Davis
