On Wed, 12 Jan 2011 04:49:26 -0500, Steven Wawryk <[email protected]>
wrote:
I like the direction you're taking but have some quibbles about details.
Specifically, I'd go for a more complete separation into random-access
code-unit ranges and bidirectional code-point ranges:
Thanks for taking the time. I will respond to your points, but please
make your rebuttals to the new thread I'm about to create with an updated
string type.
Is there a reason not to include is(Unqual!T == dchar)?
It's defined at the bottom as a simple alias to T[], since you do not need
these features for a dchar[] string (it's correct to treat a dchar string
as an array).
An opAssign from a T[] could facilitate conversion back and forth
between code-point and code-unit ranges.
Yes, that would be a good feature.
There is the alternative of deferring decoding to the user and returning
T[]'s holding exactly 1 code-point instead of dchars. I'm not sure
which is best, but I'd be interested in seeing a case for choosing one
or the other.
Definitely returning decoding and returning dchar is best. The whole
point of this string type is to handle the decoding for you. If you want
to do decoding manually, you can just stick with arrays.
I don't see a need for _charStart, opIndex, opSlice and codeUnits. If
the underlying T[] can be returned by a property, then these can be done
through the code-unit array, which is random-access.
But that puts extra pain on the user for not much reason. Currently,
strings slice in one operation, you are proposing that we slice in three
operations:
1. get the underlying array
2. slice it
3. reconstruct a string based on the slice.
Plus, if you remove opIndex, you are restricting the usefulness of the
range. Note that this string type already will decode dchars out of the
front and back, why not just give that ability to the middle of the string?
template string_t(T) if (is(Unqual!T == dchar))
{
alias T[] string_t;
}
Note the definition of string_t!dchar here ^^^^
-Steve
