no-autodecode -- game plan

Steven Schveighoffer schveiguy at gmail.com
Wed Aug 19 13:06:55 UTC 2020


On 8/19/20 8:40 AM, Adam D. Ruppe wrote:
> On Wednesday, 19 August 2020 at 12:23:54 UTC, Steven Schveighoffer wrote:
>> On 8/18/20 6:21 PM, Andrei Alexandrescu wrote:
>>> Why not do it in std.v2021.*?
>>>
>>
>> What do you mean? Have a complete alternative phobos library?
>>
>> 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.
> 
> Andrei's suggestion is a good idea to allow forward massive changes 
> without breaking any existing code.

I think it's an OK idea. But I don't want to wait forever for this to 
gel. And these PRs are not going to break code, it shouldn't affect 
anything, since I'm not disabling autodecoding at all except in a 
separate test.

When we get to the point where all of Phobos can be built without 
autodecoding, then we have to make the decision how to proceed with the 
breakage.

> The only regret is we didn't think to version it like this from the start.
> 
> A copy of everything is an acceptable cost.

The copy of everything is not acceptable to me. I had to change 
something like 53 lines of std.utf. That's about 1.5% of the 4k+ line file.

If we have to maintain 2 copies of std.utf, most of which are EXACTLY 
the same, it would be a nightmare. And that's one module.

The only way this works is if we split the files at the point of release 
(when no-autodecoding is completely ready), and only backport bug fixes 
to the prior version.

In this sense, it's better IMO to do this based on semantic versioning 
and git branches rather than copies of files.

-Steve


More information about the Digitalmars-d mailing list