GenSpawn

Introduces a fairness boundary that yields control back to the scheduler of the runtime system. This allows the carrier thread to resume execution of another waiting fiber.

This function is primarily useful when performing long-running computation that is outside of the monadic context. For example:

 fa.map(data => expensiveWork(data))

In the above, we're assuming that expensiveWork is a function which is entirely compute-bound but very long-running. A good rule of thumb is to consider a function "expensive" when its runtime is around three or more orders of magnitude higher than the overhead of the map function itself (which runs in around 5 nanoseconds on modern hardware). Thus, any expensiveWork function which requires around 10 microseconds or longer to execute should be considered "long-running".

The danger is that these types of long-running actions outside of the monadic context can result in degraded fairness properties. The solution is to add an explicit cede both before and after the expensive operation:

 (fa <* F.cede).map(data => expensiveWork(data)).guarantee(F.cede)

Note that extremely long-running expensiveWork functions can still cause fairness issues, even when used with cede. This problem is somewhat fundamental to the nature of scheduling such computation on carrier threads. Whenever possible, it is best to break apart any such functions into multiple pieces invoked independently (e.g. via chained map calls) whenever the execution time exceeds five or six orders of magnitude beyond the overhead of map itself (around 1 millisecond on most hardware).

Note that cede is merely a hint to the runtime system; implementations have the liberty to interpret this method to their liking as long as it obeys the respective laws. For example, a lawful, but atypical, implementation of this function is F.unit, in which case the fairness boundary is a no-op.

Introduces a fairness boundary that yields control back to the scheduler of the runtime system. This allows the carrier thread to resume execution of another waiting fiber.

This function is primarily useful when performing long-running computation that is outside of the monadic context. For example:

 fa.map(data => expensiveWork(data))

In the above, we're assuming that expensiveWork is a function which is entirely compute-bound but very long-running. A good rule of thumb is to consider a function "expensive" when its runtime is around three or more orders of magnitude higher than the overhead of the map function itself (which runs in around 5 nanoseconds on modern hardware). Thus, any expensiveWork function which requires around 10 microseconds or longer to execute should be considered "long-running".

The danger is that these types of long-running actions outside of the monadic context can result in degraded fairness properties. The solution is to add an explicit cede both before and after the expensive operation:

 (fa <* F.cede).map(data => expensiveWork(data)).guarantee(F.cede)

Note that extremely long-running expensiveWork functions can still cause fairness issues, even when used with cede. This problem is somewhat fundamental to the nature of scheduling such computation on carrier threads. Whenever possible, it is best to break apart any such functions into multiple pieces invoked independently (e.g. via chained map calls) whenever the execution time exceeds five or six orders of magnitude beyond the overhead of map itself (around 1 millisecond on most hardware).

Note that cede is merely a hint to the runtime system; implementations have the liberty to interpret this method to their liking as long as it obeys the respective laws. For example, a lawful, but atypical, implementation of this function is F.unit, in which case the fairness boundary is a no-op.

Introduces a fairness boundary that yields control back to the scheduler of the runtime system. This allows the carrier thread to resume execution of another waiting fiber.

This function is primarily useful when performing long-running computation that is outside of the monadic context. For example:

 fa.map(data => expensiveWork(data))

In the above, we're assuming that expensiveWork is a function which is entirely compute-bound but very long-running. A good rule of thumb is to consider a function "expensive" when its runtime is around three or more orders of magnitude higher than the overhead of the map function itself (which runs in around 5 nanoseconds on modern hardware). Thus, any expensiveWork function which requires around 10 microseconds or longer to execute should be considered "long-running".

The danger is that these types of long-running actions outside of the monadic context can result in degraded fairness properties. The solution is to add an explicit cede both before and after the expensive operation:

 (fa <* F.cede).map(data => expensiveWork(data)).guarantee(F.cede)

Note that extremely long-running expensiveWork functions can still cause fairness issues, even when used with cede. This problem is somewhat fundamental to the nature of scheduling such computation on carrier threads. Whenever possible, it is best to break apart any such functions into multiple pieces invoked independently (e.g. via chained map calls) whenever the execution time exceeds five or six orders of magnitude beyond the overhead of map itself (around 1 millisecond on most hardware).

Note that cede is merely a hint to the runtime system; implementations have the liberty to interpret this method to their liking as long as it obeys the respective laws. For example, a lawful, but atypical, implementation of this function is F.unit, in which case the fairness boundary is a no-op.

Introduces a fairness boundary that yields control back to the scheduler of the runtime system. This allows the carrier thread to resume execution of another waiting fiber.

This function is primarily useful when performing long-running computation that is outside of the monadic context. For example:

 fa.map(data => expensiveWork(data))

In the above, we're assuming that expensiveWork is a function which is entirely compute-bound but very long-running. A good rule of thumb is to consider a function "expensive" when its runtime is around three or more orders of magnitude higher than the overhead of the map function itself (which runs in around 5 nanoseconds on modern hardware). Thus, any expensiveWork function which requires around 10 microseconds or longer to execute should be considered "long-running".

The danger is that these types of long-running actions outside of the monadic context can result in degraded fairness properties. The solution is to add an explicit cede both before and after the expensive operation:

 (fa <* F.cede).map(data => expensiveWork(data)).guarantee(F.cede)

Note that extremely long-running expensiveWork functions can still cause fairness issues, even when used with cede. This problem is somewhat fundamental to the nature of scheduling such computation on carrier threads. Whenever possible, it is best to break apart any such functions into multiple pieces invoked independently (e.g. via chained map calls) whenever the execution time exceeds five or six orders of magnitude beyond the overhead of map itself (around 1 millisecond on most hardware).

Note that cede is merely a hint to the runtime system; implementations have the liberty to interpret this method to their liking as long as it obeys the respective laws. For example, a lawful, but atypical, implementation of this function is F.unit, in which case the fairness boundary is a no-op.

A non-terminating effect that never completes, which causes a fiber to semantically block indefinitely. This is the purely functional, asynchronous equivalent of an infinite while loop in Java, but no native threads are blocked.

A fiber that is suspended in never can be canceled if it is completely unmasked before it suspends:

 // ignoring race conditions between `start` and `cancel`
 F.never.start.flatMap(_.cancel) <-> F.unit

However, if the fiber is masked, cancellers will be semantically blocked forever:

 // ignoring race conditions between `start` and `cancel`
 F.uncancelable(_ => F.never).start.flatMap(_.cancel) <-> F.never

A non-terminating effect that never completes, which causes a fiber to semantically block indefinitely. This is the purely functional, asynchronous equivalent of an infinite while loop in Java, but no native threads are blocked.

A fiber that is suspended in never can be canceled if it is completely unmasked before it suspends:

 // ignoring race conditions between `start` and `cancel`
 F.never.start.flatMap(_.cancel) <-> F.unit

However, if the fiber is masked, cancellers will be semantically blocked forever:

 // ignoring race conditions between `start` and `cancel`
 F.uncancelable(_ => F.never).start.flatMap(_.cancel) <-> F.never

A non-terminating effect that never completes, which causes a fiber to semantically block indefinitely. This is the purely functional, asynchronous equivalent of an infinite while loop in Java, but no native threads are blocked.

A fiber that is suspended in never can be canceled if it is completely unmasked before it suspends:

 // ignoring race conditions between `start` and `cancel`
 F.never.start.flatMap(_.cancel) <-> F.unit

However, if the fiber is masked, cancellers will be semantically blocked forever:

 // ignoring race conditions between `start` and `cancel`
 F.uncancelable(_ => F.never).start.flatMap(_.cancel) <-> F.never

A non-terminating effect that never completes, which causes a fiber to semantically block indefinitely. This is the purely functional, asynchronous equivalent of an infinite while loop in Java, but no native threads are blocked.

