Details

    • Type: Bug
    • Status: CLOSED
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: Scala 2.11.0-M3
    • Component/s: None

      Description

      We should deprecate NotNull and corral its implementation in the compiler. Its implementation has been unfinished since 2.5.

        Attachments

          Activity

          Hide
          moors Adriaan Moors added a comment -

          > 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 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.)

          Show
          moors Adriaan Moors added a comment - > 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 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.)
          Hide
          mja Mike Allen added a comment -

          Adriaan, thanks for your response. As for the feature not working "at all", I tested it and found it worked pretty well, but I accepted that it was incomplete and that there might be a surprise or two in store. There are other experimental features in Scala 2.10 that were in common use (e.g. macros), so I assumed that you guys were working on finishing the job. C'est la Vie.

          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?

          Show
          mja Mike Allen added a comment - Adriaan, thanks for your response. As for the feature not working "at all", I tested it and found it worked pretty well, but I accepted that it was incomplete and that there might be a surprise or two in store. There are other experimental features in Scala 2.10 that were in common use (e.g. macros), so I assumed that you guys were working on finishing the job. C'est la Vie. 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?
          Hide
          extempore Paul Phillips added a comment -

          Part of the difficulty is the same difficulty which makes it easy to deliver null to AnyVal and Nothing, both of which should exclude it: uninitialized references And scala allowing overridden and abstract vals makes that problem largely insoluble if you want to keep separate compilation.

          Show
          extempore Paul Phillips added a comment - Part of the difficulty is the same difficulty which makes it easy to deliver null to AnyVal and Nothing, both of which should exclude it: uninitialized references And scala allowing overridden and abstract vals makes that problem largely insoluble if you want to keep separate compilation.
          Hide
          moors Adriaan Moors added a comment -

          The original implementation only caught blatant assignments of null to a NotNull type. As Paul alluded to, tracking non-nullness is a form of effect tracking, which is much trickier than regular type checking because it's flow sensitive (e.g., `val x = if(foo) notNull else null; ... ; if(foo) methodExpectingNotNull` is a common pattern that requires flow sensitivity/full dependent types to type check). More generally, it likely requires whole-program analysis to get good results (but that still doesn't solve how to do java interop).

          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)

          Show
          moors Adriaan Moors added a comment - The original implementation only caught blatant assignments of null to a NotNull type. As Paul alluded to, tracking non-nullness is a form of effect tracking, which is much trickier than regular type checking because it's flow sensitive (e.g., `val x = if(foo) notNull else null; ... ; if(foo) methodExpectingNotNull ` is a common pattern that requires flow sensitivity/full dependent types to type check). More generally, it likely requires whole-program analysis to get good results (but that still doesn't solve how to do java interop). 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)
          Hide
          mja Mike Allen added a comment -

          Paul, Adriaan, thanks to you both for your comments. Not for the first time, it appears to be a much more complex issue than I had assumed. Maybe it's easier just to deprecate null? In any case, I'll be sure to follow-up your links: guaranteed non-null reference types would seem to be a natural fit with Scala and would sure make life easier for a lot of us.

          Also, as for static checking, I should point out (for anyone interested) that Scalastyle includes a test for the use of null - highly recommended!

          Show
          mja Mike Allen added a comment - Paul, Adriaan, thanks to you both for your comments. Not for the first time, it appears to be a much more complex issue than I had assumed. Maybe it's easier just to deprecate null ? In any case, I'll be sure to follow-up your links: guaranteed non-null reference types would seem to be a natural fit with Scala and would sure make life easier for a lot of us. Also, as for static checking, I should point out (for anyone interested) that Scalastyle includes a test for the use of null - highly recommended!

            People

            • Assignee:
              moors Adriaan Moors
              Reporter:
              moors Adriaan Moors
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: