Skip to content

IOLocal: MTL Local instance & semantics #3385

@armanbilge

Description

@armanbilge

@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.

  1. As noted, Cats Effect already has a dependency on MTL, via the testkit. So it's not technically increasing our bincompat vulnerability.1
  2. 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

  1. 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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions