| 12:15 | <littledan> | rwaldron-: If you're thinking of async do expressions, I'd be really in favor of them. We just need to move forward on do expressions! |
| 12:16 | <littledan> | but an async block statement also makes sense to me, as a complement |
| 13:09 | <rwaldron-> | littledan not Async Do Expressions, but yes the that I was "floating" a few years ago was essentially an "Async Block Statement" (sort of?): `async { /* this code is executed async */ }`. I stopped pursuing it because `(async () => { })()` can be used to achieve the same outcome. |
| 13:10 | <rwaldron-> | but yes the idea that* |
| 13:10 | <littledan> | Yeah, I think that is a good idea for a complement |
| 13:11 | <littledan> | I would be in favor of that addition |
| 13:11 | <rwaldron-> | I had a practice of marking synchronous code with labelled blocks and wanted to be able to do something similar for async stuff that didn't need to return anything |
| 13:12 | <rwaldron-> | "I think that is a good idea for a complement [09:11:06] <+littledan> I would be in favor of that addition" ... Neat! |
| 13:12 | <rwaldron-> | :D |
| 13:14 | <littledan> | One "hard part" is deciding what to do about var declarations, return, break, etc in such a block. I like bakkot's suggestion for do expressions to just ban them all |
| 13:18 | <rwaldron-> | I would definitely ban var, but it's not a function so there is no return, and not a loop thing so there is no continue. That leaves break, which I think might be useful (unless there is some strong argument that I'm not aware of?) |
| 13:20 | <rwaldron-> | https://i.gyazo.com/4ecb7eed84e4f6a74d740c82868baaf1.png |
| 14:38 | <bradleymeck> | my main concern is swallowed errors |
| 14:38 | <bradleymeck> | return/break/etc. are confusing but probably not fatal |
| 15:09 | <littledan> | rwaldron-: I guess break could work if it comes before the first await, but sometimes you can't statically tell whether it will be preceded by an await or not |
| 15:10 | <littledan> | oh, to break out of the async block? yeah, that case seems fine |
| 15:10 | <littledan> | but only that one label could be allowed (and inner labels), not labels that are further out |
| 15:10 | <rwaldron-> | Yes, just to break out of the async block |
| 15:11 | <rwaldron-> | I would be +1 to disallowing the label by name |
| 15:11 | <littledan> | yeah so it seems like we agree on all these points. IMO we should go for your idea here. Let me know if there's something I can do to help. |
| 15:11 | <devsnek> | async blocks seem meh |
| 15:11 | <littledan> | devsnek: why? |
| 15:11 | <devsnek> | because of all the rules y'all are iterating through here |
| 15:11 | <rwaldron-> | devsnek isn't wrong |
| 15:12 | <devsnek> | recreating functions from first principles lol |
| 15:12 | <rwaldron-> | ¯\_(ツ)_/¯ |
| 15:12 | <rwaldron-> | devsnek see above, that's why I ultimately stopped pursuing this idea. |
| 15:13 | <devsnek> | it's interesting but also scary |
| 15:14 | <rwaldron-> | But maybe there's merit to "something that is definitely not a function, that ensures async execution". Maybe that thing is async do expressions. |
| 15:15 | <devsnek> | yeah I like the idea... |
| 15:16 | <devsnek> | there are just so many assumptions people need to have that are already implied by function boundaries... it seems like a learning nightmare |
| 15:41 | <mathiasbynens> | I'll just leave this here: https://github.com/tc39/ecmarkup/pull/263#issuecomment-708470782 |
| 15:42 | <mathiasbynens> | whoops, didn't mean to link to any specific comment https://github.com/tc39/ecmarkup/pull/263 |
| 16:17 | <Bakkot> | mathiasbynens neat, although I am extremely hesitant to rely on chrome-only APIs; has any other browser even started work on this, to your knowledge? |
| 16:17 | <ljharb> | rwaldron-: if do expressions exist, then async do expressions seem like an easy/trivial addition on top of them to me |
| 16:17 | <rwaldron-> | ljharb agreed. |
| 16:18 | <mathiasbynens> | Bakkot: it’s not “relying” — browsers that don’t yet implement this modern CSS feature just don’t get the benefit (i.e. they get the same experience they’re getting today) |
| 16:18 | <mathiasbynens> | Bakkot: but yeah only Chrome implements this standard, currently |
| 16:22 | <Bakkot> | mathiasbynens I don't really care about whether you label this a standard; my concern is whether other browsers are intending to ship it |
| 16:25 | <Bakkot> | I am not dead set against chrome-only performance hacks, especially since this is a chrome-only performance issue in the first place - god knows I've shipped enough of those - I'd just be more comfortable if other browsers had said they were working on shipping the feature |
| 16:25 | <Bakkot> | (that is, it would no longer feel like a chrome-only hack) |
| 16:31 | <mathiasbynens> | Bakkot: Mozilla is on board: https://github.com/mozilla/standards-positions/issues/135#issuecomment-650923098 WebKit: <crickets> https://lists.webkit.org/pipermail/webkit-dev/2020-May/031217.html |
| 16:32 | <Bakkot> | hmm |
| 16:32 | <Bakkot> | thanks |
| 16:39 | <Bakkot> | that certainly does give a much nicer experience in Chrome |
| 16:40 | <Bakkot> | will land once the upstream bug (which I also observe) is fixed on chrome stable and you've marked the PR ready to go |
| 17:26 | <Bakkot> | mathiasbynens also there was https://github.com/tc39/ecmarkup/pull/261; I'm not sure how these things interact |
