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

[Steven Schveighoffer via Digitalmars-d]

On 5/10/16 1:46 PM, Vladimir Panteleev wrote:
> 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?
>

Does synchronized(someMutex) go through the same mechanism? Because it 
shouldn't, and then we can have the compiler properly interpret what the 
nothrow @nogc status is.

I think Monitor.lock/unlock should be nothrow/@nogc. I'm not familiar 
with the vibe.d code, but I'd believe that if you need those to throw or 
allocate, then you should have to go through another mechanism.

-Steve