When using bind inside either blocks, to simulate a failure, I sometimes do MyError.left().bind(). T...

# arrow

[Satyam Agarwal]

When using bind inside either blocks, to simulate a failure, I sometimes do MyError.left().bind(). This leads to compiler warning me like : Returning type parameter has been inferred to Nothing implicitly. Please specify type arguments explicitly to hide this warning. Nothing can produce an exception at runtime.

What are the implications of this, apart from readability that MyError.left().bind() is not clear in what the RHS can be.
iirc, its not trivial to remove these errors, they can only be suppressed. Is there any work being done in fixing this ?

Also, MyError.left().bind() is this recommended approach ? I often use filterOrOther to avoid warnings.

[mitch]

@Satyam Agarwal 👋 you can do

MyError.left().bind<Unit>()

[Satyam Agarwal]

Yes, but I want to avoid that too 🙂

Not having to write .bind() is whole another conversation

[simon.vergauwen]

Is there any work being done in fixing this ?

I'm not sure what needs fixing here 😅 The warning is coming from Kotlin Std, if you want to work around it the most straightforward thing would be to create a function that infers something else than Nothing.

fun <A> myError(): Either<MyError, A> = MyError.left()

That way Unit can be inferred here, and the Nothing warning will dissapear.

[mitch]

we had this alias defined in our codebase which we use every now and then. essentially this is like MonadError[F[_], E].raiseError(err: E): F[A] with A being always Unit. Not sure if that is less or more inconvenient.

suspend fun <L> RestrictedEitherEffect<L, *>.reject(leftValue: L): Unit = leftValue.left().bind<Unit>()
suspend fun <L> EitherEffect<L, *>.reject(leftValue: L): Unit = leftValue.left().bind<Unit>()

sealed class MyError {
  data class SomeErrorType(val value: String) : MyError()
}

fun main() {

  val x = either.eager<MyError, Int> {
    reject(MyError.SomeErrorType("123"))

    5
  }

  println(x)
  // Either.Left(SomeErrorType(value=123))
}

[mitch]

probably not going to be very future-resistant as that taps very deep into the arrow effect implementation homer disappear

[simon.vergauwen]

This is the same to shift which we'll have in the next Arrow release.

https://github.com/arrow-kt/arrow/blob/main/arrow-libs/core/arrow-core/src/commonMain/kotlin/arrow/core/continuations/EffectScope.kt#L31

You'll also not have to wrap your error into Left anymore first.

[simon.vergauwen]

So @mitch you can deprecate that function in favor of shift soon.

[mitch]

that’s awesome!

[mitch]

@simon.vergauwen these are really cool! when is the next release of arrow planned approximately? What happened to the previous delimited continuation implementation?

that shift in option, would it make sense to have just shift() as an alias as well? seems we’ll write shift(None) everywhere. right now we had reject() for option { } .
https://github.com/arrow-kt/arrow/blob/main/arrow-libs/core/arrow-core/src/commonMain/kotlin/arrow/core/continuations/option.kt#L19

[Satyam Agarwal]

Thanks for the thoughts. shift sounds cool.

[simon.vergauwen]

@mitch the new implementation supports the same API, so it'll be a simple deprecate/replace. We're currently working on the release blog post and it'll be released in the coming week(s).

[simon.vergauwen]

Oh, a shift() alias in Option sounds good.

[phldavies]

would ensure(false) { MyError } not do the same thing for now?

[simon.vergauwen]

Yes, it would.