New Issue: What, if anything, should we do about special method names?

Notifications Issues
1

19038, "bradcray", "What, if anything, should we do about special method names?", "2022-01-18T22:52:23Z"

Today, Chapel has the following special method names (ignoring those defined by operators):

  • initialization: init, postinit, init=, deinit
  • direct access/iteration: this, these
  • I/O: readThis, writeThis, readWriteThis
  • hashing: hash
  • context management: enterThis, leaveThis

This issue is somewhat of an umbrella issue asking what we want to do about them—if anything—where I expect we'll wrestle with different subsets on distinct issues.

The motivation for this issue is to note that a variety of naming schemes are currently used:

  • keyword-based (init, this)
  • simple description (hash, init, init=, postinit, deinit)
  • "doThis" style: readThis, writeThis, readWriteThis, enterThis, leaveThis
  • cute/clever: this, these

And users have expressed concern about things like:

  • How can I be alerted that I'm opting into a special method rather than happening to use a name that Chapel gives special meaning to?
  • How can I ensure that my code will not break if/when more special methods are added over time?

And in some cases, these questions are complicated by the fact that the Chapel compiler will introduce implementations of these methods if the user hasn't created them (such that all types are printable or hashable by default, for example).

Here are some related issues: