On 12/31/11 2:04 AM, Walter Bright wrote:
On 12/30/2011 11:09 PM, Andrei Alexandrescu wrote:
On 12/30/11 10:09 PM, Walter Bright wrote:
I'm not so sure about that. Timon Gehr's X macro tried to handle
UTF-8 correctly, but it turned out that the naive version that
used [i] and .length worked correctly. This is typical, not
exceptional.
The lower frequency of bugs makes them that much more difficult to
spot. This is essentially similar to the UTF16/UCS-2 morass: in a
vast majority of the time the programmer may consider UTF16 a
coding with one code unit per code point (which is what UCS-2 is).
The existence of surrogates didn't make much of a difference
because, again, very often the wrong assumption just worked. Well
that all didn't go over all that well.
I'm not so sure it's quite the same. Java was designed before there
were surrogate pairs, they kinda got the rug pulled out from under
them. So, they simply have no decent way to deal with it. There isn't
even a notion of a dchar character type. Java was designed with
codeunit==codepoint, it is embedded in the design of the language,
library, and culture.
This is not true of D. It's designed from the ground up to deal
properly with UTF.
I disagree. It is designed to make dealing with UTF possible.
D has very simple language features to deal with
it.
Disagree. I mean simple they are, no contest. They could and should be
much better, make correct code easier to write, and make incorrect code
more difficult to write. Claiming we reached perfection there doesn't
quite fit.
We need .raw and we must abolish .length and [] for narrow
strings.
I don't believe that fixes anything and breaks every D project out
there.
I agree. This is the only reason that keeps me from furthering the issue.
We're chasing phantoms here, and I worry a lot about over-engineering
trivia.
I disagree. I understand that seems trivia to you, but that doesn't make
your opinion any less wrong, not to mention provincial through
insistence it's applicable beyond a small team of experts. Again: I know
no other - I literally mean not one - person who writes string code like
you do (and myself after learning it from you); the current system is
adequate; the proposed system is perfect - save for breaking backwards
compatibility, which makes the discussion moot. But it being moot does
not afford me to concede this point. I am right.
And, we already have a type to deal with it: dstring
No.
Andrei
