Case for std.experimental

[Andrei Alexandrescu via Digitalmars-d]

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