• Alex (14/14) May 14 2019 Seems to be an issue about changing it.
• Seb (5/19) May 14 2019 Or just use Dub which allows to use the proper solution to this:
• Robert Schadek (1/1) May 14 2019 https://github.com/dlang/projects/issues/40
• Alex (42/69) May 15 2019 Not everyone uses dub and since dub is not directly part of D
• Seb (15/67) May 15 2019 Dub is part of the official ecosystem and shipped with the
• Dennis (4/9) May 15 2019 What if my projects depends on three packages, and those packages
• Alex (46/56) May 15 2019 You must then explicitly import them.
• Jonathan M Davis (26/40) May 15 2019 Completely aside from the versioning issues brought up in this thread,
• KnightMare (9/12) May 26 2019 I think versioning is mandatory.

Alex <AJ gmail.com> writes:

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.

Seb <seb wilzba.ch> writes:

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.

Robert Schadek <rschadek symmetryinvestments.com> writes:

https://github.com/dlang/projects/issues/40

Alex <AJ gmail.com> writes:

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.

Seb <seb wilzba.ch> writes:

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).

Dennis <dkorpel gmail.com> writes:

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?

Alex <AJ gmail.com> writes:

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]

Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:

On Tuesday, May 14, 2019 6:21:57 AM MDT Alex via Digitalmars-d 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.

Completely aside from the versioning issues brought up in this thread,
another point that Andrei had for why we want to use code.dlang.org instead
of std.experimental is that it gives the chance for us to take projects that
have proven themselves over time and merge all or part of them into Phobos
after they're thoroughly battle-tested. So, we're able to take APIs and
implementations that have proven themselves, whereas what has happened with
std.experimental (and much of what was merged into phobos prior to
std.experimental) thus far is that stuff gets designed explicitly for Phobos
rather than being battle-tested first. And the fact that something is in
std.experimental creates this weird situation where people _can_ use it, but
many don't, because it's experimental, and those who do get mad when it
changes, because their code breaks. So, we have problems updating what's in
std.experimental, and it's not necessarily getting battle-tested the way
that it should, because it's labeled as experimental. It really has not
worked well for us.

Using code.dlang.org as the proving ground for projects allows us to
function more like what happens with Boost and C++'s stdlib, which has been
very successful for them. Andrei seems to now strongly favor that approach.

There's also the issue that on some level, code.dlang.org negates the need
for putting stuff in phobos. Some stuff should end up in Phobos at some
point, but unless it's something that really needs to be standard, there
isn't necessarily a good reason to. Having it available via the official
package manager means that it will be available without needing to actually
get it into Phobos.

- Jonathan M Davis

KnightMare <black80 bk.ru> writes:

On Wednesday, 15 May 2019 at 12:06:50 UTC, Jonathan M Davis wrote:
 Completely aside from the versioning issues brought up in this 
 thread, another point that Andrei had for why we want to use 
 code.dlang.org instead of std.experimental> - Jonathan M Davis

I think versioning is mandatory.
Using std.experimantal or code.dlang.org or renaming modules are 
not very helpful. Its like odd job or homemade, not industrial or 
professional.
I wrote about versioning in another topic as I see it, I am not a 
compiler/RT writer at all:
https://forum.dlang.org/post/hgspjuiqjjtptdexwlus forum.dlang.org
Versioning is big topic for reasoning.