It makes sense, but it's an excessive amount of boilerplate which almost no one actually writes.
And while it is concurrency, it's not _structured_ concurrency because it doesn't wait for task cleanup to finish in case of errors - so control moves past the block while the tasks are still running.
Thanks, fixed.
Put together a presentation on a possible direction for getting native structured concurrency in JS, taking as a constraint that we already live in a world where cancellation means AbortController. Interested in your thoughts!
docs.google.com/presentation...
Yup!
You can also do this for IIFEs (which have a similar restriction to avoid ambiguity with FunctionDeclaration) but there's less reason to care in that case.
It's more common when there's more than one property. `({ user, body, message } = getRequest());` is much nicer to read than `const request = getRequest(); user = request.user; body = request.body; message = request.message;`.
That said, yes, I also use destructuring for a single property.
Only because no one uses it! If we all started doing this then people would recognize this pattern.
My most idiosyncratic JS opinion is that we should all write
`0, { x } = y;`
instead of
`({ x } = y);`
so you don't have to jump to the end of the line to add the parenthesis. If only I could convince tooling to support this... (i.e. get prettier not to add the parentheses back)
With this attitude, TS becomes much more pleasurable. You can write the code you were going to write anyway but with types written down instead of in your head, and most of the time TS will validate it or catch real bugs, and in the remaining cases you just tell it the right answer and move on.
I really like to emphasize to people that TypeScript is going to be wrong about things sometimes, and you need to embrace that this is OK and that you can and should use `// @ts-expect-error` or `as unknown as Foo` in cases where you know better than the typechecker. It's fine!
This is such a quintessential "working on JavaScript [and friends]" bug. Dumb compat hacks for engines no one has touched in a decade? Check. Weird parser inconsistencies? Check. Even a BOM mention!
If we go with "visible in else" it's actually pretty hard to get disposal to happen before the else! Try rewriting this without relying on "dispose before else":
if (using resource = getResource(); resource.needsUpdate) {
resource.update();
} else {
await postMessage('no updates required');
}
Just because that's how you call always `hasOwnProperty` though, it's not something the attacker could actually control. They could have done `Object.hasOwn` if they only cared to work on modern runtimes, and would not benefit from caching in that case.
As a person who says the thing you quoted all the time I am confused about the relevance of this CVE, which does not modify any builtins?
Agreed! I will probably do this as a followup, but have to get regular async helpers first.
github.com/tc39/proposa...
Discworld has good values and was this for me at that age. The Tiffany Aching books especially though he might be turned off by 9yo girl protag.
Some of Doctorow's stuff is more explicitly inculcating those specific values, and is good for 13yos. Little Brother is probably a decent first one.
Several people blamed the recent npm incidents on JS's minimal standard library.
I think that's wrong: the affected packages are mostly either already covered by node or could not reasonably be in a standard library.
But! I'm always taking suggestions for new stdlib features.
Not exactly stalled; there's just a lot of work which needs to be done first. Activity currently is at github.com/tc39/proposa.... I believe the plan is for module declarations to proceed after this proposal, with the declaration evaluating to the ModuleSource object introduced in this proposal.
That's because this isn't upsert. Upsert does mutation when the value already exists. This doesn't.
Pedantry: you made a quiz about _V8_'s Date parser. Almost none of this is required by spec (although it is allowed), and several of these behave differently in other browsers. Which is even worse!
A sync iterator yielding a rejected promise is not an error in the iterator, whereas an async iterators doing so is. So when lifting sync to async, we need to handle rejected promises from the iterator as if the _consumer_ had an error (by calling `.return`).
Thanks! Further pedantry: "Note that in for of with sync iterators, .return() is always called after .next() throws" - not so. The bug arises because consumers aren't supposed to call .return if the iterator throws, only if the consumer does.
So, a break/return/throw inside the loop causes `.return` to be called, but the iterator being exhausted, or throwing, does not call `.return` to be called.
Good post! Nitpick: you say `.return` is called "when the iteration stops (due to a break, due to reaching the end of the iterator, or due to the iterator having thrown)". The latter 2 are wrong. It is called only on _early_ exits from the loop which are not caused by the iterator throwing.
using controller = new AbortController.AutoAbort(); let pages = await Promise.all(urls.map(url => fetch(url, { signal: controller.signal })); // automatically cancels outstanding requests if any request fails
Some of that is because the lack of syntax means we don't clean up things we probably should. For example, with a [hypothetical] disposable AbortController, it would be trivial to clean up outstanding fetch requests when other requests fail. Usually JS devs just don't bother.
we have almost finished working through your list
chunking is coming in proposal-iterator-chunking
ranges are making less progress
rest is done
x.com/qntm/status/...
Any pointers to which? I've previously been skeptical of adding CBOR because I thought it didn't have wide adoption yet but it's already backing web specs that would be relevant data.
Parallelism and concurrency! respectively:
github.com/tc39/proposa...
github.com/tc39/proposa...
less exciting but still exciting (but I'm biased): native base64
github.com/tc39/proposa...
