Conversation
|
I don't think we should choose to keep API compatibility and make a wrapper class around k.c.a impl. We should follow kotlin stdlib API shape and create a new module like arrow.atomics2 while keeping package name. Moreover a wrapper class do harm performance. |
I think this is actually what we should do to keep our API compatible while at the same time making our maintenance work much less (instead of keeping 4 versions of the code, the new one just wraps the common one).
I think the difference in this case (just one more indirection) is quite minimal, to be honest. Even more so because in almost every platform (except JVM) we may get a more performant implementation from Kotlin Team. |
|
I think this is a good temporary solution. To be honest, I don't see why anyone would use Arrow atomics instead of the stdlib ones, though. Maybe |
|
Superseded by #3879 |
Just trying, maybe we should only merge once this is out of experimental