Escaping the Tyranny of the GC: std.rcstring, first blood

[Manu via Digitalmars-d]

On 23 September 2014 15:37, Andrei Alexandrescu via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On 9/22/14, 9:53 PM, Manu via Digitalmars-d wrote:
>
>> On 23 September 2014 14:41, Andrei Alexandrescu via Digitalmars-d
>> <digitalmars-d at puremagic.com <mailto:digitalmars-d at puremagic.com>> wrote:
>>
>>     On 9/22/14, 8:03 PM, Manu via Digitalmars-d wrote:
>>
>>         I still think most of those users would accept RC instead of GC.
>>         Why not
>>         support RC in the language, and make all of this library noise
>>         redundant?
>>
>>
>>     A combo approach language + library delivers the most punch.
>>
>>
>> How so? In what instances are complicated templates superior to a
>> language RC type?
>>
>
> It just works out that way. I don't know exactly why. In fact I have an
> idea why, but conveying it requires building a bunch of context.
>

The trouble with library types like RefCounted!, is that they appear to be
conceptually backwards to me.
RefCounted!T suggests that T is a parameter to RefCounted, ie, RefCounted
is the significant object, not 'T', which is what I actually want. T is
just some parameter... I want a ref-counted T, not a T RefCounted, if that
makes sense.
When we have T* or T[], we don't lose the 'T'-ness of the object, we're
just appending a certain type of pointer, and I really think that RC should
be applied the same way.

All these library solutions make T into something else, and that has a
tendency to complicate generic code in my experience. In most cases,
templates are used to capture some type of thing, but in these RefCounted
style cases, it's backwards, it effectively obscures the type. We end out
with inevitable code like is(T == RefCounted!U, U) to get U from T, which
is the thing we typically want to know about, and every instance of a
template like this must be special-cased; they can't be rolled into
PointerTarget!T, or other patterns like Unqual!T can't affect these cases
(not applicable here, but the reliable pattern is what I refer to).

I guess I'm saying, RC should be a type of pointer, not a type of thing...
otherwise generic code that deals with particular things always seems to
run into complications when it expects particular things, and gets
something that looks like a completely different sort of thing.


         Library RC can't really optimise well, RC requires language
>>         support to
>>         elide ref fiddling.
>>
>>
>>     For class objects that's what's going to happen indeed.
>>
>>
>> Where is this discussion? Last time I raised it, it was fiercely shut
>> down and dismissed.
>>
>
> Consider yourself vindicated! (Not really, the design will be different
> from what you asked.) The relevant discussion is entitled "RFC: reference
> counted Throwable", and you've already participated to it :o).


I see. I didn't really get that from that thread, but I only skimmed it
quite quickly, since I missed most of the action.

I also don't think I ever insisted on a particular design, I asked to have
it *explored* (I think I made that point quite clearly), and suggested a
design that made sense to me. The idea was shut down in principle, no
competing design's explored.
I'm very happy to see renewed interest in the topic :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140923/85106315/attachment-0001.html>