On Friday, 27 May 2016 at 13:32:30 UTC, Andrei Alexandrescu wrote:
> On 5/27/16 7:07 AM, Marc Schütz wrote:
>> On Thursday, 26 May 2016 at 16:11:22 UTC, Andrei Alexandrescu wrote:
>>> RFC: what primitives should RCStr have?
>>
>> It should _safely_ convert to `const(char)[]`.
>
> That is not possible, sorry. -- Andrei

 I wonder if it could...

 For a while now I've wondered why there isn't an option to include flags to every type (for debugging)? The flags could relay a lot of information, like if a variable was originally immutable, const, shared, other? If it was originally allocated using the GC, malloc, C/C++/Other or stack. If it used a constructor, init, or not at all (= void)? Along with control options like where/when an assignment tries to happen, copies it's state (or it's variables with indirection), or printing an output each time it changes, etc.

 With the current state of things, I'll just take your word on it.

On 05/27/2016 05:02 PM, Era Scarecrow wrote:
>   With the current state of things, I'll just take your word on it.

Reasoning is simple - yes we could safely convert to const(char)[] but that means effectively all refcounting is lost for that string. So we can convert but in an explicit manner, e.g. str.toGCThisWillCompletelySuckMan. -- Andrei

On Friday, 27 May 2016 at 21:25:50 UTC, Andrei Alexandrescu wrote:
> On 05/27/2016 05:02 PM, Era Scarecrow wrote:
>>   With the current state of things, I'll just take your word on it.
>
> Reasoning is simple - yes we could safely convert to const(char)[] but that means effectively all refcounting is lost for that string. So we can convert but in an explicit manner, e.g. str.toGCThisWillCompletelySuckMan. -- Andrei

not if [] would be ref-counted too ;-)

On Friday, 27 May 2016 at 21:25:50 UTC, Andrei Alexandrescu wrote:
> On 05/27/2016 05:02 PM, Era Scarecrow wrote:
>>   With the current state of things, I'll just take your word on it.
>
> Reasoning is simple - yes we could safely convert to const(char)[] but that means effectively all refcounting is lost for that string. So we can convert but in an explicit manner, e.g. str.toGCThisWillCompletelySuckMan. -- Andrei

But conversions to scope const(char)[] could be made safe, right? (If scope were ever fully implemented, that is.)

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

2) make assignments and slicing work through that refcount pointer, adding cpu cost

3) somehow need to know the appropriate freeing strategy, adding some kind of indirect call when refcount = 0, and would make creating a slice more tedious as you'd need to know this (meaning you also probably need to allocate this structure! no more free ptr[0 .. length] operation on malloc'd blocks.)


So I'd be pretty strongly against that.

On Friday, 27 May 2016 at 22:09:48 UTC, tsbockman wrote:
> But conversions to scope const(char)[] could be made safe, right? (If scope were ever fully implemented, that is.)

Indeed, and I really think we should spend more effort on making this work. Not as much as Rust spends on it, but a lil more than our current return ref dip.

On 05/27/2016 06:09 PM, tsbockman wrote:
> On Friday, 27 May 2016 at 21:25:50 UTC, Andrei Alexandrescu wrote:
>> On 05/27/2016 05:02 PM, Era Scarecrow wrote:
>>>   With the current state of things, I'll just take your word on it.
>>
>> Reasoning is simple - yes we could safely convert to const(char)[] but
>> that means effectively all refcounting is lost for that string. So we
>> can convert but in an explicit manner, e.g.
>> str.toGCThisWillCompletelySuckMan. -- Andrei
>
> But conversions to scope const(char)[] could be made safe, right? (If
> scope were ever fully implemented, that is.)

Yah, in principle. -- Andrei

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.

On 27 May 2016 at 23:32, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 5/27/16 7:07 AM, Marc Schütz wrote:
>>
>> On Thursday, 26 May 2016 at 16:11:22 UTC, Andrei Alexandrescu wrote:
>>>
>>> RFC: what primitives should RCStr have?
>>
>>
>> It should _safely_ convert to `const(char)[]`.
>
>
> That is not possible, sorry. -- Andrei

It should safely convert to 'scope const(char)[]', then we only need a fat-slice or like at the very top of the callstack...

On 27 May 2016 at 02:11, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> I've been working on RCStr (endearingly pronounced "Our Sister"),

Ah, I totally skipped over this thread...

Wow... this really doesn't work in any accent I'm close to, but I can
hear it if I imagine you saying it ;)
If I said RCStr, it sounds like 'are'-'see'-strrr, but 'our sister'
would be 'hour'-sistə... isn't it strange that word recognition seems
to work pretty much reliably down a sliding scale until an arbitrary
point where it just drops off. There's not a lot of fuzzy area in the
middle.