Dealing with Autodecode

[Jonathan M Davis via Digitalmars-d]

On Wednesday, June 01, 2016 08:14:06 Andrei Alexandrescu via Digitalmars-d 
wrote:
> 4. Rally behind RCStr as the preferred string type of the D language.
> RCStr manages its own memory, is fast, and has the right interface (i.e.
> offers several views for iteration without an implicit one, doesn't
> throw on invalid code points, etc).
>
> This is the key component. We get rid of GC-backed strings, which is
> part of the crucial goal for D we need to achieve, and reap the benefit
> of a better design as a perk. Breaking existing code does not have the
> right benefit for the cost.
>
> Let's keep the eyes on the ball, folks. We want to rid D of the GC.
> That's the prize.

Since when has it been the goal to get rid of GC-allocated strings? We
definitely want an alternative to GC-allocated strings for code that can't
afford to use the GC, but auto-decoding issues aside, why would I want to
use RCString instead of string if the GC isn't a problem for my program?
Walter pointed out at dconf that using a GC is often faster than reference
counting; it's just that it can incur a large cost at once when a collection
is run, whereas the cost of ref-counting is amortized across the time that
the program is running.

I expect that RCString will be very important for us going forward, but I
don't see much reason to use it as the default string type in code over just
using string except for the fact that we have the auto-decoding mess to deal
with. It seems more like RCString is an optimization for certain types of
programs than what you'd want to use by default.

- Jonathan M Davis