Naming things - unwrapping Eithers in boundary-break: .value or .?

[adamw]

Recent ox releases include a boundary-break implementation specialised to Eithers, which allows you to write "unwrap" an Either within a specified boundary, for example:

def lookupUser(id1: Int): Either[String, User] = ???
def lookupOrganization(id2: Int): Either[String, Organization] = ???

val result: Either[String, Assignment] = either:
  val user = lookupUser(1).value
  val org = lookupOrganization(2).value
  Assignment(user, org)

Here, .value is used for the "unwrapping". However, one alternative would be to use the Rust-inspired .?. On the one hand, @lbialy argues that .value is clash-prone, along with @Ichoran who says .value suggests that it's a safe accessor.

On the other, symbolic operators historically didn't work out that well, plus, as @alexandru points out, it looks awkward and doesn't play well with fewer-braces.

What's your take? Vote with a 👍 on a comment with your pick, or propose your own!

[adamw]

.value

[adamw]

.?

[JD557]

Disclaimer: Bikeshed ahead! (My opinions about this are not that strong)

I'm not a fan of neither .? not .value, as they both seem to imply that the left is "wrong", an this is not necessarily the case.

While Either is right biased, which makes it convenient to have an error channel on the left and a happy path on the right, Either is just a tagged union. It doesn't carry the semantic weight of something like Try, Result or Validated.

I don't have any good suggestions, though... Maybe something like .rightValue/.leftValue?

[adamw]

@JD557 in general, yes, either is just a tagged union of equivalent types; but in terms of boundary-break, and the way it's used for error handling in ox we're taking the right-biased interpretation.

[kciesielski]

I'd also add .unwrap for your consideration.

[lbialy]

Uh, the worst part of Rust api :( I'm still a big fan of the question mark operator. It's visually different, suggests something non-typical is happening and symbolic operators are not a very big problem if they are not overused and really signify some rather well defined and very common operations (remember exclamation mark in akka signifying async send?). Not a lot of people complain about sharks in CE and ZIO after they got accustomed to them.

…

On Fri 12. Apr 2024 at 10:31, Krzysztof Ciesielski ***@***.***> wrote: I'd also add .unwrap for your consideration. — Reply to this email directly, view it on GitHub <#118 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBVNUSOMHZZG4S5JYQSOBLY46LWXAVCNFSM6AAAAABGDSN4VCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJRGI4DINBWGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[adamw]

Uh, the worst part of Rust api :(

@lbialy So it's the worst part, or is ? ok? ;)

[lbialy]

.unwrap()

…

On Fri 12. Apr 2024 at 11:52, Adam Warski ***@***.***> wrote: Uh, the worst part of Rust api :( @lbialy <https://github.com/lbialy> So it's the worst part, or is ? ok? ;) — Reply to this email directly, view it on GitHub <#118 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBVNUUGGYIVBH32MBNF7XTY46VFTAVCNFSM6AAAAABGDSN4VCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJRGQZTMNJVG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Ichoran]

Personally, I've been using .? for a long time in my own code--I do use Rust as well, so that was my inspiration to create the feature (at first as a Scala 2 macro that mostly worked)--and I've found it very pleasant.

I haven't often run into cases where Alexandru's critique would apply because .? works best (both in performance and ability to reason about behavior) when local and in a flat style, not deeply nested monadic stuff. I have lots of code that looks like

  def loadTemplate(): Source Or Err = Or.Ret:
    "template.qmd".path.slurp.?.tap(lines => parse(lines).?)

(The Or stuff is a success-unboxed Either clone; Or.Ret: is my version of either: here.)

The point of using .? or whatever you call it is to get your error cases out of your hair fast and where they occur. And .? is quite visually distinctive. The only way I've made it even more obvious is calling it .GET or somesuch and I don't like the shouting.

If you don't have a favored branch and a disfavored branch but rather two co-equal branches, you should not have a single accessor but something like

extension [L, R](either: Either[L, R]) {
  /** Exit to boundary matching the left branch, or keep going with the right branch's value. */
  inline def rightOrBreak(using Label[L]): R = either match
    case Right(r) => r
    case Left(l) => boundary.break(l)

  /** Exit to boundary matching the right branch, or keep going with the left branch's value. */
  inline def leftOrBreak(using Label[R]): L = either match
    case Left(l) => l
    case Right(r) => boundary.break(r)
}

However, even though I wrote them, I never use these, or variants that have Either[L, R] as the label, in practice. It's confusing. Dropping out early with a disfavored or default value is cool. Jumping helter-skelter whenever computation is finished from multiple points is not cool.

I'm not voting here because I've already made my own choice with my own library, but I wanted to share some experiences.

[lbialy]

This is also something Martin seems to be keen to introduce to the language, given his keynote from 2023. I don't really understand @alexandru's comment about .? not fitting fewer braces syntax (which I personally don't like because I like the distinction between "just a separate scope" like class x: or object y: or def fun: Unit = and "lambda-passed-as-argument body" like map { x =>) because that's exactly the context in which Martin first proposed question mark operator publicly 🤔

[adamw]

A weekend though - since we are considering symbolic operators, maybe we're incorrectly fixated on ? which comes from Rust. In Java, this is used for the elvis operator; in Kotlin, for optionally dereferencing nulls. We can imagine a similar operator being used for explicit-nulls in Scala.

So ... maybe e.g. .! would actually be better? This might indicate quite strongly that it's a short-circuiting operation, disrupting the normal control flow.

[alexandru]

This is also something Martin seems to be keen to introduce to the language, given his keynote from 2023. I don't really understand @alexandru's comment about .? not fitting fewer braces syntax (which I personally don't like because I like the distinction between "just a separate scope" like class x: or object y: or def fun: Unit = and "lambda-passed-as-argument body" like map { x =>) because that's exactly the context in which Martin first proposed question mark operator publicly 🤔

The fewer braces syntax is here to stay, and, unless it gets deprecated somehow, will probably become the dominant style in Scala 3, once backwards compatibility with Scala 2.x is no longer a concern. This syntax isn't experimental, and there's no in-between. Another outcome would be for Scala to have multiple syntaxes, forever, but that's not very Pythonic, and it's not a very likely outcome, due to conformity nowadays being forced by Scalafmt. Although, a Klingon language option would be fun.

This is valid syntax, showing method chaining in action, and it's less than ideal for the obvious reason that .? is barely visible, looking like someone's cat briefly stepped over the keyboard:

validate(user).flatMap: user =>
    fetchRepository(user)
.?

// ...also this...
validate(user)
    .flatMap: user =>
        fetchRepository(user)
    .?

I've always disliked special operators. I think all special operators in Scala-land suck, making the language actually harder to read. I'm not fond of operators such as <+>, >>, or *> from Cats, or <*> from Scalaz, either. The reasons would be:

• you don't have a clear name for it that you can communicate verbally, unless you learn it, and then it's something silly like the “tie-fighter operator”;
• it looks like noise;
• I hate infix or postfix method notations, too;
• no matters what the authors think about it, the operation is rarely that special as to warrant the use of a special operator.

The argument that Martin may want to make .? official is a good one if it comes to pass. But then Martin says in Lean Scala that we should drop DSLs and use the language instead. So better make sure that .? will actually become official, and also provide an alternative for those of us that will hate it anyway (which is what Cats does).

Something to think about 🙂

[ahoy-jon]

.get ? Like for options, we know already it means something special!

[lbialy]

Would be nice to be able to define `.ok?` or even `.left?`/`.right?` but parser doesn't seem to like this kind of stuff.

…

On Mon 15. Apr 2024 at 13:27, Jonathan Winandy ***@***.***> wrote: .get ? Like for options, we know already it means something special! — Reply to this email directly, view it on GitHub <#118 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBVNUS3GQ3C6FSJISD3YT3Y5O2SJAVCNFSM6AAAAABGDSN4VCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJWGU4TQOJWHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Ichoran]

I don't recommend .get because it doesn't really scream "short-circuit". The key for this to work is for it to be obvious. Nonlocal control flow requires attention.

.! is fine too, I suppose, but ! in Scala has been used for messaging actors, which is less like local control flow than is elvis or the nullable-type-as-option operation. I actually used it myself for an orthogonal control flow operation where you can have different attempts; .! is used to try to get something for which a failure means you should move to the next strategy:

val m = Map("a" -> 1, "b" -> 2)
val number = attempt:
  safe{ "w".toInt }.!
.attempt:
  m.get("c").!
.default:
  0

It's...okay. I find .? stands out better.

.ok should be fine. Not sure why the parser wouldn't like it? But I'm not sure it stands out enough.