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

[Jonathan M Davis via Digitalmars-d]

On Wednesday, May 11, 2016 14:22:39 Dicebot via Digitalmars-d wrote:
> On Wednesday, 11 May 2016 at 14:12:47 UTC, Jonathan M Davis wrote:
> > Regardless of the desirability of marking stuff with nothrow,
> > one _huge_ difference between nothrow and pure or @nogc is that
> > it's trivial to use a function that throws inside of nothrow
> > code by wrapping it in a try-catch block. @safe is in a similar
> > boat thanks to @trusted, but pure and @nogc can only be gotten
> > around via some nasty casts.
>
> It doesn't apply if throwing is desired as part of API, which is
> exactly the case for monitor and issue I had before with adding
> nothrow to some Fiber methods.

I wasn't disagreeing with that. If there are valid uses cases for a monitor
throwing, then its functions should not be nothrow. My point is that if
those functions aren't marked with nothrow, it's trivial to use them in
nothrow code (even if it's a bit ugly) by wrapping them in try-catch blocks,
whereas attributes like pure or @nogc are not so easy to get around. pure
wouldn't apply in this case, but @nogc might. However, until the issues with
using exceptions without the GC are resolved, as long as monitor's functions
can be nothrow, it makes no sense to mark them with @nogc.

So, the lack of nothrow is far from a blocker for anyone wanting nothrow
code. It's @nogc that's more of an issue, but we're going to need language
improvements before we can consider using @nogc in this case.

- Jonathan M Davis