Making `for` simpler and more regular

Language Design
25

My issues with for are a bit different.

  • (... ; ...) vs {... ; ...}: somewhat sympathetic but overall meh. I believe arguments were brought forward for both styles.
  • Explicit vals: we had that and got rid of it. No way going back.
  • require semicolon before if: ditto. Outlawing “postfix” ifs where alignment is otherwise vertical could make a good rule for a linter, though.
  • yield with a type parameter: would complicate things further.
  • foreach: I would hate to have to work without it.

For me, the more pressing issues are:

  • Destructuring vs filtering. We should investigate whether there is a good way to distinguish irrefutable pattern matching from the rest. It has to work uniformly for val bindings and for generators. Maybe use ?=, ?<- for bindings that can fail? A failing match in a for expression would have to filter.
  • Leaving out yield accidentally. I would actually like to revive SIP 12. That would force you to write either yield or do and would also make the parents vs braces debate redundant.
  • Contorted code in the translation of = bindings, as described in this Dotty issue. This one is in my mind very important because it currently leads to bad generated code. To fix this, we’d need to change the rules so that an if in a for expression requires a “zero” or “empty” getter in the generated-over structure, instead of a withFilter method as of now. That’s a bigger change that affects libraries so migration is harder.
3 Likes