Am Sat, 28 May 2016 14:15:45 +1000 schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>:
> On 28 May 2016 at 10:16, Adam D. Ruppe via Digitalmars-d > <digitalmars-d@puremagic.com> wrote: > > On Friday, 27 May 2016 at 21:51:59 UTC, Seb wrote: > >> > >> not if [] would be ref-counted too ;-) > > > > > > That would be kinda horrible. Right now, slicing is virtually free and > > compatible with all kinds of backing schemes. If it became refcounted, it'd: > > > > 1) have to keep a pointer to the refcount structure with the slice, adding > > memory cost > > This is only true for the owner. If we had 'scope', or something like > it (ie, borrowing in rust lingo), then the fat slice wouldn't need to > be passed around, it's only a burden on the top-level owner. > 'scope' is consistently rejected, but it solves so many long-standing > problems we have, and this reduction of 'fat'(/rc)-slices to normal > slices is a particularly important one. I second that thought. But I'd be ok with an unsafe slice and making sure myself, that I don't keep a reference around. A lot of functions only borrow data and can work on a naked pointer/ref/slice, while the owner(s) have the smart pointer. These can of course be converted to templates taking either char[] or RCStr, but I think borrowing is cleaner when the function in question doesn't care a bag of beans if the chars it works on were allocated on the GC heap or reference counted. -- Marco