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

deadal nix deadalnix at gmail.com
Fri Oct 30 14:44:44 PDT 2015


I don't think the case for baking @rc into the language has been made at
this point. Providing guarantee about escaping is necessary and sufficient
to build RC. Providing more needs to be justified. Right now, the only
reason I've seen for this is optimization, but intrinsics are largely
sufficient for this, and don't even need to be standardized.

2015-10-30 14:31 GMT-07:00 Andrei Alexandrescu <andrei at erdani.com>:

> A few matters Walter and I just discussed and wanted to submit for
> scrutiny:
>
> * @rc classes shall not be single-rooted. Rationale: there is no strong
> advantage in it and it would force all @rc classes to embed a vptr. This
> has been already discussed and largely agreed upon in this group.
>
> * @rc classes will not use COM's AddRef and Release automatically.
> Rationale: (a) that's what C++'s shared_ptr does and not one soul ever
> complained; (b) the calls are virtual so less efficient and fusion is not
> possible; (c) it's a lot extra work for one platform.
>
> * Undecided about integrating automatically with Objective-C's refcounts.
> I'm hoping more details from platform experts.
>
> I'd like to get a DIP draft started by someone else but Walter or myself.
> Looking for a rigorous person who knows PL well and can manage this complex
> document and be its ombudsman. I'm proposing Timon for this role - would
> you want to?
>
>
> Andrei
> _______________________________________________
> 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/20151030/a38a3704/attachment.html>


More information about the Dlang-study mailing list