fix(deps): update dependency com.michael-bull.kotlin-result:kotlin-result to v2.3.1

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
com.michael-bull.kotlin-result:kotlin-result	2.0.3 → 2.3.1

---

Release Notes

michaelbull/kotlin-result (com.michael-bull.kotlin-result:kotlin-result)

v2.3.1

Compare Source

• Add fallible running accumulation functions (b319b10)
  • Iterable.tryRunningFold
  • Iterable.tryRunningFoldIndexed
  • Iterable.tryRunningReduce
  • Iterable.tryRunningReduceIndexed
  • Iterable.tryScan (alias of tryRunningFold)
  • Iterable.tryScanIndexed (alias of tryRunningFoldIndexed)
• Add destination collection variants for partition functions (4cfeec2)
  • Iterable.partitionTo
  • Iterable.combineErrTo
• Widen tryReduce generic constraints generic constraints from <T, E> to <S, T : S, E> (1b84ca7)
  • Iterable.tryReduce
  • Iterable.tryReduceIndexed
  • Flow.tryReduce

v2.3.0

Compare Source

• Enable Kotlin unused return value checker by @​rileymichael (753785c)
  • Closes #​134 and #​135
• Add @BindingDsl marker to prevent implicit outer-scope bind() (520d364)
• Shadow async on CoroutineBindingScope to auto-bind Result (103ac88)

Warnings for unused Result return values

The library now compiles with -Xreturn-value-checker=full, implicitly treating all public functions as @MustUseReturnValue. Consumers who enable -Xreturn-value-checker=check in their own builds will receive warnings when they silently discard a Result returned by this library.

Side-effect functions whose return value exists only for optional chaining (onOk, onErr, onEachOk, onEachErr, and their indexed/Flow variants) are marked @IgnorableReturnValue.

Preventing implicit outer-scope bind() in nested bindings

When nesting binding/coroutineBinding blocks with different error types, bind() can silently resolve to an outer scope. This compiles without warning but produces wrong control flow — the BindingException bypasses the inner scope's try/catch and short-circuits the outer scope instead:

val outer: Result<Int, String> = binding {
    val inner: Result<Int, Int> = binding {
        "hello".toErr().bind() // silently resolves to outer scope's bind()
    }

    inner.getOrElse { 0 } // never reached
}

This release annotates both BindingScope and CoroutineBindingScope with a shared @DslMarker annotation, making implicit cross-scope bind() calls a compiler error. All four nesting combinations (binding/coroutineBinding in either direction) are caught. If you intentionally need to bind across scopes, explicit qualification (e.g. this@binding) is required.

Auto-binding async in coroutineBinding

Previously, the correct way to run concurrent operations in coroutineBinding required placing bind() inside the async lambda:

suspend fun provideX(): Result<Int, ExampleErr> { ... }
suspend fun provideY(): Result<Int, ExampleErr> { ... }

val result: Result<Int, ExampleErr> = coroutineBinding {
    val x: Deferred<Int> = async { provideX().bind() }
    val y: Deferred<Int> = async { provideY().bind() }
    x.await() + y.await()
}

This was non-obvious. A natural reading of the API led users to place bind() outside, chaining .await().bind() at the call site:

suspend fun provideX(): Result<Int, ExampleErr> { ... }
suspend fun provideY(): Result<Int, ExampleErr> { ... }

val result: Result<Int, ExampleErr> = coroutineBinding {
    val x: Int = async { provideX() }.await().bind() // suspends here until provideX() completes
    val y: Int = async { provideY() }.await().bind() // provideY() doesn't start until provideX() is done
    x + y
}

This compiles without warning, but chaining .await() immediately after async defeats concurrency — each call suspends until completion before the next starts.

This release adds an async member function on CoroutineBindingScope that automatically binds Result-returning lambdas. The member returns Deferred<V> instead of Deferred<Result<V, E>>, so bind() placement is handled for you and the sequential .await().bind() pattern above becomes a compiler error (there is no Result left to bind()). The correct usage is now the natural one:

suspend fun provideX(): Result<Int, ExampleErr> { ... }
suspend fun provideY(): Result<Int, ExampleErr> { ... }

