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