New Issue: Should 'this' methods be replaced with operators of some form? What form?

Notifications Issues
1

18263, "bradcray", "Should 'this' methods be replaced with operators of some form? What form?", "2021-08-19T22:25:33Z"

In the early times of Chapel, we needed a way to implement arrays and provide users a way to create other indexable/accessible data structures, but didn't have operator methods as we do today. This led to the "cute" approach of having proc this(...) serve as the accessor method, where we wouldn't have to reserve a special identifier for the purpose since this was already reserved and seemed to suggest "call me"/"access me".

Now that we have operator methods, it's been pointed out that they may be a more clear / obvious way of expressing accessors, which seems compelling. But if we went this route, how should they be expressed? E.g.,

// primary method form
record R {
  operator [](args) { ... }
  operator [args] { ... }
  operator [(args) { ... }
  operator [(args)] { ... }
  // ...something else?
}

// secondary method form
operator R.[](args) { ... }
operator R.[args] { ... }
operator R.[(args) { ... }
operator R.[(args)] { ... }
// ...something else?

Other considerations:

  • does the fact that parens and square brackets are interchangeable temper our response here? Or cause us to want to stick with the status quo?
  • what's the implication for the these iterator if we switch? If we don't? (maybe it should've also been renamed iter this when we split proc and iter out as distinct declaration styles?)