The Case Against Autodecode

[ZombineDev via Digitalmars-d]

On Wednesday, 1 June 2016 at 22:24:49 UTC, Andrei Alexandrescu 
wrote:
> On 06/01/2016 06:09 PM, ZombineDev wrote:
>> Regardless of how different people may call it, it's not what 
>> this
>> thread is about.
>
> Yes, definitely - but then again we can't after each 
> invalidated claim to go "yeah well but that other point stands".

My claim was not invalidated. I just didn't want to waste time 
arguing about it, because it is off topic. My point was that 
foreach is a purely language construct that doesn't know about 
the std.range.primitives module, therefore doesn't use it and 
therefore foreach doesn't perform **auto**decoding. It does 
perform explicit decoding because you need to specify a different 
type of iteration variable to trigger the behavior. If the 
variable type is not specified, you won't get any decoding (it 
will instead iterate over the code units).

>> Deprecating front, popFront and empty for narrow
>> strings is what we are talking about here.
>
> That will not happen. Walter and I consider the cost excessive 
> and the benefit too small.

On the other hand many people think that the cost of using a 
language (like C++) that has accumulated excessive number of bad 
design decisions and pitfalls is too high.
Keeping bad design decisions alienates existing users and 
repulses new ones.

I know you are in a difficult decision making position, but 
imagine telling people ten years from now:

A) For the last ten years we worked on fixing every bad design 
and improving all the good ones. That's why we managed to expand 
our market share/mind share 10x-100x to what we had before.

B) This strange feature you need to know about is here because we 
chose comparability with old code, over building the best 
language possible. The language managed to continue growing (but 
not as fast as we hoped) only because of the other good features. 
You should use this feature and here's a long list of things you 
need to consider when avoiding it.

The majority of D users ten years from now are not yet D users. 
That's the target group you need to consider. And given the 
overwhelming support for fixing this problem by the existing 
users, you need to reevaluate your cost vs benefit metrics.

This theme (breaking code) has come up many times before and I 
think that instead of complaining about the cost, we should focus 
on lower it with tooling. The problem I currently see is that 
there is not enough support for building and improving tools like 
dfix and leveraging them for language/std lib design process.

>> This has little to do with
>> explicit string transcoding in foreach.
>
> It is implicit, not explicit.
>
>> I don't think anyone has a
>> problem with it, because it is **opt-in** and easy to change 
>> to get the
>> desired behavior.
>
> It's not opt-in.

You need to opt-in by specifying a the type of the iteration 
variable and that type needs to be different than the 
typeof(array[0]). That's opt-in in my book.

> There is no way to tell foreach "iterate this array by 
> converting char to dchar by the usual language rules, no 
> autodecoding". You can if you e.g. use uint for the iteration 
> variable. Same deal as with .representation.

Again, off topic. No sane person wants automatic conversion 
(bitcast) from char to dchar, because dchar gives the impression 
of a fully decoded code point, which the result of such cast 
would certainly not provide.

>> On the other hand, trying to prevent Phobos from autodecoding 
>> without
>> typesystem defeating hacks like .representation is an uphill 
>> battle
>> right now.
>
> Characterizing .representation as a typesystem defeating hack 
> is a stretch. What memory safety issues is it introducing?

Memory safety is not the only benefit of a type system. This goal 
is only a small subset of the larger goal of preventing logical 
errors and allowing greater expressiveness.

You may as well invent a memory safe subset of D that works only 
ubyte, ushort, uint, ulong and arrays of those types, but I don't 
think anyone would want to use such language. Using 
.representation in parts of your code, makes those parts like the 
aforementioned language that no one wants to use.