Introduce "inclusive" `race` as new default semantic

[djspiewak]

Full discussion here: https://discord.com/channels/632277896739946517/839263556754472990/1078054700932419695

The short version is that race, in its current form, represents a resource leak. If there's a tie (i.e. f.cancel *> f.join does not produce Outcome.Canceled()), then it's ambiguous as to what result should be chosen. Right now, we technically bias to the Left, but this is just an implementation detail made manifest. Even worse, if a race is doubly-successful in this way, it's very possible that a resource was acquired which will now just disappear. In most cases, resources which are acquired and then later exposed to an error or self-cancelation will trigger finalizers, but often not in success cases, so this is particularly dangerous.

In a very real sense, race should never have returned Either. The more correct return type would have been Ior.

We can address this in one of two ways. We can either introduce a new variant, like raceInclusive, which returns Ior and then deprecate race. Alternatively, we can play tricks with Dummy implicits and break everyone's sources:

def race[A, B](fa: F[A], fb: F[B])(implicit D: Dummy): F[Ior[A, B]] = ???
private[effect] def race[A, B](fa: F[A], fb: F[B]): F[Either[A, B]] = ???

I'm very tempted to say this is better because it avoids significant problems and cleans up the API (in some sense), but this is definitely a request for comments.

This is all orthogonal to the fiber isolation semantics of race. This affects a few things, but the most significant being self-cancelation semantics: do we treat self-cancelation as "losing the race", or do we treat it as cancelation and embed that result into the parent fiber? The former semantic leads to issues like #3396, while the latter semantic opens up some interesting possibilities (such as a computation "giving up" and allowing the alternative to complete naturally).

racePair is capable of handling all of this generality, and so for any use-cases which are not extremely common, we should push people in that direction, despite the fact that it's very low-level and somewhat hard to work with correctly. We should focus the pretty parts of the API on the most common semantics, which is likely fiber non-isolation (i.e. timeout semantics).

[Jasper-M]

do we treat self-cancelation as "losing the race", or do we treat it as cancelation and embed that result into the parent fiber? The former semantic leads to issues like #3396, while the latter semantic opens up some interesting possibilities (such as a computation "giving up" and allowing the alternative to complete naturally).

Aren't both of those things related to the former semantic?

[armanbilge]

do we treat self-cancelation as "losing the race"

In this case, race(canceled, sleep(1.second)) ends after 1 second with rhs as the winner. The lhs "lost" the race. This is the former semantic.

do we treat it as cancelation and embed that result into the parent fiber

In this case, race(canceled, sleep(1.second)) ends in cancelation effectively immediately. The lhs "won" the race. This is the new semantic.

Does that answer your question?

[Jasper-M]

Sorry I didn't phrase my question very well. I was mainly confused about this part:

the latter semantic opens up some interesting possibilities (such as a computation "giving up" and allowing the alternative to complete naturally)

Isn't this an example of a possibility that the former semantic gives you, and not the latter?

[armanbilge]

Oh, gotcha, I think you are right! Daniel can clarify maybe.

[GreyPlane]

uh, I just found this issue after I implemented my own sketchy version while my original goal was to achieve a similar short-circuit evaluation semantic of boolean for IO racing but the general concern about the semantic seems very valid, nice to see this API came into cats-effect.

[djx314]

val brokenOrNot: Boolean = readFromJavaParameterOrReadFromTypesafeConf.getOrElse(true Or false)

trait Dummy

object Dummy {
  implicit def dymmyImplicit: Dummy = macro macroFold(brokenOrNot) {
    broke the macro and compile failed // if brokenOrNot is true
  } {
    val positiion = c.getPosition
    printlnCompiletimeMessage(position) // suggest what the caller need to do and tagged the code where you need to update.
    null.asInstanceOf[Dummy] // if brokenOrNot is false
  }
}

[djx314]

val breakTheCompilerOrNot: Boolean = readFromJavaParameterOrReadFromTypesafeConf.getOrElse(true Or false)

trait Dummy

object Dummy {
  implicit def dymmyImplicit: Dummy = macro macroFold(breakTheCompilerOrNot) {
    broke the macro and compile failed // if breakTheCompilerOrNot is true
  } {
    val positiion = c.getPosition
    printlnCompiletimeMessage(position) // suggest what the caller need to do and tagged the code where you need to update.
    null.asInstanceOf[Dummy] // if breakTheCompilerOrNot is false
  }
}

Let the caller decide on their own whether to break the source code or not. Just get the parameter from the JVM parameter or other place is OK.
If need to break the source code, make the implicit macro failed and will throw implicit not found. And if no need to break, use print compile message to replace the usage of deprecate annotation.