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 ?
Looks like a performance super footgun (if no type information involved)🤣
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:

x
  .filter()
  .transform()
  |> apply1(%)
  |> apply2(%)

works fine, but if the function applications are first, you're stuck with

(x
  |> apply1(%)
  |> apply2(%))
  .filter()
  .transform()

or giving up on using the original method application syntax entirely, as in

x
  |> apply1(%)
  |> apply2(%))
  |> %.filter()
  |> %.transform()
21:51
<Ashley Claymore>
x
  |> apply1(%)
  .  filter(f)
  |> apply2(%)
  .  map(f2)

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:

Else, set hygienicTemp to hygienicTemp.[[Value]].

23:11
<jmdyck>
See https://github.com/tc39/ecma262/pull/1570
23:28
<jugglinmike>
jmdyck: Thanks!