4 ms·

scala> val x = Some(null) x: Some[Null] = Some(null)

virtualwhys 12y ago
That's pretty contrived, when would you _ever_ wrap a thing that could be null in a Some? Even so, to continue with your example: scala> x foreach println null x.get res2: Null = null Hey, what do you know, no NPE. Try harder ;-)
- adamwbarr 12y ago
  Ok fair point re it being contrived! Although (having just re-read it), the original post's complaint was actually that: > the compiler (afaik) doesn't prevent you from setting an Optional field to null ie scala> val option: Option[Any] = null option: Option[Any] = null
  - the_af 12y ago
    Exactly, that was my complaint. It makes elegant pattern matching against Option types (the whole point of using them, in fact) less than useful. Now, in Scala-land, you have to check that they aren't null, which sucks.
    - frowaway001 12y ago
      This complaint shows pretty well that some people have never actually used Scala.
      - the_af 12y ago
        Can you elaborate? The whole point of Option types is that I can map (for example) over them without explicitly checking what their value is, and it will work without a runtime error. Same with pattern matching. With the introduction of null, this is no longer possible. I've just shown an example of getting an NPE while mapping over an Option[String]. Now we're back in Java-land, where I must explicitly check for nulls, read the source code of every method or trust some comment that tells me that it will never return null. (Ok, not exactly like Java-land: a Scala programmer who returns a null for a function with type Option is very inexperienced or is doing something naughty. But why does the language even allow it?) Aside from telling me I'm wrong, can you explain why?
        roryokane 12y ago
        Scala needed to support null somehow in order to interoperate with arbitrary Java code, such as passing null as a parameter to a third-party Java library. So at least some variables should be allowed to have null. Maybe they couldn’t think of a way to prevent Option-typed variables from being null without preventing arbitrary Java interop. Making only Option types reject nulls might have been thought too hacky. Those are just my guesses of the design rationale, working from the fact that Scala does support nulls. But perhaps Scala could have come up with a better solution that still allows null use when necessary. If you think of some syntax and elegant semantics for allowing you to forget about null for most code, I’d be interested to see your proposal.
        adamwbarr 12y ago
        I agree that the design is a result of trading off the desire to do away with nulls vs retaining Java interoperability. Preventing (at compile time) only Options from being null is surely impossible when casting/reflection are available. It is commonly understood that if an API returns Option[A] then the client can assume it will not return null. Personally I have never experienced a real error from this.
        the_af 12y ago
        Oh, I understand why null was needed (backwards compatibility, like you said), and I'm no language designer, so I don't know what I would have done instead. Maybe mark pieces of code that must interact with Java code with "unsafe" blocks, outside of which no nulls can escape? unsafe { ... } Don't know if this would work. I'm just disappointed because this slightly breaks the Option type, that's all.
        frowaway001 12y ago
        > I'm just disappointed because this slightly breaks the Option type, that's all. I have never ever seen this happening. The complaint feels a lot like "well, someone could use reflection and change the cached values of Integer, why don't you check that every time something returns an Integer?" to me. null is the sad fact of running on the JVM, but pretending that it doesn't exist works 99.9999% of the time in Scala.

That's pretty contrived, when would you _ever_ wrap a thing that could be null in a Some? Even so, to continue with your example: scala> x foreach println null x.get res2: Null = null Hey, what do you know, no NPE. Try harder ;-)

adamwbarr 12y ago
Ok fair point re it being contrived! Although (having just re-read it), the original post's complaint was actually that: > the compiler (afaik) doesn't prevent you from setting an Optional field to null ie scala> val option: Option[Any] = null option: Option[Any] = null
- the_af 12y ago
  Exactly, that was my complaint. It makes elegant pattern matching against Option types (the whole point of using them, in fact) less than useful. Now, in Scala-land, you have to check that they aren't null, which sucks.
  - frowaway001 12y ago
    This complaint shows pretty well that some people have never actually used Scala.
    - the_af 12y ago
      Can you elaborate? The whole point of Option types is that I can map (for example) over them without explicitly checking what their value is, and it will work without a runtime error. Same with pattern matching. With the introduction of null, this is no longer possible. I've just shown an example of getting an NPE while mapping over an Option[String]. Now we're back in Java-land, where I must explicitly check for nulls, read the source code of every method or trust some comment that tells me that it will never return null. (Ok, not exactly like Java-land: a Scala programmer who returns a null for a function with type Option is very inexperienced or is doing something naughty. But why does the language even allow it?) Aside from telling me I'm wrong, can you explain why?
      - roryokane 12y ago
        Scala needed to support null somehow in order to interoperate with arbitrary Java code, such as passing null as a parameter to a third-party Java library. So at least some variables should be allowed to have null. Maybe they couldn’t think of a way to prevent Option-typed variables from being null without preventing arbitrary Java interop. Making only Option types reject nulls might have been thought too hacky. Those are just my guesses of the design rationale, working from the fact that Scala does support nulls. But perhaps Scala could have come up with a better solution that still allows null use when necessary. If you think of some syntax and elegant semantics for allowing you to forget about null for most code, I’d be interested to see your proposal.
        adamwbarr 12y ago
        I agree that the design is a result of trading off the desire to do away with nulls vs retaining Java interoperability. Preventing (at compile time) only Options from being null is surely impossible when casting/reflection are available. It is commonly understood that if an API returns Option[A] then the client can assume it will not return null. Personally I have never experienced a real error from this.
        the_af 12y ago
        Oh, I understand why null was needed (backwards compatibility, like you said), and I'm no language designer, so I don't know what I would have done instead. Maybe mark pieces of code that must interact with Java code with "unsafe" blocks, outside of which no nulls can escape? unsafe { ... } Don't know if this would work. I'm just disappointed because this slightly breaks the Option type, that's all.
        frowaway001 12y ago
        > I'm just disappointed because this slightly breaks the Option type, that's all. I have never ever seen this happening. The complaint feels a lot like "well, someone could use reflection and change the cached values of Integer, why don't you check that every time something returns an Integer?" to me. null is the sad fact of running on the JVM, but pretending that it doesn't exist works 99.9999% of the time in Scala.