domenic at domenicdenicola.com (2014-01-14T17:36:37.481Z)
On 6 January 2014 17:59, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> The major new complication of `do`-expressions is that they allow for the occurrence of `break`/`continue`/`return` abrupt completions in contexts such as `for` loop heads where they could not previously occur. However, `do`-expressions where still on the table when I did the spec. work for "completion reform" so the ES6 draft already deals with these abrupt completions in those contexts. Even though there is currently no way to produce them.
I agree that's a complication, which is why I would propose to
disallow them, at least for the time being. Motivation:
- YAGNI -- I have a hard time coming up with a use case that isn't
obfuscated code (even considering generated code).
- They complicate the semantics and implementation -- for example, you
would have to roll back non-empty expression stacks (in a stack
machine implementation).
- They destroy nice equivalences -- in particular, I'd like `do {...}`
to be equivalent to `(() => {...})()`, e.g. to minimise refactoring hazards.
- We can always allow them later, if the need should ever arise.
Dave, I remember you were in favour of allowing these. Do you have
specific use cases in mind?
On 6 January 2014 17:59, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote: > The major new complication of do-expressions is that they allow for the occurrence of break/continue/return abrupt completions in contexts such as for loop heads where they could not perviously occur. However, do-expressions where still on the table when I did the spec. work for "completion reform" so the ES6 draft already deals with these abrupt completions in those contexts. Even though there is currently no way to produce them. I agree that's a complication, which is why I would propose to disallow them, at least for the time being. Motivation: - YAGNI -- I have a hard time coming up with a use case that isn't obfuscated code (even considering generated code). - They complicate the semantics and implementation -- for example, you would have to roll back non-empty expression stacks (in a stack machine implementation). - They destroy nice equivalences -- in particular, I'd like "do {...}" to be equivalent to "(() => {...})()", e.g. to minimise refactoring hazards. - We can always allow them later, if the need should ever arise. Dave, I remember you were in favour of allowing these. Do you have specific use cases in mind? /Andreas