std.unittests [updated] for review
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Tue Feb 1 08:31:54 PST 2011
On 2/1/11 9:21 AM, Don wrote:
> Jonathan M Davis wrote:
>> On Sunday 30 January 2011 05:28:36 SHOO wrote:
>
>>> To be frank, I don't think that such a helper is necessary.
>>> I think these helpers will harm intuitive readability of unittest code.
>>> For unittest code, it is necessary to be able to understand easily even
>>> if without the document.
>>
>> Do you really find
>>
>> assertPred!"=="(min(5, 7), 5);
>>
>> to be all that harder to understand than
>>
>> assert(min(5, 7) == 5);
>
> I do. *Much* harder. Factor of two, at least.
> In absolute terms, not so much, because it was the original assert is
> very easy to understand. But the relative factor matters enormously.
> Much as comparing:
> a.add(b);
> a += b;
>
> And I think this is a very important issue.
>
> >I don't see how these functions could be anything but an improvement.
> > But even if they get into Phobos, you obviously don't have to use them.
>
> This is not true. Including them in Phobos gives a legitimacy to that
> style of programming. It's a role model.
>
> Including stuff like this could give D a reputation for lack of
> readability. My belief is that right now, the #1 risk for Phobos is that
> it becomes too clever and inaccessible.
>
> IMHO, something simple which has any appearance of being complicated,
> needs a VERY strong justification.
One more thought. Don, you are in the unique position to (a) be strongly
opinionated about this and (b) have insider knowledge about the
compiler. You could, therefore, modify the definition of assert to
automatically rewrite failed calls of the form assert(expr == expr),
assert(expr < expr) etc. etc. as discussed in this thread.
The rewritten forms would give the runtime the compared values to do
whatever with. There is the sensitive issue of converting values of
arbitrary types to strings at the runtime level, but we may be able to
find a good solution to that.
Andrei
More information about the Digitalmars-d
mailing list