Which tools do you miss in D?

Jonathan M Davis jmdavisProg at gmx.com
Fri Jan 31 17:28:26 PST 2014


On Monday, January 27, 2014 08:01:30 Andrei Alexandrescu wrote:
> On 1/26/14 11:16 PM, Knud Soerensen wrote:
> > I miss check_expect from racket.
> > 
> > It is used for unit testing
> > 
> > check_expect(expression, result)
> > Will test if expression equals result
> > if it is not it print "Got expression but expected result" with file and
> > line information.
> > 
> > In D making unit tests is more tedious.
> > When I develop in D I typical start with.
> > 
> > writeln(expression)
> > writeln(result)
> > 
> > then when the code is working I replace it with
> > assert(expression==result)
> > 
> > Then if I do some refactoring which don't work I change again
> > writeln(expression)
> > writeln(result)
> > 
> > When it is working again
> > assert(expression==result)
> > 
> > This back and forth process in D is very tedious compared to Racket.
> 
> I do the same. There's a enhancement request in bugzilla for having
> assert detect these patterns itself.

assertPred took care of this - e.g. assertPred!"=="(lhs, rhs, expected) or 
assertPred!"<"(lhs, rhs, expected) - but it failed the review process with the 
consensus that assert should be changed to do this for you. However, as I 
understand it, it was ultimately decided by those who looked at implementing 
it that that wasn't going to work. std.datetime still uses a stripped-down 
version of it internally as _assertPred, but I'm fairly certain that it's 
introduced too much template bloat as a result and that it's the main cause 
for the large amount of memory that std.datetime requires when compiling its 
unit tests. So, while I like the idea of a templated function which prints out 
what the expected result and actual result on a test failure rather than just 
that the test failed, at this point, I'm not at all certain that it's worth 
the overhead. And if assert can't reasonably be made to take of it itself, a 
templated function like assertPred would pretty much be the way that you'd 
have to go.

- Jonathan M Davis


More information about the Digitalmars-d mailing list