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 :)
