TC39 Delegates
2023-11-27
plaintext logs
prev next
source on github
09:23
<sffc>
Hey Jesse I took a look at how other programming languages handle decimal normalization since both those things are subjects of your slide deck. I may have a conflict during the scheduled time for that discussion; I'll try to call in, but you already know my position on the issue of normalization.
https://github.com/tc39/proposal-decimal/issues/89
09:29
<Jesse>
thanks, that's a great contribution! Right, many other languages do support trailing zeros. I appreciate the suggestion to see how the "middle ground" suggestion. I'll continue the discussion in the GitHub issue.
09:30
<littledan>
Do we have a draft schedule yet?
15:01
<Chris de Almeida>
we have a packed agenda, so please be mindful (as well as forgiving if the chairs seem pushy as we approach or exceed timeboxes 🙂)
15:04
<Chris de Almeida>

Ben and Michael Ficarra have topics that are currently in overflow, but we hope to be able to slot those in where possible, so please be on the lookout for messages from chairs

as usual, similar goes for everyone presenting, as we will try to move things forward if time allows, while still respecting constraints

15:05
<littledan>
amazing how the agenda always fills up despite looking empty shortly before the deadline
16:03
<Chris de Almeida>

Ben and Michael Ficarra have topics that are currently in overflow, but we hope to be able to slot those in where possible, so please be on the lookout for messages from chairs

as usual, similar goes for everyone presenting, as we will try to move things forward if time allows, while still respecting constraints