A fiber that is suspended in never can be canceled if it is completely unmasked before it suspends:

 // ignoring race conditions between `start` and `cancel`
 F.never.start.flatMap(_.cancel) <-> F.unit

However, if the fiber is masked, cancellers will be semantically blocked forever:

 // ignoring race conditions between `start` and `cancel`
 F.uncancelable(_ => F.never).start.flatMap(_.cancel) <-> F.never

A low-level primitive for racing the evaluation of two fibers that returns the Outcome of the winner and the Fiber of the loser. The winner of the race is considered to be the first fiber that completes with an outcome.

racePair is a cancelation-unsafe function; it is recommended to use the safer variants.

A low-level primitive for racing the evaluation of two fibers that returns the Outcome of the winner and the Fiber of the loser. The winner of the race is considered to be the first fiber that completes with an outcome.

racePair is a cancelation-unsafe function; it is recommended to use the safer variants.

A low-level primitive for racing the evaluation of two fibers that returns the Outcome of the winner and the Fiber of the loser. The winner of the race is considered to be the first fiber that completes with an outcome.

racePair is a cancelation-unsafe function; it is recommended to use the safer variants.

A low-level primitive for racing the evaluation of two fibers that returns the Outcome of the winner and the Fiber of the loser. The winner of the race is considered to be the first fiber that completes with an outcome.

racePair is a cancelation-unsafe function; it is recommended to use the safer variants.

A low-level primitive for starting the concurrent evaluation of a fiber. Returns a Fiber that can be used to wait for a fiber or cancel it.

start is a cancelation-unsafe function; it is recommended to use the safer variant, background, to spawn fibers.

A low-level primitive for starting the concurrent evaluation of a fiber. Returns a Fiber that can be used to wait for a fiber or cancel it.

start is a cancelation-unsafe function; it is recommended to use the safer variant, background, to spawn fibers.

A low-level primitive for starting the concurrent evaluation of a fiber. Returns a Fiber that can be used to wait for a fiber or cancel it.

start is a cancelation-unsafe function; it is recommended to use the safer variant, background, to spawn fibers.

A low-level primitive for starting the concurrent evaluation of a fiber. Returns a Fiber that can be used to wait for a fiber or cancel it.

start is a cancelation-unsafe function; it is recommended to use the safer variant, background, to spawn fibers.

Returns a Resource that manages the concurrent execution of a fiber. The inner effect can be used to wait on the outcome of the child fiber; it is effectively a join.

The child fiber is canceled in two cases: either the resource goes out of scope or the parent fiber is canceled. If the child fiber terminates before one of these cases occurs, then cancelation is a no-op. This avoids fiber leaks because the child fiber is always canceled before the parent fiber drops the reference to it.

 // Starts a fiber that continously prints "A".
 // After 10 seconds, the resource scope exits so the fiber is canceled.
 F.background(F.delay(println("A")).foreverM).use { _ =>
   F.sleep(10.seconds)
 }

Returns a Resource that manages the concurrent execution of a fiber. The inner effect can be used to wait on the outcome of the child fiber; it is effectively a join.

The child fiber is canceled in two cases: either the resource goes out of scope or the parent fiber is canceled. If the child fiber terminates before one of these cases occurs, then cancelation is a no-op. This avoids fiber leaks because the child fiber is always canceled before the parent fiber drops the reference to it.

 // Starts a fiber that continously prints "A".
 // After 10 seconds, the resource scope exits so the fiber is canceled.
 F.background(F.delay(println("A")).foreverM).use { _ =>
   F.sleep(10.seconds)
 }

Returns a Resource that manages the concurrent execution of a fiber. The inner effect can be used to wait on the outcome of the child fiber; it is effectively a join.

The child fiber is canceled in two cases: either the resource goes out of scope or the parent fiber is canceled. If the child fiber terminates before one of these cases occurs, then cancelation is a no-op. This avoids fiber leaks because the child fiber is always canceled before the parent fiber drops the reference to it.

 // Starts a fiber that continously prints "A".
 // After 10 seconds, the resource scope exits so the fiber is canceled.
 F.background(F.delay(println("A")).foreverM).use { _ =>
   F.sleep(10.seconds)
 }

