std.experimental Timeline

Steven Schveighoffer via Digitalmars-d digitalmars-d at puremagic.com
Thu Dec 31 10:26:08 PST 2015


On 12/31/15 12:45 PM, Jack Stouffer wrote:
> Currently, we have two modules in std.experimental with a third on the
> way and potentially a single function as well:
> https://github.com/D-Programming-Language/phobos/pull/2945/files
>
> Yet it's a bit concerning that there's no plan on when any of these will
> be moved into the main namespace.

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"

> std.logger has been in std.experimental for eight releases and eight
> months. Robert Schadek believes it's blocked by the non existant
> RCString:
> https://github.com/D-Programming-Language/phobos/pull/1500issuecomment-155457980

I think this is probably something that needs revisiting. I don't 
remember the rationale behind delaying the movement of logger into std.

> Also, knowing when std.allocator will be moved is important, because
> certain functions should integrate std.allocator as soon as it's
> available and have them usable in the same release. People who would
> contribute those changes need to know when that is going to happen in
> order to get the necessary work done before hand.

This is somewhat tricky. New functions can just be put in 
std.experimental. Changed functions are not as easy.

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).

-Steve


More information about the Digitalmars-d mailing list