Move std.typecons.apply to std.experimental

[wilzbach]

Introduced in #6182

Can we please instead of sticking our necks out, have an experimental stage for new functions?

Rust is showing the way here by making news additions "unstable" first and then stabilizing them after this testing period, e.g. https://blog.rust-lang.org/2018/02/15/Rust-1.24.html (they do the same thing for language features too: https://doc.rust-lang.org/unstable-book)
I proposed a few things at #6178 (comment) (I don't care which one is picked).

However, any mechanism that allows us to mark it unstable for one or two versions is a lot better than immediately releasing it and releasing that we have made a mistake / slight oversight which happens far too frequently.

Just going to make a move here with one approach. May the nitpicking for the best solution begin ;-)

[dlang-bot]

Thanks for your pull request, @wilzbach!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + phobos#6389"

[FeepingCreature]

Seems reasonable, since it has to be freestanding anyways. Needs an import there, ofc. :)

[JackStouffer]

I'd be more on board with this if we had a process of when to move it to stable typecons. wrap has been sitting there for a while.

[MetaLang]

I think this is function is simple enough that it does not need a stabilization period, but I'm on board either way.

[wilzbach]

I'd be more on board with this if we had a process of when to move it to stable typecons. wrap has been sitting there for a while.

Yeah, but wasn't it that the new wrap introduced breaking changes to the existing wrap, wasn't it?
(IIRC someone had mentioned some issues with Final, so I never tried to move that one either)

Anyhow, we can also simply add a warning to the docs if that's easier for everyone.
An example without background:

dlang/dlang.org#2308

or an orange message box with background as added here:

dlang/dlang.org#1778

I think this is function is simple enough that it does not need a stabilization period, but I'm on board either way.

I agree, but you got to start somewhere and I have being saying this for a while now and this was the first function that got added - and in this case just because Jack was so upset with how slowly things are moving and "stuck out his neck". Not that I'm against this rescue of this PR, it's just that this shouldn't be the normal case on how we merge new symbols and without an experimental stage of some sort such PRs are never merged.
There's typically always something that could be done to improve a new addition as it's really hard to get things 100% correct on the first try (e.g. in this case we could make it work for classes too -they are "nullable" too)

[JackStouffer]

My condition for approving this there needs to be, explicitly stated in the docs, a period when this will be moved out of experimental and into std (baring excessive bugs of course).

Honestly, there should be an inverse of my deprecation process DIP, i.e. a DIP for defining a process of moving experimental functions to mainline after N releases.

[wilzbach]

I guess it's too late for this now :/
Though I really think we should have some model of marking symbols als unstable.
Maybe we can use @__future for this?