On 31 May 2016 at 01:00, Marco Leise via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > 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.
D loves templates, but templates aren't a given. Closed-source projects often can't have templates in the public API (ie, source should not be available), and this is my world.