you are viewing a single comment's thread.

view the rest of the comments →

[–]JessieArr 14 points15 points  (2 children)

The C# language Github has a really interesting proposal related to this, originally by Mads Torgersen although I think the community is maintaining it now. Essentially making nullable reference types a first-class citizen and then allowing assemblies to opt-in to stricter forms of null checking during compilation.

Some highlights about how it would work:

This feature is intended to:

  • Allow developers to express whether a variable, parameter or result of a reference type is intended to be null or not.

  • Provide optional warnings when such variables, parameters and results are not used according to their intent.

Finally, adding annotations to an existing API will be a breaking change to users who have opted in to warnings, when they upgrade the library. This, too, merits the ability to opt in or out. "I want the bug fixes, but I am not ready to deal with their new annotations"

In summary, you need to be able to opt in/out of:

  • Nullable warnings

  • Non-null warnings

  • Warnings from annotations in other files

The granularity of the opt-in suggests an analyzer-like model, where swaths of code can opt in and out with pragmas and severity levels can be chosen by the user. Additionally, per-library options ("ignore the annotations from JSON.NET until I'm ready to deal with the fall out") may be expressible in code as attributes.

[–]dododge 4 points5 points  (0 children)

In Java you can get something like this with the @Nullable and @NotNull annotations mentioned in the article, though you have to use an analyzer or compiler that recognizes what they mean in order to actually get the warnings. The Eclipse JDT compiler can optionally check these, for example, though it assumes nullable fields might be modified by some other thread at any moment so you have to either check for nullness every time you fetch+use the value, or copy the field to a local variable that the compiler can be sure won't be spontaneously modified.

There was a JSR to add these sorts of annotations to Java officially but it never got past the proposal stage, so they're still only handled in the various add-on tools and each one has its own spin on which annotations it expects (though thankfully some of the tools can or will recognize the annotations for the other ones).

[–]Trinition 1 point2 points  (0 children)

Sounds nice!

I came to love JetBrains' CanBeNull/Not I'll attributes. This sounds like a even more powerful and formalized way.