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
