TC39 Delegates
2022-02-11
plaintext logs
prev next
source on github
18:02
<justingrant>
When proposing a new built-in method that returns a list of things, what's the latest guidance about when the list should be an array vs. an iterator? Iterators seem obviously better in the cases where the results can be a long list and/or where the result comes from an async/streaming source. But if the result is short and comes from an immutable native array that's already in memory, then is it OK to return an array to get better ergonomics (filter/map, [0], etc.) ? Context: https://github.com/tc39/ecma402/issues/598#issuecomment-1035916876
18:04
<bakkot>
there is no guidance, we're just gonna fight about it every time probably
18:06
<bakkot>
though I think for short collections people are happy with arrays, generally
18:07
<bakkot>
temporal has a couple new array-returning methods, e.g.
18:07
<bakkot>
it only really makes sense to have an iterator when you might have a lot of elements
18:10
<ptomato>
I think all the Temporal methods were changed to return iterators as a result of pre-stage3 review
18:13
<TabAtkins>
We are probably gonna fight about it, but yes, return arrays when the values are short and/or fast to produce. Nothing wrong with them, lots right with them. The web platform uses arrays all over the place.
18:14
<jschoi>
We are probably gonna fight about it, but yes, return arrays when the values are short and/or fast to produce. Nothing wrong with them, lots right with them. The web platform uses arrays all over the place.
Imagine when tuples get standardized and we need to talk about whether to return tuples.
18:14
<TabAtkins>
I'm annoyed every time Python returns a tuple rather than a list, so yeah, I anticipate those being fun.
18:22
<bakkot>

I think all the Temporal methods were changed to return iterators as a result of pre-stage3 review

pretty sure nothing in the temporal spec right now returns an iterator and both Temporal.Calendar.prototype.fields and Temporal.TimeZone.prototype.getPossibleInstantsFor return arrays

18:23
<bakkot>
unless the rendered spec is out of date
18:23
<bakkot>
lots of things consume iterables, which is right and proper
18:24
<ptomato>
oh, you're right, I was thinking of changing things to consume iterables
18:24
<ptomato>
carry on then
18:25
<TabAtkins>
ah yeah anything that takes an array should take an iterator, definitely. (webidl makes this automatic with the sequence<> argument type, but I guess you have to be a little more explicit in JS specs)
20:20
<justingrant>

though I think for short collections people are happy with arrays, generally

Cool. Sounds like the guidance is:

  1. Input parameters that are lists should beIterable
  2. Return values that are long lists or are lists populated from an async or streaming source should beIterable
  3. Return values that are short lists from a synchronous source should beArray

Is that right?

FWIW, Temporal has an interesting corner case for (1) above: the CalendarProtocol.fields method currently accepts an Iterable<string>, as must the equivalent method in the builtin Temporal.Calendar class that implements that protocol. But the only callers of that method pass a <10-element array of static, immutable values. We've gotten implementer feedback that using an Iterable here makes the implementation harder.

What's the benefit of accepting an Iterable in this case if the only callers of this method are expected to come from inside ECMAScript where we can guarantee that only Array is passed? FYI https://github.com/tc39/proposal-temporal/issues/2053

20:23
<ptomato>
I think we had gotten the feedback during stage 3 review that we should accept an iterable there because a userland implemenation of fields() might want to return one?
20:25
<bakkot>
If it's actually only supposed to be called internally then it shouldn't be exposed
20:25
<bakkot>
if it's exposed then you have to design it as if it's going to be used
20:26
<bakkot>
anyway for that specific question see https://github.com/tc39/proposal-temporal/issues/1610
20:27
<bakkot>
this was also discussed in plenary IIRC so you can probably find it in the notes as well
20:32
<ptomato>
it's exposed because it's necessary for writing a custom calendar, so indeed we have to assume it's going to be used
20:43
<jschoi>

Let’s say I have a syntax-directed operation associated with the production ConditionalExpression : ShortCircuitExpression ? AssignmentExpression : AssignmentExpression.

How do I refer in the algorithm to either particular AssignmentExpression, since |AssignmentExpression| is ambiguous?

20:45
<bakkot>
the first |AssignmentExpression|