Returns a Resource that manages the concurrent execution of a fiber. The inner effect can be used to wait on the outcome of the child fiber; it is effectively a join.

The child fiber is canceled in two cases: either the resource goes out of scope or the parent fiber is canceled. If the child fiber terminates before one of these cases occurs, then cancelation is a no-op. This avoids fiber leaks because the child fiber is always canceled before the parent fiber drops the reference to it.

 // Starts a fiber that continously prints "A".
 // After 10 seconds, the resource scope exits so the fiber is canceled.
 F.background(F.delay(println("A")).foreverM).use { _ =>
   F.sleep(10.seconds)
 }

Races the evaluation of two fibers and returns the result of both.

The following rules describe the semantics of both:

1. If the winner completes with Outcome.Succeeded, the race waits for the loser to complete. 2. If the winner completes with Outcome.Errored, the race raises the error. The loser is canceled. 3. If the winner completes with Outcome.Canceled, the loser and the race are canceled as well. 4. If the loser completes with Outcome.Succeeded, the race returns the successful value of both fibers. 5. If the loser completes with Outcome.Errored, the race returns the error. 6. If the loser completes with Outcome.Canceled, the race is canceled. 7. If the race is canceled before one or both participants complete, then whichever ones are incomplete are canceled. 8. If the race is masked and is canceled because one or both participants canceled, the fiber will block indefinitely.

Races the evaluation of two fibers and returns the result of both.

The following rules describe the semantics of both:

1. If the winner completes with Outcome.Succeeded, the race waits for the loser to complete. 2. If the winner completes with Outcome.Errored, the race raises the error. The loser is canceled. 3. If the winner completes with Outcome.Canceled, the loser and the race are canceled as well. 4. If the loser completes with Outcome.Succeeded, the race returns the successful value of both fibers. 5. If the loser completes with Outcome.Errored, the race returns the error. 6. If the loser completes with Outcome.Canceled, the race is canceled. 7. If the race is canceled before one or both participants complete, then whichever ones are incomplete are canceled. 8. If the race is masked and is canceled because one or both participants canceled, the fiber will block indefinitely.

Races the evaluation of two fibers and returns the result of both.

The following rules describe the semantics of both:

1. If the winner completes with Outcome.Succeeded, the race waits for the loser to complete. 2. If the winner completes with Outcome.Errored, the race raises the error. The loser is canceled. 3. If the winner completes with Outcome.Canceled, the loser and the race are canceled as well. 4. If the loser completes with Outcome.Succeeded, the race returns the successful value of both fibers. 5. If the loser completes with Outcome.Errored, the race returns the error. 6. If the loser completes with Outcome.Canceled, the race is canceled. 7. If the race is canceled before one or both participants complete, then whichever ones are incomplete are canceled. 8. If the race is masked and is canceled because one or both participants canceled, the fiber will block indefinitely.

Races the evaluation of two fibers and returns the result of both.

The following rules describe the semantics of both:

1. If the winner completes with Outcome.Succeeded, the race waits for the loser to complete. 2. If the winner completes with Outcome.Errored, the race raises the error. The loser is canceled. 3. If the winner completes with Outcome.Canceled, the loser and the race are canceled as well. 4. If the loser completes with Outcome.Succeeded, the race returns the successful value of both fibers. 5. If the loser completes with Outcome.Errored, the race returns the error. 6. If the loser completes with Outcome.Canceled, the race is canceled. 7. If the race is canceled before one or both participants complete, then whichever ones are incomplete are canceled. 8. If the race is masked and is canceled because one or both participants canceled, the fiber will block indefinitely.

Races the evaluation of two fibers and returns the Outcome of both. If the race is canceled before one or both participants complete, then then whichever ones are incomplete are canceled.

Races the evaluation of two fibers and returns the Outcome of both. If the race is canceled before one or both participants complete, then then whichever ones are incomplete are canceled.

