Array types

[Mouvedia]

• default for one and more
• typed arrays
• regex support

[Mouvedia]

Should we reuse the existing JS syntax—rest parameters—for zero or more?

[...Number]

I consider this the main use case.
Reusing ... has 2 problems:

• it would ultimately be a dupe of [Type*]
• ...Type already expands to an array so the surrounding brackets are redundant

Typed arrays (shouldn't be confused with TypedArray)

[String, Number]

// valid
['test', 1]
// invalid
['test', 1, 2]

Regular expression
+ (one or more) should be in the MVP.
The rest should be relegated to the backlog for now.

[tomek-he-him]

• it would ultimately be a dupe of [Type*]

[Type*] looks quite cryptic to someone who doesn’t know the spec.

• ...Type already expands to an array so the surrounding brackets are redundant

Actually, I have a feeling that ES 2015 rather sees the ... as expanding to a list of comma separated items without any brackets around that. I. e.:

const myItems = [a, b, c];

fun(...myItems) ≅ fun(a, b, c);
[...myItems, d] ≅ [a, b, c, d];

So I don’t see that as a problem.

All in all, I really like your idea. More than the regex-inspired syntax proposed by @ericelliott, to be honest. To a newcomer, [Number, ...Number] is much less cryptic than [Number+].

[tomek-he-him]

If we go down the regex path, it gets tricky to parse too. Consider something like:

[((Number|String){3,}, Function){2,5}]

I don’t think anyone would need such a monster. So let’s KISS (don’t get me wrong 😃).

[Mouvedia]

looks quite cryptic to someone who doesn’t know the spec.

Who doesn't know regular expressions, yes.

Actually, I have a feeling that ES 2015 rather sees the ... as expanding to a list of comma separated items without any brackets around that.

You are probably right. It's used with objects as well after all.

At this point I would like 0 or more [...Example] and what I am calling typed array—for a lack of a better denomination—for the MVP. I agree with @tomekwi in that we could leave out regexes for now.

The only remaining issue is 1 or more. Would [Type, ...Type] be acceptable?
If not, what would you propose that wouldn't require regexes?

[tomek-he-him]

I actually like [Type, ...Type].

[maiermic]

How about:

• [...Type] instead of [Type*]
• [Type...] instead of [Type+]

[Mouvedia]

How about:

• [...Type] instead of [Type*]
• [Type...] instead of [Type+]

I dunno what the others think, but IMO it's brillant and obvious. Ashamed I didn't think of it.

[ericelliott]

I don't hate this:

[...Type] instead of [Type*]
[Type...] instead of [Type+]

And I don't think it could be a slippery slope like introducing regex features.. ;)

[Mouvedia]

Ill make a PR to support this proposal this week. It will just be examples/descriptions without corresponding sub sections hence avoiding naming things inappropriately.

[ericelliott]

When you do, make it clear that [...Type] is short for Array[...Type].

We frequently have a need to document collection polymorphisms ... see Lodash collection/*. I think it's important that we can use rtype to do that.

[Mouvedia]

@ericelliott You can commit on the branch Ill create: I can't possibly describe stuff I don't comprehend.

[ericelliott]

@Mouvedia It means, for example, that you can do this:

interface Collection: Object | Array

highPass(cutoff: Number, collection: Collection[...Number]) => numbers: [...Number]

Collection polymorphism is very common in JavaScript, and we should have an easy way to deal with it.

See also Generics and Collection Polymorphism from"Programming JavaScript Applications".

[Mouvedia]

@ericelliott The usage of brackets for that use case seems to make sense since it's limited to objects (arrays included). But still why not Collection{...Number}? I am not saying it's better but the choice seemed completely arbitrary. I support the feature; I just don't know why we should favour that syntax.

I like to limit the scope of the additions to the specification so that there's less friction in the process.
Next time you should probably open a new issue so that we can iterate faster.

[ericelliott]

But still why not Collection{...Number}?

Because it's a generic function. It works for both arrays and objects. The point of using [] for generics is that we can easily handle both cases. For the common Array case, it looks totally natural. For the generic collection case, it's not a big stretch.

I'd open a new issue, but we have already discussed generics in depth in several other issues, and generics and typed arrays are deeply interconnected. Any array syntax we adopt should use the generic syntax that we decide to go with, for internal consistency. This is why I favor the square bracket syntax for generics.

[Mouvedia]

Yeah I think we should continue this discussion on #80. I consider "typed arrays" a consensual subject, illustrated by the fact that we easily converged to a common solution.

[maiermic]

[...Type] is short for Array[...Type]

No, [...Type] is short for Array[Type]. You cann't use the spread operator to pass generic types. Thus, you can't use Collection[...Number] in

interface Collection: Object | Array

highPass(cutoff: Number, collection: Collection[...Number]) => numbers: [...Number]

either. Not to mention the fact that you didn't declare the interface Collection as generic. What do you like to express by Collection[...Number]? Is highPass the example from Generics and Collection Polymorphism?

function highPass(number, cutoff) {
   cutoff = cutoff || this.cutoff;
   return (number >= cutoff);
}

[Mouvedia]

@maiermic please discuss anything generics related on #80 and migrate your reply there, thanks.

[ericelliott]

[...Type] is short for Array[...Type]

No, [...Type] is short for Array[Type]

You can't use the spread operator to pass generic types.

I think we lost the signal here.

What we're discussing, unless I'm missing something, is a new syntax for how the spread operator is interpreted in the context of the square bracket notation for generic invocations.

In this context, I mean that the bracket notation, [Type] is equivalent to Array[Type] because Array is the default type constructor.

The spread operator in this context means the same thing whether Array is specified or not:

[...Type] instead of [Type*] (zero or more values of type Type)
[Type...] instead of [Type+] (one or more values of type Type)

Thus Foo[...Type] means that the collection type is Foo, and it may have zero or more values of type Type. Array[...Type] means that the collection type is Array, which is default, which is why [...Type] is short for Array[...Type].

Unless I'm mistaken, whether zero or more or one or more is default when you specify [Type] without the dots is undecided, so the assertion that [...Type] is short for Array[Type] is not certain, yet (though I agree that should probably be the default).

[Mouvedia]

That's exactly what I was trying to avoid. The issues regarding generics should be discussed on #80.
Ill do the PR soon so please refrain to post here unless it concerns specifically what this issue is about (typed arrays).

[ericelliott]

@Mouvedia As I have mentioned several times, generics and typed arrays are inextricably linked -- and that's a feature, because it enables the easy expression of collection polymorphism.

[Mouvedia]

@ericelliott I don't deny this. It may be or may not. What I want is adding what covers the main use case to the specification. If it happens to fit in the bigger picture of what's gonna be added next then all the better.

But Iv seen you changing your mind over the syntax of generics. You were at one time supporting whitespace.

I am being practical that's all. Small iterations FTW.

[ericelliott]

@Mouvedia Point taken. I'm open to a PR for [...Foo], [Foo...] in the context of typed arrays with no mention of generics. In a future PR, we can discuss the relation to generics.