std.experiemental

[Alex]

On Tuesday, 14 May 2019 at 13:42:04 UTC, Seb wrote:
> On Tuesday, 14 May 2019 at 12:21:57 UTC, Alex wrote:
>> Seems to be an issue about changing it.
>>
>> Why not just change the name
>>
>> std.experimental->std.experimental2
>>
>> and people that have code just need to do a mass module change 
>> ("import std.experimental" -> import std.experimental2;")
>>
>> This then does break backwards compatibility but is a simple 
>> bridge to solve the problem.
>>
>> By having some type of versioning one could report when 
>> someone uses a new module that will break old code.
>>
>> Could use dates
>>
>> module std.experimental_04_05_2019;
>>
>> Then one simply has to import it by date. This separates all 
>> experimental and allows backwards compatibility and solves 
>> future issues.
>
> 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.