On 7/30/14, 8:56 AM, Dicebot wrote:
> 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 :)

No! The point here is we don't offer the guarantees. We just don't want std.experimental to devolve into "anything goes" territory. If a library has known significant work ahead of it, we shouldn't put it in std.experimental. -- Andrei

On Wednesday, 30 July 2014 at 17:44:06 UTC, Andrei Alexandrescu wrote:
> No! The point here is we don't offer the guarantees. We just don't want std.experimental to devolve into "anything goes" territory. If a library has known significant work ahead of it, we shouldn't put it in std.experimental. -- Andrei

Ok, I will keep those rules in mind for future reviews / voting even if I don't understand their merit :)

On Wednesday, 30 July 2014 at 18:00:59 UTC, Dicebot wrote:
> On Wednesday, 30 July 2014 at 17:44:06 UTC, Andrei Alexandrescu wrote:
>> No! The point here is we don't offer the guarantees. We just don't want std.experimental to devolve into "anything goes" territory. If a library has known significant work ahead of it, we shouldn't put it in std.experimental. -- Andrei
>
> Ok, I will keep those rules in mind for future reviews / voting even if I don't understand their merit :)

My view on the purpose of std.experimental notwithstanding, maybe we should discuss the meaning of the _vote_: What about making the vote simply about whether the module is believed to be a) of enough importance to be in Phobos by the wider community, and b) close enough to the mark in terms of design and implementation that a solid result is reachable in the near future? A positive vote would then be a mandate for the contributor and the Phobos committers/reviewers to work on ironing out the remaining kinks to make the package suitable for shipping with the standard library. In other words, the vote would effectively put the pull request for the addition on a level with all the others that contain no or only minor changes to the public API.

Cheers,
David

On Wednesday, 30 July 2014 at 22:44:38 UTC, David Nadlinger wrote:
>> Ok, I will keep those rules in mind for future reviews / voting even if I don't understand their merit :)
>
> My view on the purpose of std.experimental notwithstanding, maybe we should discuss the meaning of the _vote_: What about making the vote simply about whether the module is believed to be a) of enough importance to be in Phobos by the wider community, and b) close enough to the mark in terms of design and implementation that a solid result is reachable in the near future?

(b) is a bit too vague. With something like std.logger full rewrite of API can be done in quite a small time being thus "reachable in the near future" :) Effectively it implies that Phobos reviewers "know better" when it comes to exposed API and this is something I disagree with (I am one of those reviewers after all and I won't trust myself). Voting is an opportunity to a future users to tell "this API looks so bad I'd better write one of my own than go with it".

At the same time minor glitches and overall Phobos style compatibility has not been traditionally considered a voting blocker so far so it already partially works that way - going through normal PR review process is still expected.

"Dicebot" <public@dicebot.lv> Wrote in message:
> 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.
> 


-- 

"Dicebot" <public@dicebot.lv> Wrote in message:

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

std.purgatory

On 29 July 2014 18:34, David Nadlinger via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> the DMD release cycle takes the "rapid" out of "rapid iteration".

Sad but true.