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):
- 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 (
- simple description (
- "doThis" style:
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:
- [ ] Should we reserve 'init', 'init=', or 'deinit' as keywords? · Issue #13897 · chapel-lang/chapel · GitHub
- [ ] secondary init=() with two arguments should cause compilation error · Issue #15963 · chapel-lang/chapel · GitHub (on the topic of generating errors for bad uses of init methods)
- [ ] Should we change `proc this` into an operator? · Issue #19037 · chapel-lang/chapel · GitHub
- [ ] What should the name of our standard hashing method be? · Issue #18340 · chapel-lang/chapel · GitHub
- [ ] What should the special methods for context managers be named? · Issue #18811 · chapel-lang/chapel · GitHub
... more to be added as we go...