Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow IOApp to access the default ExecutionContext #1457

Merged
merged 1 commit into from
Nov 28, 2020

Conversation

Daenyth
Copy link
Contributor

@Daenyth Daenyth commented Nov 28, 2020

Currently it's not possible for users of IOApp to use the default
ExecutionContext that backs the ContextShift.

They need to either use IOApp.WithContext, or use two unrelated pools, or
override the default ContextShift.

This should remove some needless hoop-jumping, I think

Close #748

@Daenyth Daenyth force-pushed the get-ec branch 2 times, most recently from 94e02fa to ba98993 Compare November 28, 2020 01:19
@Daenyth
Copy link
Contributor Author

Daenyth commented Nov 28, 2020

[error] /home/runner/work/cats-effect/cats-effect/core/shared/src/main/scala/cats/effect/IOApp.scala:105:3: Could not find any member to link for "ExecutionContext".

What's the correct way to fix that? I'm not super familiar with scaladoc

@djspiewak
Copy link
Member

Easiest way to fix it in the short term is to remove the reference and just use the name. Medium term though we should bring in unidoc or write the references ourselves.

Currently it's not possible for users of `IOApp` to use the default
ExecutionContext that backs the ContextShift.

They need to either use `IOApp.WithContext`, or use two unrelated pools, or
override the default `ContextShift`.

This should remove some needless hoop-jumping, I think

Close typelevel#748
@djspiewak djspiewak merged commit 2ff1331 into typelevel:series/2.x Nov 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Consider exposing IOApp's ExecutionContext as protected
2 participants