std.unittests [updated] for review

[Brad Roberts]

On 2/1/2011 9:12 AM, Andrei Alexandrescu wrote:
> On 2/1/11 10:51 AM, Michel Fortin wrote:
>> On 2011-02-01 11:31:54 -0500, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> said:
>> 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.
> 
> In that case problem solved. Don, if you arrange things such that this user-level code:
> 
> int a = 42;
> double b = 3.14;
> assert(a <= b, "Something odd happened");
> 
> ultimately calls this runtime function:
> 
> assertCmpFailed("<=", "42", "3.14", "Something odd happened");
> 
> I promise I'll discuss with Sean and implement what it takes in druntime to get that completed.
> 
> We need to finalize that before Feb 7 though because on that date the vote for Jonathan's library closes. If you do
> implement that, probably we'll need to reject the library in the current form and propose back an amended version.
> 
> 
> Andrei

I agree with Don.  The proposed set of functions are great from an output perspective, but awful from a crisp syntax
standpoint.  They're a work around for the underlying problem: assert needs a UI face lift (though I remember when
assert didn't even support a text output -- adding that was my first contribution to the compiler/language).  There are
certainly complexities in pulling apart the bool expression though, and I'm not sure what a good solution is for that.

If there's any sort of consensus around focusing on assert instead (and I recognize that there isn't yet), some pre-set
arbitrary deadline isn't terribly relevant.  Having one by the 7th is kinda unlikely.

As a further point against the assertPred!op model, consider why the use of postfix/rpn calculators is restricted to a
very small subset of advanced calculators.  It's just now how most people think about expressions.

Later,
Brad