Proposal: Exceptions and @nogc

[Adam D. Ruppe via Digitalmars-d]

On Monday, 3 April 2017 at 21:31:39 UTC, Jonathan M Davis wrote:
> though the exception message poses a similar problem 
> (especially if you'd normally construct it with format), and I 
> don't know how you get around that other than not using 
> anything more informative than string literals

This is why strings are considered harmful to me. Instead, you 
can make a new exception class inline that stores the data and 
lazily sinks it to the toString delegate on demand. This doesn't 
work for all data types, but it does for a lot of useful ones.

It is also another reason why this proposal is not that great - 
having a helper function allocate the exception means you can 
avoid allocating the string.

This file shows like 3 concepts I have with exceptions, but the 
RaisedExceptionDetails.toString shows this:

http://arsdnet.net/exception.d


It is an easily solved library problem... and would be *easier* 
to use than format().