[review] new string type (take 2)

[Andrei Alexandrescu]

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