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

[Jonathan M Davis via Digitalmars-d]

On Wednesday, May 11, 2016 11:16:41 Dicebot via Digitalmars-d wrote:
> On Wednesday, 11 May 2016 at 07:05:07 UTC, Dicebot wrote:
> > On Tuesday, 10 May 2016 at 17:46:17 UTC, Vladimir Panteleev
> >
> > wrote:
> >> So I guess the way forward here for the Druntime code is to
> >> abandon the synchronized() statement and use locks directly?
> >
> > I believe this is the way. Synchronized statements don't add
> > any crucial value compared to plain locks. At the same time
> > forbidding throwing from even more runtime overrides would be
> > both annoying and unnecessary restrictive.
>
> It is probably also worth re-iterating on my long standing
> position that adding more `nothrow` in fundamental facilities is
> a false goal and almost always does more harm than good.
> Exceptions are main (and pretty much only) error handling
> facility in D. By adding `nothrow` base runtime class methods you
> make impossible for D developers to use standard language
> facilities and force uncalled hacks to workaround it.
>
> `nothrow` is much more intrusive than `@safe` or `pure` in that
> sense and should not be applied blindly to everything simply
> because it is possible.

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.

That being said, I think that anything that really shouldn't ever throw
should be marked nothrow, but we need to be sure that it really doesn't ever
make sense for it to throw before we mark it as nothrow. If it does make
sense for it to throw under any circumstances, then we can't mark it as
nothrow, and then anyone who wants nothrow is going to have to use try-catch
blocks to use it in nothrow code.

- Jonathan M Davis