this makes me very happy. do-expressions could be one of the best features to come to JS since ES5:https://twitter.com/BrendanEich/status/808684436665602048 …
-
-
Control flow in expression position makes me :(. Not allowed in `eval`, e.g. Why is that a thing you'd want? 1/
-
`for (let a of b) { fn(a, y, do {if (cond) continue; z;}); }` = sadness. 2/2
-
Worse: `for (x; do { if(cond) continue; a; }; y) { ... }`. What's the use case for control flow, to justify language complexity? 3/2
-
it might actually be harder to disallow in terms of complexity, but also, returning seems quite useful.
-
Harder on spec or implementors? Spec yes, but worth it I think. Doubt for implementors. What's the use case of returns in expr. pos?
-
have you ever tried to write: x || throw new Error("...")? I have, many times.
-
I'm fine with throw! Arbitrary exprs, iifes already can throw. Concerned about return, break, continue. Don't see use case, either.
- 5 more replies
New conversation -
-
-
is this like a Ruby Proc/Lambda?
-
no, it's more like an IIFE: to group stmts as an expr.
-
will FiB hoist but stay entirely inside do block?
@TheLarkInn@wycats@ArnaudRinquin@kentcdodds@andrewingram@littlecalculist -
FiB == function in block?
-
yep
-
Aren't they block-scoped since ES6 anyway, so just same behavior persists?
-
tbh i cannot yet wrap my head around FiB... too many caveats, every time i approach i get more confused
-
no one knows JS ¯\_(ツ)_/¯ (this one will never get old)
End of conversation
New conversation -
-
-
Huh I thought it would be more like Haskell's do and do monady things with async/await.
-
Would await inside do make the whole do block evaluate to a promise?
-
let p = async do { await x; await y; } waits for the whole thing to complete.
- End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.