03:41 | <sirisian> | I remember seeing something years ago, but I can't remember if it had a name. A keyword on functions that reversed the async/await calls, so every result in the function was awaited unless marked as async. Anyone know what I'm talking about? |
03:43 | <ljharb> | i'm not sure how that could reasonably work. it might have been on esdiscuss or the discourse tho |
05:13 | <Ashley Claymore> | https://github.com/ziolko/babel-plugin-auto-await ? |
05:13 | <sirisian> | ah yes, that was probably it. Thank you. |
05:20 | <sirisian> | It's not the discussion I was thinking of, but I think it might have been referenced. Like a lot of modern projects I deal with a lot of async code. Was thinking if there wasn't a quick fix for simple functions. (Assuming the programmer knows what they're doing awaiting everything in a function). |
05:20 | <Jack Works> | https://github.com/ziolko/babel-plugin-auto-await ? |
05:21 | <sirisian> | yes, it would be, especially on large functions. |
20:24 | <joepie91 🏳️🌈> | re: pipeline functionality, while I frequently complain about the increasing complexity of JS (and feel that some of the more recent additions were a mistake), I do not agree that the pipeline syntax is pointless or unnecessary. it solves a very real, irritating and widespread problem (mixing method and function invocations in a readable manner), and as someone who actually is maintaining a userland implementation of sorts for this kind of functionality, the inability to use await is a limitation I haven't been able to find a workaround for without language changes either. using regular old Promise syntax (ie. .then ) is a little better, but only a little. |
20:25 | <joepie91 🏳️🌈> | I really hate new things being added to core in general but this is one of the few things that passes even my criteria :p |
20:48 | <bakkot> | not totally convinced by "method and function invocations in a readable manner" - you can go one way (methods, then functions), but not the other (functions, then methods) |
20:51 | <bakkot> | like:
works fine, but if the function applications are first, you're stuck with
or giving up on using the original method application syntax entirely, as in
|
21:51 | <Ashley Claymore> |
Brackets aren't required, if ok that the scope of the pipe leaks into subsequent lines. |
21:51 | <Ashley Claymore> | Though I would probably write it like the last example with all pipes |
23:07 | <jugglinmike> | In https://tc39.es/ecma262/#sec-returnifabrupt, what's the purpose of this step:
|
23:11 | <jmdyck> | See https://github.com/tc39/ecma262/pull/1570 |
23:28 | <jugglinmike> | jmdyck: Thanks! |