std.experiemental

[Seb]

On Wednesday, 15 May 2019 at 08:05:16 UTC, Alex wrote:
> On Tuesday, 14 May 2019 at 13:42:04 UTC, Seb wrote:
>> On Tuesday, 14 May 2019 at 12:21:57 UTC, Alex wrote:
>>> [...]
>>
>> Or just use Dub which allows to use the proper solution to 
>> this: semantic versioning.
>>
>> This is what we did once it became clear that breaking changes 
>> are hard - even for std.experimental.
>
> Not everyone uses dub and since dub is not directly part of D 
> core it is not a solution.
>
> Maybe all phobos modules need to be designed with versioning.
>
> module std.traits.V2019.05.05
>
> and aliases are used to point to whatever is most recently 
> desired... then versioning issues are just handed by changing 
> the aliases..
>
> One could, for example, tell D to use all versions < some 
> specific date:
>
> -LibVer2018.05.01
>
> and it will set the alias up to use the most recent libraries 
> up to that date.
>
> Then one can ALWAYS keep their project in sync. If a new 
> library comes out which a higher date then one has to 
> specifically mention use it. One can upgrade the project 
> through different versions by changing the date and it just 
> works.
>
> Why this works?
>
> When projects are designed they are designed at a specific 
> date. There is a time when the project compiles and works with 
> all the libs that were designed at some date. So this point in 
> time has to be captured. -LibVer captures this date.
>
> If a project worked at Date X then -LibVerX would allow that 
> project to work no matter what changes has been made to any 
> libs after that since it worked before and past libs are not 
> modified.
>
>
> So, suppose I have a project I created in 2018.05.01.  I come 
> back 3 years later and it's 2020... the project no longer works.
>
> 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.
>
> One can then do -LibVer2019...
>
> If it fails then the compiler can report the failures(could do 
> a dustmite like effect and figure out which libs and what 
> functionality changed to cause the failure).
>
> If it passes then one can continue to increase the effect(and 
> all this could be automated).
>
> All this requires is for all libs to be timestamped and 
> immutable(any "change" requires a timestamp)... that solves the 
> problem. Versions are useless because they do not correlate to 
> other libraries. Timestamps are what makes it all work.

Dub is part of the official ecosystem and shipped with the 
official releases.

There are no plans at all to ship older versions of Phobos for 
many reasons: huge library and release size, no stable ABI, and 
most importantly lack of manpower.

If you just want things to work in two years, lock to a specific 
compiler version.
Here's an example with Make:

https://github.com/wilzbach/d-bootstrap

However, I have to admit that your approach is very interesting 
and a bit similar to what C++ does with their -std switch, so I 
do encourage you to work out the details and submit a DIP (the 
process is currently being revamped, so it won't be dead sink 
without feedback anymore).