Case for std.experimental

[Dicebot via Digitalmars-d]

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.