MonadUnliftIO instance for SafeT?

[merijn]

It seems like SafeT nicely fits Snoyman's MonadUnliftIO design, and having an instance for it would make it drastically simpler to write code that supports both Pipes and Conduit. In addition the unliftio-core library has a very minimal dependency footprint (only depending on base and transformers on which pipes already depends anyway).

[Gabriella439]

I'm not convinced that UnliftIO is the correct abstraction. I think the correct abstraction is either MonadManaged:

https://hackage.haskell.org/package/managed-1.0.6/docs/Control-Monad-Managed.html#t:Managed

... or an equivalent type class replacing Managed with Data.Acquire.Acquire

[merijn]

That may well be, but a significant portion of the ecosystem doesn't use MonadManaged, but ResourceT or MonadUnliftIO. For some of my libraries I'm trying to expose a streaming interface that can be used with either pipes or conduit (and maybe machines if I ever get around to that), but the lack of shared abstraction is making it a real pain for me. Having MonadUnliftIO at the base of both would drastically simplify my life.

Alternatively, I could simply make the pipes interface require MonadResource and rely on ResourceT over SafeT, but that doesn't seem like it plays as nice with Pipes.

[Gabriella439]

I still think the best solution would be to add a MonadAcquire class to the resourcet package. I think that has nice laws and would satisfy most use cases, plus it's an addon to an already widely used package