Geek Answers Handbook

When should I use Option.empty [A], and when should I use None in Scala?

In Scala, when I want to install something in None , I have several options: using None or Option.empty[A] .

Should I just select one and use it sequentially, or are there moments when I have to use one over the other?

Example:

 scala> def f(str: Option[String]) = str f: (str: Option[String])Option[String] scala> f(None) res0: Option[String] = None scala> f(Option.empty) res1: Option[String] = None
+8
source share
5 answers

If possible, I would stick with None , which is almost always the case. It is shorter and widely used. Option.empty allows you to specify the type of the base value, so use it when you need help with type inference. If the type is already known to the compiler, None will work as expected, however when defining a new variable

 var a = None

will cause infering in a None.type which is unlikely that you wanted.

You can then use one of two ways to help conclude what you need

 @ var a = Option.empty[String] a: Option[String] = None @ var a: Option[String] = None a: Option[String] = None @ var a = None: Option[String] // this one is rather uncommon a: Option[String] = None

Another place when the compiler needs help:

 List(1, 2, 3).foldLeft(Option.empty[String])((a, e) => a.map(s => s + e.toString))

(The code does not make sense, but only as an example) If you omit the type or replace it with None the battery type will be displayed in Option[Nothing] and None.type respectively.

And for me personally, this is where I would go with Option.empty , for other cases I use Option.empty use None .

+9
source

The short answer uses None when it Option.empty[T] to value, for example, when passing a parameter to a function, use Option.empty[T] when defining something.

var something = Option.empty[String] means something is None now, but may become Some("hede") in the future. var something = None , on the other hand, means nothing. you cannot reassign it using Some("hede") compiler will get angry: found : Some[String] required: None.type Thus, this means that None and Option.empty[T] are not alternatives. You can pass None to any [T] option, but you cannot pass Some [T] to None.type

+3
source

The following are export worksheets using Scala and Scalaz.

 def f(str: Option[String]) = str //> f: (str: Option[String])Option[String] f(None) //> res1: Option[String] = None var x:Option[String]=None //> x : Option[String] = None x=Some("test") x //> res2: Option[String] = Some(test) x=None x

Now using Scalaz,

 def fz(str: Option[String]) = str //> fz: (str: Option[String])Option[String] fz(none) //> res4: Option[String] = None var xz:Option[String]=none //> xz : Option[String] = None xz=some("test") xz //> res5: Option[String] = Some(test) xz=none xz

Please note that all statements are evaluated equally, regardless of whether you use None or Option.Empty . How?

As you can see, it is important to tell Scala your intentions with the return type in the var x:Option[String]=None statement var x:Option[String]=None . This allows you to later assign Some . However, a simple var x=None will not work in later lines, because this will cause the x variable to solve None.type , and not Option[T] .

I would think that you need to follow the convention. For assignments, I would choose the var x:Option[String]=None option var x:Option[String]=None . Also, when using None, it is useful to use a return type (in this case Option [String]) so that assignment is not permitted by None.type .
Only in cases where I have no way to provide a type, and I need some kind of task, I will go for Option.Empty

+1
source

Given that Option[A].empty just returns None :

 /** An Option factory which returns `None` in a manner consistent with * the collections hierarchy. */ def empty[A] : Option[A] = None

I would say:

  • As you said, be consistent throughout the code base. Aligning this will mean that programmers entering your code base have less to worry about. "Should I use None or Option.empty ? Well, I see that @cdmckay uses X in the entire call base, I will also use this."

  • Readability - think that conveys the very moment that you want most. If you read a specific method, would it be better for you to return an empty Option (let it ignore for a moment the fact that the base implementation simply returns None ) or explicit None ? IMO, I think of None as a non-existent value, as the documentation indicates:

     /** This case object represents non-existent values. * * @author Martin Odersky * @version 1.0, 16/07/2003 */
+1
source

As everyone else has pointed out, this is more of a matter of personal taste, in which most people prefer None , or, in some cases, you obviously need to put this type because the compiler cannot make a conclusion.

This question can be extrapolated to other Scala classes such as Sequences , Map , Set , List and so on. In all of them, you have several ways to determine the empty state. Using sequence:

  • Seq()
  • Seq.empty
  • Seq.empty[Type]

Of 3, I prefer the second, because:

  • The first ( Seq() ) is error prone. It looks like if someone wanted to create a sequence and forgot to add elements
  • The second ( Seq.empty ) is clearly about wanting to have an empty sequence
  • While the third ( Seq.empty[Type] ) is as explicit as the second, it is more verbose, so I usually don't use
0
source

More articles:


All Articles