std.experimental – DConf?

[w0rp via Digitalmars-d]

On Friday, 30 May 2014 at 10:35:57 UTC, David Nadlinger wrote:
> On Friday, 30 May 2014 at 05:20:57 UTC, Andrei Alexandrescu 
> wrote:
>> Also please don't analyze this to death. It's meant to reduce 
>> friction, not increase this.
>
> I'm not sure whether your comment was just targeted at the 
> naming discussions, but in general, I find it very valid to 
> discuss the details of the proposal, especially the interaction 
> with package management.
>
> The benefits of having std.experimental over just bundling dub 
> with DMD must be clear and the separation well-defined. 
> Otherwise, this change will only increase friction instead.
>
> Personally, I rather like the idea of std.experimental being a 
> staging area for libraries that already passed some initial 
> round of review (be it in the form of a dub package or 
> otherwise) to get more widespread attention before being "set 
> in stone". We desperately need something like this, as the 
> review process has turned out to be to rigid for fear of 
> including suboptimal APIs, yet at the same time has failed to 
> catch several design problems as only few reviewers typically 
> made an effort to actually use the code.
>
> I, however, don't think that std.experimental is a good way to 
> gather initial feedback for a module, as the compiler release 
> cycle is just too inflexible for that.
>
> David

It's always, always easier to experiment by releasing a dub 
package. Including a module in the standard library requires the 
approval of a commity. You can always release a dub package, no 
one is going to stop you.

std.experimental is probably best used for things that are 90% of 
the way into being included in std. We could find out how to 
address the remaining 10% then by seeing how people actually use 
the modules.