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] or [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.
Reaction to this proposal (requiring one-element array literals to be written as [1,] rather than [1]) 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);
or:
var nameOpt = parser.addOption(name="legalname",
- opts=["--name"]);
+ 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"],
+ opts=["--no-vcs", ],
defaultValue=false);
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.
As an update on this topic: Since merging the warning for 1-element arrays, I've only found additional real-world user codes that use 1-element arrays (e.g., Arkouda and CHAMPS). Since one of the strong assumptions in proposing this warning was that "nobody uses 1-element arrays anyway, so it won't really affect working codes", I'm currently thinking that we should not warn for this case—particularly since Python supports 1-element arrays without trailing commas, and we are very interested in appealing to Python programmers. Specifically, I'd prefer for 1.30 to not go out with this warning enabled.
What I am exploring instead is a warning more specifically for the case that led me to open Issues · chapel-lang/chapel · GitHub namely, array literals of range literals (perhaps just 1-element arrays of range literals; perhaps just ones without a trailing comma). If you have thoughts on this matter, please feel encouraged to put them on the issue: