RFC: reference counted Throwable

Daniel N via Digitalmars-d digitalmars-d at puremagic.com
Sat Sep 20 04:55:31 PDT 2014


On Saturday, 20 September 2014 at 04:48:33 UTC, Andrei
Alexandrescu wrote:
>> I basically agree with Walter on this one, no switch please, 
>> it's
>> maintenance nightmare for library devs.
>
> Why is it a maintenance nightmare?
>

Sorry, let's defer this, I might have overstated the negative
side-effects before carefully considering methods to mitigate the
impact.

>> My proposal would be to permanently use ARC for Throwable, no 
>> flags.
>
> How about other objects? Throwable is but the first step, and a 
> good one to inform larger designs. We can't force RC on all 
> objects on all applications.
>

I was viewing everything from a totally different perspective:
Normally what prevents an API to be nogc is exceptions, even
_emplace_ falls victim of this, in my line of reasoning I was
counting on the ripple effect to get us quite far, the remaining
issues could be fixed by refining the API to make it possible to
avoid allocations if desired.

However, since you had a different goal in mind, your solution
starts making more sense to me, it's also very easy to flip a
switch and benchmark individual applications, maybe people from
both camps will be surprised at the results.

>> What does the GC bring to exceptions that makes it sufficiently
>> invaluable to warrant two parallel implementations? It can't 
>> be about
>> performance, since _thrown_ exceptions are already in the slow 
>> path...
>> Backwards compatibility?
>
> Conversion from Throwable to Object.
>
>
> Andrei

The conversion could allocate on the GC, which would be
functionally backwards compatible and if the performance
degradation is a concern the code could be updated to avoid the
superfluous allocation by staying in the RCObject hierarchy.

Daniel


More information about the Digitalmars-d mailing list