[ruby-core:109700] [Ruby master Feature#18959] Handle gracefully nil kwargs eg. **nil

Issue #18959 has been updated by austin (Austin Ziegler).


LevLukomskyi (Lev Lukomskyi) wrote in #note-14:
> @austin, your example is a perfect example of "overengineering".

On this, we disagree. I find the number of sigils required for `**({ id: id, name: name } if id.present?)` to be a sure sign that someone is trying to be clever, rather than correct.

> We could argue about "clearness", although about "conciseness" it's easy to check – option 1: 72 characters, option 2: 62 characters, so option 2 is 15% more concise, clear winner.

Except that it’s not a clear winner at all. It means that I have to look at every single parameter to see the logic that applies to that parameter, which means that there’s a *substantially* increased surface for bugs. I can write a *test* for `resolve_options` to make sure it always does the right thing. I can’t do that for inline `if id.present?` cases. If you don’t like the separate method `resolve_options`, then use ternaries:

```ruby
some_function({
  some: 'value',
  id: id.present? ? id : :omit,
  name: id.present? ? name : :omit
}.delete_if { _2 == :omit })
```

Yes, I’m using `== :omit` instead of `_2.nil?` because nil may be a permitted value in the API being called, and I don’t know that. But a `resolve_options` method on the class where `some_function` is defined could know that.

> > > it has a high probability for compatibility issues
> 
> Currently, nobody is using `**nil` because it throws an error because `nil.to_hash` is not defined. So I don't see how adding such feature would lead to _"high probability of compatibility issues"_.

Daniel DeLorme points out some oddities that would be involved with a monkeypatch above: https://bugs.ruby-lang.org/issues/18959#note-3 

Yes, this feature *could* be useful, but I also think that your example use cases are code that I would never permit because it’s clever over clear.

----------------------------------------
Feature #18959: Handle gracefully nil kwargs eg. **nil
https://bugs.ruby-lang.org/issues/18959#change-98926

* Author: LevLukomskyi (Lev Lukomskyi)
* Status: Open
* Priority: Normal
----------------------------------------
The issue:

```ruby
def qwe(a: 1) end

qwe(**nil) #=> fails with `no implicit conversion of nil into Hash (TypeError)` error

{ a:1, **nil } #=>  fails with `no implicit conversion of nil into Hash (TypeError)` error
```

Reasoning:

I found myself that I often want to insert a key/value to hash if a certain condition is met, and it's very convenient to do this inside hash syntax, eg.:

```ruby
{
  some: 'value',
  **({ id: id } if id.present?),
}
```

Such syntax is much more readable than:

```ruby
h = { some: 'value' }
h[:id] = id if id.present?
h
```

Yes, it's possible to write like this:

```ruby
{
  some: 'value',
  **(id.present? ? { id: id } : {}),
}
```

but it adds unnecessary boilerplate noise.

I enjoy writing something like this in ruby on rails:

```ruby
content_tag :div, class: [*('is-hero' if hero), *('is-search-page' if search_page)].presence
```

If no conditions are met then the array is empty, then converted to nil by `presence`, and `class` attribute is not rendered if it's nil. It's short and so convenient! There should be a similar way for hashes!

I found this issue here: https://bugs.ruby-lang.org/issues/8507 where "consistency" thing is discussed. While consistency is the right thing to do, I think the main point here is to have fun with programming, and being able to write stuff in a concise and readable way.

Please, add this small feature to the language, that'd be so wonderful! 🙏



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

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