On Tuesday, 23 May 2017 at 22:40:43 UTC, Martin Nowak wrote:
The proposal is a very mechanical fix, throwing several special
cases at one specific problem.
Why does it have to be refcounted? Seems like there is only
ever one reference to the current exception (the catch
variable).
The only thing that seems necessary is to require scope on
catch variable declarations, so that people do not escape the
class reference, then this info might be used by the runtime to
free exception objects after the catch handler is done.
Amaury put a bit more words into that.
http://forum.dlang.org/post/[email protected]
Has staticError been considered? It has a potential issue with
multiple nested exceptions, but otherwise works fine.
https://github.com/dlang/druntime/blob/bc832b18430ce1c85bf2dded07bbcfe348ff0813/src/core/exception.d#L683
I'm trying to understand your and Amaury's point. Normally, when
you say `new` you get memory from the GC allocator. The @nogc
attribute is supposed to prevent this, if I understand it
correctly. Are you saying that `@nogc` as such is misconceived,
because what a good language feature should really be doing is
identifying and preventing new memory that _can't_ be
deterministically destroyed? Is the problem here with the @nogc
attribute? Because I think Walter's goal with this DIP is to make
it so that you can put @nogc on _called_ functions that throw
using `new`. Whereas your solution is to ignore that `new
Exception` allocation, on account of the fact that you can
deterministically destroy the Exception, provided you use `scope`
catch blocks at, or above, the call site. Your solution might
actually have its priorities straight, and `@nogc` may be
designed badly because it clumps all GC allocations into one big
basket. However, getting new memory from the GC still could
trigger a collection cycle, which is what @nogc was created for,
and simply knowing that you can reliably destroy the allocated
memory doesn't change that.
Thus, if I understand correctly, you and Amaury are arguing that
`@nogc` as currently designed is a false goal to be chasing, that
the more important goal is memory that can be deterministically
destroyed, and therefore it distresses you that the language may
be altered to chase the false prize of `@nogc` everywhere,
instead of focusing on a real prize worth attaining?
