Types of Rest and Spread

[Naddiseo]

I can see four choices:

1. Use an Array generic: Array<Type>
   • Pros: more specific type hinting
   • Cons: Longer to type; needs the concept of generics
2. Just specify the type of the item: Type
   • Pros: To the point about what the type each item is.
   • Cons: Checker needs to know that rest and spread are list item of Type
3. Implicitly they are an Array (or Argument), so just use: Array
   • Pros: Simple boxed check
   • Cons: Checker doesn't check to see if the items are correct.
4. Nothing at all.
   • Pros: No changes
   • Cons: Nothing is checked.

[Naddiseo]

1. typescript has: Type[]
   • Pros: no special syntax changes; precedent in typescript.
   • Cons: How does one do compound types, if any?

[lukescott]

As far as rest is concerned:

function doSomethingWithNumber(...numbers Number) {}

As far as array values, I'm would think this is easier:

function doSomethingWithNumber(numbers Number[]) {}

Go does this (not that we should do this):

function doSomethingWithNumber(numbers []Number) {}

The Type gets into template/overloading territory, doesn't it? I would think a tool like Babel could handle this at build time. Doing it in the engine would be tricky without strict typing.

[Naddiseo]

The only downside to Type[] is allowing an empty [] in the syntax.

[lukescott]

And if type is an expression, which would be quite powerful, it would be invalid syntax.

[Naddiseo]

As far as rest is concerned:
function doSomethingWithNumber(...numbers Number) {}

Okay, now I've played about with it a bit, that makes sense.

And if type is an expression, which would be quite powerful, it would be invalid syntax.

Yes. This. It would allow something like let a (1 < 2 ? 3 : "four")[] = []; to be valid.

[lukescott]

I'm saying that if Type (or is it TypeHint) were allowed to be any expression, Type[] would be invalid syntax. Although looking at that let a (1 < 2 ? 3 : "four")[] = []; I'm not sure what that is supposed to do.

[Naddiseo]

Exactly, that's what I was getting at. The ternary is just a place holder for "any expression", so that example would be syntactically valid nonsense.

[lukescott]

Good point. Extends allows "any expression" though. But I think in this case allowing "any expression" may be disastrous.

[Naddiseo]

(refs #30): I think this falls out of scope. If at some point in the future, the tool/linter creators ask for casting, then we can revisit the issue, or create a new spec. Closing for now.

[Naddiseo]

Oops, that last comment was supposed to be on the casting issue (I was typing in the wrong window).

Regarding this issue: Do we want to hint the container type (Uint8Array), or the type of the elements?

[lukescott]

Type of the elements. So ...args String would mean an array of strings. That's how Go does it, although their syntax is actually args... String. And with calling a method they do func(items...) instead of func(...items). I think ES6 has the ... backwards, but it's too late for that...

[Naddiseo]

Okay, sounds good in the case of same type elements. Do we want something for multi type args? Or is Object good enough:

function fn(...args Object) {}
fn(1, "2", {three: 3}); // linter is happy

[lukescott]

That would actually fail because 1 and "2" aren't Object's. You would do this instead:

function fn(...args) {}
fn(1, "2", {three: 3}); // linter is happy

If a type hint is provided all of those must be of that type. If a type hint is omitted then it's considered mixed. Object would be any reference type, but not any of the primitive types.

[Naddiseo]

Good point.

Okay, TODO is to add TypeHint for BindingRestElement in the syntax.