On Fri, 30 May 2014 12:32:55 -0400, Chris Williams
<yoreanon-chr...@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