On 1/12/11 11:28 AM, Don wrote:
Michel Fortin wrote:
On 2011-01-11 20:28:26 -0500, Steven Wawryk <[email protected]> said:
Why not choose which of these abstractions is most appropriate in a
given situation instead of trying to shoe-horn both concepts into a
single abstraction, and provide for easy conversion between them?
When character representation is the primary requirement then make it
a bidirectional range of code points. When storage representation and
random access is required then make it a random access range of code
units.
I think you're right. The need for a new concept isn't that great, and
it gets complicated really fast.
I think the only problem that we really have, is that "char[]",
"dchar[]" implies that code points is always the appropriate level of
abstraction.
I hope to assuage part of that issue with representation(). Again, it's
not documented yet (mainly because of the famous ddoc bug that prevents
auto functions from carrying documentation). Here it is:
/**
* Returns the representation type of a string, which is the same type
* as the string except the character type is replaced by $(D ubyte),
* $(D ushort), or $(D uint) depending on the character width.
*
* Example:
----
string s = "hello";
static assert(is(typeof(representation(s)) == immutable(ubyte)[]));
----
*/
/*private*/ auto representation(Char)(Char[] s) if (isSomeChar!Char)
{
// Get representation type
static if (Char.sizeof == 1) enum t = "ubyte";
else static if (Char.sizeof == 2) enum t = "ushort";
else static if (Char.sizeof == 4) enum t = "uint";
else static assert(false); // can't happen due to isSomeChar!Char
// Get representation qualifier
static if (is(Char == immutable)) enum q = "immutable";
else static if (is(Char == const)) enum q = "const";
else static if (is(Char == shared)) enum q = "shared";
else enum q = "";
// Result type is qualifier(RepType)[]
static if (q.length)
return mixin("cast(" ~ q ~ "(" ~ t ~ ")[]) s");
else
return mixin("cast(" ~ t ~ "[]) s");
}
Andrei
