Swift-like "guard-let" in Scala - scala

Question

In Swift, one can do something like:
guard let x = z else {return} // z is "String?"
In this simple case, if z (an optional) is empty, the function will exit.
I really like this structure and recently started developing in Scala, and I was wondering if there's an equivalent in Scala.
What I found is this:
val x = if (z.isEmpty) return else z.get // z is "Option[String]"
It works - but I still wonder if there's a more "Scala-ish" way of doing it.
EDIT: the use case is that a configuration argument is allowed to be null in the app, but this specific function has nothing to do in that case. I'm looking for the correct way to avoid calling code that will not work.

Answer 1

Scala is functional so using return to break out early is almost always a bad idea (partly because return doesn't work the way it might appear).
In this case there are a couple of choices.
Using map allows the value inside an Option to be processed if it is there:
val xOpt = z.map { x =>
// process x
}
xOpt is a new Option that contains the results of the processing, or None if z was already None.
The alternative is to use a default value if z is None and then use that.
val x = z.getOrElse(defaultX)
// process x
In this case x is a bare value not an Option.

Answer 2

Admittedly I'm not familiar with Swift, but since you're not returning a value, this is presumably in a function being called for side-effect.
In Scala, the natural equivalent for "perform this side-effect if and only if this Option is non-empty is foreach:
z.foreach { x =>
// code that uses x
}
There is syntactic sugar around this, the above is equivalent to
for (
x <- z
) { // the absence of yield is significant here
// code that uses x
}
If z is empty, the foreach does nothing, so the "code that uses x would be everything in the function after the guard-let.
It might be that there's an implicit null being returned in the early exit case (it's hard to think of another value that would make sense) if this is a function being called for value. In that case, the natural equivalent would be map:
z.map { x =>
// code that computes a value from x
} // passes through None if z is empty
The for sugar would be
for (
x <- z
) yield {
// code that uses x
}
As above, "code that uses x" means everything after the guard-let.
If you happened to have two nullable arguments like
guard let x = z else { return }
guard let w = y else { return }
You could nest these or have multiple <-'s in your for expression:
for {
x <- z
w <- y
} yield {
// code that uses x and w
}
Alternatively (and my personal preference), you can use zip:
z.zip(y).foreach {
case (x, w) =>
// code that uses x and w
}
// or in the called-for-value case
z.zip(y).map {
case (x, w) =>
// code that uses x and w
}.headOption // zip creates an Iterable, so bring it back to Option

Answer 3

For comprehensions are similar:
def f(z: Option[String]) = for {
x <- z // x is String
result = x + " okay"
} yield result
This is useful when you have several short-circuiting operations, but the downside (compared to Swift) is you can't use other control structures such as if without some difficulty.
However, for in Scala can be used for more than just Option, e.g. to process lists:
def products(xs: Vector[Int], ys: Vector[Int]) = for {
x <- xs
y <- ys
} yield x * y // Result is a Vector of each x multiplied by each y

Answer 4

It is important to understand that Option is a monad. Being a monad means that it supports map and flatMap and also many other collection operations like foreach. Being a monad, and specifically supporting map, flatMap, and foreach also means that Option can be used as a generator in a for-comprehension.
The best way of thinking about Option is as a collection that can hold either 0 or 1 values. (In fact, Option does inherit from IterableOnce, and it implements several of the methods of Iterable, so you can not just think of Option as a collection, it simply is a collection.) A lot of the knowledge you have about collections transfers directly to Option, and Option supports the most important of the standard Scala collections operations, including the afore-mentioned monad operations.
So, what happens if you iterate over an empty collection? Well, nothing! What happens if you map over an empty collection? Well, you get back an empty collection!
So, the correct way of working of Options is actually not to try and get the value out of it, but instead to treat the Option as a collection.
So, instead of trying to get x out of the Option and then manipulating x, you can manipulate the value inside of the Option.
E.g. if you want to print it:
z.foreach(println)
// or
for (x <- z) println(x)
Iterating over an empty collection doesn't do anything, so this will either do nothing (if the Option is empty) or will print the value.
If you want to downcase it:
val x = z.map(_.toLowerCase())
// or
val x = for (x <- z) yield x.toLowerCase()
Note that in my case, x is an Option[String] (i.e. either a Some[String] or None) whereas in your case, x is a String, i.e. in my case, we are staying in the land of Options and don't leave.
Only at the very boundary of your system should you try and extract the value out of the Option, and the best way to do that is the method getOrElse, which does exactly what it sounds like: it gets the value out of the option if there is one, otherwise it returns the default value that you supplied.