ES6 Generators #534
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -295,18 +295,26 @@ declare class JSON { | |
| } | ||
|
|
||
| /* Iterators */ | ||
| interface IteratorResult<Y,R> { | ||
| done: boolean; | ||
| value?: Y|R; | ||
|
There was a problem hiding this comment. So for I actually wonder if maybe we can make value not be optional, since the union'd There was a problem hiding this comment. The value is optional—it becomes undefined upon completion of the iterator. i.e., when |
||
| } | ||
|
|
||
| interface $Iterator<Y,R,N> { | ||
| @@iterator(): $Iterator<Y,R,N>; | ||
| next(value?: N): IteratorResult<Y,R>; | ||
| } | ||
| type Iterator<T> = $Iterator<T,void,void>; | ||
|
|
||
| interface $Iterable<Y,R,N> { | ||
|
There was a problem hiding this comment. Can we name these type vars more explicitly? They can show up in error messages, and sometimes without context it makes the error more confusing/unclear. There was a problem hiding this comment. Do you have an opinion on the more explicit names? There was a problem hiding this comment. I have no objection. I can add a commit here, but it seems like an easy enough change to make in your internal merge, too, if you want to make the change yourself. (I'm not sure what the internal merge looks like, of course, so this could be wrong-headed of me.) There was a problem hiding this comment. Yea, |
||
| @@iterator(): $Iterator<Y,R,N>; | ||
| } | ||
| type Iterable<T> = $Iterable<T,void,void>; | ||
|
|
||
| /* Generators */ | ||
| interface Generator<Y,R,N> { | ||
| @@iterator(): $Iterator<Y,R,N>; | ||
| next(value?: N): IteratorResult<Y,R>; | ||
| } | ||
|
|
||
|
There was a problem hiding this comment. Super rough idea, but I wonder if we could express this as something like interface $Iterator<Y, R, N> {
next(value?: N): IteratorResult<Y>;
}
type Iterator<T> = $Iterator<T, *, *>
interface $Iterable<Y, R, N> {
@@iterator(): $Iterator<Y, R, N>;
}
type Iterable<T> = $Iterable<T, *, *>;
// Generator<Y, R, N> should be an $Iterable<Y, R, N>
// Generator<Y, R, N> should be an Iterable<Y>
// Generator<Y, R, N> should be an $Iterator<Y, R, N>
// Generator<Y, R, N> should be an Iterator<Y>
interface Generator<Y, R, N> {
@@iterator(): Iterator<Y>;
next(value?: N): IteratorResult<Y|R>;
}
declare function $yieldDelegate<R, N>(g: $Iterable<*, R, N>, n:N): RIf we do this, I think we could deal with something like yield *({ [Symbol.iterator]: function *() { return yield 4; } })ignoring the fact that Flow doesn't have support for There was a problem hiding this comment. Sorry, I'm a bit unclear about what that buys us. Could you extend your example with a test case showing an expected type error? There was a problem hiding this comment. So here's what I'm trying to do. If you If you're So given the example above If you call I think it's possible to capture this idea, by creating |
||
| /* Maps and Sets */ | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did you decide to parameterize
IteratorResulton two things rather than just one? They seem equivalent to me...I'm just curiousThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a bit of future proofing. Once #577 is fixed, we can use a better type for this that takes advantage of this parameterization:
type IteratorResult<Y,R> = { done: false, value: Y } | { done: true, value: ?R }(Annoyingly, the
valuemember isRthe first timedoneswitches totrue, but if you callnextagain, it becomesundefined. >:(.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That said, #577 hasn't changed yet, and interfaces as type unions isn't possible either, so I'll commit this change and you can take it at your discretion.