TC39 Delegates
2023-01-31
plaintext logs
prev next
source on github
14:54
<rbuckton>
shu, waldemar: Were you able to review the Async Explicit Resource Management proposal specification text?
14:58
<Rob Palmer>
Plenary begins in T-minus 1 minute encounting.
14:59
<shu>
rbuckton: i didn't have a chance to review the whole thing, but i did look at the using await sections of the draft spec
15:02
<rbuckton>
rbuckton: i didn't have a chance to review the whole thing, but i did look at the using await sections of the draft spec
The rest of the spec text that isn't using await is the same as the sync-version prior to carving AsyncDisposableStack and @@asyncDispose out in the November plenary.
15:02
<shu>
were there changes to using await? it looked like an exact mirror of the sync case, except plumbing through the ~async-dispose~ hint and awaiting disposable resources with that hint on block exit
15:05
<rbuckton>
were there changes to using await? it looked like an exact mirror of the sync case, except plumbing through the ~async-dispose~ hint and awaiting disposable resources with that hint on block exit
No. The ~async-dispose~ plumbing was there when you reviewed Explicit Resource Management prior to Stage 3 since I'd left it in to support AsyncDisposableStack. The only changes I've made aside from adding the using await syntax were to incorporate editorial feedback that I already received on the sync version of the proposal since creating https://github.com/tc39/ecma262/pull/3000, so that the spec text shared between the two remains consistent.
15:05
<shu>
cool, that makes sense
15:06
<rbuckton>
I should clarify, there were minor changes to address Mathieu Hofman and erights concerns about any evaluated using await forcing an explicit await even if the initialized value is null or undefined, but that should be about it.
15:08
<Michael Ficarra>
hmm, it would be nice if useGrouping had a string specifier for all options so you could ignore that it also takes undefined/Booleans
15:09
<Michael Ficarra>
it doesn't currently have a "never" option, just false
15:17
<Rob Palmer>
Is Frank Tang here? His agenda item is next.
15:23
<Anthony Bullard>
bterlson: Should TCQ have a "Comment on topic" action that implies no further commentary is necessary?
15:23
<Anthony Bullard>
Maybe action is the wrong term. Maybe "queue item"?
15:25
<bterlson>
It's more like a flag on the queue topic I would say (since it could be a reply or a new topic)
15:26
<bterlson>
but yeah it could be added
15:36
<Michael Ficarra>
we could also just leave those comments here in Matrix and the chairs could read them aloud at their discretion
15:37
<ljharb>
adding "EOM" at the end seems like it's been a workable convention
15:38
<HE Shi-Jun>
what "optional" and "allow" mean in the example?
15:38
<Michael Ficarra>
yeah, the status quo is also not bad
15:39
<Michael Ficarra>
what "optional" and "allow" mean in the example?
it could mean anything, it's just an example
15:41
<HE Shi-Jun>
yeah, I just curious how to explain the example
15:41
<rbuckton>
Would be interesting if you could just 👍️ the current topic, since we often get a lot of +1 <eom> comments
15:42
<ryzokuken>
Would be interesting if you could just 👍️ the current topic, since we often get a lot of +1 <eom> comments
"react to current topic" as opposed to reply, I guess
15:42
<HE Shi-Jun>
I don't understand if downgrade to stage 2 why not unship...
15:42
<Anthony Bullard>
That's what I was going for rbuckton . Just a lightweight mechanism to register feedback on the current topic
15:42
<ryzokuken>
where you could use some basic emotes like 👍️ 👎️ etc
15:43
<Michael Ficarra>
if we have a 👍️ react, we must also have a 💩
15:43
<danielrosenwasser>
what "optional" and "allow" mean in the example?
HE Shi-Jun: You could imagine that in a runtime like Deno, Node.js, or others, allow could restrict permissions when importing a certain library. So you could give the library file-system access, but not access to make network requests
15:44
<Anthony Bullard>
Yeah, that's why I thought free text for it is still important so we don't fall down the emoji reaction rathole
15:44
<rbuckton>
Not sure if I'd go as far as adding 👎️, since a negative reaction or concern is better represented as a topic.
15:45
<Anthony Bullard>
That's a good point
15:45
<rbuckton>
Plus we already have an emoji reaction thing that I don't think we've ever actually used correctly.
15:45
<Anthony Bullard>
Maybe then just "Support current topic"
15:45
<rbuckton>
Maybe then just "Support current topic"
Basically, yes.
15:46
<ryzokuken>
One problem I can think of is that it goes against our very recent discussion about explicit support
15:46
<ryzokuken>
I guess it's still explicit though
15:46
<HE Shi-Jun>
HE Shi-Jun: You could imagine that in a runtime like Deno, Node.js, or others, allow could restrict permissions when importing a certain library. So you could give the library file-system access, but not access to make network requests
the example is to import a css module so i don't understand how a css module relate to fs access...
15:47
<danielrosenwasser>
Yeah, the example might have been meant to be written with a .js extension, or the runtime has special behavior
15:47
<danielrosenwasser>
it's for your imagination :D
15:48
<HE Shi-Jun>
maybe it disallow @import "https://...." in css? 😅
15:54
<shu>
btw for folks less involved in this discussion, we have a response here: https://github.com/whatwg/html/issues/7233#issuecomment-1407049226
16:06
<bterlson>
I prefer status quo to adding reacts on the agenda item. I don't want negative reacts, and would rather positive reacts have SOME context.
16:07
<bterlson>
"the proposal is great EOM" is better than a random thumb up IMO.
16:07
<bakkot>
(I agree but could not resist showing agreement by a random thumb up)
16:10
<littledan>
shu: If you want to do a temperature check, state the question clearly
16:10
<shu>
yes i will craft a question when we do it
16:10
<littledan>
the chairs have a recommended process for this now
16:10
<shu>
but i want to do it after justin's item
16:10
<rbuckton>
We discussed this internally and one of our suggestions matches what @shu just said. Change semantics of assert, add with keyword to replace it (i.e., assert as an alias to with), phase out assert/forbid via lint
16:14
<rbuckton>
Maybe we can just think of assert as a cast with implicit type coercion. (half j/k, half serious)
16:14
<shu>
yeah i honestly believe we have shoehorned ourselves into one particular meaning of "assert"
16:14
<shu>
and are not being flexible
16:15
<shu>
which is... a psychological thing, not a semantics thing
16:15
<rbuckton>
Can whoever is typing mute?
16:15
<shu>
think that was me, sorry
16:19
<yulia>

