[Dlang-study] [rcstring] Defining rcstring

[Marc Schütz]

(back to list)

Am Wed, 3 Feb 2016 11:24:16 -0500
schrieb Andrei Alexandrescu <andrei at erdani.com>:

> On 02/03/2016 10:20 AM, Marc Schütz wrote:
> > I assume you also don't want to allow access to the underlying
> > storage (most likely `char[]`?). I don't see this as a good thing
> > at all. Without the ability of getting at least a `const(char)[]`
> > out of it, RCString would be next to useless in practice.
> 
> Could you please substantiate that?

Well, no existing code will know about RCString. That leaves only
rangified functions, which currently isn't even a large part of Phobos,
and probably even less of third-party libraries. It can be changed, of
course, but it's a lot of work, and it often makes code considerably
uglier and complicated, less readible, and therefore more error prone.

> 
> I was thinking we could provide access to the underlying slice as a 
> @system primitive. Code using it would be @system or rebrand it as 
> @trusted etc.

That's an option. I wonder if we should even make it implicit
via `alias this`. It surely is more ergonomic, and we don't lose safety.

> 
> >> * Since string-compatibility is off the table, how about we fix
> >> string's issues with autodecoding? RCString should offer no indexed
> >> access and no length. Instead it offers the ranges byCodeUnit,
> >> byChar, byWChar, and byDChar. The first one does not do any
> >> decoding and offers length and random access. (What should be its
> >> element type?) The other ones are bidirectional ranges that do the
> >> appropriate decoding.
> >
> > Definitely. I would prefer this even for normal strings... The
> > element type of `byCodeUnit` should be char/wchar/dchar, of course.
> 
> I guess we could add byOctet that iterates ubytes.

std.string.representation could be extended to accept any string-like
type:
http://dlang.org/phobos/std_string.html#.representation

> 
> >> * Immutable does not play well with reference counting. I'm of a
> >> mind to reject immutable rcstring for now and figure out later how
> >> to go about it. Then const rcstring is okay because we always
> >> consider const a view on mutable strings (even though they're
> >> gone). We'll cast const away when manipulating the refcount.
> >
> > As noted by others, this is not a good idea. We can't solve this
> > recurring problem by ignoring it.
> 
> RCString neither tries to solve the matter, nor ignore it. It simply 
> acknowledges it. Once we do have a solution (possibly informed by 
> RCString itself), we will use it to "turn on" immutable RCString,
> which will be a great test for the feature and a non-breaking
> improvement. It will all work out nicely.
> 
> The point here is to break the stalemate by taking a step in a good 
> direction.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digitale Signatur von OpenPGP
URL: <http://lists.puremagic.com/pipermail/dlang-study/attachments/20160204/02973e7c/attachment.sig>