Nick Sabalausky wrote:
"BCS" <[email protected]> wrote in message
news:[email protected]...
Hello Nick,
I *definitely* want that for string mixins of both the
template-generated and ctfe-generated varieties.
Why? I don't see any reason aside from documentation to do it.
Well, for one thing, not having it forces any code using my custom-assert
library to look like this crap...
mixin(deferAssert!(`foo == 3 || foo > 5`, "foo is bad"));
...which understandably no one wants to touch and I *absolutely* don't blame
them one bit. Compare that to this...
deferAssert!(`foo == 3 || foo > 5`, "foo is bad");
...ahhh, now I can actually see what the hell's going on!
Now come on, the second one also looks ugly and confusing as hell. Sure,
mixins are powerful (and sometimes I couldn't avoid using them myself),
but really, I never understood what people like about writing code into
STRING LITERALS. At least with the mixin you see in which context the
code will be compiled (though only roughly), unlike the second line of
code, which just obfuscates the code further.
And the only reason why you need this for your asserts is that you want
to get the location of the failing assert. That's mostly because of D's
lacking backtrace abilities of D (defAssert just had to resolve the
location of the previous stackframe).
On the other hand, I heard D2 has an ugly trick to get the caller's
location:
dd ddd
void defAssert(bool condition, cha^Wstring message, string file =
__FILE__, int line = __LINE__);
defAssert(condition, message);
