# \[design\] one-element array syntax

**URL:** <https://chapel.discourse.group/t/design-one-element-array-syntax/17680>\
**Category:** Users\
**Created:** [November 30, 2022, 1:10am UTC](https://chapel.discourse.group/t/design-one-element-array-syntax/17680 "2022-11-30T01:10:15Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![bradcray](https://yyz2.discourse-cdn.com/free1/user_avatar/chapel.discourse.group/bradcray/32/72_2.png) [@bradcray](https://chapel.discourse.group/u/bradcray)\
**Post date:** [November 30, 2022, 1:10am UTC](https://chapel.discourse.group/t/design-one-element-array-syntax/17680/1 "2022-11-30T01:10:15Z")

</div>

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]` 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.

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](https://github.com/chapel-lang/chapel/issues/21092)

Thanks!  
-Brad

---

<div class="post-metadata">

**Author:** ![nelsonluisdias](https://yyz2.discourse-cdn.com/free1/user_avatar/chapel.discourse.group/nelsonluisdias/32/691_2.png) [@nelsonluisdias](https://chapel.discourse.group/u/nelsonluisdias)\
**Post date:** [November 30, 2022, 7:48pm UTC](https://chapel.discourse.group/t/design-one-element-array-syntax/17680/2 "2022-11-30T19:48:56Z")

</div>

Agreed: makes it more consistent and easier to remember.

---

<div class="post-metadata">

**Author:** ![bradcray](https://yyz2.discourse-cdn.com/free1/user_avatar/chapel.discourse.group/bradcray/32/72_2.png) [@bradcray](https://chapel.discourse.group/u/bradcray)\
**Post date:** [January 10, 2023, 1:00am UTC](https://chapel.discourse.group/t/design-one-element-array-syntax/17680/3 "2023-01-10T01:00:23Z")

</div>

Hi Chapel Users & Devs —

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:

```diff
- var sorter = spawn(["sort"], stdin=pipeStyle.pipe, stdout=pipeStyle.pipe);
+ var sorter = spawn(["sort",], stdin=pipeStyle.pipe, stdout=pipeStyle.pipe);

```

or:

```diff
   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.

Thanks,  
-Brad

---

<div class="post-metadata">

**Author:** ![bradcray](https://yyz2.discourse-cdn.com/free1/user_avatar/chapel.discourse.group/bradcray/32/72_2.png) [@bradcray](https://chapel.discourse.group/u/bradcray)\
**Post date:** [February 13, 2023, 11:41pm UTC](https://chapel.discourse.group/t/design-one-element-array-syntax/17680/4 "2023-02-13T23:41:16Z")

</div>

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](https://github.com/chapel-lang/chapel/issues/21092%E2%80%94) 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:

> <https://github.com/chapel-lang/chapel/issues/21092>
>
> A one-tuple in Chapel is represented as \`(elem, )\` since simply \`(elem)\` is ambi…guous whether we mean a 1-tuple or simply a parenthesized expression. Meanwhile, for one-element array literals, we support either \`\[elem\]\` or \`\[elem, \]\`. I believe the reason for this is that there isn't the same sort of ambiguity.
> 
> \[This SO question\](https://stackoverflow.com/questions/74575947/chapel-ranges-defined-using-bounds-of-type-rangeint64-bounded-false-are) makes me wonder whether this is a mistake, since even though it is unambiguous, it could cause someone unfamiliar with the language to get a surprising result due to misplaced brackets. Whereas if the compiler gave them an error stating that \`\[expr\]\` is not a legal expression, and that if their goal was to get a one-element array literal they should add a trailing comma, then such mistakes would be less problematic. In saying this, I'm assuming that 1-element arrays are not likely to be all that common.
> 
> Making this change would also make 1-element arrays more consistent with 1-tuples, which seems mildly attractive.

Thanks,  
-Brad