On Wednesday, 11 May 2016 at 11:16:41 UTC, Dicebot wrote:
It is probably also worth re-iterating on my long standing
position that adding more `nothrow` in fundamental facilities
is a false goal and almost always does more harm than good.
Exceptions are main (and pretty much only) error handling
facility in D. By adding `nothrow` base runtime class methods
you make impossible for D developers to use standard language
facilities and force uncalled hacks to workaround it.
`nothrow` is much more intrusive than `@safe` or `pure` in that
sense and should not be applied blindly to everything simply
because it is possible.
Sometimes you really, actually must ensure that things aren't
going to throw, such as in a signal handler, unmanaged thread,
between fork and exec, bare-metal, ...
Your point is orthogonal to the goal of adding nothrow/@nogc
without breaking user code, and I don't disagree with it.