val result: Result<Int, ExampleErr> = coroutineBinding {
    val x: Deferred<Int> = async { provideX() }
    val y: Deferred<Int> = async { provideY() }
    x.await() + y.await()
}

Both coroutines launch immediately and run concurrently. bind() is called inside each async coroutine, cancelling the scope on the first error without waiting for the caller to await. When the block does not return a Result, the standard CoroutineScope.async extension is used instead.

v2.2.0

Compare Source

Fallible Operations (try*)

Fallible collection operations now use a try prefix, inspired by Gleam's naming convention and mirroring stdlib's collection API more closely. Several new operations have also been added.

• Rename mapResult* functions to tryMap*, mapAll to tryMap, fold/foldRight to tryFold/tryFoldRight (d052cf5)
  • The previous names are deprecated with @Deprecated + ReplaceWith for easy migration
• Add tryFind, tryFindLast, tryForEach, tryForEachIndexed, tryReduce, tryReduceIndexed for Iterable (d2011f0)
• Add tryFilter, tryAssociate, tryFlatMap, tryGroupBy, tryPartition + variants for Iterable (f32985e)

Flow Extensions

The kotlin-result-coroutines module now includes extensions for the kotlinx-coroutines Flow type, bringing the same Result-aware operations available on Iterable to asynchronous streams. This was born out of the discussion in #​78.

• Add Flow extensions for kotlin-coroutines (15d44a0)
  • Factory: Result<Flow<V>, E>.toFlow()
  • Flow: filterOk, filterErr, onEachOk, onEachErr, allOk, allErr, anyOk, anyErr, countOk, countErr, partition, combine, combineErr
  • Try: tryFilter, tryFilterNot, tryMap, tryMapNotNull, tryFlatMap, tryForEach, tryReduce, tryFold, tryFind, tryFindLast, tryAssociate, tryAssociateBy, tryAssociateWith, tryGroupBy, tryPartition

Other

• Rename onSuccess/onFailure to onOk/onErr (a7c66c0)
  • The new indexed variants (onEachOkIndexed, onEachErrIndexed) proved that the Success/Failure naming becomes too verbose. Ok/Err is more readable.
• Rename filterValues/filterErrors to filterOk/filterErr (87f4c36)
  • Aligns naming with existing allOk/allErr/anyOk/anyErr/countOk/countErr conventions
• Add onEachOk, onEachOkIndexed, onEachErr, onEachErrIndexed for Iterable<Result> (a7c66c0)
• Add combineErr and combineTo/combineErrTo for Iterable<Result> (1133e00, c06eeb3)
• Propagate nested coroutineBinding failures by @​dbottillo (d952b52)
  • Closes #​128 and #​133
• Make BindingException public (549ed30)
  • Fixes 'internal' type accessed from public inline declaration warning that will become an error in Kotlin 2.4
• Update Kotlin to 2.3.10 (12ceff7)
• Update Gradle to 9.4.0 (468b1a5)

v2.1.0

Compare Source

• Annotate Result#{value,error} direct access as unsafe by @​hoc081098 (db45c67)
  • For full context and discussion on this topic, please read through the PR by @​hoc081098 at #​123, and the initial discussion presented by @​kirillzh in #​104.

---

Library consumers that directly access either Result.value or Result.error, e.g. in the situation they are extending the library to implement their own functionality, must now opt-in to unsafe access of these properties.

Failure to do so will result in a compilation error:

---

There are three ways to opt-in:

1. On a function-level

    @OptIn(UnsafeResultValueAccess::class)
    fun myFunctionThatAccessesValueDirectly() { ... }

2. On a file-level:

   @file:OptIn(UnsafeResultValueAccess::class)
   
   fun myFunctionThatAccessesValueDirectly() { ... }
   fun anotherFunctionThatAccessesValueDirectly() { ... }

3. On a project-level in build.gradle.kts

   kotlin {
       compilerOptions {
           optIn.add("com.github.michaelbull.result.annotation.UnsafeResultValueAccess")
           optIn.add("com.github.michaelbull.result.annotation.UnsafeResultErrorAccess")
       }
   }

---

Configuration

📅 Schedule: (in timezone Asia/Tokyo)

• Branch creation
  • "before 3am"
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.