assert(condition[, message]) patch

[pragma]

In article <2dpe83lsz5rb.v7hpd58hsxeu.dlg at 40tude.net>, Derek Parnell says...
>
>One reason for extending Build is so I can use it to build things other
>than D applications. But I've kept in mind the 'normal' case of using it
>with D so that is where the performance bias is.

Its interesting that you mention this.  I recently drafted a parser-frontend
generator that generates .d code as output; it works a treat, but I'm presently
having to go through multiple build steps.  So, would "things other than D
applications" happen to cover preprocessors other than just .mac file handling?
;)

>So Walter, if you want to stop this nasty abomination of source code abuse,
>please allow coder defined messages in the built-in assert statement ;-)

Nice.

In a more serious, and on-topic note, I too believe that assert() could stand
some expansion to allow for more succinct error reporting.  It all comes down to
the matter of reporting "how and why" something breaks rather than just "where".

As a preface, I for one do not use an IDE when developing my software.  D seems
to do pretty well for me without it, although I'm still longing for
out-of-the-box stack tracing.

Anyway, so I run some code that trips on an assert, and it coughs up
"foobar.d(42)" as where I need to look.  The assert has done its job, as I go to
line #42 and go hunting for the reason behind why it tripped up.  As I'm
basically flying blind (no watch window and no stack trace), my next step is
almost always: add a writefln() before the assert to get some more information
as to how this happened.  Meshing those two steps seems like an obvious choice
to me.

Another way to look at it is in the use of static assert().  With the
compile-time regexp processor(s) out there, they halt on static assert() and
then cough up some rudimentary explaination as to *why* using pragma(msg).  I
wouldn't even consider either implementation usable without the msg/assert
idiom, so I don't really use them apart from each other.  In fact, I'll argue
that its impossible to meaningfully extend the compiler/D-grammar through
templates without using the two together; the library user just wouldn't have a
clue otherwise.

To sum up: I honestly feel that the two capabilities, assert() and writefln(),
should be merged into an extended assert() statment, for the sake of encouraging
better coding and library use.

- EricAnderton at yahoo