Races the evaluation of two fibers and returns the Outcome of both. If the race is canceled before one or both participants complete, then then whichever ones are incomplete are canceled.

Races the evaluation of two fibers and returns the Outcome of both. If the race is canceled before one or both participants complete, then then whichever ones are incomplete are canceled.

Given an effect which might be uncancelable and a finalizer, produce an effect which can be canceled by running the finalizer. This combinator is useful for handling scenarios in which an effect is inherently uncancelable but may be canceled through setting some external state. A trivial example of this might be the following (assuming an Async instance):

 val flag = new AtomicBoolean(false)
 val fa = F blocking {
   while (!flag.get()) {
     Thread.sleep(10)
   }
 }

 F.cancelable(fa, F.delay(flag.set(true)))

Without cancelable, effects constructed by blocking, delay, and similar are inherently uncancelable. Simply adding an onCancel to such effects is insufficient to resolve this, despite the fact that under some circumstances (such as the above), it is possible to enrich an otherwise-uncancelable effect with early termination. cancelable addresses this use-case.

Note that there is no free lunch here. If an effect truly cannot be prematurely terminated, cancelable will not allow for cancelation. As an example, if you attempt to cancel uncancelable(_ => never), the cancelation will hang forever (in other words, it will be itself equivalent to never). Applying cancelable will not change this in any way. Thus, attempting to cancel cancelable(uncancelable(_ => never), unit) will ''also'' hang forever. As in all cases, cancelation will only return when all finalizers have run and the fiber has fully terminated.

If fa self-cancels and the cancelable itself is uncancelable, the resulting fiber will be equal to never (similar to race). Under normal circumstances, if fa self-cancels, that cancelation will be propagated to the calling context.

Given an effect which might be uncancelable and a finalizer, produce an effect which can be canceled by running the finalizer. This combinator is useful for handling scenarios in which an effect is inherently uncancelable but may be canceled through setting some external state. A trivial example of this might be the following (assuming an Async instance):

 val flag = new AtomicBoolean(false)
 val fa = F blocking {
   while (!flag.get()) {
     Thread.sleep(10)
   }
 }

 F.cancelable(fa, F.delay(flag.set(true)))

Without cancelable, effects constructed by blocking, delay, and similar are inherently uncancelable. Simply adding an onCancel to such effects is insufficient to resolve this, despite the fact that under some circumstances (such as the above), it is possible to enrich an otherwise-uncancelable effect with early termination. cancelable addresses this use-case.

Note that there is no free lunch here. If an effect truly cannot be prematurely terminated, cancelable will not allow for cancelation. As an example, if you attempt to cancel uncancelable(_ => never), the cancelation will hang forever (in other words, it will be itself equivalent to never). Applying cancelable will not change this in any way. Thus, attempting to cancel cancelable(uncancelable(_ => never), unit) will ''also'' hang forever. As in all cases, cancelation will only return when all finalizers have run and the fiber has fully terminated.

If fa self-cancels and the cancelable itself is uncancelable, the resulting fiber will be equal to never (similar to race). Under normal circumstances, if fa self-cancels, that cancelation will be propagated to the calling context.

Given an effect which might be uncancelable and a finalizer, produce an effect which can be canceled by running the finalizer. This combinator is useful for handling scenarios in which an effect is inherently uncancelable but may be canceled through setting some external state. A trivial example of this might be the following (assuming an Async instance):

 val flag = new AtomicBoolean(false)
 val fa = F blocking {
   while (!flag.get()) {
     Thread.sleep(10)
   }
 }

 F.cancelable(fa, F.delay(flag.set(true)))

Without cancelable, effects constructed by blocking, delay, and similar are inherently uncancelable. Simply adding an onCancel to such effects is insufficient to resolve this, despite the fact that under some circumstances (such as the above), it is possible to enrich an otherwise-uncancelable effect with early termination. cancelable addresses this use-case.

