-
Notifications
You must be signed in to change notification settings - Fork 560
Description
@bpholt recently brought up the issue of providing an MTL Local instance for IOLocal in armanbilge/oxidized#9 (comment). That repo exists because Cats MTL can't provide it (since it creates a dep cycle with CE), and Cats Effect hasn't provided it (so far). Here are some reasons we should reconsider.
- As noted, Cats Effect already has a dependency on MTL, via the testkit. So it's not technically increasing our bincompat vulnerability.1
- http4s is pursuing MTL-based middleware for 1.0. So MTL will likely end up on the classpath of all practical Typelevel applications anyway.
Furthermore: there is a lot of frustration about the semantics to expect from IOLocal e.g. #3100, typelevel/fs2#2842.
The interesting thing is, if you use IOLocal only as a Local (i.e. none of its lower-level methods) I am pretty sure you won't run into weird behavior like that. Local encodes semantics that make it safe to use IOLocal, without leaking implementation details about how Stream or whatever uses Fibers under-the-hood. Of course, it is less powerful when used this way, but that's par-for-the-course.
So I think there's an argument to push Local as the blessed way to interact with an IOLocal, unless you are specifically doing low-level stuff. Think .background to .start. And that could be another good reason to provide such an instance directly.
Footnotes
-
although I suppose in the current state we could break the testkit if MTL had to break, and it would be less bad than breaking core. ↩