On 3/8/14, 7:53 PM, Vladimir Panteleev wrote:
From my POV, I could say I see consensus, with just you defending a
decision you made a while ago :) But I'd prefer a constructive discussion.
What exactly is the consensus? From your wiki page I see "One of the
proposals in the thread is to switch the iteration type of string ranges
from dchar to the string's character type."
I can tell you straight out: That will not happen for as long as I'm
working on D. I'm ready to fight on this not only Walter Bright, but him
and Walter White together. (Fortunately the former agrees the breakage
is too large; haven't asked the latter yet.)
Anyway, I don't want to "inflict massive breakage" either. I want the
amount of breakage to be a justified cost of fixing a mistake and
permanently improving the language's design going forward.
It seems you and I have a different view of the tradeoffs involved.
In all seriousness, at this point I'm worried that you will defend the
status quo even if the breakage turns out minimal. Instead of dealing
with absolutes, advantages and disadvantages should be weighed against
another (even with the breaking-backwards-compatibility penalty being
very high).
Of course. If you come with something better, I'd be glad to take a look.
Unit. s.byChar.front is a (possibly ref, possibly qualified) char.
So... does byChar for wstrings do the same thing as byWchar?
No, it transcodes from UTF16 to UTF8.
And what if
you want to iterate a wstring by char?
byChar.
Wouldn't it be better to have
byChar/byWchar/byDchar be a range of char/wchar/dchar regardless of the
string type
that's right
, and have byCodeUnit which iterates by the code unit type?
We must add that too. I agree the resulting design is roundabout (you
have char[] which is by default iterated by code point, and you need to
wrap it to get to its units that were there in the first place).
I also wanted to add some ASCII string love (by ascribing it a separate
type) but Walter has good arguments opposing that.
Andrei
