JSDoc to assert that an expression is not null

[Dominator008]

TypeScript is implementing non-nullable types and strict null checks in microsoft/TypeScript#7140.

I'm interested in one thing they are adding to the language:

Non-null assertion operator

A new ! postfix expression operator may be used to assert that its operand is non-null and non-undefined in contexts where the type checker is unable to conclude that fact. Specifically, the operation x! produces a value of the type of x with null and undefined excluded. Similar to type assertions of the forms x and x as T, the ! non-null assertion operator is simply removed in the emitted JavaScript code.

// Compiled with --strictNullChecks
function validateEntity(e: Entity?) {
    // Throw exception if e is null or invalid entity
}

function processEntity(e: Entity?) {
    validateEntity(e);
    let s = e!.name;  // Assert that e is non-null and access name
}

I wonder if we can introduce a similar semantics with JSDoc, something like

var e = /** ! */ (x);

or

var e = /** @notnull */ (x);

[dimvar]

I wouldn't rush to add this, especially since we don't know yet how popular it will be in TypeScript. We can get similar behavior by casting to an appropriate non-nullable type, or by using an assertion. Closing for now, and if in the future we find that it's a great convenience to have this operator, we can revisit.

[calebpitan]

The future is now!

Can we reopen this?

[DrSensor]

microsoft/TypeScript#23405

[brad4d]

The best way to get us to reconsider it would be to file a new issue since this is quite an old one.
That way it will get into our current issue triaging process.

At first glance, I can't see a strong reason to add this feature, since you can get this effect by specifying the actual type like this.

var e = /** @type {!ActualType} */ (x);

So, if you file another issue, be sure to explain why the approach above isn't good enough.
I'm afraid that "it's too verbose" isn't likely to be a sufficient reason.
We actually prefer it when types are very explicitly specified, since that makes it easier for both the human reader and the compiler to know what is expected.