On Tuesday, 29 July 2014 at 17:22:38 UTC, Dicebot wrote:
[snip]
> I wonder what are other opinions.

Here's what I'd like to see as a D user with std.experimental...

dub:
    ==> free-for-all libraries of varying quality
    ==> Promoted on official D website.
    ==> Included in the D download

std.experimental:
    ==> Released with Phobos
    ==> Reviewed modules by core D devs, akin to BETA/RC
    ==> Guarantees on API stability but not set in stone.
    ==> [maybe?] Changes require deprecation and another round in std.experimental


std:
    ==> High quality with API in stone.
    ==> Modules have been through 2 rounds of review
    ==> Changes require deprecation over a longer period.





Cheers,
uri.

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. 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."

What keeps bothering me is this: imagine something has not passed vote for std.experimental inclusion. That means that some changes will happen, one more voting and it will eventually get there one release later.

And if has passed the vote, effectively the same stuff happens - changes are done, staging period prolonged and we get to the very same point. Only difference is that earlier versions of the module don't get wider user exposure.

Now that I see several comments here seeking for certain stability even in std.experimental and can understand why later exposure can be a good thing. That, however, makes me even more convinced that "experimental" is a terrible name for that package and we are using it purely as staging are instead.

On Tuesday, 29 July 2014 at 19:50:15 UTC, Wyatt wrote:
> 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/

I am using this term in a same sense as some Linux distros - place for packages that are supposed to get to the main repo but are not yet there. Sometimes it takes form of separate repository users can optionally enable to have a look at upcoming stuff.

Linux kernel definition is similar but somewhat more specialized to their development model.

On Tuesday, 29 July 2014 at 21:01:07 UTC, Jonathan M Davis wrote:
> 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.

Sorry, stupid typo, 's' and 'd' are too close on the keyboard :(

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:lr8r7a$j7v$1@digitalmars.com...
> 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

+1

-=mike=- 

> Now that I see several comments here seeking for certain stability even in std.experimental and can understand why later exposure can be a good thing. That, however, makes me even more convinced that "experimental" is a terrible name for that package and we are using it purely as staging are instead.

I think that if we rename std.experimental as std.stagging, we can consider that  it has absolved from its own expe\b\b\b\bstaging phase.

Just now this will cause no code breakage, and hopefully it will also avoid some confusions and discussions in the future.

On Wednesday, 30 July 2014 at 15:21:12 UTC, Dragos Carp wrote:
>> Now that I see several comments here seeking for certain stability even in std.experimental and can understand why later exposure can be a good thing. That, however, makes me even more convinced that "experimental" is a terrible name for that package and we are using it purely as staging are instead.
>
> I think that if we rename std.experimental as std.stagging, we can consider that  it has absolved from its own expe\b\b\b\bstaging phase.
>
> Just now this will cause no code breakage, and hopefully it will also avoid some confusions and discussions in the future.

As far as I recall, there was extensive bike-shedding about this a while back. The decision (which I support) was to go with std.experimental, as it makes it clear that there are no API stability guarantees and the module will eventually go away. Making it sound unstable was the entire point of going with that name over the alternatives.

Cheers,
David

On Wednesday, 30 July 2014 at 15:24:22 UTC, David Nadlinger wrote:
> On Wednesday, 30 July 2014 at 15:21:12 UTC, Dragos Carp wrote:
>
> As far as I recall, there was extensive bike-shedding about this a while back. The decision (which I support) was to go with std.experimental,

Sorry, probably this was before I started following the forum discussions.

> as it makes it clear that there are no API stability guarantees

Andrei made the point that API should be stable with unforeseen exceptions and I support this.

> and the module will eventually go away.

Hopefully the module will get one level upper in std. and not go away.

> Making it sound unstable was the entire point of going with that name over the alternatives.

As in this thread, we see that "empty" std.experimental already generates unnecessary discussions.

In my opinion, DUB is the right place (playground) for experiments.

On Wednesday, 30 July 2014 at 15:24:22 UTC, David Nadlinger wrote:
> The decision (which I support) was to go with std.experimental, as it makes it clear that there are no API stability guarantees

..and at the same time you do want to require the very same stability guarantees :)

On 7/30/14, 5:41 AM, Dicebot wrote:
> 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.
>> 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."
>
> What keeps bothering me is this: imagine something has not passed vote
> for std.experimental inclusion. That means that some changes will
> happen, one more voting and it will eventually get there one release later.
>
> And if has passed the vote, effectively the same stuff happens - changes
> are done, staging period prolonged and we get to the very same point.
> Only difference is that earlier versions of the module don't get wider
> user exposure.
>
> Now that I see several comments here seeking for certain stability even
> in std.experimental and can understand why later exposure can be a good
> thing. That, however, makes me even more convinced that "experimental"
> is a terrible name for that package and we are using it purely as
> staging are instead.

Let it be more conservatively named. -- Andrei