www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - =?UTF-8?Q?Re=3A_std=2Eexperimental_=E2=80=93_DConf=3F?=

reply 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
May 29 2014
next sibling parent "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.
May 30 2014
prev sibling next sibling parent "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
May 30 2014
prev sibling next sibling parent "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.
May 30 2014
prev sibling parent "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.
May 30 2014