[andolanra]

Since Ruby 3, the automatic coercion of keywords to a hash—the second example underneath "Passing Hash to Functions" in this post—is considered a legacy style and is generally frowned upon in new code. That is to say, code like the second call to `foo` here:

    def foo(kwargs = {})
      kwargs
    end
    
    foo({k: 1})  # ok: passing hash argument
    foo(k: 1)    # ok: keywords coerced to hash

One of the strongest arguments for avoiding this sugar is that it makes the code more brittle in the face of future changes. In particular, in the example above, if we add a new keyword argument to `foo`, then any call which omitted the curly braces will break, while calls which used them will keep working fine:

    # added a new keyword arg here
    def foo(kwargs = {}, frob: false)
      kwargs
    end
    
    foo({k: 1})  # still ok: `frob` defaults to false
    foo(k: 1)    # ArgumentError: no keyword: :k

This is touched on in the blog post describing the extensive changes made to keywords in Ruby 3: https://www.ruby-lang.org/en/news/2019/12/12/separation-of-p...

[Klonoar]

This might be me having huffed too many types lately, but I feel like I would want that to break.

[mcv]

Adding a parameter that has a sensible default value? I don't think I'd want that to break anything.

[Klonoar]

The inverse here - specifying {} directly - does not at a glance imply a default value is being constructed.

(Or perhaps it does and this is just some Ruby-ism I'm not exposed to)

[andolanra]

That's kind of the point of default values, though. If you wanted to make a change to the method and you want it to break to alert you to all the calls, then you can add a keyword without adding a default value for it.

    def foo(kwargs = {}, frob:)
      kwargs
    end

[software_writer]

You're right, thanks for the demo and sharing the link, really appreciated. I'll update the article to mention this.