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
