@nogc and exceptions

[Jakob Ovrum via Digitalmars-d]

On Friday, 12 September 2014 at 11:03:09 UTC, monarch_dodra wrote:
> I think option "b)" is the right direction. However, I don't 
> think it is reasonable to have the "catch" code be responsible 
> for the cleanup proper, as that would lead to a closed design 
> (limited allocation possibilities).

Exceptions using other alocators simply don't set the flag.

> I like the option of having "exception allocators" that can 
> later be explicitly called in a "release all exceptions" style, 
> or plugged into the GC, to be cleaned up automatically like any 
> other GC allocated exception. This would make the exceptions 
> themselves still @nogc, but the GC would have a hook to 
> (potentially) collect them. For those that don't want that, 
> then they can make calls to the cleanup at deterministic times.

We can't change existing instances of `throw` to use such a 
manually managed heap without silently causing user code to leak.

> Finally, if somebody *does* want to keep exceptions around, he 
> would still be free to do so *provided* he re-allocates the 
> exceptions himself using a memory scheme he chooses to use (a 
> simple GC new, for example).

Yes, but we can't let existing code that escapes exceptions run 
into memory corruption because we changed the allocator. We need 
`scope`.

> ... well, either that, or have each exception carry a callback 
> to its allocator, so that catch can do the cleanup, regardless 
> of who did the allocation, and how. GC exceptions would have no 
> callback, meaning a "catch" would still be @nogc. An existing 
> code that escapes exceptions would not immediately break.

I think this would depend on having multiple proposed exception 
allocation strategies in the first place.

We know when the cleanup happens and we roughly know the 
allocation pattern (exceptional paths are rarely hit etc.), so I 
think we should focus on finding/creating an allocator ideal for 
this pattern, then apply it to Phobos.