On Tuesday, 31 March 2015 at 21:05:40 UTC, Xavier Bigand wrote:
Le 31/03/2015 20:21, Andrei Alexandrescu a écrit :
On 3/31/15 7:45 AM, Idan Arye wrote:
On Tuesday, 31 March 2015 at 13:34:24 UTC, Dicebot wrote:
On Tuesday, 31 March 2015 at 10:25:57 UTC, Idan Arye wrote:
I understand the preference to librarize as much as
possible, but I
don't think the desire to sacrifice every possible bit of
convenience
to avoid the tiniest changes to the language is always
beneficial. I
don't say that implementing everything inside the compiler
is good
either though, but in many cases some slight changes to the
language
can make the library solution so much more simple and
elegant.
In this case, allowing to name a unittest should be a very
simple
language change that'll make any library implementation of
the rest
of the feature more elegant to use, simpler to implement,
and more
consistent with alternative library implementations.
It isn't simple at all. Name is just one of many meta-values
you
commonly want to attach to unittest block. Some others:
description,
dependency, parallelization, benchmark tag, I/O indicator.
It is
simply impossible to foresee it all in a language feature -
but it is
exactly kind of data UDA are designed for. All we need is to
enhance/fix the language to actually make using of that
information
convenient.
But unittests already have
names(http://dpaste.dzfl.pl/b15e94000f15), so
the only required change is to allow the user to specify that
name. This
should be much simpler than adding entirely new fields.
Interesting point! -- Andrei
It will be nice to have named unittest.
And better if IDEs will be able to retrieve those names, to
allow replay by name, displaying results by names,...
Building by unittest name! Imagine - instead of placing temporary
code in `main` to develop a new feature or fix a bug, you put in
a named unittest and tell your IDE/build-system to only build
that unittest(and whatever code needed for it to run). You
`writeln` stuff to the console, and when you get some changes to
output what you want you change the `writeln`s to `assert`s and
proceed to work on the next step. When you are done, all you have
to do is tidy it up a bit and BAM - without any special effort
you get a unittest that tests that feature/bug you just worked on.
