no-autodecode -- game plan
schveiguy at gmail.com
Wed Aug 19 14:12:40 UTC 2020
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:
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
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
> You don't want to kill the D programming language, do you?
I can't agree with either of these statements. At all.
More information about the Digitalmars-d