std.experimental Timeline

[Steven Schveighoffer via Digitalmars-d]

On 12/31/15 1:54 PM, Jack Stouffer wrote:
> On Thursday, 31 December 2015 at 18:26:08 UTC, Steven Schveighoffer wrote:
>> I'm not concerned. Code can live in experimental as long as it's
>> needed to flesh out the API. The idea behind std.experimental is to
>> give us a disclaimer that the API may change at any release despite
>> usage.
>>
>> So the timeline is "when it's ready"
>
> I concerns me because without deadlines things get endlessly delayed.
> Also, keeping things in experimental for too long encourages a overly
> cautious mentality IMO.

Yes, but the alternative is to have a bad API we must maintain. For 
example, object.destroy used to be called object.clear. It's just now 
coming out of the requirement to be supported as clear, and I can 
finally add a method to AAs that clear all elements (I implemented it 
last year, but put on hold because it was determined that we should wait 
until we could use the "obvious" name).

The idea of having it in std.experimental instead of just on its own 
repository is so that it goes through the same rigors of testing that 
all of phobos does, and so that it gets used more. For all intents and 
purposes, it's "official", just that the API isn't completely baked.

I'd say that if people are using it for a good period of time and nobody 
has any serious objections to it, then we can consider moving it to std.

>
>> In the case of allocator, it's quite possible we could start including
>> parameters to functions that are allocators in std, since the behavior
>> of the allocator is implementation, not API. In other words, a
>> function that takes an allocator may not have to be in
>> std.experimental, as long as you know that the parameter is an
>> allocator and the implementation knows how to properly use it (and
>> existing code compiles).
>
> I was under the impression that any Phobos code importing from
> experimental was taboo.
>

I wouldn't say so. If it's an implementation detail, so what? The key is 
to avoid breaking changes with user code, not breaking changes between 
std.experimental and std.

But I'm not the end-all rule maker. Perhaps there is a rule that it's taboo.

-Steve