Note that there is no free lunch here. If an effect truly cannot be prematurely terminated, cancelable will not allow for cancelation. As an example, if you attempt to cancel uncancelable(_ => never), the cancelation will hang forever (in other words, it will be itself equivalent to never). Applying cancelable will not change this in any way. Thus, attempting to cancel cancelable(uncancelable(_ => never), unit) will ''also'' hang forever. As in all cases, cancelation will only return when all finalizers have run and the fiber has fully terminated.

If fa self-cancels and the cancelable itself is uncancelable, the resulting fiber will be equal to never (similar to race). Under normal circumstances, if fa self-cancels, that cancelation will be propagated to the calling context.

Given an effect which might be uncancelable and a finalizer, produce an effect which can be canceled by running the finalizer. This combinator is useful for handling scenarios in which an effect is inherently uncancelable but may be canceled through setting some external state. A trivial example of this might be the following (assuming an Async instance):

 val flag = new AtomicBoolean(false)
 val fa = F blocking {
   while (!flag.get()) {
     Thread.sleep(10)
   }
 }

 F.cancelable(fa, F.delay(flag.set(true)))

Without cancelable, effects constructed by blocking, delay, and similar are inherently uncancelable. Simply adding an onCancel to such effects is insufficient to resolve this, despite the fact that under some circumstances (such as the above), it is possible to enrich an otherwise-uncancelable effect with early termination. cancelable addresses this use-case.

Note that there is no free lunch here. If an effect truly cannot be prematurely terminated, cancelable will not allow for cancelation. As an example, if you attempt to cancel uncancelable(_ => never), the cancelation will hang forever (in other words, it will be itself equivalent to never). Applying cancelable will not change this in any way. Thus, attempting to cancel cancelable(uncancelable(_ => never), unit) will ''also'' hang forever. As in all cases, cancelation will only return when all finalizers have run and the fiber has fully terminated.

If fa self-cancels and the cancelable itself is uncancelable, the resulting fiber will be equal to never (similar to race). Under normal circumstances, if fa self-cancels, that cancelation will be propagated to the calling context.

Races the evaluation of two fibers that returns the result of the winner, except in the case of cancelation.

The semantics of race are described by the following rules:

1. If the winner completes with Outcome.Succeeded, the race returns the successful value. The loser is canceled before returning. 2. If the winner completes with Outcome.Errored, the race raises the error. The loser is canceled before returning. 3. If the winner completes with Outcome.Canceled, the race returns the result of the loser, consistent with the first two rules. 4. If both the winner and loser complete with Outcome.Canceled, the race is canceled. 8. If the race is masked and is canceled because both participants canceled, the fiber will block indefinitely.

Races the evaluation of two fibers that returns the result of the winner, except in the case of cancelation.

The semantics of race are described by the following rules:

1. If the winner completes with Outcome.Succeeded, the race returns the successful value. The loser is canceled before returning. 2. If the winner completes with Outcome.Errored, the race raises the error. The loser is canceled before returning. 3. If the winner completes with Outcome.Canceled, the race returns the result of the loser, consistent with the first two rules. 4. If both the winner and loser complete with Outcome.Canceled, the race is canceled. 8. If the race is masked and is canceled because both participants canceled, the fiber will block indefinitely.

Races the evaluation of two fibers that returns the result of the winner, except in the case of cancelation.

The semantics of race are described by the following rules:

1. If the winner completes with Outcome.Succeeded, the race returns the successful value. The loser is canceled before returning. 2. If the winner completes with Outcome.Errored, the race raises the error. The loser is canceled before returning. 3. If the winner completes with Outcome.Canceled, the race returns the result of the loser, consistent with the first two rules. 4. If both the winner and loser complete with Outcome.Canceled, the race is canceled. 8. If the race is masked and is canceled because both participants canceled, the fiber will block indefinitely.

Races the evaluation of two fibers that returns the result of the winner, except in the case of cancelation.

The semantics of race are described by the following rules:

