New Issue: Should we change 'proc this' into an operator?

Notifications Issues
1

19037, "bradcray", "Should we change 'proc this' into an operator?", "2022-01-18T22:48:48Z"

When we introduced proc this() as a means of permitting user-defined types to be indexable, we chose it because we didn't want to reserve a user identifier for this, this was already a reserved word, and it felt syntactically appropriate to use this() as the way to say "you can call into / index into this".

However, since that time, we've introduced operators into the language, which represent another compelling way to represent this since it could be viewed as the application of [...] or (...) to the this argument. Some minor challenges to taking an operator-based approach include:

  • what would we call it?
  • since [...] and (...) are interchangeable in Chapel, how would we indicate that this operator supports both?
  • since none of our operators so far have a this argument, presumably this would need to be taken in as the first formal argument explicitly? E.g., to support a call on type R that takes a single int, it seems like we'd write operator R.whateverItsCalled(r: R, i: int) { ... } rather than simply operator R.whateverItsCalled(i: int) { ... }?

As far as names go, here are some initial brainstorms:

  • operator R.this(...)
  • operator R.call(...)
  • operator R.index(...)
  • operator [](...) // relies on understanding that defining this operator also defines paren-access
  • operator [(...) // ditto: express the operator as a single square bracket rather than a pair
  • operator [(...)] // put the formals where they fall syntactically? (but maybe explicit this breaks this anyway)
  • operator (...) // no operator name => the direct accessor operator

Or, given the caveats/compromises above and that this is reserved, are these changes a marked improvement over the status quo?