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

[Mathias Lang via Digitalmars-d]

On Tuesday, 10 May 2016 at 17:46:17 UTC, 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?

As far as I remember, the issue was not the design, but that it 
required a design change on Vibe.d's side.

See 
https://github.com/rejectedsoftware/vibe.d/pull/972#issuecomment-75714736 where Sonke mentions that "actually mutexes in vibe.d are never nothrow".
However, since some of the internals of Vibe.d are now supported 
upstream, the problem might disappear in a foreseeable future.