On 1/16/11 6:35 PM, Steven Wawryk wrote:
Andrei,
I note that your specific criticisms of Steve's proposal all relate to
the "random-access" of the bidirectional code-point range. This is
essentially my objection too.
As you are the key person to determine whether it is adopted, what do
you think of the remainder of his proposal?
One thing that I don't think is understood is that Walter is the key
person here. This is a compiler and druntime change, and a big one.
My only possible role is that I can call Walter on Skype with a strong
case. Walter has a strong "wanking detector". This whole changing the
string type, which is working well, with a type that has its own
problems, breaks a lot of code, and at the end of the day makes small
improvements - that will trigger the wanking detector for sure, and I
simply don't have enough good arguments to counter that.
Apart from the indexing and slicing of code-points I see a lot of merit
to the proposal, especially that it would mean that std.algorithm would
not need to special-case for strings any more.
This is a misunderstanding. std.algorithm needs no special casing for
strings. It uses isXxxRange which work correctly for strings. Functions
in std.algorithm are special-cased for strings when they could gain in
efficiency. This is because there is no VLERange abstraction.
It would need only be
concerned about whether it has a random-access range or a bidirectional
range. The user could choose whether to pass to std.algorithm any of:
* a random-access code-unit range
* a bidirectional code-point range
* a bidirectional grapheme range, etc according to the outcome of the
other discussions
In the interest of moving this on, would it become acceptable to you if:
1. indexing and slicing of the code-point range were removed?
2. any additional ranges are exposed to the user according to decisions
made about graphemes, etc?
3. other constructive criticisms were accommodated?
Steve
I believe the proposed scheme:
1. Changes the language in a major way;
2. Is highly disruptive;
3. Improves the status quo in only minor ways.
I'd be much more willing to improve things by e.g. defining the
representation() function I talked about a bit ago, and other less
disruptive additions.
Andrei
