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.
