New Issue: Should we rename 'iter these(...)'? To what?

Notifications Issues
1

19041, "bradcray", "Should we rename 'iter these(...)'? To what?", "2022-01-19T00:17:43Z"

This issue asks whether we should rename iter these() to something less cute / special—and more importantly, to what?

Historically, we've had proc this() as a means of indexing into / calling a user-defined type directly, as noted in #19037. When we also needed a way to iterate over things directly, we added iter these() as a means of doing it, which was not as principled (this was reserved, these was not), but felt "cute" (this returns once, these yields multiple things) and sufficientlyunlikely to be an identifier that the user would want to use.

As we work towards stabilizing the language, we should make sure this is a name we want to live with, where leading options are:

  • keep it an iter but change it to another name
    • iter this(...): note that proc and iter were introduced after these so the only way we had to distinguish between the two was different identifiers; since splitting def into proc and iter we could've used proc this vs. iter this as a way of distinguishing
    • some other identifier?
      • and maybe we should reserve that identifier to make it clear?
  • make it an operator?
    • note that no operators are iterators / can yield today, so this would be a new / special case
    • what to call it?

This issue is also related to Should we change `proc this` into an operator? · Issue #19037 · chapel-lang/chapel · GitHub and Should `this` methods be replaced with operators of some form? What form? · Issue #18263 · chapel-lang/chapel · GitHub