Thoughts on versioning

[Adam D Ruppe]

On Wednesday, 27 October 2021 at 13:57:50 UTC, Andrei 
Alexandrescu wrote:
> It's interesting that both you and Sebastiaan mention an 
> "inverted delta" of sorts whereby current std is redone to use 
> std2.

Well, generally new functions end up being more fundamental than 
old, so this is just naturally simpler.

In the case of the Windows functions, the Unicode functions can 
take any string the ANSI functions can, which is not true vice 
versa. So naturally, you'd be forced to write the less functional 
one in terms of the more functional one.

In the case of various Phobos modules:

* Removing autodecoding in v2 makes it more general. You can 
always write an autodecode function in terms of a plain function 
- just do a wrapper that adds the decode adapter.

Doing it the other way happens to be possible here too, using a 
byCodeUnit wrapper, but generally it is easier to add something 
in a wrapper than remove something that was already added.

* Some people hate std.socket because it uses classes. Well, if 
you build a std2.socket on top of it, those people will still be 
angry. But std2.socket could be a struct api and then the 
original std.socket class is built on top of it.

(in that case it would probably be a waste of time; just keeping 
the original std.socket unmodified - it is already a fairly thin 
layer on the underlying C functions anyway - and writing 
std2.socket right on top of the underlying C functions too is 
easy enough.)

* A generalization of std.socket: you can always build GC 
functions on top of @nogc foundations (e.g. `string 
toLower(string s) { return s.asLowerCase.array; } `). Not true 
other way around.

* If you want to trim down an interface, again, you can define 
std.v2 to be minimal then layer on stuff for compatibility on 
top. Users who stick to std.v2, importing just it and not the old 
one, they will not pay the cost of carrying these functions 
around.

But if you defined std.v2 on top of std.v1, it is impossible to 
remove functions. If a user imports std.v2, they automatically 
drag all the std.v1 baggage along too, whether they like it or 
not.

* Just as a matter of merge conflicts, making the bulk of your 
edits on the forward moving version is a more natural way to work.

The con here is maintaining compatibility with the old one is a 
bit harder since you're making edits and the old one might rely 
on it. But.... worse case you just copy/paste when the divergence 
is too much and lock in the old version letting the new one 
evolve.