Ben: due to a timebox change, your topic is out of overflow and is now scheduled on Day 4
16:04
<Ben>
Thanks for letting me know!
16:54
<Chris de Almeida>
both overflow topics are now on the schedule on Day 4
17:31
<nicolo-ribaudo>
Thanks chairs for adding "END DAY X" and "LUNCH" to TCQ :)
18:01
<rbuckton>
Hmm. I may also be unavailable in April for the same reason, though I believe we have a hotel so I may be able to dial in.
18:09
<littledan>
Note: Ashley and Ben volunteer for notes all the time; it'd be great to have additional note-takers to relieve them
18:11
<ljharb>
also the Meet apps don't have an "incognito mode"
18:20
<Ben>
Note: Ashley and Ben volunteer for notes all the time; it'd be great to have additional note-takers to relieve them
I'll also have to step out for ~20 minutes after the 402 editor's update
18:22
<Michael Ficarra>
chairs, can we ask Samina to add a link to these slides to the agenda?
18:23
<Rob Palmer>
yes, that will happen
18:24
<littledan>
Note, "New Proposal?" is, WinterCG is looking for a place to publish standards, and I'm proposing Ecma. https://github.com/wintercg/admin/issues/58
18:24
<littledan>
This could be a good way to enable TC39 collaboration with efforts on server-side JS runtimes
18:26
<ljharb>
(please don't use AI for any image designs for legal reasons)
18:26
<snek>
and aesthetic reasons
18:28
<rbuckton>
Here's the other cap design we've used
18:28
<ljharb>
there's a beanie too
18:29
<saminahusain>
rbuckton: both look good.
18:29
<saminahusain>
What would be good to recognize 100th
18:30
<ljharb>
i grab more socks at conference booths than hats or shirts these days :-) but also a windbreaker/jacket would be awesome
18:31
<shu>
(please don't use AI for any image designs for legal reasons)
wait why? i used AI for the old hat logos
18:33
<Jesse>
are we going more in the baseball hat direction, or rather trucker-style?
18:33
<ljharb>
wait why? i used AI for the old hat logos
the old hats were created long before LLMs were commonplace, so i'm not sure what you mean - unless you think i meant adobe illustrator?
18:33
<shu>
yes, i have AI at home, Adobe Illustrator
18:33
<ljharb>
this isn't TDZ :-p
18:33
<ethanarrowood>
are we going more in the baseball hat direction, or rather trucker-style?
trucker please for us big headed folk
18:34
<shu>
are we going more in the baseball hat direction, or rather trucker-style?
the last run we had 3 styles: trucker, "dad cap", and beanie
18:34
<rbuckton>
are we going more in the baseball hat direction, or rather trucker-style?
Hopefully a choice? I have a strong preference for the baseball cap style from a comfort perspective
18:34
<snek>
should probably make a channel for hats
18:35
<ryzokuken 🇮🇹>
or a reflector thread?
18:35
<ljharb>
Jack Works: just installed it, this is awesome thanks
18:35
<saminahusain>
I think 3 styles would be fine. Should I plan for these threetrucker, "dad cap", and beanie
18:35
<saminahusain>
Yes, please a channel for hats would be great.
18:35
<snek>
is this a LSP, can i run it in my vim
18:35
<Michael Ficarra>
oooh this will be super handy
18:36
<Chris de Almeida>
#tc39-swag:matrix.org
18:36
<rbuckton>
This is what I wanted my extension to do, but I haven't had the time to work on it in a long while. This looks great.
18:36
<Jesse>
new channel? this is a full-service channel!
18:36
<bakkot>
is this a LSP, can i run it in my vim
apparently yes!
18:37
<snek>
#tc39-swag:matrix.org
room isn't in the category
18:37
<snek>
oh wait now it is
18:37
<Chris de Almeida>
so impatient
18:37
<Jack Works>
https://marketplace.visualstudio.com/items?itemName=MagicWorks.ecmarkup
18:40
<Jack Works>
is this a LSP, can i run it in my vim
the VSCode extension is made of TMLanguage (syntax highlight JSON), snippets (JSON), language definition (JSON) and a language server (provides hover information and completion)
18:40
<Jack Works>
I believe you can take the tmlanguage (https://github.com/Jack-Works/ecmarkup-language-service/tree/main/extension-vscode/syntaxes), that will highly improve the editing experience
18:44
<Jack Works>
Now all LSP features are based on @tc39/ecma262-biblio and simple string analysis, no real analyze (using ecmarkup/grammarkdown in the backend) support, but I plan to add them. For example I want to make goto definition work for local-defined grammar/AOs
18:46
<Jack Works>
I tried to do real analyze last year, but having some problem with bundling those two libs, and they are not built in an incremental way so the performance is not good. I hope I can have time to improve or reimplement part of them to provide better experience
18:52
<bakkot>
https://github.com/tc39/faq/pull/2
18:52
<bakkot>
^ PR documenting how to resolve disagreements
18:55
<rbuckton>
Now all LSP features are based on @tc39/ecma262-biblio and simple string analysis, no real analyze (using ecmarkup/grammarkdown in the backend) support, but I plan to add them. For example I want to make goto definition work for local-defined grammar/AOs
Grammarkdown has ways to reference other grammars, but doesn't itself parse a full ecmarkup file. I'd love for ecmarkup to generate a grammarkdown .grammar file that is included in ecma262-biblio to make that process easier.
18:56
<littledan>
even if the disclaimer is read and understood, it might not be believed as credible
18:57
<bakkot>
wonder if it might be better to attribute answers to specific delegates? maybe that would be believed?
18:58
<bakkot>
rbuckton: I have an issue for putting the grammar in the biblio https://github.com/tc39/ecmarkup/issues/431 but I either did not know or forgot that grammarkdown had a specific format it used
18:59
<littledan>
wonder if it might be better to attribute answers to specific delegates? maybe that would be believed?
I don't think so either? The community might view each of us (or, worse, just some of us) as authoritative.
18:59
<bakkot>
anyway definitely agreed it would be nice for the biblio to hold the grammar
18:59
<bakkot>
I don't think so either? The community might view each of us (or, worse, just some of us) as authoritative.
that's fair but if people attribute quotes to "a TC39 delegate" instead of "TC39" that would at least be an improvement
18:59
<bakkot>
I don't know if they would, though
19:00
<littledan>
I dunno, it feels like some alleged weasel wording that people at each level would just filter out unless they feel forced to repeat it
19:00
<bakkot>
fair
19:00
<Jack Works>

by the way, can you bakkot add a .d.ts for the Biblio package?
https://github.com/Jack-Works/ecmarkup-language-service/blob/main/language-server/src/biblio.d.ts

It should be something like index.d.json.ts as I know how TS NodeNext should work

19:00
<littledan>
to be clear I like the idea of having a disclaimer--we don't want to let people lawyer their way through to something by citing the FAQ
19:01
<bakkot>
Jack Works: can do; open an issue? (or a PR)
19:05
<ljharb>
https://github.com/tc39/proposal-array-grouping/issues/60
19:11
<littledan>
Great work from @legendecas on the V8 implementation
19:13
<littledan>
What is the current plan for which globals will be included
19:14
<littledan>
(Sorry I cannot access the queue right now)
19:15
<Chris de Almeida>
added to tcq queue
19:18
<littledan>
Great to see this moving forward
19:18
<littledan>
Thanks Leo!
19:23
<leobalter>
Slides added to the TC39 Agenda (I just opened the PR: https://github.com/tc39/agendas/pull/1506
19:24
<leobalter>
What is the current plan for which globals will be included
Thanks for the feedback (cc syg ). I'll focus on that in the next plenary.
19:28
<littledan>
If someone wants to pick up Array.isTemplateTag, it would be a great complement to this proposal, together with trusted types
19:30
<littledan>
Please keep going ptomato
19:30
<littledan>
We heard you well
19:30
<ljharb>
nicolo-ribaudo: that's a case for Function tho, not necessarily eval
19:31
<bakkot>
if you can't hear, reload
19:31
<bakkot>
I have run into this bug with google meet before
19:31
<bakkot>
where it drops the audio feed from a specific person
19:31
<nicolo-ribaudo>
If somebody can ask Philip to screen share yb himself I'll reload and fix my audio
19:32
<nicolo-ribaudo>
If somebody can ask Philip to screen share yb himself I'll reload and fix my audio
Robert Pamely:
19:39
<littledan>
I don’t think what Jordan is saying is aligned with the goals around CSP
19:40
<shu>
i don't think "only direct eval is a problem" is a widely shared web security opinion afaik
19:40
<ljharb>
it very much might not be aligned with CSP's goals, i'm not sure what those are
19:40
<littledan>
It would probably be good to say that for the notes
19:40
<snek>
jordan i don't quite understand like
19:40
<snek>
i mean i understand your want of Function()
19:40
<snek>
but i don't understand how you can distinguish it from eval in any meaningful way
19:40
<ljharb>
i just mean i'm personally concerned when i see use of eval() but not Function()
19:41
<ljharb>
i mean, they're different code paths
19:41
<ljharb>
and eval even has special stuff for direct vs indirect
19:42
<littledan>
Maybe in the future you could be more clear about your goals and that you aren’t talking about the goals of CSP itself
19:43
<littledan>
I agree that direct eval is a terrible extra level of bad but I also like the guarantees of unsafe-eval
19:43
<littledan>
Note that csp also disallows things like inline event handlers, which also don’t see local scope
19:43
<ljharb>
i'm not sure why it's on me to clarify that my goals aren't the goals of others when i'm not claiming to be speaking for the goals of others.
19:43
<bakkot>
I am definitely concerned when I see Function, and you should be too
19:44
<ljharb>
CSP blocks lots of things
19:44
<ljharb>
I am definitely concerned when I see Function, and you should be too
i'd love to understand more about those concerns
19:45
<bakkot>
you have to be really careful to audit that either a) no user-controled code ends up in the call to Function() or b) the result is never invoked, and that is very hard to do in a large web application
19:46
<bakkot>
of course if the argument is static it's fine, which is the point of this proposal
19:46
<ljharb>
fair enough
19:46
<ljharb>
i still wouldn't want eval() in my codebase even with a static string tho, and i'd be fine with having that with Function
19:47
<bakkot>
fine not to want eval with a static string, but that's not a security issue, I would think? more of a linter concern, not something that needs to be banned in the browser
19:48
<ljharb>
fair enough as well
19:56
<Michael Ficarra>
CSP also fails at composition
20:05
<littledan>
CSP also fails at composition
What do you mean by this?
20:13
<bakkot>
littledan: there are some cases where policy A enables one behavior, and policy B enables a second, but no combination of policies can enable both behaviors (other than not using CSP at all)
20:13
<littledan>
Do you have an example?
20:14
<bakkot>
IIRC unsafe-inline plus nonces
20:14
<littledan>
Wow weird, how is that prohibited?
20:14
<bakkot>
mm, maybe I am thinking of unsafe-inline plus strict-dynamic actually?
20:15
<bakkot>
ah, no, both of those
20:15
<bakkot>
here: https://www.w3.org/TR/CSP3/#allow-all-inline
20:15
<bakkot>
see step 2.1
20:15
<bakkot>
it just explicitly checks for nonce sources when determining whether unsafe-inline can be used
20:16
<littledan>
So that might be fixable?
20:16
<bakkot>
nonce sources, hash sources, and strict-dynamic
20:16
<bakkot>
yeah, presumably; on the other hand it was presumably done on purpose
20:58
<bakkot>
(also changing it without introducing a new directive would potentially weaken the security posture of existing pages, which would maybe be bad.)
21:24
<rbuckton>

I'm still generally a fan of an API like:

let bytesRead = Uint8Array.encodeBase64(input, inputPos, output, outputPos, count);

and you use count - bytesRead to determine how much data is yet to be encoded

21:26
<bakkot>
rbuckton: that doesn't give you streaming, unfortunately
21:26
<rbuckton>
it gives the developer more control over buffer sizes for memory-constrained environments, avoids excess allocations, and is consistent with a lot of similar C++ APIs
21:26
<rbuckton>
That specifically gives you streaming.
21:26
<bakkot>
even accounting for the fact that you need to skip over whitespace?
21:26
<bakkot>
whitespace is the thing that has tripped me up here
21:31
<rbuckton>
even accounting for the fact that you need to skip over whitespace?
Fair point, I suppose. In .NET, the streaming API requires state so it has its own class like TextEncoder (https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.tobase64transform?view=net-8.0)
21:38
<rbuckton>
Possibly feasible by splitting the API into two methods, one that normalizes base64 input (removes whitespace, etc.), and one that does the decoding, but it's certainly not as convenient.
21:38
<Michael Ficarra>
I think engines should work on just not making the allocation when it's immediately destructured
21:38
<nicolo-ribaudo>
The reason for this discussion is to avoid two passes
21:39
<nicolo-ribaudo>
Since that's what the proposal was blocked on
21:42
<shu>
it's unclear if that pays off in the general case
21:42
<shu>
whereas the # of web APIs that have that level of performance requirements is very small
21:43
<shu>
and we can probably just design those specially
21:43
<rbuckton>

It would be nice to be able to have multiple return/output values without depending on destructuring. That's one of the things my as-yet-not-presented ref proposal would provide:

let bytesRead;
let bytesWritten = Uint8Array.encodeBase64(input, inputPos, inputLen, output, outputPos, ref bytesRead);
21:49
<Luca Casonato>
Thanks for seeing this one through bakkot
21:51
<bakkot>
don't jinx it!
21:56
<Michael Ficarra>
okay toFixed exists though
22:06
<littledan>
Objective C/Swift also has its own ad-hoc kind of decimal that no one seems to mind
22:19
<littledan>
Sorry for jumping in; will stop
22:22
<littledan>
But, I would kinda appreciate it if Waldemar could just make his point rather than quizzing the presenter
22:22
<Michael Ficarra>
IEEE is normalising though, right?
22:22
<littledan>
No, IEEE explicitly does represent trailing zeroes
22:22
<littledan>
So, normalizing would be sort of subsetting IEEE, just like we are also sort of subsetting by not including a bunch of signaling modes
22:23
<rbuckton>
I'm not sure this Q&A approach is constructive
22:34
<shu>
i am losing the thread of discussion here wrt decimal
22:37
<shu>
i am not hearing an argument for why this should be part of the data model, just that having it in the data model gives you extra bits of info...?
22:41
<littledan>
Yes there are three libraries by MikeMcl, and the design here is better
22:42
<littledan>
But they aren’t adopted broadly enough, and people try to avoid using them with strings or fixed point number usage
22:43
<ljharb>
those usages (that people want to avoid) would still apply with a non-primitive builtin tho, no?
22:43
<littledan>
Sorry what is the connection to primitiveness?
22:44
<ljharb>
i guess it's less about it being a primitive and more about operator overloading - syntax support
22:44
<ljharb>
if i can't write 1.23m * 3m or the equivalent, then i wouldn't think anything we could add would be ergonomic enough to warrant using it
22:44
<hax (HE Shi-Jun)>
I guess people avoid using them because they don't want introduce a heavy lib?
22:44
<ljharb>
iow the java-style API on the slide isn't something i'd want to see us add, nor would i want to see used in a codebase i had to maintain. numbers are too fundamental for a .add() to be reasonable or elegant enough to use, imo
22:47
<ljharb>
the argument does apply that it's a coordination point, but we had a single dominant userland library already for temporal to replace Date, and we had a decade or more of usage to validate the need, and the variety of use cases it supports
22:47
<shu>
sidebar: i want to resist coming to some black and white conclusions here like "batteries included is always a bad rationale" or "tc39 shouldn't try to solve any coordination problems"
22:47
<shu>
these all end up being case-by-case in the end
22:47
<hax (HE Shi-Jun)>
I also hope we can have decimal literal and op overloading but it could be a separate problem. People could use transpilers if they really want.
22:48
<eemeli>
Ashley Claymore: You mentioned a YAML library that came with its own "decimal" type. Was that a real-world example?
22:49
<shu>
why doesn't bloomberg make a library?
22:49
<shu>
it could put its engineering weight behind something that's fast and maintainable and evangelize that
22:49
<hax (HE Shi-Jun)>
Ashley Claymore: You mentioned a YAML library that came with its own "decimal" type. Was that a real-world example?
which yaml lib?
22:49
<ljharb>
it could put its engineering weight behind something that's fast and maintainable and evangelize that
imo that would build a much stronger case for a builtin decimal that lacks syntactic support
22:50
<rbuckton>
One of the best reasons to have a built-in decimal, IMO, was to be able to implement it as a primitive value with operators. The worst part of Decimal in Java is that it's method based.
22:55
<rbuckton>
shu: IIRC, you said in a previous plenary that the effort to add bigint outweighed its benefits for the language, given that the predominant use of bigint so far is cryptocurrency mining. Would that be an accurate characterization? Would higher-precision calculations in Sheets not be enough of a motivator for V8 to consider implementing this as a primitive? Are there runtime optimizations/performance benefits of syntactic decimal math vs method-based math that are worth considering?
22:56
<shu>
bad ROI on BigInts is an accurate characterization
22:56
<shu>
higher-precision calculations in Sheets may be a motivator for me if it's Sheets making the feature request, but it's not?
22:56
<shu>
like, look at Excel
22:57
<shu>
Excel also uses IEEE floating point, and it truncates
22:57
<snek>
we use bigints in discord a lot :)
22:57
<shu>
i'm saying, if you want this to be motivated by a product, the product needs to speak up
22:58
<shu>
gesturing at possible adoption is not compelling in itself
22:58
<rbuckton>
Do you use them for actual math, or as a standin for a numeric string?
22:58
<snek>
we do bitwise math on them
22:58
<bakkot>
I have used a bigint as a bitset once I think
22:58
<shu>
that says we should've added Bitset :)
22:59
<shu>
more than that BigInt was the right call
22:59
<Ashley Claymore>
Ashley Claymore: You mentioned a YAML library that came with its own "decimal" type. Was that a real-world example?
nope sorry, I was trying to turn internal Bloomberg things into more generic terms on the fly. YAML here stands for internal xml based APIs coming from other systems
22:59
<snek>
the only non-bitset operation we do on them can also be done on f64 (shifting right 22 bits)
22:59
<rbuckton>
we do bitwise math on them
IMO, the two main use cases for bigint that aren't crypto are nanosecond precision and 64-bit integer flags/bitmasks, neither of which needed an arbitrarily-sized integer value.
23:00
<bakkot>
(my bitset was > 64 bits fwiw)
23:01
<eemeli>
nope sorry, I was trying to turn internal Bloomberg things into more generic terms on the fly. YAML here stands for internal xml based APIs coming from other systems
Ah, got it. That's what I thought, but wanted to check. For context, I maintain the yaml package on npm and was not aware of such a JS YAML library.
23:01
<littledan>
Note that Jesse has been working on a good library here, having a full JS implementation of the proposal
23:02
<shu>
FYI all i will not be able to attend for the next 3 days, Rezvan will be attending on V8's behalf
23:02
<bakkot>
who else was taking notes? I have a question for other note takers. Ashley Claymore ?
23:03
<rbuckton>
My last question still stands: Could native, syntactic decimal math outperform any given userland library? And if so, by how much (approximately)?
23:05
<littledan>
I think moving towards engaging products is a good direction for TC39. It isn’t something we have done in the past—product discussions have often been treated as out of scope and implicitly discouraged. Ashley described a real product need that we have at Bloomberg, and we can work with survey respondents to more fully develop more of them.
23:08
<rbuckton>
I think moving towards engaging products is a good direction for TC39. It isn’t something we have done in the past—product discussions have often been treated as out of scope and implicitly discouraged. Ashley described a real product need that we have at Bloomberg, and we can work with survey respondents to more fully develop more of them.
I've never heard of such a practice being discouraged, and if it is that seems unfortunate. IIRC, a number of proposals are driven by the needs of large projects. ShadowRealm, WeakRef, Shared Structs, Async Context, etc. are all driven by such a need, I think.
23:09
<littledan>
IMO, the two main use cases for bigint that aren't crypto are nanosecond precision and 64-bit integer flags/bitmasks, neither of which needed an arbitrarily-sized integer value.
We did discuss BigInt vs Int64 at some length while developing things. Int64 introduces quite some additional unfortunate complexity/arbitrary design decisions. And from an implementation standpoint, my understanding was that the difficult part was adding a primitive, not the contents of whether it was big or not
23:09
<rbuckton>
I have seen cases where feedback from these projects has been discounted and ignored, however.
23:10
<littledan>
I've never heard of such a practice being discouraged, and if it is that seems unfortunate. IIRC, a number of proposals are driven by the needs of large projects. ShadowRealm, WeakRef, Shared Structs, Async Context, etc. are all driven by such a need, I think.
No one is explicitly discouraging it, but we also aren’t seeing lots of examples of product-driven presentations. This is why I said it was implicitly discouraged.
23:14
<rbuckton>
We did discuss BigInt vs Int64 at some length while developing things. Int64 introduces quite some additional unfortunate complexity/arbitrary design decisions. And from an implementation standpoint, my understanding was that the difficult part was adding a primitive, not the contents of whether it was big or not
It's unfortunate that the introduction of bigint didn't pave the way for implementations to become more flexible in terms of adding new primitives. IIRC, BigNumber/Decimal/etc. was being discussed at the same time as BigInt, so the potential was already present.
23:15
<rbuckton>
And BigInt followed on the heels of Symbol
23:16
<rbuckton>
IMO, both Decimal and Temporal should be primitive, as they both involve operations that could be better expressed syntactically (+, -, >, <, etc.)
23:20
<ljharb>
also Records and Tuples and shared structs
23:20
<rbuckton>
Though, I have to admit I'm biased, having many years of using .NET, where Decimal and DateTimeOffset/TimeSpan have syntactic operators (DateTimeOffset.Now + TimeSpan.FromMinutes(5))
23:24
<rbuckton>

