Hi Chapel Users —
Today, Chapel supports 1D array literals using the syntax
[elem1, elem2, elem3, ...]. When an array has just a single element, it can currently be written either as
[elem,], where the latter form is consistent with how we write one-tuples (e.g.,
(elem, )). Note that for 1-tuples, the trailing comma is required to distinguish it from a normal parenthesized expression.
This week, we've been considering whether to require the
[elem, ] form for one-element array literals, the reason being that someone new to the language might not understand the role of square brackets vs. curly brackets and place them around expressions, accidentally creating array literals without meaning to, and winding up confused. Implicit in this proposal is a belief that 1-element arrays are not used very commonly; and, given that, consistency with tuples and closing this potential for confusion seems likely to be more valuable than not having to type the extra comma.
If you'd like to give this proposal a thumbs-up or comment on it, please do so on the following GitHub issue: Should our 1-element array literals require a trailing comma? · Issue #21092 · chapel-lang/chapel · GitHub
Agreed: makes it more consistent and easier to remember.
Hi Chapel Users & Devs —
Reaction to this proposal (requiring one-element array literals to be written as
[1,] rather than
) has generally been positive, so I've started into the process of implementing it.
In doing so, I found some cases that made me realize that single-element arrays are not quite as rare in practice as I was imagining, in particular because some library routines take arrays (of strings, say) as arguments, and use-cases that only want to pass in an array with a single element are not completely uncommon. This shows up most notably in the
spawn() routine of the
Subprocess standard module as well as uses of the
ArgParse package. For example:
- var sorter = spawn(["sort"], stdin=pipeStyle.pipe, stdout=pipeStyle.pipe);
+ var sorter = spawn(["sort", ], stdin=pipeStyle.pipe, stdout=pipeStyle.pipe);
var nameOpt = parser.addOption(name="legalname",
+ opts=["--name", ]);
var showFlag = parser.addFlag(name="show", defaultValue=false);
var dirArg = parser.addArgument(name="directory", numArgs=0..1);
var vcsFlag = parser.addFlag(name="vcs",
+ opts=["--no-vcs", ],
While this makes the change less of a no-brainer than I'd been originally imagining it to be, I think I'm still personally in favor of it to avoid surprises and unify with tuples. That said, I wanted to give others the opportunity to balk or push back based on this new data.