-
Notifications
You must be signed in to change notification settings - Fork 451
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
deprecate arrow.continuation #2672
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great @i-walker! 🙏
Just one thought on the arrow.core.generic
package for AtomicRef
.
@@ -0,0 +1,52 @@ | |||
package arrow.core.generic |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be under generic
🤔 Perhaps we should put it under continuation
?
It's not really an arrow.core
type, but it's required for the continuation
runtime.
I think it's useful enough to expose since I've been using it already in some downstream MPP projects.
It's something I really miss in MPP projects and is not easily available in Kotlin since atomic-fu
is not stable yet and still has some issues to be used in libraries.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, agree we can put this under arrow.generic. Maybe even create a small micro lib just with this descriptor, bc it can live without the overhead of arrow.core. What do you think? I am good with both options
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just remembered that arrow.generic
is a dedicated package for generic programming in the incubator, so should we keep it under arrow.core.continuation @nomisRev ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, let's just keep it in arrow.core.continuation
. We can always push it down into another dependency if we really need to later without making a binary breaking change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done :D
No description provided.