VLERange: a range in between BidirectionalRange and

[Jonathan M Davis]

On Monday 17 January 2011 04:08:08 Steven Schveighoffer wrote:
> On Sat, 15 Jan 2011 17:19:48 -0500, foobar <foo at bar.com> wrote:
> > I like Michel's proposed semantics and I also agree with you that it
> > should be a distinct string type and not break consistency of regular
> > arrays.
> > 
> > Regarding your last point: Do you mean that a grapheme would be a
> > sub-type of string? (a specialization where the string represents a
> > single element)? If so, than it sounds good to me.
> 
> A grapheme would be its own specialized type.  I'd probably remove the
> range primitives to really differentiate it.  Unfortunately, due to the
> inability to statically check this, the invariant would have to be a
> runtime check.  Most likely this check would be disabled in release mode.
> 
> This can cause problems, and I can see why it is attractive to use strings
> to implement graphemes, but that also has its problems.  With grapheme
> being its own type, we are providing a way to optimize functions, and
> allow further restrictions on function parameters.
> 
> At the end of the day, perhaps grapheme *should* just be a string.  We'll
> have to see how this breaks in practice, either way.

I think that it would make good sense for a grapheme to be struct which holds a 
string as Andrei suggested:

struct Grapheme(Char) if (isSomeChar!Char)
{
     private const Char[] rep;
     ...
}

I really think that trying to use strings to represent graphemes is asking for 
it. The element of a range should be a different type than the that of the range 
itself.

- Jonathan M Davis