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

[Vladimir Panteleev via Digitalmars-d]

Here is the situation, AIUI:

1. We allow users to provide their own Monitors, which hook into 
the synchronized(obj) statement.

2. These monitors' methods are unadorned (no nothrow/@nogc).

3. As a result, synchronized(obj) statements will not compile in 
nothrow/@nogc code, because we can't know that the Monitor 
implementation doesn't throw / use the GC.

4. As Matthias mentioned, fixing this was attempted before (by 
making the Monitor methods `nothrow`). However, this broke code 
(vibe.d specifically), as its implementation was actually not 
`nothrow`: https://issues.dlang.org/show_bug.cgi?id=11216

This is a problem e.g. in Druntime code, because it currently 
forces a lot of code that should be `nothrow` to not be annotated 
as such, even when the synchronization objects used use the 
standard D monitor implementation, which is actually `nothrow`.

So I guess the way forward here for the Druntime code is to 
abandon the synchronized() statement and use locks directly?