DIP 1008 Preliminary Review Round 1

[MysticZach via Digitalmars-d]

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/gtqsojgqqaorubcsneie@forum.dlang.org
>
> 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?