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.

Reply via email to