RFC: reference counted Throwable

[via Digitalmars-d]

On Saturday, 20 September 2014 at 09:19:21 UTC, Dicebot wrote:
> On Saturday, 20 September 2014 at 09:05:24 UTC, Marc Schütz 
> wrote:
>> On Saturday, 20 September 2014 at 08:32:55 UTC, Dicebot wrote:
>>> On Saturday, 20 September 2014 at 08:20:47 UTC, Marc Schütz 
>>> wrote:
>>>> I don't think ARC is needed.
>>>>
>>>> library RC + borrowing + uniqueness/moving = WIN
>>>
>>> You can't do polymorphic entity RC (like exceptions) without 
>>> at least some help from compiler because language currently 
>>> does not provide tools for lifetime control of classes. At 
>>> least _some_ form of ARC is necessary.
>>
>> I think we can, using templated alias this. We're not there 
>> yet, but it's probably feasable, seeing that Igor Stepanov 
>> already implemented multiple alias this [1]. With that and 
>> maybe a little opDispatch magic, it should be possible to 
>> making wrappers that are implicitly convertible to wrappers of 
>> parents of their inner types.
>>
>> Granted, for exceptions there's more needed: There needs to be 
>> support for throwing and catching these wrappers, and for 
>> catching wrappers of derived types, too. But note that 
>> throw/catch itself doesn't involve copying, it's a moving 
>> operation, which might make it easier.
>>
>> [1] https://github.com/D-Programming-Language/dmd/pull/3998
>
> Yeah but implicitly convertible to what? If you convert it to 
> `Throwable` your reference counting facilities are circumvented 
> resulting in dangling exception reference at point where 
> `Throwable` gets caught.

As I said, throw/catch is at its core a moving operation. For 
classes this isn't important (they are references), but for an RC 
wrapper it would be, so we could specify that.

Move-constructing from an lvalue in the context of D can be seen 
as a three-step process:

1) create a temporary, initialize with T.init
2) bit-swap the variable with the temporary
3) destroy the variable

It can be seen that the value that is to be moved (the RC 
wrapper) must be non-const (only at the head, it may still be 
tail-const).

Now, any generic RC type that wants to be implicitly convertible 
to its payload type must do this via borrowing in order to be 
safe (see my proposal at [1]). Using const-borrowing, we can 
guarantee that the wrapper will not be thrown (or moved, in 
general) as long as borrowed references to its payload exist:

     struct RC(T) {
         // ...
         T _payload;
         scope!(const this) borrow() {
             return _payload;
         }
         alias borrow this;
     }

This already solves avoiding dangling references to the 
exception: No references can be left behind when the exception is 
thrown, and the wrapper will not be destroyed, but moved, thus 
not releasing the exception's memory.

The second part is really "just" some way to transport the 
wrapper via the exception mechanism, including support for 
catching wrappers of derived exception types.

>
> Special casing catching such wrappers to still preserve 
> original ref-counted type while pretending to be Throwable at 
> call site sounds like a terrible hack, much worse than any sort 
> of ARC complexity.

IMO it would only a hack _if_ they were indeed special cased. I'm 
sure we can find a more generic mechanism that would allow this 
to be implemented cleanly. Note that the other requirements I 
described above (borrowing, move semantics) are also things that 
just happen to be usable here: they are desirable in general, 
exceptions are just one possible application.

[1] http://wiki.dlang.org/User:Schuetzm/scope