Proposal: Exceptions and @nogc

[Jack Stouffer via Digitalmars-d]

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. 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.

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

In my mind, the whole point of std.allocator was to make Phobos 
allocation strategy agnostic. So, at some point, we're going to 
have to find a way to integrate std.allocator into Phobos to get 
rid of the GC usage anyway. Exceptions seem like as good as any 
other place to start.

Or, find a way to get RC with objects.

> In any case, the compiler will insert calls to specific 
> functions to allocate/free exception objects. Those functions 
> will be in druntime, but anyone can override them with their 
> own implementation.

And this will be done by changing the meaning of people's code 
and adding a special case to new.

This smells like C++.