my understanding re process:

Withdrawing Proposals, Reverting to Earlier Stages, and Adopting Proposals

At any point in the process, a proposal champion may propose that a proposal be downgraded to an earlier stage or withdrawn. Consensus of the committee is necessary for these transitions.

16:20
<ljharb>
that doesn't mean only a champion may propose it.
16:20
<ljharb>
anyone can propose any changes at any time, whether they achieve consensus or are procedurally valid is a separate thing.
16:21
<Anthony Bullard>
As a new delegate in a new member organization, is there a document I can read to learn more about in-band and out-of-band?
16:21
<yulia>
my view is that a downgrade should have the champions involved. forcing something to stage 1 is what i am objecting to here. I find this very concerning
16:21
<ljharb>
nothing can be forced because champions participate in consensus
16:21
<ljharb>
only proposed. which forces nothing.
16:22
<shu>
yeah we just don't have consensus for re-opening IB/OOB
16:22
<yulia>
yep, agreed. I am responding to what you were proposing and saying that it would be inappropriate. I am surprised it was brought up i guess?
16:22
<yulia>
like, that is a huge leap
16:22
<shu>
wait what i said?
16:22
<yulia>
sorry, no, what jordan said
16:22
<shu>
ah yes agreed, i was also surprised
16:23
<Michael Ficarra>
I don't think so, but you can add the terms to the glossary at https://github.com/tc39/how-we-work/blob/main/terminology.md
16:23
<Michael Ficarra>
in this context, in-band means within the source text, specifically within the import declaration
16:24
<Michael Ficarra>
out-of-band would be things like HTTP headers, CLI flags, browser config, etc
16:26
<Justin Ridgewell>
OOB would be something like import maps: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/importmap
16:26
<yulia>
sorry i may have overreacted there
16:28
<Anthony Bullard>
So basically with OOB configuration of the behavior happens outside of the ECMAScript source but is applied within the execution of said source?
16:29
<ljharb>
yes, just like CSP and import maps
16:29
<Anthony Bullard>
Sounds good. Adding these terms to the above document will be good practice for going through the process here
16:30
<Michael Ficarra>
Anthony Bullard: PRs welcome
16:40
<Michael Ficarra>
if we had a temperature check for using in eval, I would give it a 👍️
16:40
<Michael Ficarra>
but I don't feel strongly enough to even add a topic to TCQ
16:42
<littledan>
Yeah I feel like we could go either way on eval; it's fine to prohibit or support
16:42
<littledan>
I don't think most JS developers have internalized that they can use let at the top level of a direct eval
16:43
<littledan>
+1 to doing a temperature check
16:44
<yulia>
Anthony Bullard: in case you are looking for other stuff on tcq, maybe adding a temp check question isn't a bad idea... (i can help, i did the original implementation of the temp check)
16:45
<Anthony Bullard>
Working on it
16:45
<Anthony Bullard>
Just trying to find a good reference for the term in-band
16:47
<Anthony Bullard>
I will reach out if I have any questions. Haven't any took a peek at the repo yet
16:47
<Jack Works>
is this being temp checked?
16:47
<rbuckton>
Yes
16:47
<Michael Ficarra>
Jack Works: yes, on TCQ
16:47
<Jack Works>
i can't see a vote UI, did I miss that?
16:48
<Anthony Bullard>
By the way, does the TCQ "Log" go anywhere?
16:48
<yulia>
i can't see a vote UI, did I miss that?
try reloading
16:48
<yulia>
or there may be a bug
16:49
<Michael Ficarra>
I just refreshed and the temp check is gone now
16:49
<yulia>
oh
16:49
<Jack Works>
tried many time but see nothing
16:49
<yulia>
😬
16:49
<yulia>
current state
16:49
<Anthony Bullard>
It's gone for me as well after a refresh
16:49
<Jack Works>
i support to reject using directly in eval
16:50
<yulia>
ill vote on your behalf jack
16:50
<HE Shi-Jun>
why only ban await,not ban yield?
16:50
<shu>
because there's the async using await ron will present later, i presume
16:51
<HE Shi-Jun>
ok. so if syntax is async using, no need to ban await?
16:51
<shu>
🤷
16:52
<bakkot>
I would be happy to ban yield and for that matter also undefined, as long as we're banning stuff
16:52
<yulia>
alright, if anyone wants to discuss anything from this meeting, i'll be around for the next hour. I won't make the afternoon session
16:52
<bakkot>
{ using undefined = x } // oh no
16:54
<HE Shi-Jun>
I really hope we banned let undefined and const undefined in ES6 (only allow var undefined for webcompat).
16:55
<Anthony Bullard>
Michael Ficarra: Any conventions on commits / branches for this repo that I'm not seeing?
16:55
<ljharb>
const undefined is banned because consts need a value :-p but let undefined works fine
16:57
<bakkot>
just not at the top level of scripts because it's a global non-configurable property
16:58
<Anthony Bullard>
Seems like there are not. https://github.com/tc39/how-we-work/pull/127
17:01
<Anthony Bullard>
Of course it's written in the one popular framework I haven't used in 5 years
17:02
<Anthony Bullard>
yulia: Temp check question would be adding an item to the queue for a temp check, but the temp check ui also displaying the question?
17:04
<yulia>
temp check ui showing the question
17:05
<yulia>
so, the chair would need to enter it
17:09
<yulia>
right now non-chairs can't start a temp check
17:13
<Anthony Bullard>
Gotcha
17:14
<Anthony Bullard>
Let me fork, clone, and learn Vue real quick and hopefully we can have this ready for the Seattle meeting
17:36
<rbuckton>
just not at the top level of scripts because it's a global non-configurable property
That would never be disposed, because it never goes out of scope.
17:38
<bakkot>
That would never be disposed, because it never goes out of scope.
sorry, that was re: let undefined failing if you just type it in the console because it's attempting to redeclare a non-configurable global property, not about using
17:39
<rbuckton>
Ah, my bad.
17:46
<rbuckton>
ok. so if syntax is async using, no need to ban await?
We might need to ban async using in other places instead. See https://tc39.es/ecma262/#prod-ForInOfStatement, which needs to ban async of because async of => {} is a legal arrow. async using would potentially require a complex cover grammar to deal with similar cases.
17:48
<bakkot>
are there any contexts in which async [no lineterminator here] using is currently legal?
17:48
<bakkot>
other than the horrible async arrow one
17:49
<littledan>
within double quotes!!!
17:49
<littledan>
or a regexp
17:49
<rbuckton>
I would be happy to ban yield and for that matter also undefined, as long as we're banning stuff
I'm less concerned about yield because I don't see a using yield declaration being a thing.
17:49
<rbuckton>
or a regexp
or a method name.
17:49
<bakkot>
ah, yes, method names also
17:50
<bakkot>
I think the async arrow case is the only one likely to be problematic, but that one would be a problem, certainly
17:50
<rbuckton>
Where as using [no LineTerminator here] await isn't legal anywhere outside of string/regexp literal contexts.
17:54
<shu>
please don't make me write a bunch more string comparisons on every binding identifier parse :(
17:54
<bakkot>
what about only the binding identifier parses in using declarations
17:54
<shu>
cycles are precious and come dear
17:54
<bakkot>
i mean how many of those can there be
17:55
<shu>
that's a new feature so we can start with a lower bar
17:55
<shu>
can't break people's expectations if we start super low!
17:55
<ryzokuken>
https://www.w3.org/2023/01/pressrelease-w3c-le-launched.html.en
18:00
<ljharb>
https://tc39.es/proposal-async-explicit-resource-management/#sec-suppressederror
18:14
<ljharb>
 * waldemar: note i'm not talking about suppressed, which is the suppressed error, i'm talking about error, which is the cause of the suppression (re your queue item)
