Project

General

Profile

Actions

Feature #21973

closed

Smile argument

Feature #21973: Smile argument
7

Added by kinoppyd (Yasuhiro Kinoshita) 3 months ago. Updated 3 days ago.

Status:
Rejected
Assignee:
-
Target version:
-
[ruby-core:125157]

Description

Ruby makes us smile. So I want Ruby to smile too, and that is why I would like to propose this feature.

The smile argument makes Ruby smile by allowing a method call to end its argument list with :).

smile_method(arg, :)

This syntax implicitly supplies keyword arguments by matching the names of local variables in the current scope with the names of the method’s keyword parameters.

For example, if a method has the following signature:

some_method(arg, smile:, hugging:)

then these two calls would be equivalent:

arg = "hello"  
smile = "smile"  
hugging = "hugging"  
some_method(arg, smile:, hugging:)
arg = "hello"  
smile = "smile"  
hugging = "hugging"  
some_method(arg, :)

The motivation behind this feature is the assumption that names used in a method signature are often also used at the call site.

For instance, if a library method defines keyword arguments like (from:, to:), I expect that code using that method would often have local variables named from and to holding the actual values before passing them along.

In real application development, when developers adopt a new library, they will usually look at the argument list of the method they want to call. If they intend to use that method as designed, it seems natural that they may also choose the same variable names as those in the method signature.

This idea was inspired by Scala’s implicit parameters. It is not exactly the same feature, but as a lazy person, I find the idea of context-driven currying quite appealing.

In any case, the real purpose is to make Ruby smile.

Happy Ruby! And happy April Fools' Day!


Files

clipboard-202603312047-a8wkw.png (30.3 KB) clipboard-202603312047-a8wkw.png vo.x (Vit Ondruch), 03/31/2026 06:47 PM

Updated by ko1 (Koichi Sasada) 3 months ago 1Actions #1 [ruby-core:125159]

Implementation should be easy like that :)

def q(a:, b:1)
  p a:, b: #=> {a: 10, b: 20}
end

def smile_send mid, b, *params
  h = {}

  method(mid).parameters.each do |(type, key)|
    case type
    when :keyreq
      h[key] = b.local_variable_get(key)
    when :key
      h[key] = b.local_variable_get(key) if binding.local_variable_defined?(key)
    else
      raise
    end
  end

  send mid, *params, **h
end

a = 10
b = 20

# q( :) #=> will be compiled to
smile_send :q, binding

Updated by vo.x (Vit Ondruch) 3 months ago 1Actions #2 [ruby-core:125160]

My email client does not like this proposal:


Maybe :)) (even bigger smile) should be considered instead?

Updated by matz (Yukihiro Matsumoto) 3 days ago Actions #3 [ruby-core:125703]

  • Status changed from Open to Rejected

Thanks for the proposal. I'd like to decline.

Ruby already lets you omit values in the keyword shorthand: some_method(arg, smile:, hugging:) is equivalent to some_method(arg, smile: smile, hugging: hugging). That covers most of the brevity, while keeping the keyword names visible at the call site.

What :) adds is making the names themselves disappear. When I read some_method(arg, :), I cannot tell from the call site what is being passed. I have to look up the method definition. The keyword names at the call site are not just noise: they serve as documentation, and they make the call robust against changes in the method's keyword list. If the method later renames a keyword, an explicit caller breaks loudly, while a :) caller may silently pick up an unrelated local variable or fail in a more confusing way.

Concise and easy to read are not the same thing. Here I'd rather keep the names.

Matz.

Actions

Also available in: PDF Atom