Some time ago, Walter asked me to postpone DIP 1008, "Exceptions and @nogc". Subsequently, an implementation was merged behind the -dip1008 flag. In helping to determine how to move forward with the DIP, we'd like to know if anyone is actually using the feature and, if so, what your experience with it has been.

And a small request, if you feel the urge to say something about the DIP process in this thread, please start a new thread instead. I'd like to keep this one on topic so I don't have to dig for the relevant info.

Thanks!

On Wednesday, 6 March 2019 at 12:36:56 UTC, Mike Parker wrote:
> Some time ago, Walter asked me to postpone DIP 1008, "Exceptions and @nogc". Subsequently, an implementation was merged behind the -dip1008 flag. In helping to determine how to move forward with the DIP, we'd like to know if anyone is actually using the feature and, if so, what your experience with it has been.

No, because It doesn't work.

https://issues.dlang.org/show_bug.cgi?id=19317
https://issues.dlang.org/show_bug.cgi?id=19463

On Wednesday, 6 March 2019 at 12:36:56 UTC, Mike Parker wrote:
> Some time ago, Walter asked me to postpone DIP 1008, "Exceptions and @nogc". Subsequently, an implementation was merged behind the -dip1008 flag. In helping to determine how to move forward with the DIP, we'd like to know if anyone is actually using the feature and, if so, what your experience with it has been.
>
> And a small request, if you feel the urge to say something about the DIP process in this thread, please start a new thread instead. I'd like to keep this one on topic so I don't have to dig for the relevant info.
>
> Thanks!

Haven't used it, however we could have a use for it one day as we throw manually allocated @nogc exception.

On Wednesday, 6 March 2019 at 12:36:56 UTC, Mike Parker wrote:
> Some time ago, Walter asked me to postpone DIP 1008, "Exceptions and @nogc". Subsequently, an implementation was merged behind the -dip1008 flag. In helping to determine how to move forward with the DIP, we'd like to know if anyone is actually using the feature and, if so, what your experience with it has been.


One goal behind my work on Vibe.d and the vibe-http module is to increase @nogc
compatibility. Exceptions are widely used in Vibe.d and this is one of the
deal-breakers against this goal.
I haven't actually used @nogc exceptions yet, but it would definitely help
projects such as Vibe.d that are trying to give users control over memory
management and allocation strategies, without having to rewrite existing
exception handlers using e.g. `stdx.allocator`.

As an example, the HPACK library that is currently being used in vibe's new http2
module would be fully @nogc compatible if it wasn't for exceptions. See these
design constraints:

https://github.com/vibe-d/vibe-http/wiki

If there's some interest on resuming this DIP I would be happy to start testing
@nogc exceptions in my modules.

On Wednesday, 6 March 2019 at 12:36:56 UTC, Mike Parker wrote:
> Some time ago, Walter asked me to postpone DIP 1008, "Exceptions and @nogc". Subsequently, an implementation was merged behind the -dip1008 flag. In helping to determine how to move forward with the DIP, we'd like to know if anyone is actually using the feature

Quite a bit.

> and, if so, what your experience with it has been.

Well, it doesn't work, as mentioned above. But I've come to use it anyway because I'm ok with "this code is nearly @nogc, the exception (hah) being exceptions".

If it worked (especially the part regarding calling destructors on caught RC exceptions) I'd've already announced this:

http://code.dlang.org/packages/nogc

But it doesn't, so I haven't.

AFAIC all it needs are for the bugs to be fixed.

On Wednesday, 6 March 2019 at 12:36:56 UTC, Mike Parker wrote:
> Some time ago, Walter asked me to postpone DIP 1008, "Exceptions and @nogc". Subsequently, an implementation was merged behind the -dip1008 flag. In helping to determine how to move forward with the DIP, we'd like to know if anyone is actually using the feature and, if so, what your experience with it has been.
>

We use it in our compressible flow solver (http://cfcfd.mechmining.uq.edu.au/eilmer/).  It is a working research code.  We have lots of @nogc functions in the core of our solver but really want to be able to throw exceptions.  So we throw exceptions with simple messages in the optimized build and, when we want more information, we run the simulation again with a debug build of the code that constructs more informative messages in debug{} blocks.

On 3/6/2019 4:45 AM, Nicholas Wilson wrote:
> https://issues.dlang.org/show_bug.cgi?id=19463

https://github.com/dlang/dmd/pull/9481