no-autodecode -- game plan

[Steven Schveighoffer]

On 8/19/20 9:35 AM, Andrei Alexandrescu wrote:
> Even the patch can reuse std.cmp if you pass std.cmp a range of code 
> units so you undo its penchant to autodecode.

Here's what I actually did do:

https://github.com/dlang/phobos/blob/bf258e56f2dbc28cf810e9329a0696afbe114907/std/algorithm/comparison.d#L890-L895

Essentially, if you compared 2 ranges of code units which differed, 
equal would integer promote one to the other, and compare that.

I fixed that bug, and in the process, handled both autodecoding and 
nonautodecoding strings.

This brings "equal" outside of the domain of having to think about 
autodecoding. If you have autodecoding enabled, it works. If you have it 
disabled, it works. There is no need to have a separate equal function 
in std.v2021. There is no need to call a separate equal function if you 
want no-autodecoding, equal(someString, someOtherString) works no matter 
what you care about autodecoding.

The more of this that we can do, the smaller the "drastic" change of 
moving to non-autodecoding becomes.

> 
> * * *
> 
> Lastly, I should add the following. You wrote, and I quote it again 
> because it is so important:
> 
>> autodecoding infects so many other modules, so it would be really hard 
>> to single out only some modules, we'd likely have to make a copy of 
>> nearly everything.
> 
> This is a very powerful argument AGAINST your current approach to CHANGE 
> things. You are basically saying the semantics of the standard library 
> will be deeply affected by your work. Put another way, the rework of the 
> standard library will be very incompatible with its current version. So 
> you are killing all compatibility.

Nearly ALL the changes are going to be on template constraints or 
imported traits, which means the code in the alternative package will be 
identical (but maintained separately). The end result would be a 
maintenance nightmare. Maintaining almost identical code bases, 
especially where one is used and the other isn't is just going to result 
in diverging code bases where the new one doesn't work and has to be 
fixed. See for instance how Daniel Murphy migrated the compiler from C++ 
to D without having to worry about other people breaking his changes. It 
would not have happened with a copy of everything hand-maintained.

My plea is: let's see how far I can get with an alternative view of 
Phobos (tested simultaneously), without actually pulling the trigger to 
deprecate autodecoding. At that point, we still can make a decision to 
do it a different way. Nothing is set in stone.

> Changing the stdlib to remove autodecoding would kill the D programming 
> language.
> 
> You don't want to kill the D programming language, do you?

I can't agree with either of these statements. At all.

-Steve