Thoughts about D

[Jonathan M Davis]

On Thursday, November 30, 2017 08:12:04 H. S. Teoh via Digitalmars-d wrote:
> But of course, this assumes that we even need to throw AssertError in
> the first place.  If this can be made optional, we can skip the stack
> unwinding code altogether. (But I can see that this will only work for
> specific applications, since you may not be able to avoid the need for
> the unwinding code to call dtors and stuff to free up allocated
> resources, etc., which, if it's necessary, means you can't avoid linking
> in the stack unwinding code. But it *can*, at least in theory, be
> something separate from the stacktrace construction code, so you can
> still save a bit of code there. Make the stacktrace construction code a
> zero-argument template, then it won't get linked into the executable
> unless it's actually used.)

If we're not talking about unit tests, then we could pretty much just print
everything out on the failed assertion and kill the program right then and
there rather throwing an Error - and really for most Errors, we could do
exactly that. It would be really annoying for unit tests though, since being
able to do scope(error) to print out extra information on the failure can be
really useful. But otherwise, printing out the stack trace and killing the
application right then and there rather than throwing an Error shouldn't be
expensive at all, since it's only going to happen once.

But I have a hard time believing that the cost of assertions relates to
constructing an AssertError unless the compiler is inlining a bunch of stuff
at the assertion site. If that's what's happening, then it would increase
the code size around assertions and potentially affect performance.

- Jonathan M Davis