Relaxing the definition of isSomeString and isNarrowString

[via Digitalmars-d]

On Sunday, 24 August 2014 at 13:04:10 UTC, Kiith-Sa wrote:
> On Sunday, 24 August 2014 at 12:49:30 UTC, Marc Schütz wrote:
>> On Sunday, 24 August 2014 at 12:24:03 UTC, Andrei Alexandrescu 
>> wrote:
>>> To that end I'm working on RCString, an industrial-strength 
>>> string type that's much like string, just reference counted 
>>> and with configurable allocation. It's safe, too - user code 
>>> cannot casually extract references to string internals. By 
>>> default allocation would use GC's primitives; one thing I 
>>> learned to appreciate about our GC is its ability to free 
>>> memory explicitly, which means RCString will free memory 
>>> deterministically most of the time, yet if you leak some 
>>> (e.g. by having RCString class members) the GC will pick up 
>>> the litter. I think reference counting backed up by a GC that 
>>> lifts litter and cycles and is a modern, emergent pattern 
>>> that D could use to great effect.
>>
>> Any reason why this is restricted to strings? I.e., is there 
>> something special about strings (apart from auto-decoding) 
>> that doesn't apply to arrays in general? If not, wouldn't an 
>> RCArray be a better idea?
>
> We already have an 'RCArray' (std.container.Array) although 
> it's not perfect.
> We don't have a reference counted string type that would work 
> with the string operation functions.

Well, if `isSomeString` were extended as Andrei suggests (and the 
string functions adapted a bit), I don't see why it shouldn't 
work.

But I'm not sure std.container.Array really is refcounted. The 
documentation doesn't say so, and it shows neither a postblit nor 
an opAssign.