Add type annotation for tuples

[blickly]

This issue was imported from Closure Compiler's previous home at http://closure-compiler.googlecode.com

The original discussion is archived at:
http://blickly.github.io/closure-compiler-issues/#209

[concavelenz]

I would like to see this added to assist in ES6 destructuring.

[eborden]

Previously closure compiler ignored tuple types:

/**
* @param {[number, string]} foo
*/

but in the latest build these are throwing errors. This severely limits jsDoc usage.

[dimvar]

We want to tell sm what we support, and not silently ignore type annotations. We were just silently dropping tuples before, and the programmer might have been left with the impression that we were checking them.

If you want to have them in as documentation, you can always write sth like (omit the @):

param {[number, string]} foo

[eborden]

Is it possible to suppress this warning otherwise?

[eborden]

I ask because I'm aware tuples are not being checked, but I have them is some locations where checks are still needed:

/**
* @param {{foo: Bar, baz: [number, string]}} x
*/

[dimvar]

I don't think the warning is suppressible. @MatrixFrog can you double-check this?

Also, I don't think you can get checking for the last example you mentioned, b/c when part of the jsdoc is invalid, the compiler discards the whole thing.

So yes, this change had a few drawbacks unfortunately, but overall we think it's a positive change. We'll re-add the tuple syntax when we actually type check it.

[eborden]

Bummer, well it would be nice to be able to set a flag to coerce tuple syntax to a ? in the mean time. That way existing type documentation can remain accurate without sacrificing all static checks.

[MatrixFrog]

@suppress {nonStandardJsDocs} might work, but I'm not sure.

[aslushnikov]

Any progress on this? So far we've tried to use

/** @type {{0: number, 1: string}} */

but looks like it's not actually working.

[dimvar]

No, we haven't worked on tuples yet, and they're not in the immediate horizon, so they won't happen for a few months for sure.

[shicks]

What about starting with {[a, b]} as an alias for {!Array<a|b>}? The latter is already the best we can do for many of these types, and then we can work on teaching NTI to deal with them better at some point later. (This could also provide a nice "carrot" for switching to NTI)

[MatrixFrog]

I generally want to avoid allowing syntax in such a way that it implies we're doing some checking that we are not actually doing. If we're going to do that I'd like to at least emit a warning when the OTI runs, saying that this isn't actually being checked the way the user probably thinks it is.

[dimvar]

Agree with Tyler. There is no rush to add the syntax until we're ready to add semantics as well. When we've added syntax early in the past it has led to issues, eg, all sorts of generic-type syntax was allowed before we supported generics, and was hard to migrate after we added generics.