[ruby-core:109720] [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-17:
> @austin your latest example has 110 symbols, the condition should be duplicated for each new hash key, as well as the ternary operator, so it's not good. Previous example has 294 symbols – it'll need more tests, because more code == more bugs and maintenance efforts.

This is — at its absolute most generous interpretation — a simplistic way of looking at code quality. There’s a reason that we don’t all code in APL, which by your measure, would have the least number of symbols.

Your examples increase the line-noise that detractors of Ruby point at without doing *anything* to increase the maintainability and readability of said code, and IMO do a lot to *decrease* the maintainability of said code because you can’t just *see* the configuration, you have to read the entire line of *each* configuration line.

Given how tightly you’re defending objectively unreadable code, I think that’s more than enough reason to reject this feature, because there will be people who write code as unmaintainable as you’ve championed on this.

As I’ve said: there may be a good reason for such graceful handling—preferably by changing kw splatting from `#to_hash` to `#to_h`(as @dan0042) suggests—but I can’t see anything you’ve written as example code as being a good argument in favour of it, because it’s (1) wasteful, (2) noisy, and (3) *impossible* to write good tests for in application code.

Matz & the core team generally only approve things which have strong real-world use cases. Both @sawa and I have provided *better* options than your examples.

For your example, I think that a far better option would be to make it so that `Hash#merge`, `Hash#merge!` and `Hash#update` ignore `nil` parameters.

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

But that would be an entirely *different* feature request. I still think it’s bad code to put the logic in the parameter call, but it’s still better than `**({ id: id, name: name } if id.present?)` which is *clever*, but ultimately unmaintainable for future you.

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

* 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>