1. If the winner completes with Outcome.Succeeded, the race returns the successful value. The loser is canceled before returning. 2. If the winner completes with Outcome.Errored, the race raises the error. The loser is canceled before returning. 3. If the winner completes with Outcome.Canceled, the race returns the result of the loser, consistent with the first two rules. 4. If both the winner and loser complete with Outcome.Canceled, the race is canceled. 8. If the race is masked and is canceled because both participants canceled, the fiber will block indefinitely.

Races the evaluation of two fibers that returns the Outcome of the winner. The winner of the race is considered to be the first fiber that completes with an outcome. The loser of the race is canceled before returning.

Races the evaluation of two fibers that returns the Outcome of the winner. The winner of the race is considered to be the first fiber that completes with an outcome. The loser of the race is canceled before returning.

Races the evaluation of two fibers that returns the Outcome of the winner. The winner of the race is considered to be the first fiber that completes with an outcome. The loser of the race is canceled before returning.

Races the evaluation of two fibers that returns the Outcome of the winner. The winner of the race is considered to be the first fiber that completes with an outcome. The loser of the race is canceled before returning.

Indicates the default "root scope" semantics of the F in question. For types which do ''not'' implement auto-cancelation, this value may be set to CancelScope.Uncancelable, which behaves as if all values F[A] are wrapped in an implicit "outer" uncancelable which cannot be polled. Most IO-like types will define this to be Cancelable.

Indicates the default "root scope" semantics of the F in question. For types which do ''not'' implement auto-cancelation, this value may be set to CancelScope.Uncancelable, which behaves as if all values F[A] are wrapped in an implicit "outer" uncancelable which cannot be polled. Most IO-like types will define this to be Cancelable.

Indicates the default "root scope" semantics of the F in question. For types which do ''not'' implement auto-cancelation, this value may be set to CancelScope.Uncancelable, which behaves as if all values F[A] are wrapped in an implicit "outer" uncancelable which cannot be polled. Most IO-like types will define this to be Cancelable.

Indicates the default "root scope" semantics of the F in question. For types which do ''not'' implement auto-cancelation, this value may be set to CancelScope.Uncancelable, which behaves as if all values F[A] are wrapped in an implicit "outer" uncancelable which cannot be polled. Most IO-like types will define this to be Cancelable.

Alias for productR.

Alias for productR.

Alias for productR.

Alias for productR.

Alias for productL.

Alias for productL.

Alias for productL.

Alias for productL.

Alias for ap.

Alias for ap.

Alias for ap.

Alias for ap.

Transform certain errors using pf and rethrow them. Non matching errors and successful values are not affected by this function.

Example:

scala> import cats._, implicits._

scala> def pf: PartialFunction[String, String] = { case "error" => "ERROR" }

scala> ApplicativeError[Either[String, *], String].adaptError("error".asLeft[Int])(pf)
res0: Either[String,Int] = Left(ERROR)

scala> ApplicativeError[Either[String, *], String].adaptError("err".asLeft[Int])(pf)
res1: Either[String,Int] = Left(err)

scala> ApplicativeError[Either[String, *], String].adaptError(1.asRight[String])(pf)
res2: Either[String,Int] = Right(1)

The same function is available in ApplicativeErrorOps as adaptErr - it cannot have the same name because this would result in ambiguous implicits due to adaptError having originally been included in the MonadError API and syntax.

Given a value and a function in the Apply context, applies the function to the value.

Example:

scala> import cats.implicits._

scala> val someF: Option[Int => Long] = Some(_.toLong + 1L)
scala> val noneF: Option[Int => Long] = None
scala> val someInt: Option[Int] = Some(3)
scala> val noneInt: Option[Int] = None

scala> Apply[Option].ap(someF)(someInt)
res0: Option[Long] = Some(4)

scala> Apply[Option].ap(noneF)(someInt)
res1: Option[Long] = None

scala> Apply[Option].ap(someF)(noneInt)
res2: Option[Long] = None

scala> Apply[Option].ap(noneF)(noneInt)
res3: Option[Long] = None