-
Notifications
You must be signed in to change notification settings - Fork 521
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
Split interruptible
#2343
Split interruptible
#2343
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks really good apart from my one note! And I would generally trust mima: the approached you used is indeed binary compatible.
Thanks for taking this on. |
Can we solve this by publishing a snapshot? |
@@ -1466,9 +1466,13 @@ object IO extends IOCompanionPlatform with IOLowPriorityImplicits { | |||
|
|||
override def blocking[A](thunk: => A): IO[A] = IO.blocking(thunk) | |||
|
|||
override def interruptible[A](many: Boolean)(thunk: => A): IO[A] = | |||
private[effect] override def interruptible[A](many: Boolean)(thunk: => A): IO[A] = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wait you can do that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It technically doesn't change the visibility in the bytecode, so yes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we sure it does what we want downstream?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, let's not take that risk.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
scala> import cats.effect.IO
import cats.effect.IO
scala> IO.interruptible(false) { println("hi") }
val res0: cats.effect.IO[Unit] = IO(...)
Looks like it doesn't mask it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, thanks for confirming. Good to know.
For posterity, the problem here is the following:
Looks like the |
IMO, it's worth breaking binary compatibility with Java interop on this one function in order to get the better API for everyone. Anyone have any objections? Paging @rossabaker and @johnynek for opposing opinions. |
just to chime in: My feeling is that runtime errors really suck, and if you want to be a super core library, you will be implicated in many diamonds, so try to never break binary compatibility. But this is your project, of course, so make your own calls. |
I do very much agree with this. The only reason I'm even pondering the breakage is the fact that it's confined to the Java interop exclusively. Scala code paths never hit this forwarder and remain binary compatible. |
FWIW http4s recently made a similar decision to eschew Java forwarders in http4s/http4s#5071 (comment). |
@djspiewak @vasilmkd, can someone publish a snapshot, please, so I can try and write the scalafix migration? (if it is still needed I mean 😄 ) |
I will right now. |
"io.vasilev" %%% "cats-effect" % "3.3-208-b352672" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How did the build.sbt
changes get pulled in? That PR is not merged yet.
This one is tough: a marginally better API for what is probably 100% of users, or a landmine for an unanticipated use case. We chose the Scala users in http4s, but it makes me queasy, and the risk is higher on this project. A third option is bytecode postprocessing. I haven't done it in the Scala Era, but I'm pretty sure it would be possible. |
With a repeated word of caution and previous experience, maybe it is worth reconsidering the extent of this change. |
Having these in mind, should I close this PR? |
No, not yet, let's have a discussion with Daniel, whenever he's back. We'll definitely add |
I'm back ish. :-) To @rossabaker's point… There's another option here, which is that we can keep the current Either way, I think that we can shift the discussion a bit. We agree the changes here are good (I think), and they're binary-compatible as currently written. I'm in favor of merging this PR and having a follow-up if we want to get fancy with hiding the old |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome work, @alexandrustana! Thanks for shepherding this through the process, and sorry for handing you such a thorny change.
.in(file("v3_3_0/output")) | ||
.settings( | ||
libraryDependencies ++= Seq( | ||
"io.vasilev" %% "cats-effect" % "3.3-208-b352672" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's remember to update this to the mainline 3.3.0 once released
FYI: scala-steward-org/scala-steward#2270 adds the v3_3_0 Scalafix to Scala Steward. |
@djspiewak, @vasilmkd thank you for all the help and support 🙂 |
Thank you @fthomas! @alexandrustana Thank you for the outstanding work and your patience. |
This PR tries to fix #2268.
Running
mimaReportBinaryIssues
doesn't seem to report anything, so I hope the changes are binary compatible 😄TODO: