Try redesign using Into instead of explicit conversions.

[bishabosha]

With into, there is no need for the 'Compat' conversion because when subtyping is enough then no conversion is needed.

[natsukagami]

Seems that implementing it this way would break scoping:

  test("scoping") {
    Result[Int, String]: l1 ?=>
      Result[String, Int]: l2 ?=>
        val r: Result[Int, Nothing] = Result.Ok(1)
        r.ok
  }

Here the compiler will immediately pick l2 for the Label and tries to apply a conversion (and fail) without retrying with l1.

[natsukagami]

I think we can just remove this, no need for deprecation

[bishabosha]

Seems that implementing it this way would break scoping:

  test("scoping") {
    Result[Int, String]: l1 ?=>
      Result[String, Int]: l2 ?=>
        val r: Result[Int, Nothing] = Result.Ok(1)
        r.ok
  }

Here the compiler will immediately pick l2 for the Label and tries to apply a conversion (and fail) without retrying with l1.

perhaps you could pick a better example because in any case i would expect r.ok is going to return an Int so wouldnt be correctly typed anyway - Edit: and this doesnt work with the old design either.

If i try the following would you expect err to jump to the outer label?

given Conversion[Int, Bar] = Bar(_)
class Bar(x: Int)
class Foo
Result[Int, Bar]: l1 ?=>
  Result[String, Foo]: l2 ?=>
    val r: Result[String, Int] = Result.Err(1)
    r.ok
  .ok.length

Edit 2: as a follow up - it doesnt seem possible to infer l1 but I could make it work for r.ok(using l1) - but is that really something worth supporting? (Edit 3: perhaps for tight code where you really want the inlining of jumps)

[natsukagami]

If i try the following would you expect err to jump to the outer label?

No I don't think so. On second thought I think it's actually good that it doesn't try to jump to the outer label, it could be quite confusing that way.

Edit 2: as a follow up - it doesnt seem possible to infer l1 but I could make it work for r.ok(using l1) - but is that really something worth supporting? (Edit 3: perhaps for tight code where you really want the inlining of jumps)

I think we should be able to do this yeah.

[bishabosha]

newer design to let you explicitly pass in the label to .ok, while also erasing any conversion with .ok for when error channel is a subtype

[natsukagami]

I like this design a lot :D

[natsukagami]

Is having ConvErr a convenient way to have identity conversion without it polluting the user's Conversion search space? It seems pretty neat 🤔

[bishabosha]

Yeah I think the goal was mainly to avoid needing the Compat import and also delay the conversion until the error case

[natsukagami]

Suggested change

	opaque type ConvErr[E, E1] = Conversion[Err[E], Err[E1]]
	/** Conversion from error type `E` to error type `E1`.
	* An instance is provided for every `E1 <: E`, as well as for every existing implicit [[scala.Conversion Conversion]] instance from `E` to `E1`. */
	opaque type ConvErr[E, E1] = Conversion[Err[E], Err[E1]]

[bishabosha]

Ultimately i backtracked on this design (its still there commented) in favor of eval.ok(using l1)(r) if that control is needed.

[bishabosha]

for now i went back to ok with into, but its true that with the happy path but with error conversion required it would do an extra isInstanceOf check (i.e. convert ok -> ok) - of course if the error channel lines up with the label's type then no conversion is applied

its hard to decide what to design to keep just because it does add this extra type, but the more complex design is lower runtime cost in all cases

the old design is still there as a comment