Non-Nullable by default flag

[eborden]

Closure compiler should have a flag to enable non-nullable by default. Switching to non-nullable as a compiler default would break a ton of backwards compatibility, but the existing semantics are screwy and a flag would allow a correction.

As it stands these two statements are equivalent:

/** @type {function(number)} */
/** @type {function(?number)} */

The current system requires a ridiculous amount of ! symbols to counteract this.

[concavelenz]

Actual these are not equivalent. Value types are non-nullable by default. Object types are nullable.

These are equivalent:

/** @type {function(number)} */
/** @type {function(!number)} */

[MatrixFrog]

If we have a flag, then the meaning of a given type annotation changes based on whether you enable the flag or not. We should eventually migrate to non-nullable by default but to have it as an option will make it difficult for library maintainers, I think. If anything, we could consider a flag where you're required to use either a ! or a ? on every type.

[eborden]

This is true. Would a file level pragma be possible within the current compiler architecture?

[MatrixFrog]

We could add a new annotation that lives in the @fileoverview comment. That might be a nice way to do it.

[pauldraper]

It would be a little disorienting to remember to check the header of a file before looking at any type annotations in that file. Classic action-at-a-distance.

I agree with the sentiment that non-nullable should be the default for object types. Unfortunately, I think the Closure Compiler is stuck with that.

[eborden]

File or module level pragma is not an uncommon pattern, even within JavaScript. "use strict" is a perfect example of this. I disagree that this represents an egregious anti-pattern.

[concavelenz]

Requiring "!" or "?" seems like a reasonable if annoying compromise.

[michaelhogg]

+1 for:

The current system requires a ridiculous amount of ! symbols.
We should eventually migrate to non-nullable by default.
I agree with the sentiment that non-nullable should be the default for object types.

+1 also for the idea of a file-level tag, eg @nonnull:

We could add a new annotation that lives in the @fileoverview comment.
File or module level pragma is not an uncommon pattern, even within JavaScript. "use strict" is a perfect example of this. I disagree that this represents an egregious anti-pattern.

[gonzojive]

Paul's comment that a @nonnull annotation in the @fileoverview comment would fit the action-at-a-distance anti-pattern sounds accurate. So do compiler flags that alter interpretation of comments. A proliferation of customizable options that change how to interpret closure annotations will make code harder to read.

The default behavior is confusing, as are most rules that treat "value types" differently from other data types. I agree with others that the default behavior should be non-nullable for all types. I suppose that means a closure compiler language change.

I'm not sure if closure has a system for evolving the language over time. One way to handle this might be a file-level declaration like "@annotation-language " where changes when there are incompatible changes that alter closure compiler semantics. This is how the protocol buffer language deals with incompatible language changes.

[blickly]

So far, we've added a check (ImplicitNullabilityCheck.java) that warns when
using implicitly nullable JSDoc types. i.e. Object types without either a !
or an explicit (redundant) ?. The idea is that if people got their code
clean with respect to this check, then we could change the default from
nullable to non-nullable and have it be a no-op in terms of how the
existing code was typed.

On Fri, Jul 10, 2015 at 10:23 AM, Red Daly notifications@github.com wrote:

Paul's comment that a @nonnull annotation in the @fileoverview comment
would fit the action-at-a-distance anti-pattern sounds accurate. So do
compiler flags that alter interpretation of comments. A proliferation of
customizable options that change how to interpret closure annotations will
make code harder to read.

The default behavior is confusing, as are most rules that treat "value
types" differently from other data types. I agree with others that the
default behavior should be non-nullable for all types. I suppose that means
a closure compiler language change.

I'm not sure if closure has a system for evolving the language over time.
One way to handle this might be a file-level declaration like
"@annotation-language " where changes when there are incompatible changes
that alter closure compiler semantics. This is how the protocol buffer
language deals with incompatible language changes.

—
Reply to this email directly or view it on GitHub
#641 (comment)
.

[pauldraper]

I agree that

• it is confusing that some types are default nullable and others are default non-nullable
• non-nullable is a better default than nullable

I also don't think there is a fix good enough to outweigh its disadvantages.

[alexchandel]

4 years later, the type system still requires a hideous amount of "!", and a sorely-needed @nonnull flag was never added because of bikeshedding.

[brad4d]

Created internal issue http://b/132179929