www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Make all new symbols go through std.experimental?

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
I was looking at 
https://github.com/D-Programming-Language/phobos/pull/3765 and whilst 
it's a sensible addition, I'm thinking we'd want to pass it and all 
other library additions through std.experimental first. So we'd have a 
std.experimental.range package that would be a purgatory for things to 
be added to std.range, and so on.

We have examples from the past when additions that seemed obvious and 
sensible needed a few tweaks before stabilization. Going through 
std.experimental seems like a good approach to do such.


What say you?

Andrei
Oct 27 2015
next sibling parent Jakob Ovrum <jakobovrum gmail.com> writes:
On Wednesday, 28 October 2015 at 00:28:51 UTC, Andrei 
Alexandrescu wrote:
 I was looking at 
 https://github.com/D-Programming-Language/phobos/pull/3765 and 
 whilst it's a sensible addition, I'm thinking we'd want to pass 
 it and all other library additions through std.experimental 
 first. So we'd have a std.experimental.range package that would 
 be a purgatory for things to be added to std.range, and so on.

 We have examples from the past when additions that seemed 
 obvious and sensible needed a few tweaks before stabilization. 
 Going through std.experimental seems like a good approach to do 
 such.


 What say you?

 Andrei
Sounds good!
Oct 27 2015
prev sibling next sibling parent Jack Stouffer <jack jackstouffer.com> writes:
On Wednesday, 28 October 2015 at 00:28:51 UTC, Andrei 
Alexandrescu wrote:
 I was looking at 
 https://github.com/D-Programming-Language/phobos/pull/3765 and 
 whilst it's a sensible addition, I'm thinking we'd want to pass 
 it and all other library additions through std.experimental 
 first. So we'd have a std.experimental.range package that would 
 be a purgatory for things to be added to std.range, and so on.

 We have examples from the past when additions that seemed 
 obvious and sensible needed a few tweaks before stabilization. 
 Going through std.experimental seems like a good approach to do 
 such.


 What say you?

 Andrei
Author of the PR here. If this is the precedent you want to set that's fine with me. Two things though: We would need to do some announcement to tell people that the purpose of std.experimental is fundamentally changing from "staging area for new modules" to "staging area for all new symbols". Two, we need some set rules on when each type of addition goes out std.experimental. I can envision things sitting there for a while if we don't have a hard and fast rule, as people will want to keep making additions/changes.
Oct 27 2015
prev sibling next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 28/10/15 1:28 PM, Andrei Alexandrescu wrote:
 I was looking at
 https://github.com/D-Programming-Language/phobos/pull/3765 and whilst
 it's a sensible addition, I'm thinking we'd want to pass it and all
 other library additions through std.experimental first. So we'd have a
 std.experimental.range package that would be a purgatory for things to
 be added to std.range, and so on.

 We have examples from the past when additions that seemed obvious and
 sensible needed a few tweaks before stabilization. Going through
 std.experimental seems like a good approach to do such.


 What say you?

 Andrei
Sigh, thanks for the push. I need to create a policy change document anyway for std.experimental.
Oct 27 2015
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, 28 October 2015 at 00:28:51 UTC, Andrei 
Alexandrescu wrote:
 I was looking at 
 https://github.com/D-Programming-Language/phobos/pull/3765 and 
 whilst it's a sensible addition, I'm thinking we'd want to pass 
 it and all other library additions through std.experimental 
 first. So we'd have a std.experimental.range package that would 
 be a purgatory for things to be added to std.range, and so on.

 We have examples from the past when additions that seemed 
 obvious and sensible needed a few tweaks before stabilization. 
 Going through std.experimental seems like a good approach to do 
 such.

 What say you?
