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

[Andrei Alexandrescu]

On 6/13/20 4:30 AM, Seb wrote:
> I myself consider Phobos as low priority to maintain as it's basically 
> frozen/dead code.

I was wondering what would be the drawbacks of defining an ultra-simple 
convention for versions of the standard library - with yearly 
granularity. Not being an expert in versioning I've always been coy to 
mention it, but how about trying it instead of the current stalemate. 
After all C++ does it (both with 3-year language versions and with 
things like std::tr1, std::tr2 etc) and it has a more dangerous 
modularity mechanism.

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;

Of course no need to define yearly versions for every year and every 
package/module. Just those that are worth adding backwards-breaking 
improvements.

A module should not import both std.xyz and std.v2020.xyz. Or the 
behavior is dependent on xyz and defined clearly.

I wonder how well this would work.