notes VS proposal-record-tuple

Has anything changed recently? The proposal has been in stage 3 since November 2022 [1]

[1] https://github.com/tc39/notes/blob/HEAD/meetings/2022-11/nov...

If you're curious about the naming scheme (it now goes 0 -> 1 -> 2 -> 2.7 -> 3 -> 4), then you can read the discussion surrounding the name from the last meeting notes [1].

Also, for a quicker digest, Rob Palmer (from the committee) tweeted about it [2]

[1] https://github.com/tc39/notes/blob/main/meetings/2023-11/nov...

Dialog for this update is at https://github.com/tc39/notes/blob/main/meetings/2023-03/mar...

What I would like is a "use: 'typechecked'" at the top of the file indicating that the code has already been checked. This would be accompanied by a new proprosal that defines a standard for what is considered checked (for example checking nullablity in the types) and would allow for browsers to make some optimizations. This could also perhaps reduce the amount of necessary runtime checks such that it would be possible to make it a fully sound typesystem with most of the checks done beforehand.

All the meeting notes are recorded here: https://github.com/tc39/notes/tree/main/meetings. You’ll have to do a bit of spelunking in the corresponding agendas and proposal repo to narrow down the exact meetings you’re interested in.

Here's a list of delegates for TC39, but it doesn't list people by their ECMA member organization.

This is a good question. I'm not sure I saw the notes of the meeting when this happened, but all the notes are public here: https://github.com/tc39/notes/tree/master/meetings

TC-39 is a group of people who are responsible for the standards. They have meetings every two months with member-appointed delegates and invited experts. You can check the minutes of those meetings here GitHub repository

relevant issue, which is at the crux of this problem: https://github.com/tc39/proposal-record-tuple/issues/387

There are still so many basic things that aren't in the JS stdlib, though. A good example is Map - if you need to use a tuple of two values as a key, you're SOL because there's no way to customize key comparisons. Hopefully we'll get https://tc39.es/proposal-record-tuple/ eventually, but meanwhile languages ranging from C++ to Java to Python have had some sensible way to do this for over 20 years now.

If you’re reaching for structuredClone, what you really want is native immutable Record and Tuple syntax, and the companion “deep path properties” syntax which allows for efficient and ergonomic immutable updates:

- https://github.com/tc39/proposal-record-tuple

It will be called "record" in JavaScript which will swing the popularity back the other way I guess (currently a language proposal)

I suspect considering the strong desire to maintain consistency with JavaScript, we will eventually see something that when the Record proposal passes through tc39

I hope the Record and Tuple proposal makes it through

I mean, I'd love some real immutable/persistent data structures in JS by default, or even some Immer-like syntax sugar. Something like the record/tuple proposal would be awesome.

This will become very useful once Records and Tuples are a thing, because it allows you to store object references in a record/tuple (which by definition can only contain primitives).

Record and tuple is at stage 2

Also, js has an ongoing immutable value data types proposal.