I don't know. It probably makes sense for some stuff, but in other cases, the fact that it ends up in a module other than its target module could be problematic (especially when overloads come into play). It also seems like extra red tape and extra effort that's then going to have to be spent moving symbols around. On the other hand, it would at least potentially help catch some problems. Regardless, we need to make it clear how we're going to move stuff from std.experimental to std, and what the timetable for that is supposed to be. AFAIK, thus far, we've never moved _anything_ from std.experimental to std. In the case of new modules, are we supposed to vote on them again before actually moving them into std? Do they just get moved over after they've been around for a certain period of time? Or is it some other criteria? And if we start putting new symbols in std.experimental, should those same criteria apply to individual symbols in addition to modules? Having another vote before migrating a new module might make sense, but that's definitely overkill for a new symbol. And new symbols probably don't need the same kind of bake time that a new module would. Right now, AFAIK, we have no policy with regards to std.experimental at all except that that's where new modules are supposed to go when they get voted in. - Jonathan M Davis
Oct 27 2015
prev sibling next sibling parent =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Wednesday, 28 October 2015 at 00:28:51 UTC, Andrei 
Alexandrescu wrote:
 I was looking at 
 https://github.com/D-Programming-Language/phobos/pull/3765 and 
 whilst it's a sensible addition, I'm thinking we'd want to pass 
 it and all other library additions through std.experimental 
 first. So we'd have a std.experimental.range package that would 
 be a purgatory for things to be added to std.range, and so on.

 We have examples from the past when additions that seemed 
 obvious and sensible needed a few tweaks before stabilization. 
 Going through std.experimental seems like a good approach to do 
 such.


 What say you?

 Andrei
Ok with me.
Oct 28 2015
prev sibling next sibling parent reply Robert burner Schadek <rburners gmail.com> writes:
On Wednesday, 28 October 2015 at 00:28:51 UTC, Andrei 
Alexandrescu wrote:
 We have examples from the past when additions that seemed 
 obvious and sensible needed a few tweaks before stabilization.
Could you list them please. I do not like the idea. 1. Whenever I look into "learn" I get the feeling people do not search the phobos docs. This can have many reasons, but I think adding a second place to search (std.range, std.experimental.range) will exacerbate this situation. 2. The amount of issues brought to my attention with std.experimental.logger is quite small. Again multiple possibilities (is anyone actually using the logger?), but still the amount of shakedown through experimental is not that big. 3. Every move of code from experimental to stable will require user interaction. I thought we were trying to not break old code nowadays. 4. Apis break from time to time. Just look at the rangification process. IMO no process will change that. This process will only lead to more work. Only ranting without offering some sort of solution does not stand good with me. Therefore, I would say we should put more emphasis on testing. For instance, if you look at the mentioned PR, you see that pad(Left,Right) is not once tested with any of the range functions already included in phobos. Does it work with itoa, I don't know. I'm not saying every snippet of phobos should be combined/tested against every other snippet, but enough combinations should be tested that the reviews get the feeling that the api fits reasonable into phobos. "SHAMELESS SELF PROMOTING ON" Watching https://www.youtube.com/watch?v=OPoZWnYIcP4 again strengthen my believe that testing with random input data has its merits. So please, can somebody take a look at https://github.com/D-Programming-Language/phobos/pull/2995 "SHAMELESS SELF PROMOTING OFF"
Oct 28 2015
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, 28 October 2015 at 09:08:08 UTC, Robert burner 
Schadek wrote:
 3. Every move of code from experimental to stable will require 
 user interaction. I thought we were trying to not break old 
 code nowadays.
Yeah. By putting stuff in std.experimental, we guarantee that we're going to break the code of anyone using it, whereas if we put it in std, we only have to break their code if we have to in order to make a fix (be it a bug fix or an API fix). The only upside to putting it in std.experimental in that regard is that folks should then expect that their code will be broken (and presumably trivially fixed), whereas normally, their code shouldn't break due to changes in std. It _will_ happen upon occasion whether we want it to or not though. I'm not completely against this proposed change, but it really does feel like it would just be adding extra churn without really adding much value (occasional value, probably, but in most cases, probably not). - Jonathan M Davis
Oct 28 2015
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 28-Oct-2015 03:28, Andrei Alexandrescu wrote:
 I was looking at
 https://github.com/D-Programming-Language/phobos/pull/3765 and whilst
 it's a sensible addition, I'm thinking we'd want to pass it and all
 other library additions through std.experimental first. So we'd have a
 std.experimental.range package that would be a purgatory for things to
 be added to std.range, and so on.
