FiberLocal typeclass

[TimWSpence]

I attempted to capture the current behaviour in a typeclass with laws to get the ball rolling on this. Pretty much all of it is up for debate!

It's also not binary-compatible so keen for feedback on what the cleanest way to restore bin-compat is

[kubukoz]

At this point we can't remove this anymore without breaking binary compatibility, IMO it can stay and we can just forward to it

[kubukoz]

Worst case make it private[effect] but still use it, if we want to discourage direct usage.

[TimWSpence]

Thanks! Yeah, I noted that in the message above but thought it wasn't worth dealing with until there is actually agreement on the design.

How does making it private[effect] not break bincompat sorry?

[kubukoz]

The class and methods will still be there at runtime, so 2rd party libraries built with 3.0.0 can continue to use them, but users who upgrade won't be able to touch them (because of the source level private modifier)

[TimWSpence]

Shockingly TIL visibility modifiers are only checked at compile time 🤦 😂 I did actually wonder if that was what you were saying but thought surely I would know that by now 😂

Thanks! 👍

[kubukoz]

I think private might actually make a difference, but the qualified variant (private[pkg]) won't :D

[kubukoz]

Can probably be abstracted to GenConcurrent[F, _]

[RaasAhsan]

I think FiberLocal could also be renamed to GenLocal with the appropriate aliases. Then we do FiberLocal and FiberRef for the data structures

[TimWSpence]

👍 Does the Throwable alias just become Local then?

[RaasAhsan]

I think LocalThrow ?

[RaasAhsan]

Oh no Local you are right

[RaasAhsan]

Ahh I didn't realize you were doing the scato encoding here 👍 that avoids coherence issues

[kubukoz]

Also doesn't seem that useful for the core algebra, but maybe there's something we can find there (e.g. do any other operators derive from this)

[TimWSpence]

Yeah, it would have to live as a subclass of GenConcurrent and then we'd have to impose an arbitrary subtyping relationship between GenTemporal and GenLocal or vice versa so it is probably better off to the side

[kubukoz]

I still don't understand this part

Why do we need that at all? Errors aren't part of the algebra

Seems to me like we're unnecessarily abstracting on the error here instead of quantifying existentially (GenConcurrent[F, _]). Unless we want to use errors / failed effects in laws?

[TimWSpence]

Sorry yeah, good point - we're not using them in the laws (actually we're not using Concurrent either any more - I think it can be downgraded to Spawn) 👍 @RaasAhsan happy with this?

[RaasAhsan]

#1822 is related to this as well

[RaasAhsan]

BTW there was a lot of discussion around whether we should have this as late as yesterday, but the main point of contention was that we're not sure if Monix and ZIO's local semantics will support ours. I believe we got confirmation that Monix doesn't, but Monix on CE3 doesn't exist yet and @Avasil expressed interest in a typeclass, so that could be up in the air. I think ZIO does, but we should double check.

[RaasAhsan]

I think if FiberRef is 👍 , we can add a default constructor for it here in terms of local and Concurrent[F] (in a bincompat manner even, if it comes later)

[kubukoz]

I'll make it a draft for now to avoid accidental merges, but feel free to undraft when we have that Spawn stuff figured out :)