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@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@puremagic.com
http://lists.puremagic.com/cgi-bin/mailman/listinfo/dlang-study
_______________________________________________
Dlang-study mailing list
Dlang-study@puremagic.com
http://lists.puremagic.com/cgi-bin/mailman/listinfo/dlang-study