18:14
<rbuckton>
I should have clarified re: https://github.com/tc39/proposal-explicit-resource-management/pull/140 whether it requires consensus. Given the algorithm changes in ForBodyEvaluation and CreatePerIterationEnvironment are essentially no-ops, removing them has no observable effect on runtime semantics.
18:19
<bakkot>
am warming up to the option of prohibiting '.cause' on SuppressedErrors - I think it's a conceptual mismatch for SuppressedError
18:19
<ljharb>
i'm still not clear on why it's not a cause when we all keep describing it as the thing that caused the suppression
18:19
<bakkot>
(i.e., read the options bag and throw if it's a present)
18:20
<bakkot>
it doesn't cause the suppression - the use of the syntax causes the suppression
18:20
<ljharb>
in using, sure. but not necessarily in every use of SuppressedError
18:20
<bakkot>
that's the only use of SuppressedError
18:21
<ljharb>
in the spec, but this is something users will use separately
18:21
<bakkot>
ok but it is a mismatch for the only case it gets used in the spec, so it's bad fit
18:21
<bakkot>
even if users might do a different thing where it would get used in a different way
18:21
<shu>
ljharb: perhaps you're thinking of "cause" to mean "caused mechanically the SuppressedError to be created and thrown"
18:21
<ljharb>
yes, that's what i'm thinking of
18:22
<ljharb>
the cause is what caused the SuppressedError
18:22
<shu>
whereas waldemar and kevin (and myself) think of "cause" as, like, the conceptual reason of an error
18:22
<ljharb>
which in the case kevin mentioned is a SyntaxError, right?
18:23
<shu>
yes, what ron is saying right now
18:23
<shu>
it is not a linear relationship
18:23
<shu>
the core disagreement i think is how do developers understand "cause"
18:23
<shu>
is it this linear causality chain, or is it a simpler "whatever effected it to be thrown mechanically"
18:24
<ljharb>
i would argue the latter
18:24
<shu>
yeah so far we've had folks on both sides
18:24
<bakkot>
I think the only acceptable use for "cause" is "we hit an error condition because of a prior error condition", and that is not what it means here - here it is "we had an error, and then a different error which would prevent surfacing the first one"
18:24
<rbuckton>
I think the fact there is such disagreement is evidence of reusing cause being confusing.
18:25
<ljharb>
to be clear my core motivation here is "it should not be possible to have an error that has two potential conceptual causes - .error and .cause"
18:25
<ljharb>
there are some good argument being made that .cause may not be right to replace .error
18:25
<ljharb>
but that still doesn't mean it makes sense to have an error instance with all of cause/error/suppressed
18:26
<rbuckton>
error is not the "cause", neither is supressed the "cause". My use of the term "causes a suppression" does not imply cause in this case, it implies the cause of a behavior.
18:27
<rbuckton>
to be clear my core motivation here is "it should not be possible to have an error that has two potential conceptual causes - .error and .cause"
SuppressedError does have two conceptual causes. I'm more in favor of banning cause because it results in three conceptual causes.
18:27
<ljharb>
sure, i can accept that reframing
18:29
<HE Shi-Jun>
My understanding is cause should be used by developers to specify the low-level "cause" of a high-level error. So SuppressedError is not the case.
18:32
<rbuckton>
shu: We don't use arguments.length, we generally use "not present" as in AOs.
18:32
<shu>
no we actually check arguments length in some places
18:32
<shu>
like Array#splice
18:32
<shu>
it is cursed
18:32
<shu>
i hate it
18:33
<rbuckton>
Ah. I was looking at reduce/reduceRight as an exemplar
18:34
<bakkot>
tbc I'm fine with the status quo also but very mildly prefer removing InstallErrorCause
18:35
<Ashley Claymore>
Seems a little odd to not support it silently. but maybe ok. Can't imagine people using this constructor directly very often
18:35
<shu>
yes the silent nop is weird
18:35
<shu>
but also convinced it doesn't matter in practice
18:36
<Ashley Claymore>
Please could someone add a summary to the notes
18:36
<bakkot>
error conditions in error constructors are kind of painful
18:36
<rbuckton>
Its the nature of the language. Even before { cause } was supported anyone could pass that into an Error constructor without issue, they just wouldn't get the benefit.
18:36
<HE Shi-Jun>
I think I don't understand the result of removing InstallErrorCause, what's the difference?
18:36
<shu>
tru nuf
18:36
<rbuckton>
error conditions in error constructors are kind of painful
See new AggregateError()
18:37
<rbuckton>
Only throws because undefined isn't iterable.
18:37
<bakkot>
HE Shi-Jun: the consequence of removing InstallErrorCause is, the options parameter is ignored, so if you do new SuppressedError('foo', null, null, { cause }) the cause property is not read or installed on the resulting error
18:37
<rbuckton>
(compared to other native errors, most of which check for undefined for things like message).
18:38
<bakkot>
it's only relevant if you're attempting to construct a SuppressedError manually
18:38
<Ashley Claymore>
Please could someone add a summary to the notes
bump...
18:38
<rbuckton>
I primarily added InstallErrorCause to SuppressedError for consistency with other native errors. Not having it is not an issue to the proposal.
18:39
<HE Shi-Jun>
HE Shi-Jun: the consequence of removing InstallErrorCause is, the options parameter is ignored, so if you do new SuppressedError('foo', null, null, { cause }) the cause property is not read or installed on the resulting error
ok, it's a little weird to ignore cause, but i guess it's harmless?
18:42
<rbuckton>
Process question: Does the above change I mentioned in my update before the break need consensus?
18:42
<bakkot>
Oh, I forgot to mention we'll be cutting the next annual edition of the spec shortly
18:43
<shu>
oh yeah
18:43
<ljharb>
presumably after this week's stage 4s are merged
18:43
<bakkot>
rbuckton: I generally think changes with no observable changes do not require consensus
18:44
<ljharb>
agree, if it's not observable then the only folks you may want to check with first are the editors :-)
18:46
<bakkot>
other advantage of removing cause from SuppressedError - browsers don't have to figure out how to render it
18:46
<shu>
diverging paths bro
18:46
<shu>
a slider that has notches at each suppression point, that branches into a different slider
18:51
<littledan>
ohhh maybe we did async generators wrong, I remember debating this around
18:52
<littledan>
well, I think Kevin (zenparsing) had good reasons for all the details he chose
18:53
<rbuckton>
ljharb: I created https://github.com/tc39/proposal-explicit-resource-management/issues/147 to track the consensus change to SuppressedError
18:53
<ljharb>
rbuckton: ok, i'd already filed https://github.com/tc39/proposal-explicit-resource-management/pull/146 :-)
18:54
<rbuckton>
Ah, I put together a PR as well. Thanks
18:55
<littledan>
wait isn't it technically possible to do a reentrant .next() call with sync iterator helpers? (not sure what that would do but you can construct it)
18:55
<ljharb>
i definitely think it is
18:55
<ljharb>
i was going to comment that but realized that wouldn't be the consumer calling next twice, so it probably isn't relevant here
18:56
<ljharb>
it successfully nerdsniped me for a few minutes tho
19:08
<Michael Ficarra>
we could add an agenda section ahead of the other proposal-related items for demotions only
19:08
<Michael Ficarra>
so that they are not only called out but also prioritised
19:09
<shu>
why do we need a new section
19:09
<shu>
could just order it ahead of others by convention
19:09
<shu>
as we order stuff by convention now
19:09
<ljharb>
i'd hope it's not so frequent that a section is needed
19:09
<Michael Ficarra>
sure, we could change the ordering rules also
19:09
<Michael Ficarra>
they're just already complicated enough that they are often broken
19:10
<bakkot>
well, I think Kevin (zenparsing) had good reasons for all the details he chose
as a historical note, one of the relevant details (yield being yield await) was decided in later and Kevin was in favor of a different option than we went with (in https://docs.google.com/presentation/d/1U6PivKbFO0YgoFlrYB82MtXf1ofCp1xSVOODOvranBM/edit#slide=id.g223fba4116_0_155 - he wanted option 2)
19:15
<littledan>
yeah, I remember that discussion. I guess if we went the other way, then async generators would be more parallel by default.
19:15
<bakkot>
yeah, a little bit
19:15
<bakkot>
only if you yield'd a promise though
19:16
<littledan>
oh so it wouldn't quite be enough for the semantics you're proposing?
19:16
<bakkot>
right
19:16
<bakkot>
or, well, you could get to the semantics I'm proposing, but you basically wouldn't be able to use the await syntax
19:17
<bakkot>
like in map, you wouldn't be able to do for await (item of inner) yield fn(item) because that would do at most one call to the underlying iterator at once (because for await is sequential)
19:18
<littledan>
right
19:18
<bakkot>
you'd have to do like yield inner.next().then(p => p.done ? { done: true } : Promise.resolve(p.value).then(fn).then(value => { done: false, value}))
19:18
<bakkot>
which, like, not much point to having syntax at that point
19:19
<littledan>
the iterator protocol is to scary to contemplate this
19:20
<jasew>
We definitely had conversations about another repo, I believe it exists.
19:20
<bakkot>
https://github.com/js-temporal/proposal-temporal-v2 I think
19:20
<jasew>
Yep
19:30
<shu>
littledan: i didn't understand if philip was proposing allowing truncation or requiring truncation
19:30
<shu>
if requiring truncation to microsecond then there's no compat matrix, but that's still kinda weird?
19:33
<ryzokuken>
IIUC, pdunkel's proposal was to underspecify the underlying data model and specifying the interface with nanoseconds so that implementations could change the data model in the future, it just being an implementation detail at that point.
19:33
<shu>
then that sounds like a compat matrix and i share dan's concerns
19:33
<shu>
we remain unconvinced by the use cases
19:34
<ryzokuken>
for including precision higher than microseconds?
19:34
<shu>
yes
19:35
<shu>
ryzokuken: longish discussion here https://github.com/tc39/proposal-temporal/issues/1700#issuecomment-896368225
19:36
<shu>
our previous position was "maybe we can live with it" but upon rediscussion and scoping out work for eventually shipping temporal, using int64s is something we really want
19:44
<littledan>
littledan: i didn't understand if philip was proposing allowing truncation or requiring truncation
either way it sounds like a bad idea?
19:44
<littledan>
presumably requiring truncation would be to enable an evolution path which later doesn't require it (or requires non-truncation)
19:45
<shu>
i agree it's not a good idea
19:45
<shu>
but i'm not gonna die on that hill if that's the compromise?
19:52
<Michael Ficarra>
how could ID be an initialism? what is the D?
19:52
<ljharb>
identity document
19:52
<Michael Ficarra>
wow, TIL
19:53
<ljharb>
but it's also that outside of programming, it is always id or ID and never Id (which is the freudian concept when at the start of a sentence)
19:53
<littledan>
but i'm not gonna die on that hill if that's the compromise?
sure, me neither
19:53
<ljharb>
in my experience getElementById is one of the most "gross" naming conventions i've heard folks complain about on the web behind XMLHttpRequest and "referer"
19:54
<shu>
i like Id
19:54
<jasew>
Id is consistent with DOM naming which is an environment this will be used.
19:55
<ljharb>
afaik it's just the single function, unless there's more i missed
19:55
<ljharb>
and nowadays folks use querySelector instead of the older getElementBy* functions
19:55
<rbuckton>
IIRC, "referer" isn't a naming convention, per se, but a typo we are stuck with.
19:55
<Michael Ficarra>
I'd always assumed it was an abbreviation for "Id-entity", not a titlecasing of "ID"
19:56
<jasew>
Michael Ficarra: I think it is
19:58
<ljharb>
it's also been part of the airbnb style guide for a long time (not a part i authored) and nobody's complained about the requirement, ftr https://github.com/airbnb/javascript#naming--Acronyms-and-Initialisms
19:59
<Michael Ficarra>
ljharb: that doesn't cover abbreviations like "Id" though
19:59
<ljharb>
fair point, not even in the examples
20:00
<ljharb>
i don't think it's really an abbreviation at this point tho, any more than "email" is.
20:00
<Michael Ficarra>
I mean, are you arguing that it's its own word now? Because that would have the same capitalisation
20:00
<ljharb>
at any rate i feel very strongly against "Id" but "identifier" or "code" seem fine to me
20:01
<littledan>
sorry for jumping in outside of the queue
20:04
<littledan>
Chris de Almeida: For the timezoneId/calendarId issue, see this thread https://github.com/tc39/proposal-temporal/issues/1808#issuecomment-1373987231
20:04
<littledan>
(not sure what the most representative comment is, but scroll up and down from there)
20:06
<bakkot>
it's also been part of the airbnb style guide for a long time (not a part i authored) and nobody's complained about the requirement, ftr https://github.com/airbnb/javascript#naming--Acronyms-and-Initialisms
more relevant precedent I think is the w3c rules: https://w3ctag.github.io/design-principles/#casing-rules
20:07
<eemeli>
Given the immediate context of "timeZoneId", I see the capitalization of "Id" as a result of using camelCase, and therefore completely fine.
20:07
<bakkot>
"Initialisms in APIs: All caps, except when the first word in a method or property, for example HTMLCollection, innerHTML, bgColor"
20:07
<ljharb>
timeZoneId is also something i dislike.
20:07
<bakkot>
but "Id" is not an initialism so
20:07
<ljharb>
and yes, but we're not bound by the w3c principles, and in this case i think they result in less clear names
20:07
<ryzokuken>
it specifically mentions Id
20:08
<ljharb>
yes, i know w3c does
20:08
<ljharb>
it doesn't change my opinion
20:08
<ryzokuken>
apologies, I just found out about this doc and was just exclaiming
20:09
<bakkot>
while I do not exactly consider myself bound by these rules, I am not going to want to deviate them without very, very strong reason
20:09
<ljharb>
sure, a number of folks seem unwilling to provide consensus for ID. that's fine, but i'm not willing to provide it for Id.
20:09
<ljharb>
but identifier and code seem perfectly workable
20:09
<shu>
isn't that what they're named now
20:09
<ryzokuken>
either way, it's definitely a document that affects us more strongly than everything else I see so far
20:09
<shu>
Id i mean
20:10
<ljharb>
the accessor is .id and the property is .calendar, and one proposal changes that to .calendarId. if there's already .timeZoneId then i missed it, and i can't prevent that one, obviously.
20:11
<shu>
i don't hear an argument from you jordan
20:11
<shu>
i hear "i don't like it"
20:11
<ljharb>
i find it confusing, and decades of complaints from random devs on irc/slack/etc complaining about the capitalization of the three things i mentioned reinforces my belief
20:11
<ryzokuken>
if timeZoneId already exists, that's an even compelling reason... I'd be against anything other than calendarId in that case for internal consistency.
20:12
<ljharb>
unless we also changed timeZoneId to match whatever else is chosen
20:13
<ryzokuken>
i find it confusing, and decades of complaints from random devs on irc/slack/etc complaining about the capitalization of the three things i mentioned reinforces my belief
is that really a problem lately with modern tooling/autocomplete?
20:13
<ljharb>
yes, it's about readability
20:14
<bakkot>
I really think id is the right name here
20:14
<bakkot>
or calendarId etc
20:15
<rbuckton>
I concur with Id. Id is not an initialism, its an abbreviation.
20:17
<rbuckton>
ID is like using STATS rather than Stats as the abbreviation for "Statistics"
20:19
<shu>
we need a reasonable argument for lone objections, i.e. "i understand but disagree"
20:19
<shu>
AFAICT no other delegate considers jordan's objection here reasonable
20:19
<ljharb>
my argument is already stated: i think "Id" is confusing and i would prefer to avoid confusion
20:19
<shu>
so i really do not understand what more deliberation can get us
20:19
<shu>
that is not an argument!
20:20
<shu>
that is "i don't like it"
20:20
<rbuckton>
Though I think Jordan was advocating for using calendarIdentifier and timeZoneIdentifier vs choosing Id or ID.
20:20
<shu>
and sure we make decisions based on "i don't like it" all the time
20:20
<shu>
but this is so very clearly onesided
20:20
<shu>
and you are wasting time
20:20
<Justin Ridgewell>
calendarId is fine, please let's not waste more committee time on a capitalization debate
20:20
<rbuckton>
which is, unfortunately, just another color to paint the bikeshed :(
20:20
<Justin Ridgewell>
This is a very poor reason to be a lone blocker
20:20
<Ashley Claymore>
css should have been colour
20:21
<shu>
i have a concrete next step here as well
20:22
<shu>
so as to break the logjam: i remain convinced calendarId is the right name, and i will ship with that name, as a willful violation if need be, (unless, of course, a reasonable counterargument is given)
20:24
<Chris de Almeida>
I hate Id and everyone that uses it is WRONG, but I've long since put down that sword and use it under duress
20:25
<Chris de Almeida>
calendarID > calendarId > calendarCode so if we can't have the first, then go to the 2nd
20:26
<rbuckton>
In English, ID (as in, "show me your ID") is an initialism, not an abbreviation, for "Identity Document", https://en.wikipedia.org/wiki/Identity_document, if that matters.
20:26
<ljharb>
so as to break the logjam: i remain convinced calendarId is the right name, and i will ship with that name, as a willful violation if need be, (unless, of course, a reasonable counterargument is given)
so we’re just abandoning pretense of equality between browsers and non-browser participants of tc39?
20:26
<pipobscure>
In English, ID (as in, "show me your ID") is an initialism, not an abbreviation, for "Identity Document", https://en.wikipedia.org/wiki/Identity_document, if that matters.
And Id is the abbreviation for Identifier or Identity
20:27
<Kris Kowal>
It’s also the dual of ego.
20:27
<rbuckton>
Precisely. Though id is a psychological term.
20:29
<shu>
ljharb: not at all. i believe some action is needed than continuing bikeshedding on the name
20:29
<rbuckton>
Unfortunately, ID vs Id is a very long-running debate. I lean on the side of ID makes sense if you're using SCREAMING_SNAKE_CASE (e.g., for constant values), because you are capitalizing every letter, while Id should be what you use for camelCase/PascalCase identifiers.
20:30
<ljharb>
and a perfectly reasonable option is “identifier or code”. Let’s just do one of those - i don’t want to argue about it either, but that doesn’t mean i want to concede.
20:30
<shu>
and if you think my trying to make progress on a name bikeshed is equivalent to discarding all non-browser participants' opinions, i don't know what to tell you
20:31
<ljharb>
i think that any claim of intending to ship a willful violation that disregards consensus is a dangerous precedent to set, and isn't worth buying a few weeks or months of a faster decision.
20:32
<Chris de Almeida>
does it matter that there's already precedent for Id in the spec?
20:33
<rbuckton>
I would say yes. What is the precedent?
20:34
<ptomato>
I didn't think there was any precedent in ECMA-262 or ECMA-402
20:34
<Chris de Almeida>
https://tc39.es/ecma262/#prod-SingleNameBinding
20:34
<rbuckton>
The current ECMA-262 spec uses timeZoneIdentifier in AO arguments.
20:34
<Chris de Almeida>
2. Let lhs be ? ResolveBinding(bindingId, environment).
20:34
<Chris de Almeida>
i. Set v to ? NamedEvaluation of Initializer with argument bindingId.
20:34
<littledan>
heh I don't think spec-internal things count
20:34
<rbuckton>
Yeah, unfortunately I concur. The spec is inconsistent in naming in many places.
20:35
<bakkot>
spec-internal names are terrible
20:36
<bakkot>
lots of single-letter variables, I think in at least one place with both _C_ and _c_ in the same algorithm
20:36
<rbuckton>
If it helps, not only does the DOM use Id capitalization, so does NodeJS.
20:37
<rbuckton>
https://nodejs.org/dist/latest-v19.x/docs/api/async_hooks.html#async_hooksexecutionasyncid
20:38
<Chris de Almeida>
sure... Id convention is fairly standard in many languages and libs
20:38
<shu>
i think that any claim of intending to ship a willful violation that disregards consensus is a dangerous precedent to set, and isn't worth buying a few weeks or months of a faster decision.
if only i believed that a sensible compromise was possible. but practically speaking there is definitely time, chrome isn't going to ship in a few weeks or even months
20:38
<rbuckton>
so the two largest JS ecosystem conventions use Id fairly consistently.
20:39
<shu>
i can temper my response as "by shipping time, if there isn't consensus, i'm going to ship calendarId instead of let that block shipping Temporal"
20:39
<rbuckton>
NodeJS isn't entirely consistent on how they handle initialisms, but Id seems fairly consistent.
20:40
<jasew>
If it helps, not only does the DOM use Id capitalization, so does NodeJS.
Yeah @rbuckton that was my argument, the ecosystem (whether web or server side) are already using that capitalisation, theres quite large precedent for it already.
20:48
<Chris de Almeida>
it does seem like a foregone conclusion doesn't it? I must say I have a hard time understanding the controversy
20:50
<littledan>
cleaning up the notes, I'm just sort of shocked how reasonable we all sound, and how we're making clear logical arguments on all sides. I sometimes get caught up in the emotions in the moment and lose track of that! And it's been amazing to work with the transcriptionist--when I was helping with notes, there was so little to fix.
20:50
<littledan>
like, how do we all make such interesting coherent comments improvised? We're pretty good!
20:51
<ryzokuken>
I was wondering how it must feel like to transcribe a meeting like ours
20:51
<ryzokuken>
with no context whatsoever
20:54
<littledan>
well, I think they were reading our corrections and getting better over the course of the meeting
20:54
<littledan>
anyway it'd be great to get more feedback from everyone, especially people correcting notes, on the transcriptionists this time
20:55
<ljharb>
i appreciate the tempering
20:56
<bakkot>
my feedback is that I love the transcriptionists
20:56
<bakkot>
notes require much less work to fix, and also I don't have to run the bot
20:56
<ljharb>
it's so much better. there's always going to be tiny things to polish but none of that detracts from how much better the experience is with the transcriptionist.
21:11
<HE Shi-Jun>
And Id is the abbreviation for Identifier or Identity
At least wikipedia article also use ID as the abbr for identifier or identity ( https://en.wikipedia.org/wiki/Identifier )
21:48
<bakkot>
re: notes, I do hope we can fix up the linebreaks before publishing
21:48
<bakkot>
that's the main thing I would want to change
21:53
<littledan>
Yeah, I'll definitely be in touch with the firm to see if we can get that fixed before next meeting (and I'm fixing the line breaks for the topics where I presented)
21:55
<bakkot>
That, at least, we can probably handle with a very small script
21:55
<Justin Ridgewell>
Yah, I was thinking a regex could convert the line breaks into paragraphs
21:56
<littledan>
there's often duplicated words (or small corrections) on subsequent lines
22:11
<shu>
actually even more, i'm going to walk back chrome unilaterally doing anything with a willful violation. the right next step on my end, in the case of no TC39 consensus, is an HTML spec PR to document the willful violation
22:11
<shu>
if other browsers have concerns, then we'll hash it out there, as interop is still paramount at the end of the day, but the Id spelling is definitely the right one to use on the web platform
23:58
<bakkot>
c++ apparently considering pipeline, directly referencing the JS proposal https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2672r0.html