3 ms·
Reading the proposal, I'm not sure I get the usecase for the do expression. Could I just achieve the same with a function call? Or if I want to inline the con
by davnicwil 4y ago
Reading the proposal, I'm not sure I get the usecase for the do expression.
Could I just achieve the same with a function call?
Or if I want to inline the contents of that function in the same code for readability preference, aside from syntax sugar is there a difference from (() => { ... })()?
Or have I missed something about some extra features it provides?
- nicoburns 4y ago> aside from syntax sugar is there a difference from (() => { ... })() Well it will be more efficient unless the compiler is smart enough to inline the closure call. If it is, then no, it's just sugar. But as you say, the reason to inline code is for readability, and sugar is useful for that. I tend to find I don't use (() => { ... })() much because all the noise often makes it less readable overall. An example where I would use it: const foo = do { let foo = "bar"; if (complexCondition()) foo = "baz"; if (condition2()) foo = "quz"; foo }
- WorldMaker 4y agoThe best arguments for do expressions I've seen are in recent versions of the Pipe Operator proposal which now suggests where do expressions can produce some good simpler looking pipelines with the Pipe operator. Aside from syntax sugar, it's also a tiny spot for some JIT compiler and garbage collector optimization. Arrow functions still create Function objects, which is a tiny bit of administrative overhead and possible garbage to collect. Most JIT engines are somewhat used to "IIFEs" and can optimize common patterns of that, but do notation possibly directly suggests "not a real Function" or "entirely inlinable function" to the JIT in ways that even arrow functions cannot. I don't know if that sort of micro-optimization is a great argument for do expressions, however.