Remove IOLocal#scope, revert #3214

[armanbilge]

Reverts #3214, with apologies to @iRevive. IIRC I even encouraged that PR, so my bad.

Basically, for scope to work correctly, the acquire and release effects must run on the same fiber. Resource cannot guarantee this, so IMO it's a leaky abstraction. Furthermore Ross and I demonstrated various weird/surprising behaviors when mixed with other combinators starting from #3360 (comment).

So yeah, I feel very unsure about exposing an API like this now. If we want to offer "higher-level" APIs that can be used safely, my vote is for something like #3385.

[rossabaker]

I have incidentally talked myself into it being fine. There are pointy bits, but I think the behavior is correct according to spec, and there are lots of other pointy bits. Why not remove .set, which also does weird shit in races?

I agree that higher-level APIs are needed for safe use. #3385 is excellent for "static monadic regions", but not up to the task of "dynamic monadic regions", to borrow terms from #634. I'm still pursuing that holy grail for otel4s.

[armanbilge]

I think the behavior is correct according to spec

Is it? It says this.

The original value is restored upon the finalization of a resource.

There's no way it can guarantee this, without guaranteeing that it can run those on the same fiber. Which it cannot, because allocated.

[rossabaker]

Okay, that's fair. But allocated is "an advanced and potentially unsafe api which can cause a resource leak if not used correctly". Is there an adversarial function we can pass to use that would break it?

Stream gets into trouble not by calling allocated, but pattern matching to destructure Resource.Allocated, which I consider morally the same thing.

[armanbilge]

But allocated is "an advanced and potentially unsafe api which can cause a resource leak if not used correctly"

Yes, but whose job is it to use correctly? If I compose my local.scope resource with some other resources and hand it off to something that does .allocated (e.g. a pool), is it their fault that it all went wrong?

[armanbilge]

The problem is, that even if allocated is an advanced API, you can use it correctly even if you run the acquire and release on different fibers. That's allowed.

Which is why this API doesn't work: to deliver what it promises, it relies on behavior which is not guaranteed.

[rossabaker]

That's fair. FS2 is using Allocated appropriately: it releases what it acquires. We are getting bad behavior with FS2 and IOLocal not because FS2 is buggy, but because IOLocal imposes constraints FS2 isn't designed for.

[djspiewak]

I think there are enough footguns here that I'd rather err on the side of caution. We can always bring it back in a later release.

[wunderk1nd-e]

@djspiewak @rossabaker Would going back to the originally proposed implementation using bracket dodge the issues with how the Resource might end up getting used?
#3128

[armanbilge]

@wunderk1nd-e thanks for chiming in! Yes, I believe that would address the issues, since the acquire and release phases of bracket are guaranteed to run on the same fiber.