VLERange: a range in between BidirectionalRange and

[Andrei Alexandrescu]

On 1/17/11 6:25 AM, Jonathan M Davis wrote:
> 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

If someone makes a careful submission of a Grapheme to Phobos as 
described above, it has a high chance of being accepted.

Andrei