为什么Scala的Option [T]不直接转换为字节码中的T？

Question

关于Scala我不了解的一件事是,尽管Null没有通过替换测试,但为什么Null将所有内容都包含在内.据推测,这是为了兼容Java,我想这很好 - 但随后Scala推动了Option [T]模式.

这个我不明白.Option [T]不会给你任何额外的保证(因为每个T都是事实上的选择).但它也总共有4个州:

val a: Option[String] = null
val b: Option[String] = Some(null)
val c: Option[String] = None
val d: Option[String] = Some("A string")

这似乎既低效(来自字节码pov),甚至可能比痛苦Java更糟糕.我的问题是,为什么Scala没有使Option [T]成为直接转换为java字节码的T的特殊情况.所有与Java代码(使用引用)的接口都必须通过这个选项[T](这真的,正是它是什么).当Scala方法使用不能为None的T时,会有一个注释或其他内容.

这似乎是最明显的正确,最安全和最有效的.

谢谢

Answer 1

Option的主要原因是支持Any类型,可以是AnyVal或AnyRef.Scala要求AnyVal不能为null.这意味着类型参数T不能简单地设置为null.这使得在scala集合库等库中使用泛型变得尴尬,而没有像Option这样的东西.

val n: Option[Int] = Some(null) // will not compile

我相信你是正确的,有很多可能的优化消除Option,可以消除字节代码级别的类的实际使用.有一个选项可以为Scala编译器启用积极的优化,这可能会做到这一点,但它仍在大量工作.

Answer 2

可能的原因有以下三个：

1. Scala 是一个薄包装，只会添加新内容，而且他们不想破坏它。
2. 他们不想让 Java 库使用起来很麻烦，因为所有参数都将是 Option[T] 而不是 T。
3. 他们不想使用名称修改或注释来区分用 Scala 编写的库和用 Java 编写的库（将方法标记为采用“不可为空引用”）。