Proposal: Exceptions and @nogc

[Moritz Maxeiner via Digitalmars-d]

On Monday, 3 April 2017 at 23:33:10 UTC, Jack Stouffer wrote:
> On Monday, 3 April 2017 at 21:00:53 UTC, Walter Bright wrote:
>> I don't see a point to having disparate allocation strategies 
>> for exception objects.
>
> Example: company wants to use their custom GC (like 
> sociomantic) with Phobos. They want to do this even for 
> exceptions because they believe that things will be faster if 
> they're able to completely control when any memory is freed.

AFAIK if an exception is going to be triggered, you've already 
entered the horribly slow path of stack unwinding that should 
never occur in the normal operation of any program that cares 
about performance. I doubt the performance of the exceptions' 
memory management will register compared to that.

> Your solution does not help these people use Phobos because the 
> compiler will be inserting calls to free in places they don't 
> want, which will slow down their program.

If their program slows noticeably from any changes to the slow 
path I'm forced to ask why it spends so much time on the slow 
path; this sounds like there is something fundamentally wrong 
with the program.

>
> Solution:
>
> 1. allocate exceptions in Phobos with theAllocator
> 2. if theAllocator is still the default of the GC, then the 
> user doesn't have to do anything else because the exception 
> will be garbage collected. No code is broken (I think) for 
> everyone who doesn't set theAllocator.
> 3. If theAllocator is different, then the onus is on the user 
> to properly free the exception

Consider the following:
- Application sets theAllocator to something different
- Application calls into (non-Phobos) library
- (non-Phobos) library calls into Phobos
- Phobos throws an exception (allocated using theAllocator)
- (non-Phobos) library knows how to handle the exception 
semantically and thus catches it
- To properly free the exception the (non-Phobos) library author 
must defensively call theAllocator.dispose.

AFAICT this solution will end up with everyone always calling 
theAllocator.dispose when catching from Phobos.