[ruby-core:96420] [Ruby master Feature#16274] Transform hash keys by a hash

[sawadatsuyoshi@gmail.com]

Issue #16274 has been updated by sawa (Tsuyoshi Sawada).


As for the behavior when both a hash argument and a block are given, I suggested in the issue to have the block applied after the hash has applied:

**Original proposal**
```ruby
hash.transform_keys({created: :created_at, updated: :update_time}, &:to_s)
# => {"created_at" => ..., "update_time" => ..., "author" => ...}
```

But I reconsidered this, and now I think that the block should be applied to the residue of what the hash has applied. (In other words, the hash and the block should be applied mutually exclusively of each other, with the hash having priority over the block.) Hence, I expect the following results:

**New proposal**
```ruby
hash.transform_keys({created: :created_at, updated: :update_time}, &:to_s)
# => {:created_at => ..., :update_time => ..., "author" => ...}

hash.transform_keys({created: "created_at", updated: "update_time"}, &:to_s)
# => {"created_at" => ..., "update_time" => ..., "author" => ...}
```

The reason is twofold.

First, my original proposal would lead to redundancy; I would have to provide the intermediate key `:created_at`, `:update_time`, knowing that they will not appear in the final output because of the further transformation of them into strings due to the block. Providing the final keys `"created_at"` and `"update_time"` from the beginning would be more straightforward, and will save some internal calculations to be done by Ruby.

Second, the new proposal will have more expressive power. Suppose I actually wanted:

```ruby
{:created_at => ..., :update_time => ..., "author" => ...}
```

That can be done with the new proposal, but not with my original proposal.

----------------------------------------
Feature #16274: Transform hash keys by a hash
https://bugs.ruby-lang.org/issues/16274#change-83343

* Author: sawa (Tsuyoshi Sawada)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 2.8
----------------------------------------
We have `Hash#transform_keys` and its bang version to change the keys of a hash, but that requires passing a block, which assumes that the mapping from the old keys to the new keys follows some rule. But in reality, we frequently want to change the keys where it is difficult to provide a rule. For example, suppose we have:

```
hash = {created: 2019-10-23 17:54:46 +0900, updated: 2019-10-23 17:59:18 +0900, author: "foo"}
```

and want to achieve:

```
{created_at: 2019-10-23 17:54:46 +0900, update_time: 2019-10-23 17:59:18 +0900, author: "foo"}
```


I request an option to change the keys of a hash not by giving a block, but by passing a hash. I came up with two options.

### 1. Argument for `Hash#transform_keys` and its bang version

Allow `Hash#transform_keys` to optionally take a hash argument instead of a block.

```
hash.transform_keys({created: :created_at, updated: :update_time})
# => {created_at: 2019-10-23 17:54:46 +0900, update_time: 2019-10-23 17:59:18 +0900, author: "foo"}
```

### 2. Argument for `Hash#slice` and the counterparts in other classes

Since `Hash#slice` is often the first step of modifying a hash into some other hash form, it makes sense to let it take an optional hash argument.

```
hash.slice(:created, :author, transform_keys: {created: :created_at})
# => {created_at: 2019-10-23 17:54:46 +0900, author: "foo"}
```


With option 1, it could make sense to even allow a hash argument and a block simultaneously:

```
hash.transform_keys({created: :created_at, updated: :update_time}, &:to_s)
# => {"created_at" => 2019-10-23 17:54:46 +0900, "update_time" => 2019-10-23 17:59:18 +0900, "author" => "foo"}
```




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