std.experimental Timeline

Jack Stouffer via Digitalmars-d digitalmars-d at
Fri Jan 1 10:38:49 PST 2016

On Friday, 1 January 2016 at 17:26:17 UTC, Jonathan M Davis wrote:
> On Thursday, 31 December 2015 at 18:54:05 UTC, Jack Stouffer 
> wrote:
>> 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.

I propose this simple policy:

Three major releases after the module is included, the author has 
the right to ask that it be included in std by opening a new PR 
on Phobos. Voting at this point would be redundant, so if no 
Phobos contributors have any objections, based on open bugs or 
concerns in the API, then it MUST be merged.

Simple and effective.

More information about the Digitalmars-d mailing list