Additionally, my understanding is that the opposition to adding new primitives also affects pattern matching, though I'm not sure why. I'm much less up to date on that proposal.
[1] https://github.com/tc39/proposal-record-tuple/issues/387
Could you clarify which part you’re referring to? I’m disappointed at them feeling trepidation after BigInt, but the thread I linked (and some other discussions I’ve seen) make me understand why they’d choose to focus effort elsewhere.
It would be a monumental change and it’s not entirely clear how much of the community outside the React and similar ecosystems would adopt it. It might have significant performance issues for the desired use cases and choices about value semantics would affect usability.
Pipelines, pattern matching and records+tuples have all been in the works for 4+ years, and are all still in stages 1-2. I don't think any of them has seen any significant progress in the past year, except maybe pattern matching. According to an issue in the records and tuples repo, there's been pushback on the value semantics of it (i.e. whether === can be made to work). Dropping value semantics would significantly reduce the whole proposal's usefulness.
I think all of them are at least a year or two away from reaching stage 3, if they ever do. But hey at least we now have array grouping functions.
[0] https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
[1] https://timdeschryver.dev/blog/pattern-matching-examples-in-...
We would all benefit if JS was more like C# in my opinion.
console.log(x = "hello"); console.log(const x = "hello");
e.g.
const a = { b: 1 }
console.log(a.b = 2); // logs 2 let x;
console.log(x = 'hello');
React is a fundamentally flawed framework because of the lack of this feature. It inverts the responsibility of any non-primitive prop by putting the burden on the parent element instead of the child to decide when to rerender things. So elements are no longer self-contained if they receive any non-primitive values (besides react elements).
The React compiler auto-memoization that facebook is pushing also addresses this issue through build-time magic. I not fond of this approach.
[edit: For those who don't know, Dictionary was a type in AS3 that let you use any object reference or string or number as a unique key, with any type of value attached. Garbage collection worked around this so it wasn't a weak reference as long as the dictionary object itself was alive. Think of a Javascript Set except with strongly typed keys of any kind you specified. Errors thrown at compile time. God..I miss that language.]
Record/Tuple objects are immutable primitives with structural equality, not object reference equality. So little relation to AS3 Dictionary/ES6 Map, besides being possible keys for Map/Set.
TIL and also god that would be amazing, almost to the point of making JS/TS actually nice if done right (what’s next, pattern matching?). The number one footgun in JS imo is the combination of mutability and reference copying. Immutable or at least easy-to-copy plain old data is fantastic when it is well supported in the language.
Oh boy do I have news for you... https://tc39.es/proposal-pattern-matching/
:P
…Huh? Are you referring to transpilation?
I strongly disagree, it's never been easier and more pleasant to write modern JS without transpilers. I've only rarely had to reach for a framework or transpiler in the last few years.
Working with assembly is comparatively expert work that few professionals are good at. JavaScript can be written by kids.