[design] deprecate support for `bool(w)`? (but not `bool`)

Hi Chapel Users —

We've recently been discussing removing support for bool(w) (fixed-width bools) in Chapel. I'm writing this message to see whether doing so would cause problems for any of you or your codes. (My hope is that you'll say "What is a bool(w)?" in which case it probably will not cause any and you can stop reading here unless you're curious).

As background, in Chapel's early years, we decided to support bool values of various widths so that users who wanted to decide how many bits should be devoted to their bool field or variable (which would have implications on how it was aligned w.r.t. other nearby fields or variables) could do so. As time has passed, we've wanted the ability to align non-bool values (suggesting the need for a more general memory alignment capability) and have not been aware of users making heavy use of bool(w). Meanwhile, confusion about why bools need various widths has been a recurring question, both on the development team and among new users.

For those reasons, we're proposing to remove bool(w), supporting only bool, with the intention of ultimately adding a more general memory alignment capability for those who want to say how the boolean values should be aligned in memory.

If this causes you concern (particularly if there's a lag between when bool(w) goes away and the memory alignment capability becomes available, which seems likely), please let us know by responding to this message or commenting on this issue: should we deprecate bool(w)? · Issue #21002 · chapel-lang/chapel · GitHub (GitHub thumbs-ups / Discourse likes are always appreciated as well).

Thanks!
-Brad

2 Likes