Then there needs to be a _process_ for migration and/or purging of symbols from std.exp. We have NOTHING for that aside from good intentions. So probably not a good idea to drop stuff in a place that has no concrete plans to merge with std.
 We have examples from the past when additions that seemed obvious and
 sensible needed a few tweaks before stabilization. Going through
 std.experimental seems like a good approach to do such.


 What say you?
Otherwise ok.
 Andrei
-- Dmitry Olshansky
Oct 28 2015
prev sibling next sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Wednesday, 28 October 2015 at 00:28:51 UTC, Andrei 
Alexandrescu wrote:
 What say you?
-1 To add to Robert's arguments: A: Hey, I'm really missing this function from Phobos, I think it would be a great addition. B: OK, here's a pull request which implements it. A: Great, it's merged! When can I start using it? B: I don't know, maybe in a year or so? A: :( New additions already go through the staging area that is "master", meaning that additions can take as much as 1.5 release cycles to reach end-users.
Oct 28 2015
parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Wednesday, 28 October 2015 at 09:55:10 UTC, Vladimir Panteleev 
wrote:
 A: Great, it's merged! When can I start using it?

 B: I don't know, maybe in a year or so?
To expand on this a bit: The obvious counter-argument is "why not just import std.experimental"? Well, this is not really a solution if you are writing a library, or an application distributed as source. Importing std.experimental is essentially consenting to putting a time bomb in your code. Any library / source-distributed program should also support compiling with a range of D versions (because of e.g. compiler regressions, LDC and GDC lagging behind), and although you could static-if import this or that, it's not really a solution. Thus, you need to wait for the std.experimental PR to be merged into master, then for master to be merged into stable, then for a stable release to be made, then presumably for someone to make a PR to be made to move the feature out of std.experimental, then again for that to get into stable and be released, and then 1-2 more releases for GDC and LDC to catch up to the version of Phobos which has this feature.
Oct 28 2015
prev sibling next sibling parent James Hofmann <jhofmann 321f.net> writes:
On Wednesday, 28 October 2015 at 00:28:51 UTC, Andrei 
Alexandrescu wrote:
 What say you?

 Andrei
