Our Sister

[Manu via Digitalmars-d]

On 31 May 2016 at 01:00, Marco Leise via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> Am Sat, 28 May 2016 14:15:45 +1000
> schrieb Manu via Digitalmars-d <digitalmars-d at puremagic.com>:
>
>> On 28 May 2016 at 10:16, Adam D. Ruppe via Digitalmars-d
>> <digitalmars-d at 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.