The Case Against Autodecode

[Andrew Godfrey via Digitalmars-d]

On Saturday, 28 May 2016 at 19:04:14 UTC, Walter Bright wrote:
> On 5/28/2016 5:04 AM, Andrei Alexandrescu wrote:
>> So it harkens back to the original mistake: strings should NOT 
>> be arrays with
>> the respective primitives.
>
> An array of code units provides consistency, predictability, 
> flexibility, and performance. It's a solid base upon which the 
> programmer can build what he needs as required.
>
> A string class does not do that (from the article: "I admit the 
> correct answer is not always clear").

You're right. An "array of code units" is a very useful low-level 
primitive. I've dealt with a lot of code that uses these (more or 
less correctly) in various languages.

But when providing such a thing, I think it's very important to 
make it *look* like a low-level primitive, and use the type 
system to distinguish it from higher-level ones.


E.g. A string literal should not implicitly convert into an array 
of code units. What should it implicitly convert to? I'm not 
sure. Something close to how it looks in the source code, 
probably. A sequential range of graphemes? From all the detail in 
this thread, I wonder now if "a grapheme" is even an unambiguous 
concept across different environments. But one thing I'm sure of 
(and this is from other languages/API's, not from D 
specifically): A function which converts from one representation 
to another, but doesn't keep track of the change (e.g. Different 
compile-time type; e.g. State in a "string" class about whether 
it is in normalized form), is a "bug farm".