Forking from http://forum.dlang.org/post/qsqfcayisriatreqtvcm@forum.dlang.org

Most relevant quote:

On Tuesday, 29 July 2014 at 17:15:22 UTC, Andrei Alexandrescu wrote:
> We put something in std.experimental when we can't imagine what other work is to be done on the module. (Inevitably a little more work is prompted by usage, which is the point of it all.) We don't put in std.experimental stuff that has already a known backlog of work to do.

This surprises me because during talks about std.experimental before it was discussed as possible place to advertise Phobos candidates without risking any API breakage. And now Andrei (Davis also supports this point) speaks about it as pure "staging" concept which should have same inclusion criteria as Phobos mainstream.

Reason why I find this strange is because it invalidates main argument in favor of std.experimental over something like dub package - making it easier to wider user case to try the proposal and provide API feedback. All it does with such restrictions is delaying stabilization point for one release in case something totally unforeseen comes out.

I wonder what are other opinions.

On Tuesday, 29 July 2014 at 17:22:38 UTC, Dicebot wrote:
> Forking from http://forum.dlang.org/post/qsqfcayisriatreqtvcm@forum.dlang.org
>
> Most relevant quote:
>

Personally, I think this following quote is the more compelling argument for that particular case:

On Tuesday, 29 July 2014 at 17:15:22 UTC, Andrei Alexandrescu wrote:
>
> We put something in std.experimental when we can't imagine what other work is to be done on the module. (Inevitably a little more work is prompted by usage, which is the point of it all.) We don't put in std.experimental stuff that has already a known backlog of work to do.
>

On Tuesday, 29 July 2014 at 17:27:15 UTC, safety0ff wrote:

Derp, nevermind that post.

On Tuesday, 29 July 2014 at 17:22:38 UTC, Dicebot wrote:
> (Davis also supports this point)

To avoid confusion, let me point out that this was me (i.e., "David"), not Jonathan M. Davis.

> Reason why I find this strange is because it invalidates main argument in favor of std.experimental over something like dub package - making it easier to wider user case to try the proposal and provide API feedback.

I think you got this precisely the wrong way round: Having something in Phobos makes it infinitely harder to meaningfully improve on a design, as the DMD release cycle takes the "rapid" out of "rapid iteration". Almost nobody builds DMD/druntime/Phobos from source in the grand scheme of things – pretty much only the core team and some of the forum regulars do.

Cheers,
David

On 7/29/14, 10:27 AM, safety0ff wrote:
> On Tuesday, 29 July 2014 at 17:22:38 UTC, Dicebot wrote:
>> Forking from
>> http://forum.dlang.org/post/qsqfcayisriatreqtvcm@forum.dlang.org
>>
>> Most relevant quote:
>>
>
> Personally, I think this following quote is the more compelling argument
> for that particular case:
>
> On Tuesday, 29 July 2014 at 17:15:22 UTC, Andrei Alexandrescu wrote:
>>
>> We put something in std.experimental when we can't imagine what other
>> work is to be done on the module. (Inevitably a little more work is
>> prompted by usage, which is the point of it all.) We don't put in
>> std.experimental stuff that has already a known backlog of work to do.

I'd just want to have a simple litmus test that prevents std.experimental from becoming a dumping ground of unfinished work. Consider:

"Folks, here's std.experimental.acme. I think it's usable and fairly stable but I'm sure I didn't think of all possible issues and use cases. Documentation could be also improved."

vs

"Folks, here's std.experimental.acme. The entire user-facing API is sure to change and it doesn't pass what some deem to be basic acceptance terms. Try it, but you can be sure you'll need to overhaul all use of it when it's done."


Andrei

On Tuesday, 29 July 2014 at 17:35:34 UTC, Andrei Alexandrescu wrote:
>
> I'd just want to have a simple litmus test that prevents std.experimental from becoming a dumping ground of unfinished work.

I screwed up that post, but in brief I meant to agree with your quote for the case of std.logger.

Frankly, if Dub is bundled with D, I don't see any reason for
std.experimental to exist.  Those two ideas just seemed to
develop in parallel.

On 7/29/14, 12:01 PM, Sean Kelly wrote:
> Frankly, if Dub is bundled with D, I don't see any reason for
> std.experimental to exist.  Those two ideas just seemed to
> develop in parallel.

The way I see it:

* dub: a loose federation of libraries with no implied promise.

* std.experimental: 99% sure to make it in std, use at your risk but there's a high likelihood you'll just remove ".experimental" next release, fix whatever doesn't compile, and you're good to go.


Andrei

On Tuesday, 29 July 2014 at 17:22:38 UTC, Dicebot wrote:
> Forking from http://forum.dlang.org/post/qsqfcayisriatreqtvcm@forum.dlang.org
>
> Most relevant quote:
>
> On Tuesday, 29 July 2014 at 17:15:22 UTC, Andrei Alexandrescu wrote:
>> We put something in std.experimental when we can't imagine what other work is to be done on the module. (Inevitably a little more work is prompted by usage, which is the point of it all.) We don't put in std.experimental stuff that has already a known backlog of work to do.
>
> This surprises me because during talks about std.experimental before it was discussed as possible place to advertise Phobos candidates without risking any API breakage. And now Andrei (Davis also supports this point) speaks about it as pure "staging" concept which should have same inclusion criteria as Phobos mainstream.
>
This was also my understanding of how that discussion resolved: std.experimental is a place for things we think belong in Phobos to incubate and get wide, public exposure.  There are arguments that dub obviates this, but I don't think that has nearly the visibility needed.

That is, "which of these logging libraries is the candidate for Phobos, again?"  Or, more generally, "which libraries are candidates for Phobos, again?  How can you tell?  If this is a candidate, why isn't it in the autotester?  Do we file bugs on dlang.org even though it's in the registry?"  Add a generous dollop of silence from people who reinvent the wheel because they've never heard of Dub, and serve chilled.  I'd be willing to bet anything in the std packages has several orders of magnitude more eyes acknowledging its existence.

By the way, when you say "staging" I think of the Linux kernel's definition of staging [1] for driver and filesystem development.  It's just a bit confusing. :)  On the other hand, I still think their rules for staging have some merit as an example for Phobos to ad{a,o}pt.

-Wyatt

[1] http://lwn.net/Articles/324279/

On Tuesday, 29 July 2014 at 17:34:39 UTC, David Nadlinger wrote:
> On Tuesday, 29 July 2014 at 17:22:38 UTC, Dicebot wrote:
>> (Davis also supports this point)
>
> To avoid confusion, let me point out that this was me (i.e., "David"), not Jonathan M. Davis.

LOL. Yeah. I haven't said anything in that thread. However, I agree with both David and Andrei. std.experimental should be for the place to put stuff that's passed the Phobos review process and is considered ready for inclusion. But we put it in std.experimental rather than directly into std like we've done in the past in order to give it some time to be battle tested prior to actually being included into Phobos proper, since it becomes _very_ difficult to fix the API once it's in std.

We can use dub for the stuff that hasn't passed the review process yet and std.experimental as a staging ground for std.

- Jonathan M Davis