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

[Dicebot via Digitalmars-d]

On Wednesday, 11 May 2016 at 07:05:07 UTC, Dicebot wrote:
> On Tuesday, 10 May 2016 at 17:46:17 UTC, Vladimir Panteleev 
> wrote:
>> So I guess the way forward here for the Druntime code is to 
>> abandon the synchronized() statement and use locks directly?
>
> I believe this is the way. Synchronized statements don't add 
> any crucial value compared to plain locks. At the same time 
> forbidding throwing from even more runtime overrides would be 
> both annoying and unnecessary restrictive.

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.