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