Add Async#syncStep

[armanbilge]

Takes the ideas from #1945 and #2613 and replays it for Async[F]. I think this is the law we are aiming for:

F.syncStep[G, A](fa, limit).to[F].flatMap {
  case Left(fa) => fa
  case Right(a) => F.pure(a)
} <-> fa

We should also consider adding Dispatcher#unsafeRunSyncToFuture and Dispatcher#unsafeRunSyncToPromise to match the methods on IO. Slightly annoying is the need to explicitly pass a limit since it cannot be retrieved from the IORuntime in this case.

[armanbilge]

I couldn't figure out how to get the compiler to like this without the cast 😕

[armanbilge]

The transformers were quite interesting to implement :) the law is actually quite important here in guiding the right behavior: we can only return A if we pattern match the pure representation for the underlying datatype.

[djspiewak]

Will look at this in more detail in a bit. I want to leave it open for discussion for now though since this would be a pretty significant addition to Async. Paging @SystemFw for galaxy brain thoughts, as well as absolutely anyone else who wants to weigh in.

[armanbilge]

I just added a slightly tweaked version of my law from above. I didn't realize SyncIO#to was not defined on Sync itself (makes sense in retrospect) but actually there's nothing to stop us from syncSteping into the same effect 😁

cats-effect/laws/shared/src/main/scala/cats/effect/laws/AsyncLaws.scala

Lines 69 to 77 in d82ac6b

	def syncStepIdentity[A](fa: F[A], limit: Int) =
	F.syncStep[F, A](fa, limit)(syncF).flatMap {
	case Left(fa) => fa
	case Right(a) => F.pure(a)
	} <-> fa
	// a mild hack, in case a `syncStep[G]` implementation
	// special-cases `F eq G` and thus short-circuits the law
	private[this] def syncF: Sync[F] = new Sync[F] {

[djspiewak]

Approved once the above two minor nits are addressed. I think this is a good change overall.

[djspiewak]

Oh actually, one further request: can you add this to AsyncSyntax?

[armanbilge]

Sorry, one last hack. I'd rather do this than the asInstanceOf below: type-erasure makes this okay, but unsafe casts are a footgun.

Thoughts?

[armanbilge]

Nevermind, Scala 3 doesn't like this.

[armanbilge]

We should also consider adding Dispatcher#unsafeRunSyncToFuture and Dispatcher#unsafeRunSyncToPromise to match the methods on IO. Slightly annoying is the need to explicitly pass a limit since it cannot be retrieved from the IORuntime in this case.

I tried doing this, but realized we basically can't.

1. We can't provide default implementations of these without requiring an Async[F] constraint on the methods.
2. Without SyncIO we have no way to unsafeRunSync anyway 🙃

In practice this is not a blocker since these can be implemented in user-land, but it is kind of annoying. Maybe could add them as syntax for Dispatcher in core?

[djspiewak]

In practice this is not a blocker since these can be implemented in user-land, but it is kind of annoying. Maybe could add them as syntax for Dispatcher in core?

Hmm, let's tackle this one in a follow up. We basically have to weigh whether a syntax enrichment in core is better or worse than a significantly-altered signature in std (e.g. taking a function of type G[A] => A as a parameter).

[armanbilge]

taking a function of type G[A] => A as a parameter

It would have to be G[A] => Either[Throwable, A] I think, but I suppose that's an option too 🤔