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

[Dicebot via Digitalmars-d]

On Wednesday, 11 May 2016 at 14:54:07 UTC, Jonathan M Davis wrote:
> 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

Sorry, I got your point exactly backwards :)