01:09
<Chris de Almeida>
in case we forget to mention it tomorrow, please do not ever use the I'm done speaking button in TCQ. thank you!
01:50
<rkirsling>
TC39 rule: never stop speaking
01:53
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
can we remove the button?
02:07
<Chris de Almeida>
https://github.com/bterlson/tcq/pull/68
06:57
<bakkot>
whatever happened to the rewrite?
10:02
<eemeli>
Looks like Christian Ulbrich and Tom Kopp were working on it here at least up until last June: https://github.com/zalari/tcq/pull/7
16:11
<Rob Palmer>
Sign in form with video link will be posted around 9am PT.
17:09
<keith_miller>
Is there an ETA for the video link? I still don't see one in the reflector.
17:20
<Rob Palmer>
Not quite. Michael is still setting up AV.
17:20
<keith_miller>
Oh I forgot these start at 10 not 9 lol
17:21
<Rob Palmer>
correct - there is 38 minutes until go time
17:46
<Rob Palmer>
The video link will be posted on the Reflector very soon
17:51
<Rob Palmer>
The video link is now posted via the Sign-in form on the Reflector!
18:03
<ljharb>
maybe we should add an actual persistent temperature check to tcq (like, physical room temperature)
18:05
<canadahonk>
fwiw its PST (-8) not PDT (-7)
18:13
<Aki>
SUMMARIES ARE GOOD
18:13
<Aki>
YAY SUMMARIES
18:24
<Rob Palmer>
If anyone would like to be the TC39 Liaison to IETF please let the Chairs know or reach out to Samina directly.
18:26
<ryzokuken>
we already keep track of the W3C i18n WG for TG2
18:27
<ryzokuken>
and some WGs from Unicode for that matter
18:27
<eemeli>
Only technically, mind. I've a recurring conflict with their call, and Ben has not been able to attend many of their meetings.
18:29
<Chris de Almeida>
please share resources for where folks should go to get involved in TC55 (matrix room, meeting info, etc)
18:29
<canadahonk>
https://wintertc.org + https://github.com/wintercg/admin
18:31
<Andreu Botella>
matrix room: #wintertc:matrix.org
18:32
<Aki>
rock and roll
18:32
<nicolo-ribaudo>
Thanks a lot Aki again for all the help with making sure that our technical work follows what Ecma needs
18:33
<canadahonk>
thank you all ECMA folks ๐Ÿ™‡
18:36
<kriskowal>
Youโ€™re audible, Aki
18:36
<Chris de Almeida>
oh reminder, there should not be notes during this period
18:37
<Chris de Almeida>
so please remove them and tell the transcriptionist to pause
18:37
<Ashley Claymore>
it has been paused
18:37
<nicolo-ribaudo>
Don't worry, we do things right also with you out of the call!
18:37
<Chris de Almeida>
and don't discuss here ๐Ÿ™‚
18:38
<Chris de Almeida>
of this, I have no doubt ๐Ÿ™‚
18:38
<nicolo-ribaudo>
You can come back
18:41
<ljharb>
can we make sure the transcription bot, and transcription human, have resumed?
18:41
<nicolo-ribaudo>
The human is back and apparently the bot was not running in the first place
18:42
<Aki>
Now that Google Docs has "export as markdown", is it time to update the agenda item template?
18:45
<Chris de Almeida>
say more
18:47
<Aki>
Allows us to use the standard document styles and get markdown as a result https://snaps.akiro.se/2502_ji3bx.png
18:49
<ljharb>
the only reason the notes items are they way they are, afaik, is for ease of markdown conversion, so it seems fine to change them?
18:50
<Chris de Almeida>
suggest validating the quality of the export first
18:52
<Ashley Claymore>
Maybe we could try on Thursday, when the agenda is light. To reduce 'risk' if the formatting needs manual fix up
18:53
<Aki>
I've used the export for notes for other committees
18:53
<Aki>
I'm very happy with it
18:58
<bakkot>
nicolo-ribaudo: re: linking other web specs, I bet we could figure out how to automatically generate ecmarkup-compatible biblios from web specs if we really want to
18:58
<bakkot>
the ecmarkup biblios are very simple
18:58
<shu>
gotta snipe tab into supporting it in bikeshed
18:58
<nicolo-ribaudo>
Right now we just need to link to URL and fetch so doing it manually is probably less effort than making it work automatically, but if we'll need to link to more stuff I'll look into it
18:59
<nicolo-ribaudo>
Currently we also rely on Infra, but as part of the rewrite we are just going to rely on ECMA-262 built-ins instead
19:11
<Ashley Claymore>
One thing we sometimes do is wrap parts of the transcription in backticks, e.g. when someone references Object.is.
Do you know if these would carry-through, or would we need to do this by changing the font?
19:12
<Aki>
it escapes them, but that's a very easy search & replace
19:12
<Aki>
y'all have no idea how many regex search & replaces I do on every meeting's notes
19:13
<bakkot>
have you considered just asking an LLM to "make it good" :D
19:13
<Aki>
๐Ÿคฎ
19:13
<ljharb>
can't wait to find out what lovecraftian horrors end up being stage 4 due to that
19:17
<Michael Ficarra>
somehow I feel much more comfortable trusting the speech-to-text than I do a text transform, and I can't explain why
19:18
<nicolo-ribaudo>
Probably speach-to-text worst case writes nonsense, rather than plausible-looking wrong stuff
19:18
<bakkot>
the trick with text transforms is to have it generate a diff, which you can then easily review for correctness
19:19
<bakkot>
also no, modern speech-to-text definitely writes plausible-looking wrong stuff a lot
19:19
<Aki>
Eggma showed up a lot in the last TC55 meeting
19:20
<nicolo-ribaudo>
https://docs.google.com/presentation/d/1LjsJhdTIP3wgo1odtVa-qbfyGU5M1W9YMm0AtKnJJKk/edit#slide=id.p
19:20
<bakkot>
https://github.com/bakkot/transcribe-to-gdocs/blob/fb863c5a314d078f2a0c60d26cf8774f08dd068a/replacements.js#L35-L46
19:20
<Michael Ficarra>
eggma is a new one lol
19:21
<bakkot>
(though this list was when using google's old speech-to-text; whisper is much better and I hear gemini is better still although I have not yet gotten around to hooking it up)
19:24
<Aki>
eggman
19:25
<Michael Ficarra>
if Whisper wasn't already better than a human transcriptionist (it probably is), Gemini certainly is
19:26
<ljharb>
coo coo ca choo
19:27
<rbuckton>
Oh, I missed this in my constraints. I need to be present for the Decorators discussion, so if it can remain after the lunch break I would appreciate it. I will add this to the agenda as a late breaking constraint
19:29
<Michael Ficarra>
except for 100%, right?
19:37
<canadahonk>
๐Ÿค“ as someone who has tried/done "professional" transcriptions a while ago, I think Whisper is good at speech-to-text but has terrible/no formatting last I looked
19:39
<bakkot>
50% of the human transcriptionists we've hired have actively harmful formatting (double spaces between sentences, linebreaks every few words, etc), so "no formatting" is still superior
19:41
<canadahonk>
yeah agree with that
19:46
<Ashley Claymore>
Not sure if still true today, but in the past the human transcriptionists seem to handle people talking over each other better. Giving each their own >> lines
19:47
<littledan>
Could someone record a conclusion on the chair election in the notes?
19:48
<littledan>
(I'm happy to share the doc link in a DM if anyone needs)
19:49
<canadahonk>
we already have it i believe
19:51
<nicolo-ribaudo>

Nope, this is it:

Speaker's Summary of Key Points

  • List
  • of
  • things

Conclusion

  • List
  • of
  • things
19:51
<littledan>
please edit the notes and add a summary and conclusion section, saying who was elected. It is currently missing.
19:51
<littledan>
I mean, I just pasted that in
19:51
<littledan>
I'm not sure if someone people believe that the earlier text implies the summary/conclusion
19:51
<littledan>
but... I just can't make sense of it
19:51
<canadahonk>
oh I read conclusion as conclusion of opinion oops nvm
19:51
<littledan>
we just don't have a list in the notes of who was elected
19:52
<canadahonk>
i'll do in break if no one else does
19:52
<littledan>
(this is normal -- almost nobody writes their own summary and conclusion without prompting, but I didn't know who to prompt for this topic)
19:53
<nicolo-ribaudo>
Done
19:57
<Chris de Almeida>
presenters! please note, the topics in the overhead bins have shifted during flight: https://hackmd.io/dp19kCC5QBeG1W37oESrfQ?view
21:20
<nicolo-ribaudo>

@babel/plugin-proposal-decorators is the most downloaded Babel plugin on npm for a proposal. It has (looking at some plugins for proposals that have been around for a while and are among the most downloaded ones):

  • 100x the downloads of @babel/plugin-proposal-explicit-resource-management
  • 40x the downloads of @babel/plugin-proposal-throw-expressions
  • 80x the downloads of @babel/plugin-proposal-pipeline-operator
21:21
<nicolo-ribaudo>
What is the burden with shipping first? Is it that you are the one that's going to find compatibility bugs?
21:22
<eemeli>
littledan: Did you really mean Stage 3, or should that have been 2.7?
21:23
<ljharb>
3 is when it's time to implement and ship, so while ideally things would be blocked at 2.7 if there's no desire to implement, 3 would be fine too
21:23
<ljharb>
but it's definitely subpar to have something be stage 3 that nobody's prioritizing
21:23
<bakkot>
re the isSafeNumeric item later, Number toString technically allows implementations a choice of outputs in some cases https://tc39.es/ecma262/multipage/ecmascript-data-types-and-values.html#sec-numeric-types-number-tostring
21:23
<bakkot>
does anyone actually... do that
21:25
<James M Snell>
I will say that it's rather frustrating as someone tracking the decorators spec work for some time... what I heard is that implementers don't want to prioritize it because they don't want to be the first to ship, but that they don't want to be the first to ship because the work is not prioritized..... what I'm not hearing at all is do the implementers just not want to implement decorators at all? Is this just a delay tactic to ultimately kill the proposal?
21:29
<rbuckton>
For many syntax features, developers are often comfortable with using a build tool to transform new syntax under the expectation that that transformation step can be removed once evergreen browsers have been updated to support the feature, but that requires those browsers to continue to make progress on shipping those features. Many syntax transformations are fairly cheap, though that's not always the case. Async functions and generators required fairly significant transformations and helper libraries to support, which adds overhead to bundles. The transformed emit for stage 3 decorators can also be quite large, which has a negative impact on bundle size and initial load time.
21:30
<rbuckton>
Even if feature availability is lopsided across browsers, developers can use server-side UA sniffing (or even client side with import()) to ship a leaner bundle with native decorators on browsers that support them, and a transformed bundle on browsers that don't.
21:31
<bakkot>
possible in principle and I wish people did it more, but in practice I have ~never seen server-side UA sniffing for serving scripts with downleveled features to browsers which don't support something
21:32
<ljharb>
i think facebook might do it, but i've never actually seen it
21:32
<rbuckton>
possible in principle and I wish people did it more, but in practice I have ~never seen server-side UA sniffing for serving scripts with downleveled features to browsers which don't support something
Isn't this essentially what anyone participating in an Origin Trial would need to do?
21:33
<Michael Ficarra>
possible in principle and I wish people did it more, but in practice I have ~never seen server-side UA sniffing for serving scripts with downleveled features to browsers which don't support something
we literally do that
21:33
<snek>
one of the npm-to-web cdns does it, idr the name
21:33
<bakkot>
origin trials are most often APIs which you can just make conditional within a script instead of UA sniffing
21:34
<bakkot>
we do a lot of weird things! but that's a one-off for a particular feature we needed, not a general mechanism for arbitrary features
21:36
<bakkot>
polyfill.io did for APIs but that's a slightly different thing than syntax
21:37
<bakkot>
I don't think many places are using npm-to-web CDNs in prod
21:37
<bakkot>
well, presumably lots of hobbyist stuff
21:37
<rbuckton>
possible in principle and I wish people did it more, but in practice I have ~never seen server-side UA sniffing for serving scripts with downleveled features to browsers which don't support something
Large scale applications definitely have used both server-side UA sniffing and client-side feature detection to dynamically load content in different engines for performance tweaks.
21:38
<bakkot>
I agree some people do it; we do it. But it's very very rare in my experience, looking at random retailers and hotels and so on.
21:42
<nicolo-ribaudo>
syg: What we are doing with import defer, is that deferred namespace objects guarantee that they will never have a .then property. This doesn't actually change the promises machinery, but makes sure that deferred namesapces are inert to it. And we can do it because they are already very exotic objects
21:42
<rbuckton>
If decorator downlevel emit size is a significant concern, it might be worth that kind of temporary split to produce a leaner bundle when possible. Web performance optimization is a major area of focus for large scale applications.
21:43
<shu>
thanks. still says to me there's a datapoint that we consider "then" a special evil worth special casing
21:46
<littledan>
We did already make Object.prototype be exotic (to have a frozen proto) but I agree that exotic with respect to then is an extra form of weirdness
21:49
<bakkot>
Mathieu Hofman: for the Promise.resolve constructor lookup, see https://github.com/tc39/proposal-faster-promise-adoption/issues/1
21:49
<littledan>
For the notes: every time someone says "object dot proto", they mean Object.prototype, right? Not Object.__proto__
21:50
<bakkot>
currently the check is IsPromise(p) && p.constructor === C; I think it should be IsPromise(p) && GetPrototypeOf(p) === C.prototype
21:50
<bakkot>
GetPrototypeOf usually triggers user code, but can't trigger user code once you pass the IsPromise test
21:53
<Mathieu Hofman>
Yes this is when the "SafePromiseResolve" issue came up last time
21:54
<nicolo-ribaudo>
Are firefox use counters public, with a list of example websites, like Chrome's?
21:55
<Mathieu Hofman>
I basically want to make this check into a "SafePromiseResolve" that fast path promises that do not re-enter, and delay by one tick the ones that may. Then anyone can use that operation, possibly even await.
21:55
<Mathieu Hofman>
That's not sufficient if someone overrides %PromisePrototype% then and constructor properties
21:56
<bakkot>
isn't it?
21:56
<bakkot>
Promise.resolve does not do a lookup of .then on things which pass that check
21:56
<Mathieu Hofman>
It does for constructor if I recall.
21:56
<bakkot>
Right, it does IsPromise(p) && p.constructor === Promise
21:57
<bakkot>
but if we make it IsPromise(p) && GetPrototypeOf(p) === C.prototype then it would not do anything user-observable (on real promises)
21:57
<bakkot>
and I bet we can get away with that
21:57
<bakkot>
this also applies to await since it uses the same machinery
21:58
<bakkot>
and await also does not do an actual .then lookup at all, it just does a PromiseResolve and then uses the built-in PerformPromiseThen
21:58
<Mathieu Hofman>
defineProperty(Promise.prototype, 'constructor', {get() {} })
21:58
<bakkot>
I don't know what that's intended to be a response to
21:59
<bakkot>
I am proposing to change the machinery so nothing ever looks at .constructor
21:59
<snek>
what constitutes a brand check
21:59
<snek>
like what granularity
21:59
<snek>
there are so many ways to organize objects
21:59
<nicolo-ribaudo>
A sync side-effect-free way to tell wether an object has a particular internal slot or not, for any slot
21:59
<Mathieu Hofman>
Oh, if you think that's web compatible
22:00
<snek>
for every internal slot?
22:00
<bakkot>
I give it reasonable odds
22:00
<bakkot>
since the only thing that happens if something starts failing the check is that they get another microtask tick
22:00
<nicolo-ribaudo>
Well, a brand check is for one internal slot, and Jordan would like every internal slot to have a brand check
22:00
<snek>
yeah i mean my question is what the consensus applied to
22:01
<snek>
because there are a lot of internal slots, how does one decide which ones are relevant in this case
22:01
<sffc>
Frank is ill, and I will now be presenting his slides on Intl Locale Info. Rob Palmer Chris de Almeida ryzokuken
22:01
<Mathieu Hofman>
Yeah I just need to think through the different cases of "subclassing" that the constructor check is meant to handle.
22:02
<ryzokuken>
hope he recovers soon, thanks for the heads up
22:02
<ljharb>
every internal slot that has observably different behavior, i suppose
22:02
<Mathieu Hofman>
Anyway, I'd be happy with anything that allows anyone (spec or user code) to stop triggering sync code during Promise.resolve
22:02
<ljharb>
and luca's comment seems somewhat related, in that it relates to the overarching committee goal throughout ES6 of making DOM objects JS-implementable
22:03
<bakkot>
I am very firmly convinced that the goal of making host things 100% doable in userland was a mistake
22:03
<bakkot>
that gave us Symbol.concatSpreadable and etc
22:04
<bakkot>
mostly doable in userland is good but I think it's probably OK if you can't polyfill this particular behavior?
22:04
<ljharb>
i'm not personally invested in implementable in userland, fwiw
22:04
<bakkot>
like, people probably aren't going to start relying on being able to stick .then on your polyfilled webIDL thing
22:04
<ljharb>
are there no webIDL thenables?
22:04
<bakkot>
don't think so
22:04
<ljharb>
because being able to implement one of those seems important for engines implemented in JS, if so
22:04
<James M Snell>
if it's not doable in JS then there are a ton of web platform APIs that node.js, deno, etc would have a difficult time implementing this for
22:05
<snek>
though engines implemented in js have their own object graph, so its kind of a moot point
22:05
<bakkot>
I think for node etc you could just have a built-in thing to mark objects as special in this way, and then mark them?
22:05
<bakkot>
as long as V8 exposes this as a bit you can set on an arbitrary object
22:05
<James M Snell>
Such built-in things become rather expensive from a perf cost
22:06
<bakkot>
hm, ok
22:06
<James M Snell>
anything that requires calling down into C++ becomes rather expensive in aggregate
22:06
<bakkot>
it could take a list of objects and just do a single call, if the concern is the number of times you cross the language barrier
22:06
<ljharb>
ones 100% implemented in JS yes, but not in eg node where they use JS to augment (and sometimes polyfill) standard features not implemented in JS
22:07
<shu>
do you need to mark objects often?
22:07
<Andreu Botella>
anything that requires calling down into C++ becomes rather expensive in aggregate
there's no reason V8 couldn't have a built-in that gives access to an object containing a lot of internal APIs that can be called from JS
22:07
<shu>
is it like, per instance?
22:07
<shu>
...why... would we do this?
22:07
<canadahonk>
fyi chairs I'm good to present math.clamp from now for scheduling
22:08
<James M Snell>
well, it's not just node.js itself. Also thinking about user-land provided polyfills of standardized apis
22:09
<James M Snell>
at the very least, it seems we have consensus that there's a problem to address here. I think there's likely multiple ways to address it but I want to make sure we do not prematurely take JS polyfillability off the table
22:10
<canadahonk>
is it fine to do the login form twice or if not could someone dm the meeting link?
22:10
<bakkot>
how important do you think it is to be able to polyfill this specific weird behavior? because it feels not that important to me
22:10
<ljharb>
yes, it's fine to do it multiple times
22:10
<ljharb>
i mean hermes still needs to polyfill Promise.resolve for react native, using JS, so they'd need it
22:11
<James M Snell>
having experienced this issue before with a userland polyfilled implementation, I'd personally say it's important
22:12
<snek>
technically this does exist, there's a kitchen sink object called the "extras binding"
22:12
<James M Snell>
oh god, please don't expose this to users
22:12
<shu>
snek: for me it's like, can you, with a straight face, say a thing is intended to be a thenable? if not, it'd be nice if we disallowed it to be a thenable at a language level
22:12
<Chengzhong Wu>
it triggers an emotion to see "how important to be spec compliant" in a tc39 channel
22:13
<bakkot>
well like I don't think people should be trying to polyfill document.all
22:13
<bakkot>
the language has a lot of weird corners
22:13
<snek>
well with a straight face i would say that modules aren't intended to be thenable. but idk how many people agree with me on this (well if anything, based on my original proposal being rejected, i know people don't agree with me)
22:13
<ljharb>
(+1 that subclassing builtins was a mistake)
22:14
<bakkot>
I definitely agree but that ship has sailed
22:14
<bakkot>
we can't now make them not-thenable
22:14
<Ashley Claymore>
.constructor.name.match(/promise|defer/i)
22:14
<bakkot>
but we did for deferred namespace objects at least
22:15
<ljharb>
i'd love it if we used null proto more aggressively for new spec-created objects; it seems like it'd avoid a whole class of problems
22:15
<snek>
time to merge the extends null spec pr?
22:16
<rbuckton>
FYI on terminology, a "thenable" is any object with a then method, regardless as to whether it is a promise or matches the Promise/A+ specification. i.e., if typeof x.then === "function" it's a "thenable". Being a "thenable" doesn't make it Promise-like.
22:16
<snek>
i'm aware
22:16
<bakkot>
I want this but weren't there still unresolved questions?
22:17
<littledan>
yeah, the PR didn't work at all
22:18
<snek>
the pr /works/, people just don't agree on the behavior
22:19
<rbuckton>
I only mention it because I've been running afoul of developers making the wrong assumption, or assuming the meaning of "thenable" has changed over the years. I'm mostly making the point so it's on the record in the chat log.
22:19
<snek>
like we have a set of test cases (which you can read in the pr), which delegates don't agree on the output of, or at least didn't last time it was brought up
22:21
<ljharb>

as i recall (disclaimer: i haven't read the PR in years), the options atm are either:

  1. class extends null not necessarily statically, but super is an error in what is syntactically a derived class
  2. class extends null not necessarily statically, and super is a noop

(and i think also either option, but "only statically")

and i think each option had a number of folks whom received an "ick" from it

22:23
<nicolo-ribaudo>
Wow reading through that PR I really dislike what some comments are proposing
22:23
<eemeli>
We're skipping the break?
22:24
<ryzokuken>
the break is delayed
22:24
<ryzokuken>
we'll break for 30 at the end of this presentation
22:24
<nicolo-ribaudo>
Charis can you update the agenda item on tcq?
22:24
<ryzokuken>
done, thanks
22:24
<bakkot>
https://github.com/tc39/ecma262/pull/1321 is the class extends null PR
22:24
<bakkot>
in case anyone else wants to have opinions
22:24
<bakkot>
or clean it up and bring it back :D
22:25
<snek>
i'm happy to bring it back if people agree on something
22:25
<Rob Palmer>
(Personal opinion) Just going back to the Decorators browser stalemate of "willing-to-ship-but-not-be-first", it makes me worry a tiny bit about the quality of signal Stage 3 is sending to non-browsers. If it gets unblocked, there's no worry. If it remains blocked or gets demoted, we will have unfortunately transferred risk to TypeScript that has followed our process and shipped the proposal - which has been a major churn for users of the older version of TS Stage 1 Decorators.
22:25
<snek>
can't solve a paradox
22:25
<Rob Palmer>
Maybe we could report on developer usage experience from Decorators TS to help inform/motivate browsers to begin shipping.
22:26
<snek>
well until they are open about why they're not shipping it, its kind of unclear what report they need, if any
22:28
<littledan>
This feature does not need to be a speedup to be useful, IMO. (Good to avoid false claims here though)
22:29
<bakkot>
I can't believe css shipped clamp in a different order than every other language
22:29
<bakkot>
that is such a bizarre developer-hostile decision
22:30
<snek>
i didn't know people put min after max
22:30
<bakkot>
is TabAtkins here, can we complain to them
22:30
<littledan>
CSS should have meeting minutes where they discussed this at some point...
22:31
<bakkot>
apparently a fairly common complaint https://github.com/w3c/csswg-drafts/issues/11427
22:35
<nicolo-ribaudo>
The minutes are at https://github.com/w3c/csswg-drafts/issues/2519#issuecomment-387803089. It seems like it was for alignment with a CSS function that ended up not actually existing (minmax with 3 arguments)
22:35
<bakkot>
uuuuuuuuuuuugh
22:36
<Michael Ficarra>
nice
22:36
<TabAtkins>
What up
22:36
<bakkot>
css clamp has the wrong argument order, it is different from every other language, this probably means we can't have Math.clamp
22:37
<nicolo-ribaudo>
The question would be "does JS align with CSS, or with all the other non-web languages"
22:37
<snek>
the prior art used in this is painful
22:37
<TabAtkins>
As the issue says, there's both precedents
22:37
<shu>
i thought dbaron had adopted gen z slang but i see that fr is a unit :(
22:38
<nicolo-ribaudo>
new Math.Clamper(min, max).clamp(value)
22:39
<TabAtkins>
With hindsight, I agree the weight of precedent goes with val first
22:39
<ljharb>
fr fr
22:39
<ryzokuken>
(new (new Math.ClamperFactory(min))(max)).clamp(val)
22:40
<snek>
NumberConstrainmentBuilder
22:40
<ryzokuken>
problem solved
22:40
<ljharb>
don't forget the MathFactory
22:40
<kriskowal>
BigMath
22:40
<bakkot>
please take shitposting to tdz
22:41
<littledan>
I just don't think it's so useful to overthink this kind of thing (re sffc's comment)
22:42
<littledan>
hindsight? you just shipped this just now!
22:42
<littledan>
(anyway we've been there before)
22:42
<TabAtkins>
We resolved on it six years ago
22:42
<bakkot>
clamp is pretty old at this point https://developer.mozilla.org/en-US/docs/Web/CSS/clamp
22:43
<bakkot>
unfortunately...
22:43
<TabAtkins>
Anyway do the obvious thing in JS
22:43
<TabAtkins>
Css round() looks nothing like Math.round either
22:44
<bakkot>
fair point!
22:44
<TabAtkins>
Really it's only on the simplest of cases (single argument, or all arguments semantically identical) that we match
22:45
<ljharb>
eemeli: only the ones that start with "to" :-p this one wouldn't
22:45
<eemeli>
It would still be a very radical change.
22:45
<TabAtkins>
Css even fixed JS's dumb mistake with mod() (but still shipped the bad behavior as rem())
22:46
<bakkot>
if we end up shipping rem with the other behavior that would be very funny
22:46
<ljharb>
i'm not sure it'd be "radical" - does anybody have the expectation that "all methods on a thing always return the same kind of thing"?
22:46
<TabAtkins>
I mean JS doesn't name either of them
22:46
<TabAtkins>
So that would be a self own
22:47
<ljharb>
i'd expect people call one method, and don't know or care about the ones they aren't calling
22:47
<TabAtkins>
And I *did* do significant name research to settle on mod/rem as the name pair
22:49
<bakkot>
someone used to push regularly for us to add those
22:49
<bakkot>
... possibly Brendan actually?
22:50
<TabAtkins>
We still should!
22:51
<snek>
System.clamp
22:51
<ljharb>
sffc: being aligned on the motivation is for stage 1. are you objecting to that?
22:51
<eemeli>
Given that we already have Math.min and Math.max, I don't see how anything other than Math.clamp would be better.
22:51
<ljharb>
the main reason i see is that it'd also allow BigInt.prototype.clamp (and i guess that it resolves the argument ordering question)
22:52
<TabAtkins>
Yeah please do Math.clamp(v, min, max), y'all
22:52
<ljharb>
what would the bigint clamp be then?
22:52
<bakkot>
BigInt.clamp
22:52
<nicolo-ribaudo>
The reason I like a proposal for this is that there is a 50% chance to forget "when doing max(min(...), ...), I need to pass the min to max and the max to min". A built-in function for this is motivated if it makes it easier to pass the right number in the right place
22:52
<ljharb>
then y no Number.clamp?
22:52
<bakkot>
because Math is the namespace for the number stuff
22:53
<TabAtkins>
Oh, I'm not in the meeting at I didn't see the context. But yeah sure, BigInt.clamp()
22:53
<snek>
Math.clamp(number|bigint) pls
22:53
<TabAtkins>
And yeah, Math has precedent
22:53
<eemeli>
I think the question about clamping bigints needs to be answered simlutaneously with min() and max() for bigints.
22:53
<bakkot>
those also go on BigInt
22:53
<TabAtkins>
Or the "three bigint arguments" on Math. +1 to @eemeli:mozilla.org:
22:54
<ljharb>
and in a world where we also have decimal, suddenly all the Math stuff "should" really be on Number, and Math is just weird legacy baggage?
22:54
<bakkot>
I think Number will always be privileged relative to any other numeric types
22:54
<snek>
are bigints not math
22:54
<bakkot>
so it is ok that it gets two namespaces
22:54
<littledan>
BigInts are not math
22:54
<bakkot>
re: Math.max(bigint), https://github.com/tc39/proposal-bigint-math/issues/23#issuecomment-1275893064
22:54
<bakkot>
I think this is very compelling
22:54
<ljharb>
ah, but 3n + 4n works
22:55
<bakkot>

1n + Math.max(...list) will throw a TypeError if list === []

22:55
<snek>
1 + Math.max(...list) is -Infinity, is that more helpful in practice (not that it isn't the correct thing to return)
22:56
<bakkot>
it's not necessarily more helpful but it is what your code is already designed for
22:56
<bakkot>
and unexpectedly getting a TypeError is pretty weird
22:56
<bakkot>
also, separately, I don't like the return types of functions to depend on the types of their inputs
22:57
<nicolo-ribaudo>
I did not mention it because throw-away objects are probably bad, but Math.clamp(value, { min, max }) would also be a reasonable option
22:57
<snek>
but i think at a very high level if we want to continue to separate things out, prototype methods is a probably my preferred solution. cuz then (a, b) => a.min(b) works for any numeric types
22:58
<TabAtkins>
I did not mention it because throw-away objects are probably bad, but Math.clamp(value, { min, max }) would also be a reasonable option
Note that the css clamp accepts "none" for its min/max arguments, so that would be a more consistent functionality
22:59
<snek>
this makes me wish again that js had named arguments, separate from option bags
22:59
<TabAtkins>
Allows you to optionally clamp either side without having to either branch your function name or supply infinity
22:59
<rbuckton>
Math.BigInt.{ min, max, clamp, ...} is always an option. It's a bit odd to have Number-related methods on Math but BigInt related methods on BigInt.
23:00
<eemeli>
Have we actually considered named arguments and dismissed them at some point?
23:00
<TabAtkins>
Yes, sorta
23:00
<TabAtkins>
It's fallen on syntax grounds
23:01
<rbuckton>
In the same vein, Math.Decimal.{ min, max, clamp, ... }...
23:08
<TabAtkins>
Specifically, the two obvious syntaxes are foo(arg1: v) and foo(arg1=v), and both are problematic.
23:09
<Richard Gibson>
moar punctuation: foo(arg1:: v)
23:09
<rbuckton>
I thought it had fallen on "we already have { arg1: v }" grounds
23:10
<rbuckton>
foo(arg1=v) definitely is, but why is foo(arg1: v) problematic? Something like foo(arg1:= v) would work too
23:11
<rbuckton>
Though in some languages, := means "bind and initialize"
23:11
<TabAtkins>
while I was typing it i couldn't recall what was bad about arg:val, actually
23:11
<TabAtkins>
i suspect it is just that object bags take the air out of the room
23:13
<rbuckton>
Except that they're extremely inefficient.
23:13
<TabAtkins>
oh yeah they're bad, i agree
23:13
<TabAtkins>
maybe arg:val was just becuas eof its nearness to the trinary operator being potentially confusing
23:14
<rbuckton>
C# has both foo(arg1: x) and ?:, it's not especially confusing, IMO.
23:15
<Richard Gibson>
URL fragment directives use :~:; we can't do worse than that
23:15
<rbuckton>
Especially since arg binding can only happen at the start of an argument.
23:16
<rbuckton>
Named arguments was an issue that partial application ran up against. Partial application only wants to bind Argument positions, and foo(x, { y: ? }) is not a valid Argument position, while foo(x, y: ?) would be.
23:18
<Ashley Claymore>
a little similar with parameter decorators, they don't work in the same vein for object-bag-as-named-argument-pattern
23:20
<eemeli>
I would find named arguments like foo(arg: value) to correspond rather well with the way we can already use foo({ arg: value }).
23:21
<TabAtkins>
yeah, it probably is the most natural syntax for js
23:24
<rbuckton>
I think the biggest issue with named arguments is that parameter names aren't preserved in the face of .bind and method replacement via decorators.
23:25
<TabAtkins>
i mean, they could be. it's unobservable right now.
23:25
<TabAtkins>
(source visibility doesn't contradict this)
23:25
<rbuckton>
.bind could. Decorators could not, not without additional reflection over the method being decorated and some way to dynamically define named arguments.
23:27
<TabAtkins>
tho Python gets by without having either of those preserve names, because it has *args and **kwargs
23:27
<bakkot>
named parameters working automatically (without opt-in from the callee) would break all minifiers which would be kind of a shame
23:27
<TabAtkins>
so a decorator can just take and pass (*args, **kwargs) and preserve the arg name beahvior
23:28
<littledan>
I want to repeat my request to the meeting organizers that we enable recording and publishing as a pattern for any presentation
23:28
<bakkot>
arguments.named
23:28
<littledan>
it is a very good practice, for transparency and inclusion
23:28
<littledan>
thank you Mark for bringing it in here
23:29
<bakkot>
fwiw I strongly dislike having any public recordings of my voice (though there is at least one now)
23:29
<bakkot>
but would feel somewhat awkward about personally opting out of recording my presentations every single time
23:29
<rbuckton>

for example:

function ignore() {}
function dec(t, c) {
  return ignore
}
class C {
  @dec a(x) {}
  @dec b(y) {}
}

a and b both end up with the same function for the method.

23:29
<bakkot>
I guess we could have some practice of automatically overdubbing but that would be a lot more process
23:29
<kriskowal>
opt-in to record sgtm
23:30
<kriskowal>
opt-out to not-record sbtm
23:30
<rbuckton>
So yeah, named arguments would need to be passed along somehow.
23:31
<ljharb>
fwiw i am concerned about ephemeral spirited in-group discussion, or attempted whimsy spoken aloud, becoming like a conference talk that people can critique forever even as cultural standards shift. opt-in-only covers that tho.
23:32
<bakkot>
I don't think anyone was proposing recording the discussion, just the presentations
23:32
<littledan>
yes, this would be opt-in. (but generally I think the things which look bad in retrospect were already bad at the time.)
23:33
<kriskowal>
otoh, apologizing to forty people is tractable in a way that apologizing to everyone is not
23:35
<eemeli>
Yeah, that does make it sound like it'd break the web.
23:35
<bakkot>
well, not as we usually use the term
23:36
<bakkot>
but it would be pretty annoying for developers and also probably make all websites some amount larger eventually once the minifiers updated to preserve parameter names
23:36
<snek>
there are a lot of identifiers they have to preserve anyway
23:37
<Michael Ficarra>
there are?
23:37
<Michael Ficarra>
just eval
23:37
<Michael Ficarra>
what else?
23:37
<bakkot>
property names
23:37
<bakkot>
and options bag names
23:37
<Michael Ficarra>
those aren't identifiers, get out of here
23:38
<snek>
๐Ÿคจ https://gc.gy/20c632fb-3230-4795-babd-ed57b11c0b22.png
23:38
<bakkot>
IdentifierName is, to be fair, technically not Identifier
23:39
<rbuckton>
imports from packages not bundled, exports exposed to end users, globals
23:53
<littledan>
FWIW I wouldn't mind normative text, requiring that hosts respect the immutability of immutability array buffers (but the assert reading makes sense too)
23:58
<bakkot>

I would probably do something like

NOTE: Because canonical numeric index properties of a TypedArray backed by an immutable ArrayBuffer are nonconfigurable and nonwritable, the [essential object invariants](link goes here) mean that hosts are prohibited from modifying the values in an immutable ArrayBuffer by any means.

23:58
<waldemar>
If an assert failure makes the spec normatively incorrect, then an assert cannot be informative. Informative text cannot make a spec inconsistent.
23:59
<bakkot>
Why not?
23:59
<littledan>
but, it's text that implies no normative requirements on implementations