Should we rename `iter these(...)`? To what?

[bradcray]

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 #18263. 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 https://github.com/chapel-lang/chapel/issues/19037 and https://github.com/chapel-lang/chapel/issues/18263

[mppf]

Should renaming these go along with having a replacement that allows more elegant description of the leader/follower/standalone/serial iterators?

[bradcray]

I think that would be ideal, but would require someone to solve that challenge as well (where we've had a lack of eurekas so far, or people very interested in digging into it). So I think it would also be reasonable to get what we have into a better state than it is for now, and continue to make that a post-2.0 issue. Or to stick with what we've got given that we've already called it out as a likely unstable in 2.0 feature. How's that for a wishy-washy answer?

[mppf]

Note that we do have issue #13256 which talks about some alternatives to the current situation.

[lydia-duncan]

I think it would be reasonable to rename this, but I'm having trouble thinking of alternatives. My first instinct is something with iteration in the name, since what it is doing is making the type it is defined on iterable. Maybe along the lines of iter makeIterable? However, that feels redundant with the iter keyword, to some extent