fwiw i still think "does TC39 care about long-term unforking of vastly popular JS forks" is a pretty important problem for the ecosystem

That's right, so I think we should make friendly advice them to add. If they are added, we can be free from adding a bench of syntax that doesn't do anything

the point about person heights using different units depending on the actual height involved is a good one, I think

no they switch between "feet and inches" to just "inches"

but also a bunch of the work there is API design

your invariants notion would help to that end

I think we definitely would comment on the API design, even beyond invariants

i guess there's no great non-web-biased body that standardizes JS APIs

like, our experience so far is that limiting stage advancement powers to TG1 has not stopped weird API designs

ryzokuken: the editor groups should collaborate more; frankly, I don't think 402 has the same editorial quality that 262 has

the format isn't even decided right now

I do fear this might be a bit premature

why isn't that library called getmessage then? 🤔

sffc: please don't paste links from the reflector into Matrix

shu: that's fair but my point is that this proposal does not appear to contain any data

For example in

tabs-close-tooltip = {$tabCount ->
    [one] Close {$tabCount} tab
   *[other] Close {$tabCount} tabs
}

The [one] and [other] are locale specific aliases for different counts.

npm stats are not useful

In other languages, these aliases might be more complex. For example in polish, between "one" and "many", there is "few":

tabs-close-tooltip = {$tabCount ->
    [one] Zamknij kartę
    [few] Zamknij {$tabCount} karty
   *[many] Zamknij { $tabCount } kart
}

another thing I might like to discuss if we get to decorators again on the agenda: https://github.com/tc39/proposal-decorators/issues/459

We are banning this by the way with a special early error. It must be parenthesized.

Like this?

a |> (@(expr)
class B {})

?

Yes.

Is this also banned?

a |> new @(@)
class A {}

Yes, because the pipe body is an unparenthesized decorated expression.

anyway, I really hope we could use @{foo} instead of @(foo) for decorator

#[decorate()] a'la rust

nicolo-ribaudo: no, after the @

That doesn't solve the asi hazard

a |> @
{foo}
class B {}

it's really strange to allow LT after @ for decorator

Well, it's allowed almost everywhere

bakkot, Michael Ficarra: https://github.com/js-choi/proposal-function-memo
I really wish WeakMaps supported primitives…It’d make specifying the cache’s behavior so much easier.

Many years ago, I put together the {Lru,Lfu}{Map,Set} cross product e.g., http://www.collectionsjs.com/lru-map

on a related note, I want to bring a MultiMap proposal, any interest in co-championing?

The one thing that would be super useful for proving it out in userspace would be records and tuples as keys.

Relatedly, if anyone is interested in co-championing https://github.com/js-choi/proposal-policy-map-set, then let me know.

ohhhh ok then I’m happy with that

are lines with only leading whitespace and an interpolation considered "character lines"?

feeling overwhelmed by the @s

I can probably explain how template tag composition works

YAML treats each tab equivalent to one space, I recall…?
I forget what Python does.

yaml do not allow tab I think.

You can mix tabs and spaces, but have to use them consistently at a given level; it doesn't treat N spaces as equivalent to a tab