Ruby’s Triple-Dot Operator: Argument Forwarding from 2.7 to 4.0

If you’ve ever written a method whose entire job is to pass its arguments straight through to another method, you’ve felt this pain:

class Repository
  def find(id, *args, **kwargs, &block)
    connection.find(id, *args, **kwargs, &block)
  end
end

Three parameter types, three splat operators, zero information conveyed. Ruby 2.7 solved this with a single token: ...

The problem it solves

... is Ruby’s argument forwarding shorthand. It captures everything passed to a method – positional args, keyword args, and a block – and lets you re-throw it at another method without naming a single one of them.

def find(...)
  connection.find(...)
end

Same behavior as the splat version above, minus the noise. It behaves like a bare super with parens: “take what I got, send it onward, unchanged.”

Ruby 2.7: the baseline

... shipped in Ruby 2.7 (Dec 2019) with one hard restriction: it has to be the only parameter in the definition, and the only argument in the call. You can’t mix it with named params, and you can’t inspect or transform the forwarded values.

def log_call(...)
  puts "calling..."
  perform(...)
end
def perform(*args, **kwargs, &block)
  block.call(args, kwargs)
end
log_call(1, 2, k: 3) { |a, k| p [a, k] }
# => [[1, 2], {k: 3}]

Clean, but rigid – useful only for pure pass-through wrappers (logging, memoization, decorators).

Ruby 3.0: leading arguments

Ruby 3.0 (Dec 2020) lifted the “must be alone” rule. You can now peel off one or more leading positional arguments before the ..., in both the definition and the call site:

def method_missing(name, ...)
  send(:"do_#{name}", ...)
end

This is the textbook use case – method_missing needs the method name for dispatch logic, but everything else should flow through untouched:

def transform(a, ...)
  process(a, ...)
end
def process(a, *args, **kwargs, &block)

[a, args, kwargs]

end transform(1) # => [1, [], {}] transform(1, 2, k: 3) # => [1, [2], {k: 3}]

This turned ... from a niche decorator trick into something you’d actually reach for in delegation-heavy code – Rails controllers forwarding to services, DSL builders, proxy objects.

Ruby 3.1: anonymous block forwarding

Ruby 3.1 (Dec 2021) split the block piece out on its own. If you only need to forward the block and want the positional/keyword args handled explicitly, use a bare &:

def perform(&)
  execute(&)
end

No name required on either side. This composes with regular named params:

def retry_with(times:, &)
  times.times { execute(&) }
end

Ruby 3.2: anonymous splat and double-splat

Ruby 3.2 (Dec 2022) completed the set, adding anonymous * and ** forwarding to match the anonymous & from 3.1:

def split_arguments(*, **)
  pass_positional(*)   # forwards only positional args
  pass_keywords(**)    # forwards only keyword args
end
split_arguments(1, 2, a: 3, b: 4)
# pass_positional(1, 2)
# pass_keywords(a: 3, b: 4)

This matters when a method needs to route positional and keyword args to different destinations – ... can’t do that, since it moves as one atomic bundle.

Ruby 3.3 / 3.4 / 4.0: no new syntax, better tooling

No further language changes landed for ... itself through 3.3, 3.4, or Ruby 4.0 (released Dec 2025). Two things worth knowing if you’re on current Ruby:

• RBS gained first-class support for forwarding parameters in method type signatures in 2026 (def request: (...) -> Response), so type-checked codebases no longer have to erase forwarded signatures to untyped.
• Ruby 4.0 changed splat semantics slightly: *nil no longer calls nil.to_a, and **nil no longer calls nil.to_hash. It’s not a ...-specific change, but if you forward keyword args that might legitimately be nil (e.g., **opts where opts defaults to nil), check this – it’ll raise instead of silently treating nil as {}.

Version cheat sheet

If you’re targeting older runtimes: 2.7 and 3.0 are long past EOL, 3.1 EOL’d in 2025, and only 3.2+ receives active support as of this writing. Practically, any codebase forwarding arguments today should assume 3.2+ and use whichever granularity (..., &, *, **) fits the delegation.

Where I’d push back on using it

... is DRY, but it’s opaque. def foo(...) tells a reader nothing about the method’s actual contract – they have to chase the call chain to find out what foo accepts. For a pure pass-through utility (logging wrapper, method_missing dispatch, a thin repository shim), that opacity is the whole point and it’s the right call. For a public API boundary – a service object’s entry point, a gem’s documented interface – I’d argue explicit named parameters (or at minimum RBS/Sorbet signatures) win, because the signature is the documentation, and ... erases it at the exact place callers look first.

A second edge case: you can’t currently pass extra trailing arguments after a forwarded ... in a call (bar(extra, ...) is still restricted) – only leading ones. If you need to inject an argument after the forwarded set, you’re back to explicit *args, **kwargs, &block.

Rule of thumb: reach for ... (or &/*/**) at internal delegation boundaries where the wrapper genuinely adds no new arguments of its own. Keep explicit signatures at any boundary another engineer – or a type checker – needs to reason about without reading the delegate.

Happy Rubying!

Author: Abhilash

Hi, I’m Abhilash! A seasoned web developer with 15 years of experience specializing in Ruby and Ruby on Rails. Since 2010, I’ve built scalable, robust web applications and worked with frameworks like Angular, Sinatra, Laravel, Node.js, Vue and React. Passionate about clean, maintainable code and continuous learning, I share insights, tutorials, and experiences here. Let’s explore the ever-evolving world of web development together! View all posts by Abhilash