Tracking issue for Scoped TLS

[alexcrichton]

This is a tracking issue for the unstable scoped_tls feature in the standard library. The known open questions about this API are:

• Is it useful enough to be stabilized? It doesn't look like there's been much usage yet.
• Currently the API only accepts sized type parameters, but it in theory could accept more (although the OS doesn't technically support this). A decision should be made either way.
• Are we rock-solid that the implementation is sound?

[nagisa]

This reminds me of a Reader monad and its local method a lot. Specialisation of this monad to only work in TLS context sounds really obscure to me. Could this be generalised?

[Diggsey]

The stabilization of scoped TLS precludes the safe implementation of couroutines/fibers/green threads in external libraries.

Admittedly there are also problems with normal TLS, but they seem less terminal, and can probably be limited to causing unexpected behaviour or panics rather than outright memory unsafety with some changes.

Possible solutions:

• Formalize the notion of a call-stack/context within the standard library, and provide unsafe methods to "swap" the current context with another. External libraries can then build safe interfaces around this. Rename "scoped thread-local storage" to "scoped context-local storage" or similar. Either do the same thing for normal TLS, or also provide the means for external libraries to detect whether code is currently executing within a "LocalKey::with()" call, so that they can panic if a context switch occurs there.
• Keep a per-thread token which is initially left unset. Each type of threading is given a unique token, external libraries being able to acquire unique tokens from the standard library. Once a thread's token has been set, it can never be changed, and attempting to do so will cause it to panic. Any use of TLS will attempt to set the thread's token to "threaded-only". Similarly, for any use of coroutines/fibers, the external library must attempt to set its own special token.
• Make all libraries (including std) which use TLS be effectively generic over the threading model. Only when the code is compiled into an executable is the threading model fixed. If the final executable uses only native threads, then all TLS use gets compiled down to fast, native TLS. If the final program uses fibers, then use fiber local storage. One way this could be achieved is by leaving undefined symbols in all libraries which are only supplied when the final program is linked. This would preclude the use of multiple threading models within the same program.
• Introduce some form of static analysis and a set of attributes, such that the compiler can prove at compile-time that different threading-models don't mix.

All of the options have significant downsides, either due to complexity or runtime performance.

[alexcrichton]

:bell: This issue is now entering its cycle final comment period to be deprecation in 1.8 :bell:

Scoped TLS can currently be built externally on crates.io if truly necessary, and otherwise it seems to be getting far less usage than originally anticipated.

[nikomatsakis]

Even though I was an initial advocate for (and proposer of) scoped TLS, I think it's good to deprecate it. One major limitation that I didn't fully appreciate at the time is that the T of the variable must meet T: 'static, which tends to rule out a lot of the uses I've had in mind. At least without some unsafety. e.g., in the compiler we do some tricks to put a &ty::ctxt<'tcx> in there.

[alexcrichton]

The libs team discussed this during triage yesterday and the conclusion was to deprecate