• Jonathan M Davis via Digitalmars-d (10/15) May 29 2014 If that's the case, then I'd be inclined to argue that what should go in
• Chris Williams (10/33) May 30 2014 While I like the idea of a std.experimental, I would also suggest
• Steven Schveighoffer (11/44) May 30 2014 You mean like http://dlang.org/attribute#deprecated ?
• Chris Williams (13/30) May 30 2014 Yes, except named "experimental".
• Jesse Phillips (13/36) May 30 2014 I feel like there needs to be some type of formal review. The

Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Thu, 29 May 2014 20:55:32 +0000
Dicebot via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 I have discussed this with Andrei shortly after he has merged PR
 that adds `std.experimental` to Phobos. Looks like he actually
 thinks about it as `std.staging` - place for almost complete
 Phobos modules to bring more attention to them while still being
 able to make breaking API changes.

If that's the case, then I'd be inclined to argue that what should go in
std.experimental is modules that past the Phobos review process so that rather
than sticking them in std directly, they go in std.experimental for a release
or two so that they get better battle-tested before actually being put into
std, where APIs shouldn't be changing. So, rather than doing anything to speed
up the development process, std.experimental is for making sure that APIs are
solid before they get set in stone in Phobos proper.

- Jonathan m Davis

"Chris Williams" <yoreanon-chrisw yahoo.co.jp> writes:

On Friday, 30 May 2014 at 01:39:26 UTC, Jonathan M Davis via 
Digitalmars-d wrote:
 On Thu, 29 May 2014 20:55:32 +0000
 Dicebot via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 I have discussed this with Andrei shortly after he has merged 
 PR
 that adds `std.experimental` to Phobos. Looks like he actually
 thinks about it as `std.staging` - place for almost complete
 Phobos modules to bring more attention to them while still 
 being
 able to make breaking API changes.

 If that's the case, then I'd be inclined to argue that what 
 should go in
 std.experimental is modules that past the Phobos review process 
 so that rather
 than sticking them in std directly, they go in std.experimental 
 for a release
 or two so that they get better battle-tested before actually 
 being put into
 std, where APIs shouldn't be changing. So, rather than doing 
 anything to speed
 up the development process, std.experimental is for making sure 
 that APIs are
 solid before they get set in stone in Phobos proper.

 - Jonathan m Davis

While I like the idea of a std.experimental, I would also suggest 
an attribute like "deprecated". I had been intending (should I 
ever have free time...) to add some features to std.concurrency, 
but I don't think there's any way to access the module-level 
private variables from a different file (?). Short of duplicating 
the contents of concurrency.d into a new file under 
experimental/, I don't know that there would be any way to trial 
the features without going straight to main.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Fri, 30 May 2014 12:32:55 -0400, Chris Williams  
<yoreanon-chrisw yahoo.co.jp> wrote:

 On Friday, 30 May 2014 at 01:39:26 UTC, Jonathan M Davis via  
 Digitalmars-d wrote:
 On Thu, 29 May 2014 20:55:32 +0000
 Dicebot via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 I have discussed this with Andrei shortly after he has merged PR
 that adds `std.experimental` to Phobos. Looks like he actually
 thinks about it as `std.staging` - place for almost complete
 Phobos modules to bring more attention to them while still being
 able to make breaking API changes.

 If that's the case, then I'd be inclined to argue that what should go in
 std.experimental is modules that past the Phobos review process so that  
 rather
 than sticking them in std directly, they go in std.experimental for a  
 release
 or two so that they get better battle-tested before actually being put  
 into
 std, where APIs shouldn't be changing. So, rather than doing anything  
 to speed
 up the development process, std.experimental is for making sure that  
 APIs are
 solid before they get set in stone in Phobos proper.

 - Jonathan m Davis

 While I like the idea of a std.experimental, I would also suggest an  
 attribute like "deprecated".

You mean like http://dlang.org/attribute#deprecated ?

 I had been intending (should I ever have free time...) to add some  
 features to std.concurrency, but I don't think there's any way to access  
 the module-level private variables from a different file (?). Short of  
 duplicating the contents of concurrency.d into a new file under  
 experimental/, I don't know that there would be any way to trial the  
 features without going straight to main.

First, if it is a minor increment, it can be proposed as a pull request  
for std.concurrency.

If it is a major overhaul, we need to review it more broadly. This is kind  
of the problem with just adding things to std, which is why the  
std.experimental branch was proposed -- it's so difficult to get bad  
design out of the standard library after it has been released. The  
deprecation schedule takes years.

-Steve

"Chris Williams" <yoreanon-chrisw yahoo.co.jp> writes:

On Friday, 30 May 2014 at 17:35:39 UTC, Steven Schveighoffer 
wrote:
 You mean like http://dlang.org/attribute#deprecated ?

Yes, except named "experimental".

 I had been intending (should I ever have free time...) to add 
 some features to std.concurrency, but I don't think there's 
 any way to access the module-level private variables from a 
 different file (?). Short of duplicating the contents of 
 concurrency.d into a new file under experimental/, I don't 
 know that there would be any way to trial the features without 
 going straight to main.

 First, if it is a minor increment, it can be proposed as a pull 
 request for std.concurrency.

 If it is a major overhaul, we need to review it more broadly. 
 This is kind of the problem with just adding things to std, 
 which is why the std.experimental branch was proposed -- it's 
 so difficult to get bad design out of the standard library 
 after it has been released. The deprecation schedule takes 
 years.

 -Steve

Not an overhaul but also not minor, just adding different 
interfaces:

http://forum.dlang.org/thread/kfmkxsgeeijwkndldrmj forum.dlang.org

Again, this is assuming I ever have the free time to do it, but I 
could see other such issues popping up. In the case of 
std.concurrency, since each thread gets its own set of global 
variables, the module itself is effectively the "struct" of 
information for each thread, including the thread message box. If 
I wanted to insert into the message box, I would need access to 
the module privates.

"Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:

On Friday, 30 May 2014 at 01:39:26 UTC, Jonathan M Davis via 
Digitalmars-d wrote:
 On Thu, 29 May 2014 20:55:32 +0000
 Dicebot via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 I have discussed this with Andrei shortly after he has merged 
 PR
 that adds `std.experimental` to Phobos. Looks like he actually
 thinks about it as `std.staging` - place for almost complete
 Phobos modules to bring more attention to them while still 
 being
 able to make breaking API changes.

 If that's the case, then I'd be inclined to argue that what 
 should go in
 std.experimental is modules that past the Phobos review process 
 so that rather
 than sticking them in std directly, they go in std.experimental 
 for a release
 or two so that they get better battle-tested before actually 
 being put into
 std, where APIs shouldn't be changing. So, rather than doing 
 anything to speed
 up the development process, std.experimental is for making sure 
 that APIs are
 solid before they get set in stone in Phobos proper.

 - Jonathan m Davis

I feel like there needs to be some type of formal review. The 
criteria can't be as strict for full inclusion into Phobos, but I 
don't see it as a place for half implemented modules.

I've been thinking about it and do actually like the idea of 
including dub projects with the release of Phobos. Projects we'd 
like to move into Phobos and get reviewed. This keeps ownership 
outside of Phobos and allows us to easily drop projects not 
getting enough attention, and users of the library can obtain the 
library from dub so it doesn't hurt as much. It does add to the 
release process, so I say this should be our end goal and utilize 
std.experimental as a placeholder for now.