Is it just me, or is the sound coming from the room very low? I had to turn up the volume on my speakers quiet high to hear, so I'm wondering if the gain on the microphones in the room is too low.

how would WinterCG standardisation in Ecma work? it's already in W3C

Was the microphone off when Dan Minor was speaking? I couldn't hear what was said.

one of these days we should do System.hash(value)

For some objects, its inefficient to convert the object into an existing comparable thing, or possibly even impossible to do so.

you can't build custom collection types without something like hash

Though, a sufficient hash can be shimmed.

wow this esfx repo is pure spaghetti

ok so this depends on a native module

We already have the Array unique proposal: https://github.com/tc39/proposal-array-unique

Maybe an engine VM implementer can tell us about whether there exists an immutable value for every string that can safely reveal an identity.

my employer would happily rewrite all of our translations for whatever is done here as long as it isn't completely outlandish

especially if the multi-message format/api happens.

is the library too onerous to load, too bloated, etc?

Should our guiding principle be, "don't propose libraries that are big, only libraries that are small"?

and their utility are broader

could you elaborate?

yeah thats true i guess we could make a cldr/unicode/etc api and make people figure it out themselves, but why should people have to figure out such a universal thing

i honestly still do not understand what we're losing if the guidance is "use the library"

littledan: i would argue that we do not have an agreed-upon vision for how "batteries included" the stdlib ought to be

is there a wealth of poor choices or something?

littledan: I would describe it like "momentum": the bigger it is or the faster it is being adopted, the less time it will take to reach that confidence

API standardization also tries to solve ecosystem fragmentation, insofar that its ecosystem has multiple solutions solving the same problem with difficult interoperability between solutions. I can see an anti-fragmentation justification for MessageFormat 2. It would benefit translators to converge on a single solution (that is better than gettext).

why can't we just say "this library is blessed" again? i don't mean something like built-in modules, i just mean literally "this package is blessed"

shu on top of what I brought up before. I don't think we can move forward with efforts such as https://nordzilla.github.io/dom-l10n-draft-spec/ without a syntax.

if our conclusion is recommending a specific library then we've already picked a winner, so that objection shouldn't exist to the proposal afterwards

littledan: i assume you're referring to dr. herman's presentation? (which i missed) or were there more

can someone let me in the zoom ?

you are showing as in the room. all good?

srs question, could this be an asm-like string pragma, for emscripten?

is there a concrete API i can just read somewhere that has this pattern

It depends on what do { return; } does. If it actually causes a return from the containing function, then what do you do with async do { return; }. Does async do differ dramatically from do in this case? It obviously can't return from the containing function.

that says "is used by exactly one popular package"

No, anything using WebIDL is pretty explicit that if you're returning a Promise, you always return a (possibly rejected) Promise; you never throw sync.

then i'm confused, if this is a bad pattern then... shouldn't we not add this

Is this the Promise.try() discussion happening right now? It doesn't throw sync. It just calls the function sync, but still causes a rejected promise. (If the slides are still accurate.)

Is this the Promise.try() discussion happening right now? It doesn't throw sync. It just calls the function sync, but still causes a rejected promise. (If the slides are still accurate.)

That means async do {} and do {} are wildly different things, and potentially a refactoring hazard. I'm not opposed to the capability that async do {} offers, but I wonder if it shouldn't use do in that case because it could be confusing.

TabAtkins: i know, but the function throws sync

I have been thinking about maybe async {} and expr {} or something yeah

what about expr and asyncExpr

I would prefer to never encounter a camelcase keyword

But also: you might have a function in hand that you just don't know if it's sync or async, and want to consolidate your control flow into async

I was just wondering how we could mark both as related concepts while avoiding the double keyword issue

Bradford Smith: It's identical in functionality, it's just shorter.

i can't confidently say whether it comes up super often or not but i can't come up with any strong reason to be against it

async context is happening? i thought mark was super against that

i said nullary, not unary