no-autodecode -- game plan

[Steven Schveighoffer]

On 8/19/20 9:10 AM, Andrei Alexandrescu wrote:
> 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.
>>
>> The only regret is we didn't think to version it like this from the 
>> start.
>>
>> A copy of everything is an acceptable cost.
> 
> Don't copy everything, alias everything that doesn't need change and 
> only add the declarations that should be changed.

I've done exactly this for another library: converting mysql-native to 
@safe. See the result: https://github.com/mysql-d/mysql-native/pull/214. 
It's not as simple as you say. I had to split out the common parts into 
an "impl" package, and then create "safe" and "unsafe" packages. Not 
only that, but the unsafe ones are going to suffer from performance 
because everything underneath has to be safe. And this is a pretty 
unchanging library, not like Phobos.

Consider std.algorithm. Nearly all the functions are going to have to 
import a separate std.range, to get the no-autodecoding functionality 
(i.e. anything that depends on hasLength, hasIndexing, etc.). But the 
functions themselves will be identical. So it will be mostly a copy, 
with a few aliases.

I don't think this idea works without copying a large majority of code, 
whereas versioning it means changing very little.

> The only problem I see with this is documentation. We need to have an 
> easy way to define and navigate documentation for different versions of 
> the stdlib.

That is also a problem that I faced in mysql-native. I don't have a good 
solution.

> 
> That article by Yegge once more convinced me - we need to stop (thinking 
> of) changing and start adding. We've been paralyzed by the fear of 
> change while the opportunity (made even better by a nice module system) 
> was always there.

The context of that article is somewhat similar, but not completely. 
With google services there is no using a previous version of their cloud 
service if they take it away. With the D compiler, you can alaways 
compile with previous versions until you can handle the new version. We 
aren't taking away the downloads of previous versions of the compiler. 
In fact, we can maintain older versions if we want to!

I think the better answer is to move to semantic versioning of the 
language, and have a scheduled "breaking" upgrade once a year (or 
longer), and commit to maintaining bug fixes for the previous major 
revision for a period of time. Give people the option of using older 
code if they want to keep some old package compiling and running. If 
they are actively maintaining it, then they likely need to upgrade.

-Steve