• Andrei Alexandrescu (11/11) Oct 27 2015 I was looking at
• Jakob Ovrum (3/15) Oct 27 2015 Sounds good!
• Jack Stouffer (11/23) Oct 27 2015 Author of the PR here. If this is the precedent you want to set
• Rikki Cattermole (3/14) Oct 27 2015 Sigh, thanks for the push.
• Jonathan M Davis (26/37) Oct 27 2015 I don't know. It probably makes sense for some stuff, but in
• =?UTF-8?B?Tm9yZGzDtnc=?= (3/15) Oct 28 2015 Ok with me.
• Robert burner Schadek (35/37) Oct 28 2015 Could you list them please.
• Jonathan M Davis (16/19) Oct 28 2015 Yeah. By putting stuff in std.experimental, we guarantee that
• Dmitry Olshansky (8/19) Oct 28 2015 Then there needs to be a _process_ for migration and/or purging of
• Vladimir Panteleev (13/14) Oct 28 2015 -1
• Vladimir Panteleev (19/21) Oct 28 2015 To expand on this a bit:
• James Hofmann (48/50) Oct 28 2015 I think most people like the idea of having new things
• Steven Schveighoffer (20/30) Oct 29 2015 No.
• Jack Stouffer (3/15) Oct 29 2015 Seems like three for, six against.
• Andrei Alexandrescu (2/19) Oct 29 2015 Yah, I'm glad I asked. Thanks, folks! -- Andrei
• Jesse Phillips (5/8) Oct 30 2015 Does that mean I shouldn't move the wrap struct pull request into
• Jack Stouffer (2/11) Oct 30 2015 Yes
• Andrei Alexandrescu (3/11) Oct 30 2015 No, wrap is large/important enough to warrant a staging through

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

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!

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.

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.

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

=?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.

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"

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

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

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.

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.

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.

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

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.

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

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

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

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