Feature #21875: Handling of trailing commas in lambda parameters

• Status: Open
• Assignee: -
• Target version: -

[Earlopain (Earlopain _)]

https://bugs.ruby-lang.org/issues/19107 was accepted, which is about trailing commands in method definitions.

lambdas were not explicitly mentioned but I wanted to confirm how they should behave with a trailing comma. Or if a trailing comma should even be accepted for them.

It's not clear to me since lambdas sometimes behave like blocks and sometimes more like methods. ->(...) {} for example is syntax invalid (same as in blocks) but they do check their arity with blocks don't do.

If a trailing comma is accepted it can either

• be implicit splat like in foo do |bar,|; end or foo do |bar|; end. It would also mean that the trailing comma is only allowed after a positional argument.
• Just be ignored and be accepted in most places like for method definitions.

The first option would be rather useless in regards to https://bugs.ruby-lang.org/issues/19107 when you just want to add the comma for cleaner diffs. But I guess for lambdas this happens very rarely anyways.

[Earlopain (Earlopain _)]

• Related to Feature #19107: Allow trailing comma in method signature added

[Eregon (Benoit Daloze)]

There is also lambda { |a,| a } which as far as I can tell ignores the trailing comma:

irb(main):015> proc { |a,| a }.call([1,2])
=> 1
irb(main):016> lambda { |a,| a }.call([1,2])
=> [1, 2]
irb(main):017> -> (a,) { a }
<internal:kernel>:168:in 'Kernel#loop': (irb):17: syntax error found (SyntaxError)

irb(main):020> proc { |a,| a }.call(1,2)
=> 1
irb(main):021> lambda { |a,| a }.call(1,2)
(irb):21:in 'block in <top (required)>': wrong number of arguments (given 2, expected 1) (ArgumentError)
irb(main):022> lambda { |a,*| a }.call(1,2)
=> 1

I think since there seems to be no need to change anything for lambdas/procs in this regard I would suggest to change nothing.

It's extremely rare to have a multi-line definition of lambda arguments (parameters), isn't it?
So let's not make the semantics more complicated or incompatible for such a case.

IOW I think you raise a good point and it's sufficiently different from methods to be treated differently.

[Hanmac (Hans Mackowiak)]

there are functions that look for the amount of parameters that gets spooked by this:

data = {
  'a' => 1,
  'b' => 2,
  'c' => 3
  }

data.each &proc {|a,| p a } #=> "a", "b", "c"

data.each &lambda {|a,| p a } #=>["a", 1], ["b", 2], ["c", 3]

[nobu (Nobuyoshi Nakada)]

Earlopain (Earlopain _) wrote:

If a trailing comma is accepted it can either

• be implicit splat like in foo do |bar,|; end or foo do |bar|; end. It would also mean that the trailing comma is only allowed after a positional argument.

Rather I think it should be allowed even after optional/rest/keyword/keyword-rest arguments in block parameters too.

[Eregon (Benoit Daloze)]

nobu (Nobuyoshi Nakada) wrote in #note-4:

Rather I think it should be allowed even after optional/rest/keyword/keyword-rest arguments in block parameters too.

Wouldn't that be very confusing then because proc { |a,| a }.call([1,2]) => 1 splats but proc { |a, kw: 1,| a }.call([1,2]) => [1, 2] wouldn't splat? That is the comma would have very different meaning based on its position.

It seems far safer to keep things as-is, rather than introduce semantic ambiguity without even a use case for this change (multiline lambda/block parameters are very rare).

How about closing this for now (keep things as-is) since there is no use case and there are clear disadvantages/problems?