June 05, 2017
On Friday, 19 May 2017 at 15:45:28 UTC, Mike Parker wrote:
> DIP 1008 is titled "Exceptions and @nogc".
>
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1008.md

I would like the DIP to fully articulate the choice that it's facing, that special-casing the language for `throw new` comes with some downsides, but that the alternative is to force programmers to rewrite all their exceptions if they want to mark their functions `@nogc`. This requires an analysis of the similarities and differences between `throw new` and other uses of `new`. My personal impression is that exceptions do indeed fall into a distinct category, where they are easier to contain and shorter-lived than ordinary `new` memory. But the downside is that the language loses a little elegance by having another special case, and there might be corner cases where the special case is undesirable. I can only assume that at minimum, should this DIP be _rejected_, it should be replaced by some official documentation and methods on how to properly throw exceptions in `@nogc` code.
June 11, 2017
On Friday, 26 May 2017 at 21:31:20 UTC, Steven Schveighoffer wrote:
> Part of this may mean clarifying what @nogc actually means. Does it mean no interaction with the GC system, or does it mean "cannot run a collection cycle"?

I was pleased to find GC.addRange is now @nogc, so it seems potential interaction with the GC is OK so long as allocation and collection don't happen. Non-@nogc addRange was quite a blocker for smart pointer implementation.

This does seem compatible with Walter's idea of not requiring linking of the GC runtime, at least in that the GC functions (such as addRange) can be stubbed out.
June 18, 2017
On Friday, 26 May 2017 at 08:45:40 UTC, Walter Bright wrote:
>> Why doesn't the rethrow count as a move? There is no way it can be reused in the scope that rethrows. -- Andrei
>
> It could be - it's just that there's nothing currently in the compiler to support the notion of moves. So the destructor will still wind up getting called on it.
>
> It's a good idea for a future enhancement, though.

Even worth a hack right now to avoid ref counting for those exceptions IMO.
1 2 3 4 5 6 7
Next ›   Last »