www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.experiemental

reply 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.
May 14 2019
next sibling parent reply 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.
May 14 2019
next sibling parent Robert Schadek <rschadek symmetryinvestments.com> writes:
https://github.com/dlang/projects/issues/40
May 14 2019
prev sibling parent reply 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.
May 15 2019
next sibling parent 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).
May 15 2019
prev sibling parent reply 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?
May 15 2019
parent 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]
May 15 2019
prev sibling parent reply 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
May 15 2019
parent 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.
May 26 2019