Issue #12157 has been updated by Colin Fulton.


# Examples

Currently Ruby has syntactic sugar to make passing a Hash as a final argument prettier. Consider the following:

```ruby
def foo(arg1, arg2, option_hash)
  option_hash
end
```

If someone doesn't know about the options hash syntactic sugar they can write:

```ruby
foo("hello", "world", { color: "blue", pugs: "awesome" })
  # => { :color => "blue", :pugs => "awesome" }

foo("hello", "world", { "color" => "blue", "pugs" => "awesome" })
  # => { "color" => "blue", "pugs" => "awesome" }
```

**However**, the options hash syntactic sugar allows one to write:

```ruby
foo("hello", "world", color: "blue", pugs: "awesome")
  # => { :color => "blue", :pugs => "awesome" }

foo("hello", "world", "color" => "blue", "pugs" => "awesome")
  # => { "color => "blue", "pugs" => "awesome" }

```

The curly braces get added to the arguments list _implicitly_ as long as the hash is the last argument. This makes it even more possible to write a lot of really great looking DSLs in Ruby.

[Ruby 2.0 and 2.1 added named parameters](https://robots.thoughtbot.com/ruby-2-keyword-arguments) and the [double splat syntax](https://dev.firmafon.dk/blog/drat-ruby-has-a-double-splat/), which can look identical to an options hash when calling, but named arguments are more explicit in the method definition:

```ruby
def bar(arg1, arg2, **option_hash)
  option_hash
end
```

Here is a call to `#bar`:

```ruby
bar("hello", "world", color: "blue", pugs: "awesome")
  # => { :color => "blue", :pugs => "awesome" }
```

Unlike named arguments, options hashs allow you to have keys which are not symbols, but I haven't seen many places where that is needed. Named arguments have the big benefits that they give you the ability have required keys, and they make methods easier to read. You don't have to dig through the method's source to see what keys are expected, you only have to look at the parameters list. With options hashes you have to though the code to see what keys are required.

# Discussion
The issue is that having both the options hash syntactic sugar AND named arguments at the same time causes some weird corner cases (see: #12022, #10708, and #11860).

The question I am putting forward is this: _what do we value as more important?_

Is the special syntax for options hashes so important that we we should allow for those edge cases to exist? This may be the case. If so, then what do we want to do with the edge cases? Currently the edge cases almost always assume that you meant to write an options hash, **but** #12022 shows that that makes things like decorators really ugly to write.

Personally I think that we should keep options hashes _but_ we should fix those edge cases to assume that the author means to use named arguments instead of an options hash. Named hashes are often a much cleaner and more powerful solution, so we should favor people using them.

----------------------------------------
Feature #12157: Is the option hash necessary for future Rubys?
https://bugs.ruby-lang.org/issues/12157#change-57388

* Author: Colin Fulton
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
Option hashes were great before Ruby had named arguments, but with the addition of named arguments and the double splat operator are they still needed?

One can convert named arguments into an option hash by using the double splat operator in the parameter list, so option hashes are redundant. More importantly, the existence of both option hashes and named arguments is creating odd or ugly edge cases. See #12022, #10708, and #11860. Legacy software can mostly be updated using a double splatted parameter, so it shouldn't be a hard shift to make.

What do you all think?

_Apologies if this discussion has happened before. I searched for a bit but couldn't turn anything up._



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>