Can I use?

[mikeal]

Been waiting for this for a long time, am pretty bottlenecked right now on how well I can write new cryptography in JavaScript until this lands in at least v8.

This doesn’t seem to be progressing at the pace far less meaningful language additions seem to make it in. Any thoughts on what is taking so long and anything I can do to help? Most of the beneficiaries of this are uninvolved in standards but if it helps to get more people involved I can do that.

[acutmore]

Hi @mikeal,

Would you be able to provide some details on how you are hoping to make use of R&T?

With the latest feedback we have received from the committee we will need to make changes to the design before next attempting to move forwards.

The more use-cases we have to draw from the better we can measure how well different designs meet different use-cases.

[mlanza]

Well, one use case is doing ClojureScript in JavaScript, as I've been doing for many years now. ClojureScript provides maps and vectors instead of objects and arrays. Apart from Immutable.js, JavaScript lacks these.

As you know, until records and tuples there were no value type counterparts to objects and arrays. Therefore, I've pretty much been using objects and arrays as if they were records and tuples. That is, as a rule of discipline, I write only pure functions against them. So Imagine using the ClojureScript paradigm in JavaScript but without maps and vectors.

When records and tuples finally arrive, I can finally cease this practice. I'm thrilled to know records and tuples are on the horizon! I too have been eagerly anticipating their arrival as this will only improve what I've been doing.

[acutmore]

Thanks for those details @mlanza!

When records and tuples finally arrive, I won't have to employ this practice anymore. I'll be able use records and tuples instead of objects and arrays as value types and allow objects and arrays to be treated as reference types again.

If Records and Tuples were still reference values (=== compares them by reference) but there was a static helper function RT.equal(a, b) (hypothetical name) would this still be useful for ClosureScript? I could imagine (== a b) compiling down to JavaScript that uses a mix of both === and and this built in static method to achieve full 'value type' semantics.

[mlanza]

In my library I define protocols (my own version of the proposal for first-class protocols). In it, I define an equivalence protocol so that I can do exactly what you suggest. In effect that protocol treats the reference types as value types. But I'm looking forward to doing this legitimately and not by working around the difference between reference and value types.

In my library I treat objects and arrays as value types using this technique in the large. I break out of using the library when I want to treat them as the reference types they actually are.

[errorx666]

I want to use records and tuples as keys to Maps and Sets for their value comparison semantics.

If Records and Tuples were still reference values (=== compares them by reference) but there was a static helper function RT.equal(a, b)

For me this defeats the whole purpose.

[nmay231]

I want to use records and tuples as keys to Maps and Sets for their value comparison semantics.

Same for me. Particularly for use in describing coordinates as pairs/triplets of numbers. I've resorted to using array tuples of numbers and using .toString() to get something comparable by value.

[acusti]

R&T is the most exciting proposed change to javascript i’ve even seen, and my excitement, though grown dormant from years of waiting, is easily reawakened. my use case, at a high level, is using javascript as a functional programming language. more specifically, i want to use it for:

1. having immutable data structures with ergonomic non-mutating methods for updating them (e.g. const updatedList = list.push('new item')) and for being able to use const and know it means that the variable’s value won’t ever change (const inconstantValue = { x: 1 } vs const constantValue = #{ x: 1 }).
2. for highly performant value equality semantics, e.g. for storing props in a library like react and being able to efficiently avoid unnecessary rendering, or for an immutable state library (e.g. redux) where subscriptions need not be called if the state’s value after an action is dispatched is unchanged. i would prefer this to be made available via ===, but i guess RT.equal(a, b) could be viable. but it will be a PITA to have equality checks that have to do:

const areEqual = (a instanceof Record || a instanceof Tuple) && (b instanceof Record || b instanceof Tuple) ? RT.equal(a, b) : a === b;

though i suppose this theoretical .equal() method, even if it’s a static method on the Record and/or Tuple standard built-in objects, would handle primitive values as well.

[neftaly]

I'd like to talk to workers without the structured clone overhead or sharedarraybuffer burden! I'd also like to do the CLJS interop things, in order to have access to clojure libraries.

[acutmore]

I'd like to talk to workers without the structured clone overhead or sharedarraybuffer burden

You may be interested in https://github.com/tc39/proposal-structs?tab=readme-ov-file#shared-structs

[matthew-dean]

Is someone / a group championing this proposal and moving it forward? I also feel like this is probably one of the more exciting proposals to come to JS in a long time (maybe biggest since modules?) and would "complete" the language in terms of a complete set of immutable values. This would be especially valuable in reactive libraries, like Vue, where the "reactiveness" becomes difficult and unpredictable depending on what type of value is passed to a property.

[acutmore]

Hi @matthew-dean, this proposal was discussed at the most recent TC39 meeting. The notes for that are available here: https://github.com/tc39/notes/blob/main/meetings/2024-04/april-09.md#discussing-new-directions-for-rt

This would be especially valuable in reactive libraries, like Vue, where the "reactiveness" becomes difficult and unpredictable depending on what type of value is passed to a property.

This sounds interesting, would you be able to provide an example?

[matthew-dean]

@acutmore

This sounds interesting, would you be able to provide an example?

My bad, I think this is more strictly a React issue, where props are passed as-is and components do shallow equality checks to see if props have changed. Vue actually wraps all values / props in proxies, and as a result, crawls objects deeply to recursively set proxies in order to detect changes (I think). That said, I feel like that system is not perfect and I had issues setting values when the values are objects, but I can't currently reproduce it. 🤷‍♂️

So, I think the use case for a Record would be in systems where values can be anything, and there's some sort of memoization or "change" detection between values.