std.unittests [updated] for review

[Michel Fortin]

On 2011-02-01 11:31:54 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> 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.

TypeInfo holds a pointer to the toString function, so if the compiler 
passes the two operands as D-style variadic arguments to the assert 
handler, the assert handler can use toString to print them. The 
operator should be passed as a string.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/