I think most people like the idea of having new things categorized, but encounter difficulty agreeing on what categories to use. Everyone will make broad assumptions that fit their comfort zone. Word choices like "experimental" or "testing" could influence people's impressions of stability, and so could the method of friction that is added to prevent accidental use. The point is to be a little bit scary - but are we scaring off the right people when we use these words and techniques? I don't have much D history but I would approach the issue ground-up and reconsider the options for introductions. I thought of these ways that friction could be added(considering here both library and language features): 1. Rebuild compiler with additional flags. 2. Available only in one or more separate library versions(e.g. a dub package that replaces "stable" std). 3. Run compiler with additional flags. 4. Import a named package like std.experimental. There is a very key difference between the first three and the fourth in that if you have modified the compiler, your build flags, or your library environment, you are more likely to be working on a personal machine with personal projects, and can afford to tinker with a rapidly changing situation. With 4, people will be able to use it injudiciously in production by copy-pasting source code from someone's example - no warnings will appear as a result of this. Knowing that, we have to ask some questions about workflows to settle what the role of std.experimental is. Friction appears _after_ a symbol is moved out of experimental, as noted by previous replies, when what is desired is for graduation out of experimental to be apparently seamless. On the other hand, it's very troublesome to have working code break after toggling a flag to turn on the experimental things. Flags should feel "precise" and not disturb the existing code. Environmental changes add friction around initial use - when code doesn't "just work" because it requires an environment change it is likely to be reconsidered by its user. Perhaps that means a rule like: if it's entirely new, use a build flag, or expose it in an "unstable" library version. If it modifies/refines an old, stable symbol, use std.experimental, and deprecate the old API as confidence grows - thus encouraging people to move towards experimental often, but to start manipulating the rest of the environment if they want to be truly adventurous. (this doesn't exactly solve the "post-hoc friction" problem, but it scores well on accident prevention) There's probably much more to consider but I will leave my thought there.
Oct 28 2015
prev sibling next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/27/15 8:28 PM, Andrei Alexandrescu wrote:
 I was looking at
 https://github.com/D-Programming-Language/phobos/pull/3765 and whilst
 it's a sensible addition, I'm thinking we'd want to pass it and all
 other library additions through std.experimental first. So we'd have a
 std.experimental.range package that would be a purgatory for things to
 be added to std.range, and so on.

 We have examples from the past when additions that seemed obvious and
 sensible needed a few tweaks before stabilization. Going through
 std.experimental seems like a good approach to do such.


 What say you?
No. This seems overly-cautious. We are saying we want to INTENTIONALLY break your code at some point in the future when it moves out of std.experimental. If the symbol never changes, then this is a waste. I think it's a judgment call as to whether you start off a symbol in std.experimental. Is it controversial? Does it seem like the API is difficult to use? Having a hard-set rule for something that is OBVIOUSLY designed correctly is not good. I think it's fine to require symbols to be put in purgatory if it seems like they likely will change. But having a rule that they MUST go there is too much. It's most definitely different for completely new modules. These are likely to change/grow over time, especially with new people using them. BTW, we may get more mileage out of identifying when a symbol was added. I know in many different languages, the docs for a symbol identify the first version that contained the symbol. I think someone would be more forgiving of a change to a symbol that was added recently than one that was there from 5 years ago. -Steve
Oct 29 2015
prev sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Wednesday, 28 October 2015 at 00:28:51 UTC, Andrei 
Alexandrescu wrote:
 I was looking at 
 https://github.com/D-Programming-Language/phobos/pull/3765 and 
 whilst it's a sensible addition, I'm thinking we'd want to pass 
 it and all other library additions through std.experimental 
 first. So we'd have a std.experimental.range package that would 
 be a purgatory for things to be added to std.range, and so on.

 We have examples from the past when additions that seemed 
 obvious and sensible needed a few tweaks before stabilization. 
 Going through std.experimental seems like a good approach to do 
 such.


 What say you?

 Andrei
Seems like three for, six against.
Oct 29 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/29/15 9:14 PM, Jack Stouffer wrote:
 On Wednesday, 28 October 2015 at 00:28:51 UTC, Andrei Alexandrescu wrote:
 I was looking at
 https://github.com/D-Programming-Language/phobos/pull/3765 and whilst
 it's a sensible addition, I'm thinking we'd want to pass it and all
 other library additions through std.experimental first. So we'd have a
 std.experimental.range package that would be a purgatory for things to
 be added to std.range, and so on.

 We have examples from the past when additions that seemed obvious and
 sensible needed a few tweaks before stabilization. Going through
 std.experimental seems like a good approach to do such.


 What say you?

 Andrei
Seems like three for, six against.
Yah, I'm glad I asked. Thanks, folks! -- Andrei
Oct 29 2015
parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Friday, 30 October 2015 at 03:59:32 UTC, Andrei Alexandrescu 
wrote:
 On 10/29/15 9:14 PM, Jack Stouffer wrote:
 Seems like three for, six against.
Yah, I'm glad I asked. Thanks, folks! -- Andrei
Does that mean I shouldn't move the wrap struct pull request into std.experimental? https://github.com/D-Programming-Language/phobos/pull/2945
Oct 30 2015
next sibling parent Jack Stouffer <jack jackstouffer.com> writes:
On Friday, 30 October 2015 at 16:55:53 UTC, Jesse Phillips wrote:
 On Friday, 30 October 2015 at 03:59:32 UTC, Andrei Alexandrescu 
 wrote:
 On 10/29/15 9:14 PM, Jack Stouffer wrote:
 Seems like three for, six against.
Yah, I'm glad I asked. Thanks, folks! -- Andrei
Does that mean I shouldn't move the wrap struct pull request into std.experimental? https://github.com/D-Programming-Language/phobos/pull/2945
Yes
Oct 30 2015
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/30/2015 12:55 PM, Jesse Phillips wrote:
 On Friday, 30 October 2015 at 03:59:32 UTC, Andrei Alexandrescu wrote:
 On 10/29/15 9:14 PM, Jack Stouffer wrote:
 Seems like three for, six against.
Yah, I'm glad I asked. Thanks, folks! -- Andrei
Does that mean I shouldn't move the wrap struct pull request into std.experimental? https://github.com/D-Programming-Language/phobos/pull/2945
No, wrap is large/important enough to warrant a staging through experimental. Thanks! -- Andrei
Oct 30 2015