TC39 Delegates
2023-05-17
plaintext logs
prev next
source on github
15:01
<bakkot>
morning all
15:01
<bakkot>
and/or whatever time it is
15:01
<Rob Palmer>
Plenary is starting now!
15:01
<Rob Palmer>
Please join to find out if TC39 will approve ES2023
15:01
<littledan>
I hope it gets approved 😬
15:02
<littledan>
please vote yes 🥺
15:35
<littledan>
Frank's comments are generally talking in terms of various absolutes which I think are too strong
15:51
<Chris de Almeida>
we need to clean up the notes for the conclusion of ZDT stage 1
15:51
<littledan>
I wrote a conclusion right under the heading; now writing main points
15:51
<littledan>
(not deleting the raw notes just yet)
15:52
<Kris Kowal>
ptomato: Is there any risk that zone date time formatting might require a temporal constructor to close over host data? At Agoric, we’ve enjoyed the separability of now() from temporal constructors and hope for that trend to continue.
15:52
<Chris de Almeida>
thanks for your hard work on the notes, Dan! really appreciate it. time at a premium today, so needed to move
15:56
<ptomato>
ptomato: Is there any risk that zone date time formatting might require a temporal constructor to close over host data? At Agoric, we’ve enjoyed the separability of now() from temporal constructors and hope for that trend to continue.
I think this is safe, Temporal constructors still don't close over any host data. FWIW you can currently already format Temporal.ZonedDateTime with its toLocaleString method; you just can't cache the expensive operations by creating a formatter object to format multiple ZonedDateTime, and you can't formatRange or formatToParts, so that's what this proposal is solving.
15:56
<ptomato>
Intl.DateTimeFormat does close over host data, because if you construct it without a timeZone parameter then it internally assumes the host's current time zone, but that's a long-preexisting problem and I'm assuming you're not referring to that
15:57
<ptomato>
my preferred solution would actually remove that closing over host data in the case of ZonedDateTime. (in other cases, it wouldn't be web-compatible to change that)
16:08
<bakkot>
I do not like "eliminates the need for developers to understand higher-order functions" as a motivation for design decisions
16:08
<bakkot>
I really really do not like it
16:08
<littledan>
I think we should avoid subclassing AsyncSnapshot... it's confusing for these examples
16:08
<littledan>
this is a has-a relation, not a is-a
16:09
<Justin Ridgewell>
const snapshot = new AsyncSnapshot();
snapshot.run(cb, arg1, arg2);
16:09
<Justin Ridgewell>
That's how I would normally use it.
16:28
<Willian Martins>
Do you have the Task attribution link? I don't know the scope of this api.
16:28
<Chris de Almeida>
https://docs.google.com/document/d/1_m-h9_KgDMddTS2OFP0CShr4zjU-C-up64DwCrCfBo4/edit#heading=h.pny1oyazzdg0
16:29
<Chris de Almeida>
https://bit.ly/task-attribution friendly link
16:30
<Justin Ridgewell>
Termination is https://github.com/tc39/proposal-async-context/issues/52
16:30
<Justin Ridgewell>
It's still WIP, and not proposed to be added yet
16:50
<ryzokuken>
https://notes.igalia.com/p/TWx5MikWg
16:50
<Andreu Botella>
https://notes.igalia.com/p/TWx5MikWg
I think that's not visible publicly
17:24
<ryzokuken>
I think that's not visible publicly
Should be fixed now
18:14
<littledan>
There's a reason why the W3C broke off from IETF--to not deal with this bureaucracy. (And then WHATWG broke off from W3C for the same reason...)
18:14
<littledan>
We don't realize how lucky we are bureaucracy-wise!
18:16
<shu>
"You are now DAC, the do anything committee"
18:17
<Chris de Almeida>
it's oddly non-bureaucratic in certain ways as well.. IETF WGs are mailing list all the things and consensus, no voting, no memberships, etc
18:18
<Michael Ficarra>
the default state of being is no bureaucracy; these organisations do this to themselves
18:18
<Chris de Almeida>
but IESG gatekeeping...
18:42
<Kris Kowal>
chipmorningstar and I’ve been ruminating a procedural question regarding the staging process. It’s our understanding that a canonicalization proposal must be preceded by a beatification proposal. Did we miss something?
18:44
<ptomato>

the syntax of IANA time zone identifiers:

Use only valid POSIX file name components (i.e., the parts of names other than /). Do not use the file name components . and ... Within a file name component, use only ASCII letters, ., - and _. Do not use digits, as that might create an ambiguity with POSIX TZ strings. A file name component must not exceed 14 characters or start with -.

18:46
<ptomato>
(but then there are a few legacy aliases in the TZDB that don't follow these rules)
19:05
<Michael Ficarra>
I like Promise.create!
19:05
<shu>
creat pls
19:06
<HE Shi-Jun>
But Promise.create will have very different api with Object.create?
19:07
<Michael Ficarra>
... so?
19:07
<Chris de Almeida>
Promise.create does have baked in anti-bikeshedding...
19:07
<HE Shi-Jun>
I expect the same method name would have similar api.
19:08
<shu>
i regret to inform you there are only a few good english words
19:08
<ptomato>
what. Promise.embiggen is a perfectly cromulent option
19:08
<nicolo-ribaudo>
Promise.deconstructed
19:08
<nicolo-ribaudo>
Promise.unpacked
19:08
<Michael Ficarra>
hey hey hey take it to TDZ
19:08
<Chris de Almeida>
what. Promise.embiggen is a perfectly cromulent option
winner right here
19:08
<HE Shi-Jun>
Personally I prefer Promise.deferred
19:10
<Justin Ridgewell>
Ditto, I want deferred
19:10
<Kris Kowal>
Rejection is resolution.
19:10
<Chris de Almeida>
https://github.com/tc39/proposal-promise-with-resolvers/issues/2
19:11
<Chris de Almeida>
bikeshedding thread ☝️
19:11
<Justin Ridgewell>
The precedent is strong: https://github.com/tc39/proposal-promise-with-resolvers/issues/2#issuecomment-1483909052
19:11
<HE Shi-Jun>
It's always misunderstanding what "resolve" means in the community
19:11
<Kris Kowal>
ljharb: Indeed! Resolve can defer, fulfill, or reject!
19:11
<Chris de Almeida>
preference for embiggen but will settle for deferred
19:11
<ryzokuken>
we need to resolve the meaning of resolve
19:12
<ljharb>
lol i suppose it could be "fulfillers" or something
19:12
<Rob Palmer>
Resolve, fulfill and other promising terminology is clarified in States and Fates.
19:12
<ryzokuken>
Promise.unwrap
19:13
<Kris Kowal>
I’m not even sure how far back Q.defer() goes. It may have gone back to Q from Tyler Close’s Waterken, but it may have started with my work.
19:13
<Kris Kowal>
My reasoning was that Q.defer() => Deferred
19:13
<HE Shi-Jun>
I guess many non-native speakers (like me) don't know the word embiggen...
19:13
<rbuckton>
IIRC, JQuery started with defer as well
19:14
<danielrosenwasser>
Promise.withLifecycle
19:14
<Andreu Botella>
(It's a joke from The Simpsons, it's not an actual English word)
19:14
<ljharb>
it's not a real word, it's a Simpsons reference (that's kind of become a real word)
19:14
<shu>
it is an actual english word now
19:14
<Kris Kowal>
It does indeed go back to Tyler Close’s Waterken ref_send/web_send library https://waterken.sourceforge.net/web_send/
19:15
<danielrosenwasser>
https://www.merriam-webster.com/dictionary/embiggen :) https://www.merriam-webster.com/dictionary/cromulent :(
19:15
<HE Shi-Jun>
Resolve, fulfill and other promising terminology is clarified in States and Fates.
Unfortunately some libraries (like jQuery) not follow it many years
19:16
<ljharb>
i declare shenanigans
19:16
<rbuckton>
From the reading I've done, it seems like the ecosystem migration from .defer() to new Promise was due to the executor being safer as it could capture an unexpected exception and reject the promise. That meant that new Promise was a better API for the more common use cases, not that .defer() in and of itself was a bad API.
19:16
<Kris Kowal>
Waterken’s use of defer() goes back to 2004.
19:16
<bakkot>
I kinda liked Promise.capability, but possibly only because I'm familiar with that name from the spec using it
19:16
<rbuckton>
So it seems like this almost exactly matches how .defer() was used in Q and JQuery.
19:17
<bakkot>
(Promise.withResolvers also seems fine)
19:17
<ljharb>
in jquery the promise itself had resolve and reject methods on it, so i don't think that's a match
19:17
<bakkot>
(Promise.defer seems somewhat less fine)
19:17
<Michael Ficarra>
defer implies something time-based to me, akin to setTimeout
19:17
<Andreu Botella>
let's do Promise.bikeshed
19:17
<Kris Kowal>
@bakkot Promise.caps would be more apropos. The original idea is that the read-cap and write-cap could be distributed to different parties.
19:18
<ljharb>
"cap" reads to me as a hat, not short for "capability" :-p
19:18
<rbuckton>
And I'm probably not the only one that's called the same functionality defer or deferred in my own code and in npm packages (i.e., https://www.npmjs.com/package/@esfx/async-deferred though that exports a class called Deferred)
19:18
<bakkot>
cap means "lie" actually
19:18
<ljharb>
nope https://npmjs.com/promise-deferred
19:18
<danielrosenwasser>
"cap" reads to me as a hat, not short for "capability" :-p
no cap
19:18
<Chris de Almeida>
FALSE. it's a real word
19:18
<Kris Kowal>
And I'm probably not the only one that's called the same functionality defer or deferred in my own code and in npm packages (i.e., https://www.npmjs.com/package/@esfx/async-deferred though that exports a class called Deferred)
Not the distinction I beg :-)
19:18
<Chris de Almeida>
stop gatekeeping
19:18
<Andreu Botella>
Promise.gatekeep
19:19
<nicolo-ribaudo>
If we end up going with defer, ideas for alternative names for https://github.com/tc39/proposal-defer-import-eval/ are welcome :P
19:19
<bakkot>
see that's the normal thing that defer means
19:19
<shu>
no cap
frfr
19:19
<Kris Kowal>
I am supportive of Promise.withResolvers(), and failing that, Promise.defer(). Of others I can be convinced. Really, just want the darn feature already.
19:19
<bakkot>
we should reserve the use of defer for its standard English usage and find a different name here
19:20
<Chris de Almeida>
NB: it was part of the ES promise proposal at one point, and was called deferred
19:20
<ryzokuken>
Promise.deconstruct
19:20
<ptomato>
that sounds like undoing what the Promise constructor does
19:21
<Bradford Smith>
Was I the only person who thought the plan was to have import.source for both static and dynamic import?
19:21
<Chris de Almeida>
well -- Deferred is the object returned from Promise.defer()
19:21
<Bradford Smith>
I thought part of the point was to fix syntax ambiguity.
19:21
<ljharb>
no, i thought the same
19:22
<ryzokuken>
that sounds like undoing what the Promise constructor does
well, that'd be Promise.destruct 😳
19:22
<ptomato>
true
19:22
<ljharb>
Promise.gozer
19:24
<ryzokuken>

Derrida describes the task of deconstruction as the identification of metaphysics of presence. Metaphysics of presence is the desire for immediate access to meaning, the privileging of presence over absence.

half-joking here, but why not

19:24
<HE Shi-Jun>
I like meta method :)
19:25
<rbuckton>
Most .withX methods I've seen generally don't behave this way either. I normally expect it to mean "the same thing, but with something changed" or "this thing plus that other thing", such as date.withCalendar in Temporal: https://tc39.es/proposal-temporal/docs/plaindate.html#withCalendar
19:25
<Andreu Botella>
Promise.meta.url
19:25
<bakkot>
or with on Array.prototype for that matter
19:26
<Michael Ficarra>
ljharb: just do import source a from 'b'; const from = a;
19:27
<ljharb>
or import source { default as from } from 'b';, sure. but it's awkward
19:27
<Michael Ficarra>
wait what that shouldn't work
19:27
<Michael Ficarra>
the unicode escape should be the same
19:27
<ljharb>
no?
19:28
<Michael Ficarra>
I think Luca is wrong here
19:28
<nicolo-ribaudo>
The spec right now uses "source text matched by"
19:28
<nicolo-ribaudo>
For the restriction
19:28
<Michael Ficarra>
why?
19:28
<bakkot>
or with on Array.prototype for that matter
but I think this is only really true for instance methods
19:28
<bakkot>
static methods are a different beast
19:29
<bakkot>
I don't think it's likely to be confusing
19:29
<nicolo-ribaudo>
why?
Tbh the reason is that he asked me how to do it and I didn't think about a lookahead restriction 😅
19:29
<rbuckton>

Have we considered source phase imports and export declarations? i.e., do we have to do

import source x from "y";
export { x };

but can't do

export source x from "y";

?

19:29
<ljharb>
that seems reasonable to do
19:29
<Michael Ficarra>
nicolo-ribaudo: we should def change it, that is something I would bring up during editorial review
19:29
<nicolo-ribaudo>

Have we considered source phase imports and export declarations? i.e., do we have to do

import source x from "y";
export { x };

but can't do

export source x from "y";

?

I think it should be supported, but export x from "x" is currently invalid too
19:30
<HE Shi-Jun>
precedent: await.all ?
19:30
<rbuckton>
I think it should be supported, but export x from "x" is currently invalid too
Yes, but you can do export { default as x } from "x";
19:30
<nicolo-ribaudo>
precedent: await.all ?
Well that proposal didn't go very well last time it was presented if I recall correctly
19:30
<Michael Ficarra>
super.foo and super.foo() are unrelated
19:30
<Michael Ficarra>
to each other
19:30
<bakkot>
those are very related!
19:31
<rbuckton>
Which is why I brought up the topic. If we did want export source { default as x } from "y", then wouldn't we want import source { default as x } from "y"?
19:31
<nicolo-ribaudo>
Yeah I agree we should support the export from, it was even included in some slides I presented at some point I think
19:31
<HE Shi-Jun>
Well that proposal didn't go very well last time it was presented if I recall correctly
yeah, so it's not the precednet , just similar tries...
19:31
<nicolo-ribaudo>
Maybe in the slides I presented on Monday
19:32
<shu>
i dislike import.source in static imports personally
19:32
<shu>
it's treating symmetry between static and dynamic forms as a goal, whereas that's just a "nice to have" constraint imo
19:32
<Kris Kowal>
Strongly favor the proposal as presented today.
19:33
<shu>
the goal, as Guy said, is to have something that's nice to type, so people will type it, and get the nice static analysis guarantees from bundlers and tooling
19:33
<ljharb>
sure
19:33
<ljharb>
i'm not sure import source and import.source are meaningfully different to type tho, and they're identical for static analysis
19:33
<ljharb>
obv if folks just straight up find it icky then that matters
19:34
<Chris de Almeida>
it does give some ick, tbf
19:34
<Kris Kowal>
I do find the . as indicative of dynamic.
19:34
<Justin Ridgewell>
We discussed LR1 in https://github.com/tc39/notes/blob/ace580d512db32624bd74b843e0d9757278753cd/meetings/2017-11/nov-29.md?plain=1#L303
19:34
<shu>
yeah to be clear i'm purely talking about subjective ickiness
19:34
<nicolo-ribaudo>
I find it ugly, but I don't have any technical reason against it
19:34
<ljharb>
and i'm perfectly content to accept that a number of folks find it icky :-) i just want to be clear in that case that that's the rationale, nothing technical
19:35
<Justin Ridgewell>
it's treating symmetry between static and dynamic forms as a goal, whereas that's just a "nice to have" constraint imo
This is actually a huge improvement for bundlers
19:35
<Justin Ridgewell>
https://matrix.to/#/!RkpmGMjJtqLKXzByOT:matrix.org/$a5LIDdkHQL28xkgFoGx8emGNcVNOEI4BejJWms32dG8?via=matrix.org&via=igalia.com&via=mozilla.org
19:35
<shu>
This is actually a huge improvement for bundlers
oh interesting, so you're pro import.source in the static form?
19:35
<nicolo-ribaudo>
This is actually a huge improvement for bundlers
Why do bundlers prefer a dot over a space?
19:35
<shu>
likei understand import.static for the dynamic form is a big improvement for bundlers
19:35
<Justin Ridgewell>
No preference on whether dot or space, just the syntatic requirement
19:36
<shu>
why is it an improvement in the static case?
19:36
<ljharb>
being syntactic is a huge improvement for linters too :-)
19:36
<Justin Ridgewell>
It prevents accidental deoptimizations
19:36
<shu>
what?
19:36
<shu>
how can a static import deopt?
19:37
<Justin Ridgewell>
Having a dynamic import("foo.js", attributesComputedAtRuntime) would cause us to add a lot of extra code to handle phase imports
19:37
<bakkot>
I think you're talking past each other
19:37
<shu>
yes, that's the... dynamic case
19:37
<shu>
i am asking, how does import.source help the static case
19:37
<Justin Ridgewell>
Static import can't depot, only the dynamic case
19:37
<Justin Ridgewell>
Oh, I thought you were reference the static syntax in dynamic import
19:37
<shu>
yes, so... again, how does import.source help bundlers in the static import case
19:37
<Justin Ridgewell>
It doesn't
19:38
<shu>
okay, that matches my intuition, thanks
19:38
<Michael Ficarra>
I don't think anybody has made a case for import.source in the decl form other than "it matches", which is not strong IMO
19:39
<littledan>
Who made the +1 reply that we just went through?
19:39
<bakkot>
I don't think anybody has made a case for import.source in the decl form other than "it matches", which is not strong IMO
it avoids an ambiguity here, is the other reason
19:40
<HE Shi-Jun>
Note import.source also help to solve import source \n from ambiguity for module declarations (module source {}).
19:40
<Michael Ficarra>
bakkot: not an actual ambiguity, an imagined one
19:41
<Michael Ficarra>
I completely agree with Guy here, we don't need to worry about future syntax for this
19:41
<shu>
yeah
19:41
<littledan>
apologies for creating the confusion about from
19:47
<Kris Kowal>
NB: it was part of the ES promise proposal at one point, and was called deferred
I’m not suggesting that Promise.defer should be preferred based on historical precedent, but Mark originally proposed defer https://web.archive.org/web/20160404122250/http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#q.defer
19:47
<rbuckton>
If the concern around import source from from is it being ambiguous with module declarations, we could consider an alternate syntax for importing those declarations as well. i.e., import x from <module_ref> (with the literal <> characters), so there would be no ambiguity.
19:47
<Michael Ficarra>
what? we already ban let
19:49
<Chris de Almeida>
I’m not suggesting that Promise.defer should be preferred based on historical precedent, but Mark originally proposed defer https://web.archive.org/web/20160404122250/http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#q.defer
right -- I clarified after this Promise.defer() -> Object Deferred
19:49
<rbuckton>
Not a huge fan of import.source x from "y", to be honest. I understand its an option, but I'd rather not break that glass unless we need to.
19:50
<Kris Kowal>
And it seems we don’t need to.
19:50
<Bradford Smith>
Sorry, what would be the meaning of export source ...?
19:50
<littledan>
Not a huge fan of import.source x from "y", to be honest. I understand its an option, but I'd rather not break that glass unless we need to.
Yeah, I'm generally convinced that pseudo properties will be weird outside of expression context (exactly the reason why it's normal for dynamic import)
19:50
<ljharb>
Sorry, what would be the meaning of export source ...?
export source foo from 'path'
19:50
<littledan>
So I like the "break glass" mental model
19:51
<littledan>
let isn't reserved in strict mode either btw
19:51
<Bradford Smith>
export source foo from 'path'
So, it's a way to re-export the source of some other module?
19:51
<rbuckton>
I can see it now, someone writes a prettier or dprint rule to format code as import .source x from "y" so it looks less like an expression.
19:51
<HE Shi-Jun>
what? we already ban let
We really should also ban from as identifier in ES6 😅
19:52
<Michael Ficarra>
and as
19:52
<Michael Ficarra>
import { as as as } ....
19:53
<rbuckton>
Nooo. I actually have a package that exports a function with that name.
19:54
<Chris de Almeida>
need stage 3 reviewers for Promise.embiggen() -- any volunteers?
19:54
<rbuckton>

e.g.,

import { from } from "@esfx/iterable-query";

const res = from([a, b, c]).filter(predicate).groupBy(keySelector).toArray();
19:54
<Andreu Botella>
Promise.source.from()
19:55
<HE Shi-Jun>
Nooo. I actually have a package that exports a function with that name.
I mean, import {from} from module might ok, but import from from "from" really a mess :P
19:55
<Michael Ficarra>
need stage 3 reviewers for Promise.embiggen() -- any volunteers?
do a formal call after this topic
19:56
<Chris de Almeida>
yeah, might not have time -- can do it tomorrow
19:56
<rbuckton>
I mean, in is a pseudo-keyword in for-in (and an actual keyword)
20:01
<Michael Ficarra>
I mean, you don't need quorum to assign stage 3 reviewers
20:01
<Michael Ficarra>
doesn't hurt to ask
20:02
<shu>
quorum is not even a concept we have
20:02
<Michael Ficarra>
eh, we kind of do
20:03
<Michael Ficarra>
on the last meeting day, when people are trickling in in the morning, we often delay the meeting a few minutes until we reach quorum
20:03
<nicolo-ribaudo>
"consensus by locking everyone else out of the room"
20:03
<Michael Ficarra>
everyone is always late on Thursday morning
20:03
<Michael Ficarra>
too much drinking Wednesday night
20:04
<shu>
fair, quorum is not a process formalism we have, but it is a norm we operate by where we kinda know who the core stakeholders are and don't pull a fast one when they aren't present
20:12
<littledan>
fair, quorum is not a process formalism we have, but it is a norm we operate by where we kinda know who the core stakeholders are and don't pull a fast one when they aren't present
and this norm is enforced by, if the stakeholder is present at the next meeting, they can say, "hey, you pulled a fast one!" and it's kinda undone. But this process is very infrequently applied and definitely has a 1-meeting time limit.
20:13
<Justin Ridgewell>
need stage 3 reviewers for Promise.embiggen() -- any volunteers?
Happy to do it… because I already did it.
20:32
<littledan>
Can we add a continuation topic to the agenda for Array grouping?
20:33
<littledan>
I can be backup presenter if needed, but I thought ljharb was going to present
21:00
<ljharb>
ah good call, i thought the overflow item was already there. the PR has been rebased so i'd love to present it
21:04
<Rob Palmer>
How long do you need? We miscounted before so we may well run into the afternoon session.
21:09
<littledan>
I think we should expect to go into the afternoon session. I don't want to be rushed in the source maps topic either.
21:09
<littledan>
is it an important goal for others to avoid the afternoon session tomorrow?
21:25
<ljharb>
How long do you need? We miscounted before so we may well run into the afternoon session.
ideally 2 minutes, realistically 15 is a good goal
21:28
<Rob Palmer>
Let's say 15mins then.
21:54
<Chris de Almeida>
https://hackmd.io/d88UqzA8TFaKRdjY3t8vyQ schedule updated. please take a look and lmk if any concerns
21:55
<Chris de Almeida>
it would also be helpful to be prepared to present in the earlier part of the day, if we breeze through quickly
21:57
<littledan>
LGTM, yeah this is a good conservative approximation so we don’t rush too much, but we might get through it in the morning