Is synchronized(...){...} doomed to never be nothrow/@nogc?

[Vladimir Panteleev via Digitalmars-d]

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.