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 >> <[email protected]> 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
