On 23 September 2014 15:37, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@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@puremagic.com <mailto:digitalmars-d@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 :)