New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
deprecate NotNull #7247
Comments
Imported From: https://issues.scala-lang.org/browse/SI-7247?orig=1 |
@paulp said:
So as far as I'm concerned we should deprecate the empty scala.NotNull trait for 2.11.0 but we are within our rights to remove all of the implementation which underlies it immediately. |
@adriaanm said: |
@paulp said: |
@paulp said: |
Mike Allen (mja) said: I understand and appreciate that this feature was experimental and never fully implemented. Nevertheless, I found it extremely valuable: the ability to enforce non-null references for certain types is something Scala can and should support. I don't particularly want to either trap null references, nor do I want to accommodate So, given that |
Travis Calder (CriasSK) said (edited on May 30, 2014 9:02:43 PM UTC): The only up-side to On the other hand, at the declaration of the variable you could just as easily declare an This also gives you all of your Is there some area that an Option doesn't cover for you? (Edit: Sorry, goofed the formatting) |
Mike Allen (mja) said: The need for
class SomeCannotPossiblyBeNullType extends NotNull {
// ...
}
def doSomething (x: SomeCannotPossiblyBeNullType) = {
// x is guaranteed not to be null, so dereferencing x will not cause an NPE to be thrown.
// Also, there is also no need to trap whether x is null, or to wrap x in an Option.
// Furthermore, I don't have to write a unit test to verify what happens if x is null. Can't happen.
// ...
}
def willNotWork = {
// ...
val y: SomeCannotPossiblyBeNullType = null // <- results in a compiler error
val z = somePossiblyNullReference // <- results in compiler error
// ...
} What you seem to be suggesting as an alternative is to wrap every single reference to such a class in an Ironically, this doesn't even solve the problem since you can initialize an val x: Option [String] = null
val s: = x.getOrElse ("x is null") // Whoops! Get an NPE! so even |
Travis Calder (CriasSK) said: That is, as I said you ban var x: SomeCanNeverBeNull = nonNullReference;
var y: Option[SomeCanNeverBeNull] = Option(nullableReference); // Oops, it actually was null, but we handled it cleanly That is, you seem to be assuming that nullable is your default and you're flagging non-null cases. My understanding of idiomatic Scala code was that you should consider all variables non-nullable, and flag values that might not be present as If you do your null-checks at system boundaries (IO, etc.) and when calling Java libraries, a YMMV, and my take might be wrong, but I never get a |
Mike Allen (mja) said: I would guess that, since no-one is infallible, even you occasionally forget to check for null at a system boundary and get NPEs - and then proceed to waste precious development time diagnosing, fixing and testing for them. (Unit testing for null is, therefore, very much required at the system boundary.) All the same, what if, like me, you're designing an API? In that case, nullable is the default. You have zero enforcement over banning use of null in your user's code. Every single time a reference value is passed to that API, you have to consider the possibility that the value might be null - even if there's no logical need for it (a prime example being an |
Travis Calder (CriasSK) said: It sounds like we're mostly on the same page though, with just a few different default assumptions separating our different approaches. My answer to your "what if" is that it depends on the API and what a failure might cause. If the failures would be critical and damaging, such as aborting in the middle of a vital transaction, I would null-check at boundaries. Otherwise, I would classify that as a failure of the API user, and not bother checking. (In my case, that user will probably be "future me" most of the time. I accept that.) That's just my approach, it's worked for me so far. Then again, if I got my way I'd also disallow usage of |
@adriaanm said:
I apologize for the lack of communication on this, but these two sentences are at odds: since this feature was never implemented (at all, basically), it was giving you a false sense of security. In the spirit of simplifying Scala, we've deprecated everything of which we've known for a while that it was unmaintained/broken/.... (See also: the CPS plugin. We didn't mark specialization as deprecated, even though we should've.) |
Mike Allen (mja) said: So, you've removed it. Fine - I accept that. However, going back to my original comment, is there any proposed alternative functionality (provide references that are guaranteed not to be null)? Also, I'm curious: what were the difficulties/holes in implementing this feature? |
@paulp said: |
@adriaanm said: There are no plans to replace NotNull at the moment, though some Scala 3.x release may gain effect tracking, or some lint-like tool could do a static analysis. Here are two relevant papers that should give you a sense of how it could work: http://research.microsoft.com/en-us/um/people/leino/papers/krml109.pdf, http://www.cs.cornell.edu/andru/papers/masked-types.pdf (nullness interferes with initialization) |
Mike Allen (mja) said: Also, as for static checking, I should point out (for anyone interested) that Scalastyle includes a test for the use of null - highly recommended! |
We should deprecate NotNull and corral its implementation in the compiler. Its implementation has been unfinished since 2.5.
The text was updated successfully, but these errors were encountered: