std.v2020.algorithm etc[ WAS: Is run.d going to be expand for runtime and the phobos library?]

[jmh530]

On Saturday, 13 June 2020 at 19:52:16 UTC, Andrei Alexandrescu 
wrote:
> [snip]
>> D's modularity is, or should be, rock solid. So then we could 
>> simply define "vYEAR" as versions of standard library modules. 
>> So:
>> 
>> // import the backward-compatible lib
>> import std.algorithm;
>> // import this year's algorithm with breaking changes
>> import std.v2020.algorithm;
>> // live dangerously, import work-in-progress
>> import std.v2020.algorithm;
>
> Eh, meant v2021 here.

Something like below allows the user to specify what they want 
for all of phobos at the command or to import the specific one 
they want.

module std.algorithm;

version(std_latest) {
     version = std_2_92;
}
version(std_stable) {
     version = std_2_89;
}
version(std_2019) {
     version = std_2_89;
}
version(std_2_92) {
     public import 2_92.std.algorithm;
}
version(std_2_91) {
     public import 2_91.std.algorithm;
}
version(std_2_90) {
     public import 2_90.std.algorithm;
}
version(std_2_89) {
     public import 2_89.std.algorithm;
}
...

One problem is that if you allow people to make bug fixes to old 
phobos versions, then there is no way for the subsequent releases 
to get the updates as if you could with a git branch. You would 
have to do them all manually.

I also saw a suggestion about C++'s epoch proposal on another 
thread that was interesting.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1881r0.html