Or rather:

// C#
DateTimeOffset.Now > start + TimeSpan.FromMinutes(5)

// vs

// JS/Temporal
Temporal.Instant.compare(Temporal.Now.instant(), start.add({ minutes: 5 })) > 0
23:25
<Chris de Almeida>
who else was taking notes? I have a question for other note takers. Ashley Claymore ?
yes
23:31
<Rob Palmer>
IMO, both Decimal and Temporal should be primitive, as they both involve operations that could be better expressed syntactically (+, -, >, <, etc.)
If this is the ideal, why are we accepting of the non-primitive compromise for Temporal?
23:32
<shu>
because... browsers would not ship the primitive version, like with Decimal?
23:33
<Rob Palmer>
Ok, so we are being pragmatic in order to make progress. Fine by me.
23:36
<rbuckton>
because... browsers would not ship the primitive version, like with Decimal?
Can you clarify, do you mean "would not support" or "would not ship even if standardized"?
23:37
<shu>
what is the difference between those two statements?
23:37
<shu>
as in, how did it get standardized, if the browsers do not support it?
23:37
<rbuckton>
That statement seems more definitive than "would not support unless convinced the motivation is sufficient"
23:37
<rbuckton>
"would not ship" has multiple connotations
23:38
<shu>
the general statement is "would not support unless convinced"
23:38
<rbuckton>
Thank you for the clarification
23:38
<shu>
in the specific cases of temporal and decimal, since we have discussed those at length, the answer is "not convinced"
23:38
<shu>
that is, the bar is high
23:40
<shu>
"would not ship" has multiple connotations
okay, right, i'm not supposing a hypothetical where the current TC39 working mode has broken down, and that the browsers continue to do things they've agreed to via the staging process
23:42
<rbuckton>
okay, right, i'm not supposing a hypothetical where the current TC39 working mode has broken down, and that the browsers continue to do things they've agreed to via the staging process
It still bears clarification. Despite being specified, there are parts of the spec that aren't implemented in all runtimes, like TCO, and things that are normative optional.
23:43
<shu>
ah, i see. well, TCO remains a special case as it predates the current staging process.
23:43
<shu>
but normative optional is interesting
23:45
<shu>
my personal take is i don't think normative optionality is a good idea except in very broad strokes, like "browsers have this for legacy reasons", as we use it today
23:47
<rbuckton>
As well as browsers unshipping SAB and disallowing Atomics.wait on the main thread
23:48
<rbuckton>
(both of which are understandable concerns, but are specific to browsers)
23:49
<shu>
yeah i think it's probably actually fine to have some implicit notion of "profiles"
23:49
<shu>
but full-on pick-and-choose normative optionality is harmful imo