std.experiemental

[Alex]

On Wednesday, 15 May 2019 at 08:45:41 UTC, Dennis wrote:
> On Wednesday, 15 May 2019 at 08:05:16 UTC, Alex wrote:
>> I just throw in a -LibVer2018.05.01 and it *must* work(the 
>> compiler could even handle and regression issues by 
>> downloading older compilers are modules).
>>
>> Everything works. (it must because -LibVer precisely calls in 
>> all the libs that worked when the program actually compiled.
>
> What if my projects depends on three packages, and those 
> packages import std.experimental.2015, std.experimental.2017 
> and std.experimental.2019 respectively?

You must then explicitly import them.

Initially you would start off with

import std.experimental; which is 2015

Then, 2017 comes along and you have to then do

import std.experimental.2015;
import std.experimental; which is 2017


then for 2019

import std.experimental.2015;
import std.experimental.2017;
import std.experimental;

How else would you have thought it would be done?

Now, really you would just compile your code in 2017 and IF it 
failed then you'd have to add the previous import. Else you would 
just continue along as normal...

These are only for cases where the code would break to due to 
changes.

What it does is simply this: You can get your code to work after 
a breaking change SIMPLY by doing a search and replace on import 
std.experimental.

You won't have to fiddle with anything else You will just have to 
know the name of the module it went too... which d could help by 
reporting previous versions(e.g., did you mean 
std.experimental.2015).

What this prevents is, say, from std.experimental completely 
changing, the old code destroyed, and your code destroyed in the 
process. All it requires to fix is a slight modification which is 
simply a search and replace that isn't complex(like trying to 
search and replace function names with signature dependence).

Since all the libs are retained there is no issue EXCEPT possibly 
collisions... but that requires proper module development.

Every extension should import the previous functions it does not 
change.



Also, as you use newer libraries then it is up to you to use them 
properly. E.g., if you are adding std.experimental.2015 you 
shouldn't do

in the same scope since
import std.experimental.2015;
import std.experimental;



Because now there is a potential for collision, Once have a fork 
you then need to separate the 2015 code from the latest code(use 
them in separate modules, etc)..

This is always possible because when you "upgraded" to use the 
latest experimental you know that you used a previous one. [The 
code to use the latest hasn't been written yet so it's up to you 
to properly manage it]