Am 29.12.2011 19:36, schrieb Andrei Alexandrescu:
On 12/29/11 12:28 PM, Don wrote:
On 28.12.2011 20:00, Andrei Alexandrescu wrote:
Oh, one more thing - one good thing that could come out of this thread
is abolition (through however slow a deprecation path) of s.length and
s[i] for narrow strings. Requiring s.rep.length instead of s.length and
s.rep[i] instead of s[i] would improve the quality of narrow strings
tremendously. Also, s.rep[i] should return ubyte/ushort, not char/wchar.
Then, people would access the decoding routines on the needed occasions,
or would consciously use the representation.
Yum.
If I understand this correctly, most others don't. Effectively, .rep
just means, "I know what I'm doing", and there's no change to existing
semantics, purely a syntax change.
Exactly!
If you change s[i] into s.rep[i], it does the same thing as now. There's
no loss of functionality -- it's just stops you from accidentally doing
the wrong thing. Like .ptr for getting the address of an array.
Typically all the ".rep" everywhere would get annoying, so you would
write:
ubyte [] u = s.rep;
and use u from then on.
I don't like the name 'rep'. Maybe 'raw' or 'utf'?
Apart from that, I think this would be perfect.
Yes, I mean "rep" as a short for "representation" but upon first sight
the connection is tenuous. "raw" sounds great.
Now I'm twice sorry this will not happen...
Maybe it could happen if we
1. make dstring the default strings type -- code units and characters
would be the same
or 2. forward string.length to std.utf.count and opIndex to
std.utf.toUTFindex
so programmers could use the slices/indexing/length (no lazyness
problems), and if they really want codeunits use .raw/.rep (or better
.utf8/16/32 with std.string.representation(std.utf.toUTF8/16/32)
But generally I liked the idea of just having an alias for strings...
Andrei
-- Joshua Reusch
