Oh *?^!@#?#Q@ I didn't intend to merge this, I was on the wrong tab...

This needs a follow-up at least in documentation, to tell people about the batching alternative and how to get it

• OnExecutionContext.global, maybe alsoExecutionContext.Implicits.global
• Possibly in the@implicitNotFound onExecutionContext

Here is how users can create a batching EC instance in their codebase (code adapted from a draft by@viktorklang). Maybe this can be improved further, feedback welcome.2.13.x...lrytz:custom-batching-ec

We also plan to ship the batching EC in scala-library-next.

If preferred, we can revert this PR and re-submit it.

@lrytz I have multiple issues with the proposal:

1. Have "everyone" reimplement the 2.13 global behavior will reduce performance since batches won't be shared between different implementations
2. Users who are depending on third-party library code which usesglobal have little chance of regaining lost performance since their dependency might have hard-coded the use of EC.global
3. Implementing the 2.13 global behavior requires access to internal code, which will not be under binary compatibility guarantees (relying om implementation details)
4. Users who lose performance due to the revert will likely only incidentally realize the cause
5. Putting the 2.13 global behavior inscala-library-next has very limited discoverability and I'd wager that it will see little use (although I hope I am wrong)

Have "everyone" reimplement the 2.13 global behavior will reduce performance since batches won't be shared between different implementations

Users who are depending on third-party library code which usesglobal have little chance of regaining lost performance since their dependency might have hard-coded the use of EC.global

My assumption is that the actual EC used in an application is always imported (or defined) by the application's own source code - is that wrong? Are there libraries out there that use an EC internally without requiring it to be provided as parameter? To me this would seem to be a problematic design; any application that doesn't useglobal would run with multiple ECs.

Implementing the 2.13 global behavior requires access to internal code, which will not be under binary compatibility guarantees (relying om implementation details)

Yes, we're making theBatchingExecutor andPromise.Transformation classes accessible and we'll have to guarantee binary compatibility. The accessible members are

• Promise.Transformation:public def benefitsFromBatching
• BatchingExecutor:protected def submitForExecution,protected def reportFailure,protected final def submitAsyncBatched,protected final def submitSyncBatched

This looks reasonable to me, the risk of it causing problems in 2.13.x maintenance seems really low.

Users who lose performance due to the revert will likely only incidentally realize the cause

Putting the 2.13 global behavior inscala-library-next has very limited discoverability and I'd wager that it will see little use (although I hope I am wrong)

I agree this is a concern, but in my opinion the benefits of revertingglobal to its 2.12 behavior outweigh. Of course we will highlight the change in the announcements and release notes. We can work through documentation that we own to include references.

My assumption is that the actual EC used in an application is always imported (or defined) by the application's own source code - is that wrong? Are there libraries out there that use an EC internally without requiring it to be provided as parameter? To me this would seem to be a problematic design; any application that doesn't use global would run with multiple ECs.

What people are recommended to do, and what they actually do, was what ended us up in this situation in the first place :)

Yes, we're making the BatchingExecutor and Promise.Transformation classes accessible and we'll have to guarantee binary compatibility. The accessible members are

BatchingExecutor might not be an issue, but leaking internal Promise implementation details is a bit of a no-starter since it completely prevents the implementation to evolve. Also consider ScalaJS.

I agree this is a concern, but in my opinion the benefits of reverting global to its 2.12 behavior outweigh. Of course we will highlight the change in the announcements and release notes. We can work through documentation that we own to include references.

I hope you're right!

Two more things we can do:

• Add the batching EC in aprivate[scala] field in 2.13.4
  • Application users (those not publishing a library) that have control over the Scala version at runtime could access that (there are ways to do so)
  • It could come in handy in the future, for example if there is more tooling in place so that a library could require a minimal Scala version
• Mark the new public type aliases@deprecated with a clear message, and silence the depreaction in the code snippet for a user-defined batching EC with@nowarn

@lrytz Adding theopportunistic EC (Batching on top ofglobal) as a private[scala] sounds good. A more ideal solution would be if one could have it be public, but with an @backwardsIncompatible annotation which would alert users that if they depend on it, it will not work with an older scala-lib (or even better, if an @since-annotation whose "minor" (epoch.major.minor) is not a "0" would automatically warn on compilation warning that using it means that the app is no longer backwards-compatible with an older scala-lib)

@backwardsIncompatible

This could be done with#8820

@dwijnand@lrytz Do you want me to open a PR with the private[scala]opportunistic EC so we can include it in 2.13.4?

That'd be welcome, thank you!

@lrytz@dwijnandhttps://github.com/scala/scala/pull/9296/files