Wip sip23 √

So CapturedEC closes at construction and Capturing at submission, these two
can be used to completely control where things get captured w/o putting thr
burden of prepare() on all usages of EC.

Btw do you have a link to where Twitter implements use sites of EC.prepare
and how you test that no one forgets to call it? (That was our biggest
issue)
On Jun 30, 2014 7:52 PM, "marius a. eriksen" <notifications@github.com>
wrote:

> In src/library/scala/concurrent/ExecutionContext.scala:
>
> > +     *  execution context. The recommended implementation of
> > +     *  `prepare` is to return `this`.
> > +     *
> > +     *  This method should no longer be overridden or called. It was
> > +     *  originally expected that `prepare` would be called by
> > +     *  all libraries that consume ExecutionContexts, in order to
> > +     *  capture thread local context. However, this usage has proven
> > +     *  difficult to implement in practice and instead it is
> > +     *  now better to avoid using `prepare` entirely.
> > +     *
> > +     *  Instead, if an `ExecutionContext` needs to capture thread
> > +     *  local context, it should capture that context when it is
> > +     *  constructed, so that it doesn't need any additional
> > +     *  preparation later.
> > +     */
> > +  @deprecated("Preparation of ExecutionContexts will be removed.", "2.12")
>
> Right, exactly my point: if it's a val, it will probably capture the
> wrong thing -- we need to be precise about exactly where capture happens.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/viktorklang/scala/pull/6/files#r14364332>.
>