TC39 Delegates
2023-08-14
plaintext logs
prev next
source on github
05:56
<ljharb>
that's workable but gross, and it shouldn't be called concat in that case
07:09
<bakkot>
concat is the only name for this operation in every single language and every library
14:00
<Justin Ridgewell>
This is called chain in Rust, and is combined with once to create an iterator of a single value
14:52
<Michael Ficarra>
ljharb: You're in luck! I was already planning on starting work on this proposal today.
14:53
<ljharb>
concat is the only name for this operation in every single language and every library
but concat in this language accepts a single thing or a list of things
14:55
<Michael Ficarra>
I am very much okay with the meaning of concat depending on the kind of thing it's applied to
14:58
<Michael Ficarra>
regardless, though, it's probably more important to match one of Iterator.from or Iterator.prototype.flatMap, which both reject primitives (though differ in their handling of strings)
17:52
<TabAtkins>
Yeah, so long as there's an easy way to lift a primitive into an iterable (via once() or something), then having concat() only accept iterables is fine with me.
17:53
<TabAtkins>
It'll still probably commit the cardinal sin of Treating Strings Like Iterables tho, unless we explicitly guard against that.
17:55
<ljharb>
if it requires being an array than i'll probably just always concat([].concat(item)) which would be annoying
17:56
<nicolo-ribaudo>
You can lift x into an iterable by doing [x]
18:18
<bakkot>
It'll still probably commit the cardinal sin of Treating Strings Like Iterables tho, unless we explicitly guard against that.
iterator flatmap explicitly guards against that, so concat would too
18:19
<TabAtkins>
Excellent.
18:20
<bakkot>
if it requires being an array than i'll probably just always concat([].concat(item)) which would be annoying
you'd only do that if you don't know whether or not item is an array, surely? which... I have a hard time imagining code where that comes up very much?
18:21
<TabAtkins>
yeah there's very, very little non-trivial stuff you can do with a value that could be an X or an array of Xs that doesn't require first establishing which it is. Array#concat allowing it is a weird historical quirk, most langs don't have that.
18:48
<Michael Ficarra>
iterator flatmap explicitly guards against that, so concat would too
not necessarily; if we just make Iterator.from variadic, it will iterate strings
18:48
<bakkot>
that sounds like a good reason to do concat instead of making Iterator.from variadic
18:48
<TabAtkins>
Why would variadicity change this behavior.
18:49
<Michael Ficarra>
TabAtkins: it changes nothing, that's already the behaviour of iterator.from on a single argument
18:49
<bakkot>
Iterator.from does accept strings
18:49
<bakkot>
it's only specifically flatMap which doesn't
18:49
<TabAtkins>
Ah, ok, so the Sin has already been committed.
18:49
<TabAtkins>
Damn.
18:49
<Michael Ficarra>
Iterator.from and Iterator.prototype.flatMap are different in this respect
18:49
<bakkot>
(Iterator.from being an explicit coercion it makes a lot more sense there)
18:49
<TabAtkins>
wish I'd recognized that and complained loudly about it earlier
18:50
<Michael Ficarra>
but I think it's the right call for Iterator.from; whether we like it or not, strings are iterable
18:50
<Michael Ficarra>
Array.from shouldn't reject strings either
18:50
<bakkot>
it's important not to implicitly treat strings as iterable, but explicitly is fine I think
18:51
<bakkot>
or, well
18:51
<bakkot>
given that they are iterable
18:51
<TabAtkins>
Since [..."foo"] works, I guess, ugh
18:51
<bakkot>
if they weren't, yes
18:51
<Michael Ficarra>
exactly
20:08
<ljharb>
you'd only do that if you don't know whether or not item is an array, surely? which... I have a hard time imagining code where that comes up very much?
it comes up for me all the time
20:09
<ljharb>
and yes the original Sin is that strings are iterable
20:13
<TabAtkins>
it's important not to implicitly treat strings as iterable, but explicitly is fine I think
(Note that I still feel quite strongly that this is also a (lesser) sin; there is no Correct way to iterate a string and pretending there is just misleads authors. Giving strings well-named iterator-returning methods is the correct thing to do. But that ship sailed long ago for JS.)
20:15
<bakkot>
fully agreed
20:17
<bakkot>
it comes up for me all the time
I believe you I just have a hard time imagining it
20:18
<ljharb>
(Note that I still feel quite strongly that this is also a (lesser) sin; there is no Correct way to iterate a string and pretending there is just misleads authors. Giving strings well-named iterator-returning methods is the correct thing to do. But that ship sailed long ago for JS.)
i still think we should add codeUnits and codePoints iterator methods, even tho it’s too late to remove the Symbol.iterator method ¯_(ツ)_/¯
20:19
<TabAtkins>
And if at all possible a graphemeClusters method, tho that does depend on Unicode version.
20:20
<bakkot>
a codePoints iterator might be confusing given that codePointAt gives you a number
20:20
<TabAtkins>
but codeUnits and codePoints would def be Free(tm) since that's the two iteration methods we already expose.
20:20
<bakkot>
well, unless codePoints was an iterator of numbers
23:49
<Michael Ficarra>
ljharb: iterator sequencing proposal: https://github.com/michaelficarra/proposal-iterator-sequencing
23:59
<ljharb>
i really like Iterator.of combined with concat (if it works like [].concat) or another name ("with" might be nice?) if not
23:59
<ljharb>
then i can do .with([1]) or i can do .with(Iterator.of(1)) if i'm forced to do that