Manfred Kooistra
2026-May-02 07:24 UTC
[Rd] Feature request: Allow comma after last element in a list
Thank you all for the suggested workarounds and feedback!
Here is one other easy and practicable workaround:
c(
1,
2,
3,
recursive = FALSE)
Is is not as brief as Gabor Grothendieck's suggested workaround of c(... ,
NULL), which is also visually easier to parse and logically more intuitive, and
which I already have adopted.
For my purposes, my feature request has thus been satisfyingly answered and my
problem has been solved.
* * *
[ Below are some additional thoughts not relevant to the discussion. ]
While following the discussion, I realized that in my mind,
c(1,2,3)
is not the same as
c(
1,
2,
3
)
even though they result in the same object. As I use them, the first is a
"list", the second is a "table", if with only one column.
When I manually maintain tabular data, I commonly use
read.table(textConnection("
1 A 12.3
2 B 45.6
"), header = ..., colClasses = c(...))
which easily allows me to add, delete, or rearrange rows. Here, the end of line
serves to separate the individual data points, and no comma is necessary
anywhere. This practice is what lead to my expectation to be able to use c() in
the same way.
Understanding how my expectation arose gave me the idea to use
scan(textConnection("
1
2
3
"), what = numeric(), sep = "\n")
as another possible workaround for vectors in which elements need to be easily
rearranged.
@vi@e@gross m@iii@g oii gm@ii@com
2026-May-02 16:04 UTC
[Rd] Feature request: Allow comma after last element in a list
I am glad this discussion exposed some ideas and alternatives.
I did scratch my head a bit at this latest solution as it made me question
what the original need was and how it was fulfilled, up to a point.
The solution offered was to end the "list" of comma separated items
not with
a comma, but a comma followed by an optional argument like:
c(
1,
2,
3,
recursive = FALSE)
I looked it up and indeed the c() function has two optional arguments
available. (The other is use.names).
And this not only works with the added argument at the end, but anywhere, if
used only once as in:
c(
1,
recursive = FALSE,
2,
3)
But this poses a problem in that sometimes you want it set to TRUE. After
multiple edits where additional data is added or changed, you could end up
with something like this that fails:
c(
1,
recursive = FALSE,
2,
alpha,
recursive = TRUE)
As I see it, it is not a clean solution. Having every line ending with a
comma allows all kinds of manipulations such as cut/paste to re-arrange
lines of code and adding a line at the end is clean if you remember to leave
a trailing comma.
Not all functions that you might normally provide a list of such arguments
come necessarily with an extra option like this, either.
As I see it, there is convenience for some at the expense of others who want
errors caught. If you compare the situation to something like an English
sentence where you have commas and the penultimate one often is extended
with "and" you may see that rules are not always made just for one
kind of
convenience.
"I bought milk, eggs, and SPAM."
Or is it
"I bought milk, eggs and SPAM."
But normally not
"I bought milk, eggs, SPAM."
Humans adjust and I suggest programmers can too. If the rule is no terminal
comma, then when editing, just follow the rule. The use of comma followed by
NULL at the end (or it seems anywhere, seems perfectly fine for those who
need it.
The problem may largely be one for people who use multiple languages to
program in that have different ways. The reality is they tend to be
different in many other ways too and need not all march in lockstep.
-----Original Message-----
From: R-devel <r-devel-bounces at r-project.org> On Behalf Of Manfred
Kooistra
Sent: Saturday, May 2, 2026 3:25 AM
To: r-devel at r-project.org
Subject: Re: [Rd] Feature request: Allow comma after last element in a list
Thank you all for the suggested workarounds and feedback!
Here is one other easy and practicable workaround:
c(
1,
2,
3,
recursive = FALSE)
Is is not as brief as Gabor Grothendieck's suggested workaround of c(... ,
NULL), which is also visually easier to parse and logically more intuitive,
and which I already have adopted.
For my purposes, my feature request has thus been satisfyingly answered and
my problem has been solved.
* * *
[ Below are some additional thoughts not relevant to the discussion. ]
While following the discussion, I realized that in my mind,
c(1,2,3)
is not the same as
c(
1,
2,
3
)
even though they result in the same object. As I use them, the first is a
"list", the second is a "table", if with only one column.
When I manually maintain tabular data, I commonly use
read.table(textConnection("
1 A 12.3
2 B 45.6
"), header = ..., colClasses = c(...))
which easily allows me to add, delete, or rearrange rows. Here, the end of
line serves to separate the individual data points, and no comma is
necessary anywhere. This practice is what lead to my expectation to be able
to use c() in the same way.
Understanding how my expectation arose gave me the idea to use
scan(textConnection("
1
2
3
"), what = numeric(), sep = "\n")
as another possible workaround for vectors in which elements need to be
easily rearranged.
______________________________________________
R-devel at r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel