The Case Against Autodecode

[Timon Gehr via Digitalmars-d]

On 30.05.2016 21:28, Andrei Alexandrescu wrote:
> On 05/30/2016 03:04 PM, Timon Gehr wrote:
>> On 30.05.2016 18:01, Andrei Alexandrescu wrote:
>>> On 05/28/2016 03:04 PM, 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.
>>>
>>> Nope. Not buying it.
>>
>> I'm buying it. IMO alias string=immutable(char)[] is the most useful
>> choice, and auto-decoding ideally wouldn't exist.
>
> Wouldn't D then be seen (and rightfully so) as largely not supporting
> Unicode, seeing as its many many core generic algorithms seem to
> randomly work or not on arrays of characters?

In D, enum does not mean enumeration, const does not mean constant, pure 
is not pure, lazy is not lazy, and char does not mean character.

> Wouldn't ranges - the most
> important artifact of D's stdlib - default for strings on the least
> meaningful approach to strings (dumb code units)?

I don't see how that's the least meaningful approach. It's the data that 
you actually have sitting in memory. It's the data that you can slice 
and index and get a length for in constant time.

> Would a smattering of
> Unicode primitives in std.utf and friends entitle us to claim D had dyed
> Unicode in its wool? (All are not rhetorical.)
>...

We should support Unicode by having all the required functionality and 
properly documenting the data formats used. What is the goal here? I.e. 
what does a language that has "Unicode dyed in its wool" have that other 
languages do not? Why isn't it enough to provide data types for 
UTF8/16/32 and Unicode algorithms operating on them?

> I.e. wouldn't be in a worse place than now? (This is rhetorical.) The
> best argument for autodecoding is to contemplate where we'd be without
> it: the ghetto of Unicode string handling.
> ...

Those questions seem to be mostly marketing concerns. I'm more concerned 
with whether I find it convenient to use. Autodecoding does not improve 
Unicode support.

> I'm not going to debate this further (though I'll look for meaningful
> answers to the questions above). But this thread has been informative in
> that it did little to change my conviction that autodecoding is a good
> thing for D, all things considered (i.e. the wrong decision to not
> encapsulate string as a separate type distinct from bare array of code
> units). I'd lie if I said it did nothing. It did, but only a little.
>
> Funny thing is that's not even what's important. What's important is
> that autodecoding is here to stay - there's no realistic way to
> eliminate it from D. So the focus should be making autodecoding the best
> it could ever be.
>
>
> Andrei
>

Sure, I didn't mean to engage in a debate (it seems there is no decision 
to be made here that might affect me in the future).