Skip to content

Handle forwarding parameters in parser#578

Open
Morriar wants to merge 1 commit intomainfrom
at/handle-forwarding-params
Open

Handle forwarding parameters in parser#578
Morriar wants to merge 1 commit intomainfrom
at/handle-forwarding-params

Conversation

@Morriar
Copy link
Copy Markdown
Contributor

@Morriar Morriar commented Apr 2, 2026

Summary

Expand ... (ForwardingParameterNode) into *args, **kwargs, &block instead of crashing with an unexpected parameter error.

Based on #562 by @kddnewton — simplified the approach to avoid wrapping every case in arrays: just mapflat_map and a single new when branch.

Includes test for both def m1(...) and def m2(a, ...).

Closes #562

Expand `...` (ForwardingParameterNode) into `*args, **kwargs, &block`
instead of crashing with an unexpected parameter error.

Based on #562
@Morriar Morriar requested a review from a team as a code owner April 2, 2026 22:06
@vinistock
Copy link
Copy Markdown
Member

I think the changes are fine, but I do want to confirm one aspect of this. There one minor difference before ... and the expansion, which is the fact that you cannot refer to specific parameter parts when using .... For example:

def foo(...)
  # there's no way to use forwarding parameters that isn't including all
  # of them. I can't print only the keyword ones or refer exclusively to the block
end

def bar(*args, **kwargs, &block)
  # Here, while equivalent at the call site (accepts any argument), I can refer
  # to the individual parameter parts
end

Is this something we need to be concerned about? Would it be better to have RBI print the forwarding parameter instead?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants