std.experimental Timeline

[Jonathan M Davis via Digitalmars-d]

On Thursday, 31 December 2015 at 18:54:05 UTC, 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.

We have no actual policy on the matter, and until we do, I expect 
that anything that's in std.experimental will indeed sit there 
indefinitely.

Putting stuff in std.experimental to begin with in order to let 
it be banged on a bit by the community at large before being 
finalized in std makes sense, but at what point is it actually 
ready to be put into std? How do we decide that? And do we need 
to vote again, or have any kind of further review in the 
newsgroup? Or do we just wait and see if we get bug reports on it 
and otherwise leave it as-is until we move it over into std due 
to age or because some of the Phobos devs feel like it? AFAIK, 
there's no consensus whatsoever on any of that. AFAIK, we don't 
really even have any proposals on that. We just sort of decided 
that having stuff put into experimental first would be a good 
idea so that we can minimize breaking stuff in std or be forced 
to leave it as-is permanently when a problem is found in the API 
within a release or two of it being put in Phobos.

Probably, we either need someone to propose a process so that we 
can discuss it and possibly adopt it (either by agreeing to it as 
a group or by Walter and Andrei approving it). Certainly, until 
someone pushes the issue, I expect that nothing is going to 
escape std.experimental.

>> 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 confess that I was assuming that that was the case, but I'm not 
sure that it's ever been discussed. If there's any risk of the 
code from std.experimental being thrown away from Phobos rather 
than moved into std, or if using the stuff from std.experimental 
would affect the API in std, then it would probably be a bad idea 
to use it in std. But if it's definitely going to stay in one 
form or another, and changes to it aren't going to affect the API 
in std, then maybe it would be okay. I don't know. I was assuming 
that std.experimental was an island unto itself, and it hadn't 
occurred to me that anyone would be using it in std before it go 
into std itself, but that doesn't mean that that's necessarily 
how it should be.

- Jonathan M Davis