Escaping the Tyranny of the GC: std.rcstring, first blood

[monarch_dodra via Digitalmars-d]

On Monday, 15 September 2014 at 02:26:19 UTC, Andrei Alexandrescu 
wrote:
> So, please fire away. I'd appreciate it if you used RCString in 
> lieu of string and note the differences. The closer we get to 
> parity in semantics, the better.
>
>
> Thanks,
>
> Andrei

***Blocker thoughts***
(unless I'm misunderstood)

- Does not provide Forward range iteration that I can find. This 
makes it unuseable for algorithms:
     find (myRCString, "hello"); //Nope
Also, adding "save" to make it forward might not be a good idea, 
since it would also mean it becomes an RA range (which it isn't).

- Does not provide any way to (even "unsafely") extract a raw 
array. Makes it difficult to interface with existing functions. 
It would also be important for "RCString aware" functions to be 
properly optimized (eg memchr for searching etc...)

- No way to "GC-dup" the RCString. giving "dup"/"idup" members on 
RCstring, for when you really just need to revert to pure 
un-collected GC.

Did I miss something? It seems actually *doing* something with an 
RCString is really difficult.


***Random implementation thought:***
"size_t maxSmall = 23" is (IMO) gratuitous: It can only lead to 
non-optimization and binary bloat. We'd end up having 
incompatible RCStrings, which is bad.

At the very least, I'd say make it a parameter *after* the 
"realloc" function (as arguably, maxSmall  depends on the 
allocation scheme, and not the other way around).

In particular, it seems RCBuffer does not depend on maxSmall, so 
it might be possible to move that out of RCXString.

***Extra thoughts***
There have been requests for non auto-decoding strings. Maybe 
this would be a good opportunity for "RCXUString" ?