[Dlang-study] [lifetime] Few root decisions to take on RC classes

[Amaury SECHET]

The proposed solution is not safe at all. It guarantee that the payload is
alive, but doesn't guarantee it is not moved.

The Rust road is to disable whatever is borrowed from in a mutable fashion,
and const whatever is borrowed from in a const fashion. The alternative is
to borrow from the copy rather than just root it. Alternatively, root the
object but [borrow from/pass down] the rooted object rather than the
original, so effectively to don't pass down twice the same thing.

This has a nice added bonus that ref parameters can be considered noalias
and the optimizer can do more (alias analysis is probably the number 1
barrier for modern optimizers). Almost all benchmark where Rust beat C++ is
due to extra alias informations.


2016-01-14 20:39 GMT+01:00 Andrei Alexandrescu <andrei at erdani.com>:

> Happy New Year in 2016 and beyond to everyone following this list! Well we
> hope to get ownership done this year :o).
>
> I was reviewing older exchanges, in particular the one quoted below
> regarding exceptions providing messages as lazy/transferrable sequences of
> characters.
>
> Droppable is definitely interesting, but let me make a simple point: a
> low-tech reference counted string would fit the bill perfectly well.
> Consider:
>
> * Want lazy computation? Compute the string upon the first call to msg(),
> then memoize it.
>
> * Want static allocation? Provide a means to encode that in the
> ref-counted string, e.g. by setting the reference count to uint.max etc.
>
> I understand it's old tech that's not exciting, but (a) we need to figure
> out safe reference counted types anyway and (b) reference counted strings
> are well understood and very successful across the industry.
>
> For fixing the issues with reference counting and safety, the silence in
> this group as of late suggests there are no new ideas and new work on this.
> So I suggest we proceed by refining http://wiki.dlang.org/DIP77.
>
>
> Thanks,
>
> Andrei
>
>
> On 11/06/2015 07:45 AM, Marc Schütz wrote:
>
>> On Friday, 6 November 2015 at 02:44:39 UTC, Michel Fortin wrote:
>>
>>> But how do you prevent the payload from being leaked in a way that it
>>> outlives the droppable? For instance, someone might want to log the
>>> exception message and put it into a queue for a separate logging
>>> thread to process. You're giving raw access to the string, so it's
>>> very easy mess things up if you are not careful.
>>>
>>
>> Well, that requires borrowing/sealed references:
>>
>> struct Droppable(T) {
>>      private T payload;
>>      void delegate(ref T object) dropper;
>>      ref T borrow() return { return payload; }
>>      alias borrow this;
>>      @disabled this(this);
>>      ~this() {
>>          if(dropper) dropper(payload);
>>      }
>> }
>>
>> But that's a separate topic. My point was that this is a mechanism to
>> abstract away from specific ownership schemes without making the
>> ownership part of the type (i.e. `Exception` can be used as-is no matter
>> whether the message if garbage collected or refcounted or static).
>> _______________________________________________
>> Dlang-study mailing list
>> Dlang-study at puremagic.com
>> http://lists.puremagic.com/cgi-bin/mailman/listinfo/dlang-study
>>
> _______________________________________________
> Dlang-study mailing list
> Dlang-study at puremagic.com
> http://lists.puremagic.com/cgi-bin/mailman/listinfo/dlang-study
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dlang-study/attachments/20160115/cad7fede/attachment.html>