The only reason TypeScript exists is to follow JavaScript around and implement features JavaScript comes up with in TypeScript syntax.
Yet people in TypeScript workd appear to not even bother keeping up with what goes on in ECMA-262.
I mean, you could read ECMA-262 yourself to find out if resizable ArrayBuffer is in there or not.
Things don't just magically materialize just because Microsoft TypeScript implement those things, as if they didn't exist until Microsoft TypeScript decided to implement an ECMA-262 interface, and don't exist otherwise.
Here's usage in a Native Messaging host https://github.com/guest271314/NativeMessagingHosts/blob/main/nm_typescript.ts. I asked around and plucked the code in the pending PR that has not merged.
Here's use in the browser processing data in a Web Audio API AudioWorklet https://github.com/guest271314/offscreen-audio/blob/main/audioWorklet.js.
I think people misunderstood this comment, possibly because your later responses are somewhat incoherent. I assume your complaint is that TS still has not updated its types updated to reflect the changes to ArrayBuffer to add the resize methods and so on.
There's been a couple efforts to do so which have stalled out for reasons including in one case the author deleting their GH account, and there is a current effort here which is blocked on this issue which has some interesting background about the difficulty of this change, including necessary ecosystem fixes to minimize the extent to which this has to be a breaking change.
So if the next ECMA spec adds methods like map and filter etc to everything that is an iterator, does that mean Set and Map also get them?
If so, does that then mean that when we write code it can now be even more generic and not care about the type passed to a function? So previously you’d have (in TS) an array as an argument, and if you wanted to pass a Map or Set (or even an object?) you’d need to convert it to an array.
But with this proposal, we could simply accept an Iterable or IterableIterator and a consumer could pass arrays, Set, Map?
If so that’s very cool and like what you often do in .NET where methods will accept IEnumerable or ICollection or IReadOnlyCollection etc. The backing type could be anything from a dictionary to a list to a set.
There might be reasons, but listen here: it does not matter. Operator precedence is useful only in code golfing. For every other situation there are parenthesis. Yes, even in blindingly obvious situations, use parenthesis. Pretend you are writing lisp. Anyone who has to touch the code afterwards will thank you.
guest271314@reddit
Still no resizable
ArrayBuffer
.versaceblues@reddit
How would they do this if js does not support it
guest271314@reddit
Clearly you have not read ECMA-262.
You must think JavaScript features magically happen because Microsoft decides to support them.
versaceblues@reddit
I never said that. Resizable array buffer if part of es2024 and looks like the change to add it to TS is being tracked here
https://github.com/microsoft/TypeScript/pull/58573/commits
guest271314@reddit
Yes, I know. As of today, officially, there is no Microsoft TypeScript implementation of resizable
ArrayBuffer
.That means the claim that TypeScript is a "superset of JavaScript" is not mathematically correct, as of today.
guest271314@reddit
Node.js, Deno, Bun, V8, SpiderMonkey, Chrome, Firefox all support resizable
ArrayBuffer
.lelarentaka@reddit
Is it in ECMAScript?
guest271314@reddit
This is bordering on insanity.
The only reason TypeScript exists is to follow JavaScript around and implement features JavaScript comes up with in TypeScript syntax.
Yet people in TypeScript workd appear to not even bother keeping up with what goes on in ECMA-262.
I mean, you could read ECMA-262 yourself to find out if resizable
ArrayBuffer
is in there or not.Things don't just magically materialize just because Microsoft TypeScript implement those things, as if they didn't exist until Microsoft TypeScript decided to implement an ECMA-262 interface, and don't exist otherwise.
guest271314@reddit
Yes. https://tc39.es/ecma262/multipage/structured-data.html#sec-allocatearraybuffer.
versaceblues@reddit
I guess I’m not following what you want exactly then. How would the type you are talking about be used. Do you have an example
guest271314@reddit
Sure.
Here's usage in a Native Messaging host https://github.com/guest271314/NativeMessagingHosts/blob/main/nm_typescript.ts. I asked around and plucked the code in the pending PR that has not merged.
Here's use in the browser processing data in a Web Audio API
AudioWorklet
https://github.com/guest271314/offscreen-audio/blob/main/audioWorklet.js.bakkoting@reddit
I think people misunderstood this comment, possibly because your later responses are somewhat incoherent. I assume your complaint is that TS still has not updated its types updated to reflect the changes to
ArrayBuffer
to add theresize
methods and so on.There's been a couple efforts to do so which have stalled out for reasons including in one case the author deleting their GH account, and there is a current effort here which is blocked on this issue which has some interesting background about the difficulty of this change, including necessary ecosystem fixes to minimize the extent to which this has to be a breaking change.
guest271314@reddit
No complaint. Just technical fact. I plucked the
lib.es2024.arraybuffer.d.ts
file from the PR.tokland@reddit
Typo: function abc123() -> function *abc123()
LloydAtkinson@reddit
So if the next ECMA spec adds methods like map and filter etc to everything that is an iterator, does that mean Set and Map also get them?
If so, does that then mean that when we write code it can now be even more generic and not care about the type passed to a function? So previously you’d have (in TS) an array as an argument, and if you wanted to pass a Map or Set (or even an object?) you’d need to convert it to an array.
But with this proposal, we could simply accept an Iterable or IterableIterator and a consumer could pass arrays, Set, Map?
If so that’s very cool and like what you often do in .NET where methods will accept IEnumerable or ICollection or IReadOnlyCollection etc. The backing type could be anything from a dictionary to a list to a set.
apf6@reddit
Yup Set and Map have methods that return iterators (including .keys and .values and .entries)
You can do that stuff today, but having the helper functions on the Iterator class itself is a huge added convenience.
Today you could write something like this:
With the builtin helpers the same code would be:
agumonkey@reddit
sounds like esnextnext will have linq.ts
kuikuilla@reddit
Or literally any other language that has traits/interfaces/abstract types of some kind.
apf6@reddit
is the author throwing in a little shade that he doesn't like the
reduce
function?Longjumping-Till-520@reddit
Will use --noCheck and autoimport patterns in https://achromatic.dev - nice additions!
truggyguhh@reddit
Why is the precedence so low? Other operators don't really result in nullish values.
slvrsmth@reddit
There might be reasons, but listen here: it does not matter. Operator precedence is useful only in code golfing. For every other situation there are parenthesis. Yes, even in blindingly obvious situations, use parenthesis. Pretend you are writing lisp. Anyone who has to touch the code afterwards will thank you.
uncomfortableiterati@reddit
So excited about this I've been plagued by bad suggestions for years
flippy_flops@reddit
My favorite new features...
MrChocodemon@reddit
There are some really nice changes in there.