I suspect these are better fitting as extension methods for specific types... Using these methods will introduce interface dispatch through Numeric and boxing via an unspecialized Ref. We should probably consider ways to introduce specialization without boxing via concrete classes...

@hearnadam I agree although I think that it might be better to do what you're proposing as a separate piece of work. It will actually be really good to have concrete classes that utilize AtomicInt, AtomicLong and other AtomicX under the hood for primitives.

AFAICT the changes in this PR should be backwards compatible, where we can simply ignore the implicit Numeric in the specialized implementations.

Can these be extension methods instead?

Can these be extension methods instead?

If we have them as extension methods we won't be able to override them when we end up implementing via concrete classes. Or maybe I'm missing something?

Is there anything I can do?

Is there anything I can do?

I was just waiting to see if there are any more comments before merging. @hearnadam do you have anything to add to this comment?

I don't think it's possible to avoid the boxing without deferred in-lining which I was unable to make work even in Scala 3 only.

The concrete class can at least override those methods, so you're correct that's a better approach.

I don't think it's possible to avoid the boxing without deferred in-lining which I was unable to make work even in Scala 3 only.

The concrete class can at least override those methods, so you're correct that's a better approach.

@hearnadam I think there are patterns in Scala 3 that could avoid the boxing, e.g.,:

extension (ref: Ref[Int]) {
  @targetName("getAndIncrementInt")
  def getAndIncrement: UIO[Int] = ref.getAndUpdate(_ + 1)
}

extension (ref: Ref[Long]) {
  @targetName("getAndIncrementLong")
  def getAndIncrement: UIO[Long] = ref.getAndUpdate(_ + 1)
}

But yeah can't think of a way to make this cross-compile to Scala 2 since we're lacking the targetName annotation