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<[email protected]> 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
