Sorry, off-topic, but could we do a quick test if showing my slides works?

i was going to mention this on the queue but how we explained reusability in the past is via functions. for example how do you make for..of reusable, you wrap it in a function that you call multiple times.

let those adherents import a library, that seems sufficient?

if/after pipeline has landed, i think there will be compelling reasons. but until then, i agree that there isn't. and i don't think proposals should wait for that.

to be clear, I am very, very opposed to function-based style even in a world in which we have pipeline

if you want to use more things in a method-based style, you can write a thing extending Iterator.prototype and put more methods on it

you must see this https://github.com/fantasyland/fantasy-land 😂

relative to the design of the language for the next several decades, the cost of that particular breaking change is small

I suspect there are relatively few things which use the Iterator type, and it is a very easy migration to do

speaking as editor of the specification, the name of the interface in the spec is basically the lowest possible priority

In TypeScript? Actually there are a fair amount of folks using Iterator directly, changing that would be breaking, but the interface Iterator doesn't have to align with the value Iterator.

i agree with that mental model, but i don't think that speaks for or against "counter"?

to confirm, whats the problem with iterable strings? that they are iterable at all, or that they don't iterate over the expected contents?

to confirm, whats the problem with iterable strings? that they are iterable at all, or that they don't iterate over the expected contents?

(iow we should have done String.prototype.codeUnits() and String.prototype.codePoints() and not had String.prototype[Symbol.iterator] at all)

How about .graphemes()?

absolutely, we just need a proposal and consensus (so, easy, right?) we wouldn't ever be able to unbreak strings tho :-(

Array.values() vs Array[Symbol.iterator] 😅

for (p of str) is fine

for (p of str) is fine

strings are iterable, we can't take that back

it can already warn about passing a string where an iterable is expected, though

We should all put our abbreviation in the jitsi display name

+1 (and Jitsi should make it even clearer who is currently talking even if someone else is screen sharing)

…Though come to think of it, we probably should call it something like .byCodePoints() or .codePointStrings() or something. Because the language already uses “code points” to refer to integers: String.codePointAt returns integers.

Kinda wish we had a char-like concept in JS (at least, the C# version that is always a wide char) that wasn't just Number/String

Note sure we have good use case of char?

It’s my opinion that, because “character” has so many different meanings (8/16/32-bit code units, code points, combining character clusters, grapheme clusters), it’s too ambiguous and should generally be banned from technical documentation and APIs and replaced by more specific phrases. But that’s me……

maybe we could use "rune" (rust, go use that term?)

strings probably shouldn't've supported operators

I hesitate to mention that Unicode does have more quote characters.

then again some syllables could be viewed as hypothetical

then again some syllables could be viewed as hypothetical

And of course the hypothetical code page of combining tengwar and tehtar.

Hopefully not on the same screen as emoji...

Code blocks (and code-point order) were never meant to be meaningful for users; they’re artifacts of encoding history and optimization.

This is what Unicode says, but I think Unicode could do a better job of showing this. Maybe by presenting human-user-friendly pages of writing-system repertoires…

Aye, and Map.prototype.keySet and Map.prototype.valueSet that provide façades with varying has behavior.

oh weird, i don't. i'll refresh

off-topic, I hope the queue could have emoji like 👍️ on each item, so I can just show my support without add another +1.

I feel like we are struggling to defend indefensible positions at this point. Who would actually want an array passed to set union/intersection to operate on its indices?

i agree with the need to signal a promise of conformance to some contract

i'd expect erights would say the same about the "override mistake" and hidden intrinsics needing to be fixed instead of cargoculted forever

For me it’s also that the bot is slower than the stenographer. For me to be of any use taking notes I have to add a 5-10 second delay to my audio. Which further means I can’t interact with what is happening.

the thing where 'use strict'; let x = { __proto__: Object.freeze({ prop: 0 }) }; x.prop = 1; throws instead of assigning to a property on x shadowing the thing on the prototype

is it proven to be web incompatible to change that? I’m assume it has

in TDZ a while back Rob Palmer said

The override mistake is the biggest of all the mistakes I would like to see fixed. Igalia investigated this on our behalf 3 years ago (I think it may have been Joyee?) and found that Lodash relies on the exception thrown in the bad case.