Speaking of error messages, one suggestion I'd have for the committee: a standardized way for the spec to provide hints to implementers about error messages, and guidelines for proposal authors for when to provide those hints in the spec. Proposal authors (especially if the proposal's polyfill gets a lot of use) have a lot of tribal knowledge about the requirements for error messages, but AFAIK there's not really an "official" way to convey that knowledge to implementers. Nor is there a requirement that proposal authors think through the "how are users likely to misuse this API and what should the error message say to help them?" problem. I don't think that implementers should be required to use any particular error message, but IMO having more clarity and consistency in error messages across implementations seems like a good idea, both to help users and to avoid inevitable churn from bug reports asking to improve error messages after the implementation ships. Also, implementers may not have insight into the kinds of bugs that users will run into, so they may not be in the best position to write the most helpful error message text without getting those bug reports.

I'm not proposing any specific solution, but did want to highlight the problem and see if there was any existing prior art on the committee around this issue.

We'll plan to spend our overflow time tomorrow focusing on this question. Reading the replies above, I believe that there are three possible solutions:

1. .round({}) is allowed (and does nothing), but .round() throws.
2. Both are accepted and do nothing.
3. Both throw.

The current Temporal Stage 3 proposal uses (3). There were two reasons the champions selected (3): first, because it's a no-op and likely a programmer bug, and second for defense against typos in the property name like .round({smalestUnit: 'second'}) which would be treated the same as .round({}). (Sadly there's no typo defense for optional property names without breaking extensibility, but our opinion was that preventing at least some bugs was better than preventing no bugs.)

One request I'll relay from ptomato: this proposal is already in Stage 3, so we'd ask for there to be a really persuasive case to change the existing plan of record. The default should be that we stick with what's already been approved, because we really want to get this API shipped soon!

shu : is ftang in the loop for all these normative changes and bug fixes?
ptomato: yes, he found most of them, but I am pretty sure he read the slides as well. I'll double check at the next Temporal meeting

We also implemented the following process:

• PRs that affect the spec text are marked with a spec-text label in GH https://github.com/tc39/proposal-temporal/pulls?q=is%3Apr+label%3Aspec-text
• PRs that don't affect the spec (e.g. changes to docs, polyfill, tests, build tools hell, etc.) are marked no-spec-text
• PR authors who forget to put the right label on (prime suspect: me, usually!) will be publicly embarrassed and a maintainer will quickly add the right label.

I'll leave it to Frank and other implementers to say whether it's actually been helpful in cutting down the noise, but anecdotally I've been hearing fewer complaints since we started doing this so 🤷.

var a = '1'
delete a;
function z() { 'use strict'; a }
z()

I got it.

a = '1'
delete a;
function z() { 'use strict'; a }
z()

Ok, I always interpret "why we need placeholders" as "why just primitives isn't enough" 😅

We have https://github.com/tc39/proposal-record-tuple/issues/206 where we discussed about explicit/implicit boxing

One was it's a footgun, and a user might mistakenly put mutable data where they didn't expect it

Boxes don't really help that, since #[foo()] may or may not be a box and so may or may not be mutable. Also boxes are super complicated so it seems like there's at least as much possibility for footguns there

Existing code assumes that if something is a primitive, it doesn't contain object which represent authority.

But boxes are primitives which contain objects; this argument confuses me

• what's already been said about not knowing the return type of foo()

But boxes are primitives which contain objects; this argument confuses me

But you need access to the ObjectPlaceholder to get to the content, so they are not a risk on their own

2 main reasons:

• Leaking issues with well-known and registered symbols
• Box is an explicit marker of intent, where symbol can be just other data. You don't need knowledge about the structure to understand what it means

Over the break I read and reread RepeatMatcher, but I don't think I'm incorrect in my understanding of backtracking. For /\n+$/.test("\n".repeat(100_000) + "b") we end up in a stack 100,001 calls to RepeatMatcher deep before we (a) fail to match an \n and then (b) fail to match the end of the buffer. We then unwind the stack, attempting to match the end of the buffer for each entry on the stack. This means we test for $ at offset 100,000, then at 99,999, then 99,998, etc. until we fail at offset 0 (matching no \n characters).

Now that this has failed, we advance to the next index in RegExpBuiltInExec, and do it all over again.