[ruby-core:96731] [Ruby master Feature#16494] Allow hash unpacking in non-lambda Proc

[ruby-core:96731] [Ruby master Feature#16494] Allow hash unpacking in non-lambda Proc

[zverok.offline]

Issue #16494 has been reported by zverok (Victor Shepelev).

----------------------------------------
Feature #16494: Allow hash unpacking in non-lambda Proc
https://bugs.ruby-lang.org/issues/16494

* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
First of all, I fully understand the value of separating "real" keyword arguments and disallowing implicit and unexpected conversions to/from hashes.

There is, though, one **convenient style which is now broken**:
```ruby
# words is array of hashes:
words
  .map { |text:, paragraph_id:, **rest| 
    {text: text.strip, paragraph_id: paragraph_id.to_i, **rest}
  }
  .reject { |text:, is_punctuation: false, **| text.end_with?('!') || is_punctuation }
  .chunk { |paragraph_id:, timestamp: 0, **| [paragraph_id, timestamp % 60] }
  # ...and so on
```
There is several important elements to this style, making it hard to replace:

* informative errors on unexpected data structure ("missing keyword: text")
* ability to provide default values
* clear separation of declaration "what this block expects" / "what it does with expected data", especially valuable in data processing pipelines

One may argue that in some Big Hairy Very Architectured Application you should instead wrap everything in objects/extract every processing step into method or service/extract validation as a separate concern etc... But in smaller utility scripts, or deep inside of complicated algorithmic libraries, the ability to write short and clear code with explicitly declared and controlled by language arguments is pretty valuable.

This style has *no clean alternative*, all possible alternatives are either less powerful or much less readable. Compare:

```ruby
# Try to rewrite this:
words.map { |text:, paragraph_id:, timestamp: 0, is_punctuation: false|
  log.info "Processing #{timestamp / 60} minute"
  full_text = is_punctiation ? text : text + ' '
  "<span class='word paragraph-#{paragraph_id}' data-time=#{timestamp} data-original-text=#{text}>#{full_text}</span>"
}

# Alternative with just hashes:
words.map { |word|
  # those two used several times
  text = word.fetch(:text)
  timestamp = word.fetch(:timestamp, 0)
  log.info "Processing #{timestamp / 60} minute"
  # Absent is_punctuation is ok, it default to false
  full_text = word[:is_punctiation] ? text : text + ' '
  "<span class='word paragraph-#{word.fetch(:paragraph_id)}' data-time=#{timestamp} data-original-text=#{text}>#{full_text}</span>"
}

# Alternative with pattern-matching: to unpack variables, and handle default values, it will be something like...
case word
in text:, paragraph_id:, timestamp:
  # skip, just unpacked
in text:, paragraph_id: # no timestamp:
  timestamp = 0
end
# I am even not trying to handle TWO default values
```

As shown above, `Hash#fetch`/`Hash#[]` style makes it much harder to understand what block expects hash to have, and how it uses hash components — and just makes the code longer and less pleasant to write and read. Pattern-matching (at least for now) is just not powerful enough for this particular case (it also has non-informative error messages, but it obviously can be improved).

My **proposal** is to **allow implicit hash unpacking** into keyword arguments in **non-lambda procs**. It would be **consistent** with implicit array unpacking, which is an important property of non-lambda procs, useful for reasons *very similar to described above*.



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

[ruby-core:96839] [Ruby master Feature#16494] Allow hash unpacking in non-lambda Proc

[mame]

Issue #16494 has been updated by mame (Yusuke Endoh).


The background of this proposal: https://bugs.ruby-lang.org/issues/14183#note-101

My personal feelings is the same as Jeremy; I'm negative because allowing the automatic Hash conversion makes the semantics complicated.  However, the argument semantics of non-lambda Proc are already a mess :-)  So it might be possible, though I don't like it.

However, we need to confirm if there are so many real-world use cases that rely on the old behavior.  Currently, we have only one practical case found in rubocop in the discussion above, which has been already fixed (thanks to @koic!).  IMO, it is far from enough to change it.

----------------------------------------
Feature #16494: Allow hash unpacking in non-lambda Proc
https://bugs.ruby-lang.org/issues/16494#change-83842

* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
First of all, I fully understand the value of separating "real" keyword arguments and disallowing implicit and unexpected conversions to/from hashes.

There is, though, one **convenient style which is now broken**:
```ruby
# words is array of hashes:
words
  .map { |text:, paragraph_id:, **rest| 
    {text: text.strip, paragraph_id: paragraph_id.to_i, **rest}
  }
  .reject { |text:, is_punctuation: false, **| text.end_with?('!') || is_punctuation }
  .chunk { |paragraph_id:, timestamp: 0, **| [paragraph_id, timestamp % 60] }
  # ...and so on
```
There is several important elements to this style, making it hard to replace:

* informative errors on unexpected data structure ("missing keyword: text")
* ability to provide default values
* clear separation of declaration "what this block expects" / "what it does with expected data", especially valuable in data processing pipelines

One may argue that in some Big Hairy Very Architectured Application you should instead wrap everything in objects/extract every processing step into method or service/extract validation as a separate concern etc... But in smaller utility scripts, or deep inside of complicated algorithmic libraries, the ability to write short and clear code with explicitly declared and controlled by language arguments is pretty valuable.

This style has *no clean alternative*, all possible alternatives are either less powerful or much less readable. Compare:

```ruby
# Try to rewrite this:
words.map { |text:, paragraph_id:, timestamp: 0, is_punctuation: false|
  log.info "Processing #{timestamp / 60} minute"
  full_text = is_punctiation ? text : text + ' '
  "<span class='word paragraph-#{paragraph_id}' data-time=#{timestamp} data-original-text=#{text}>#{full_text}</span>"
}

# Alternative with just hashes:
words.map { |word|
  # those two used several times
  text = word.fetch(:text)
  timestamp = word.fetch(:timestamp, 0)
  log.info "Processing #{timestamp / 60} minute"
  # Absent is_punctuation is ok, it default to false
  full_text = word[:is_punctiation] ? text : text + ' '
  "<span class='word paragraph-#{word.fetch(:paragraph_id)}' data-time=#{timestamp} data-original-text=#{text}>#{full_text}</span>"
}

# Alternative with pattern-matching: to unpack variables, and handle default values, it will be something like...
case word
in text:, paragraph_id:, timestamp:
  # skip, just unpacked
in text:, paragraph_id: # no timestamp:
  timestamp = 0
end
# I am even not trying to handle TWO default values
```

As shown above, `Hash#fetch`/`Hash#[]` style makes it much harder to understand what block expects hash to have, and how it uses hash components — and just makes the code longer and less pleasant to write and read. Pattern-matching (at least for now) is just not powerful enough for this particular case (it also has non-informative error messages, but it obviously can be improved).

My **proposal** is to **allow implicit hash unpacking** into keyword arguments in **non-lambda procs**. It would be **consistent** with implicit array unpacking, which is an important property of non-lambda procs, useful for reasons *very similar to described above*.



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

[ruby-core:96841] [Ruby master Feature#16494] Allow hash unpacking in non-lambda Proc

[zverok.offline]

Issue #16494 has been updated by zverok (Victor Shepelev).


> I'm negative because allowing the automatic Hash conversion makes the semantics complicated. However, the argument semantics of non-lambda Proc are already a mess :-) So it might be possible, though I don't like it.

I don't think it is a "mess". I think it is the "right" kind of complication to make code more easy to write. As I've already written elsewhere, there is a non-neglectable gap between what is "consistent" for computers, and what is "consistent" for humans. 

> However, we need to confirm if there are so many real-world use cases that rely on the old behavior.

My proposal, in its essence, is not "please preserve the 'old' behavior, because otherwise, it would break something".

It is "please see this behavior as a modern and consistent way to use Ruby, which should not be broken by argument separation". Not something that "well, generally, not recommended, but you _can_ do it", but as something that is seen as a "good and pretty thing, that should be promoted and used more".

I believe I am showcasing enough of the usability of the "unpacking" approach in the ticket itself (and it is not artificially constructed, just abstracted a bit example from the real-world app). I see two ways it can be refuted:

1. Show _equally clean and powerful_ way of doing things (which, I believe, is not possible, hence the ticket)
2. Say "it doesn't matter"/"doesn't look better"/"just rewrite it with separate methods", which will be the end of the discussion :)

----------------------------------------
Feature #16494: Allow hash unpacking in non-lambda Proc
https://bugs.ruby-lang.org/issues/16494#change-83844

* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
First of all, I fully understand the value of separating "real" keyword arguments and disallowing implicit and unexpected conversions to/from hashes.

There is, though, one **convenient style which is now broken**:
```ruby
# words is array of hashes:
words
  .map { |text:, paragraph_id:, **rest| 
    {text: text.strip, paragraph_id: paragraph_id.to_i, **rest}
  }
  .reject { |text:, is_punctuation: false, **| text.end_with?('!') || is_punctuation }
  .chunk { |paragraph_id:, timestamp: 0, **| [paragraph_id, timestamp % 60] }
  # ...and so on
```
There is several important elements to this style, making it hard to replace:

* informative errors on unexpected data structure ("missing keyword: text")
* ability to provide default values
* clear separation of declaration "what this block expects" / "what it does with expected data", especially valuable in data processing pipelines

One may argue that in some Big Hairy Very Architectured Application you should instead wrap everything in objects/extract every processing step into method or service/extract validation as a separate concern etc... But in smaller utility scripts, or deep inside of complicated algorithmic libraries, the ability to write short and clear code with explicitly declared and controlled by language arguments is pretty valuable.

This style has *no clean alternative*, all possible alternatives are either less powerful or much less readable. Compare:

```ruby
# Try to rewrite this:
words.map { |text:, paragraph_id:, timestamp: 0, is_punctuation: false|
  log.info "Processing #{timestamp / 60} minute"
  full_text = is_punctiation ? text : text + ' '
  "<span class='word paragraph-#{paragraph_id}' data-time=#{timestamp} data-original-text=#{text}>#{full_text}</span>"
}

# Alternative with just hashes:
words.map { |word|
  # those two used several times
  text = word.fetch(:text)
  timestamp = word.fetch(:timestamp, 0)
  log.info "Processing #{timestamp / 60} minute"
  # Absent is_punctuation is ok, it default to false
  full_text = word[:is_punctiation] ? text : text + ' '
  "<span class='word paragraph-#{word.fetch(:paragraph_id)}' data-time=#{timestamp} data-original-text=#{text}>#{full_text}</span>"
}

# Alternative with pattern-matching: to unpack variables, and handle default values, it will be something like...
case word
in text:, paragraph_id:, timestamp:
  # skip, just unpacked
in text:, paragraph_id: # no timestamp:
  timestamp = 0
end
# I am even not trying to handle TWO default values
```

As shown above, `Hash#fetch`/`Hash#[]` style makes it much harder to understand what block expects hash to have, and how it uses hash components — and just makes the code longer and less pleasant to write and read. Pattern-matching (at least for now) is just not powerful enough for this particular case (it also has non-informative error messages, but it obviously can be improved).

My **proposal** is to **allow implicit hash unpacking** into keyword arguments in **non-lambda procs**. It would be **consistent** with implicit array unpacking, which is an important property of non-lambda procs, useful for reasons *very similar to described above*.



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

[ruby-core:96848] [Ruby master Feature#16494] Allow hash unpacking in non-lambda Proc

[mame]

Issue #16494 has been updated by mame (Yusuke Endoh).


I remember.  I talked about the issue with matz before 2.7 release, and he said it does not matter.  He may have changed his mind, so I'll confirm him at the next meeting.

In my personal opinion, it matters if there are already many real-world use cases.  Otherwise, it does not matter.  I guess matz has the same feelings.  My current observation is that such a code is not so often written.

----------------------------------------
Feature #16494: Allow hash unpacking in non-lambda Proc
https://bugs.ruby-lang.org/issues/16494#change-83852

* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
First of all, I fully understand the value of separating "real" keyword arguments and disallowing implicit and unexpected conversions to/from hashes.

There is, though, one **convenient style which is now broken**:
```ruby
# words is array of hashes:
words
  .map { |text:, paragraph_id:, **rest| 
    {text: text.strip, paragraph_id: paragraph_id.to_i, **rest}
  }
  .reject { |text:, is_punctuation: false, **| text.end_with?('!') || is_punctuation }
  .chunk { |paragraph_id:, timestamp: 0, **| [paragraph_id, timestamp % 60] }
  # ...and so on
```
There is several important elements to this style, making it hard to replace:

* informative errors on unexpected data structure ("missing keyword: text")
* ability to provide default values
* clear separation of declaration "what this block expects" / "what it does with expected data", especially valuable in data processing pipelines

One may argue that in some Big Hairy Very Architectured Application you should instead wrap everything in objects/extract every processing step into method or service/extract validation as a separate concern etc... But in smaller utility scripts, or deep inside of complicated algorithmic libraries, the ability to write short and clear code with explicitly declared and controlled by language arguments is pretty valuable.

This style has *no clean alternative*, all possible alternatives are either less powerful or much less readable. Compare:

```ruby
# Try to rewrite this:
words.map { |text:, paragraph_id:, timestamp: 0, is_punctuation: false|
  log.info "Processing #{timestamp / 60} minute"
  full_text = is_punctiation ? text : text + ' '
  "<span class='word paragraph-#{paragraph_id}' data-time=#{timestamp} data-original-text=#{text}>#{full_text}</span>"
}

# Alternative with just hashes:
words.map { |word|
  # those two used several times
  text = word.fetch(:text)
  timestamp = word.fetch(:timestamp, 0)
  log.info "Processing #{timestamp / 60} minute"
  # Absent is_punctuation is ok, it default to false
  full_text = word[:is_punctiation] ? text : text + ' '
  "<span class='word paragraph-#{word.fetch(:paragraph_id)}' data-time=#{timestamp} data-original-text=#{text}>#{full_text}</span>"
}

# Alternative with pattern-matching: to unpack variables, and handle default values, it will be something like...
case word
in text:, paragraph_id:, timestamp:
  # skip, just unpacked
in text:, paragraph_id: # no timestamp:
  timestamp = 0
end
# I am even not trying to handle TWO default values
```

As shown above, `Hash#fetch`/`Hash#[]` style makes it much harder to understand what block expects hash to have, and how it uses hash components — and just makes the code longer and less pleasant to write and read. Pattern-matching (at least for now) is just not powerful enough for this particular case (it also has non-informative error messages, but it obviously can be improved).

My **proposal** is to **allow implicit hash unpacking** into keyword arguments in **non-lambda procs**. It would be **consistent** with implicit array unpacking, which is an important property of non-lambda procs, useful for reasons *very similar to described above*.



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

[ruby-core:96880] [Ruby master Feature#16494] Allow hash unpacking in non-lambda Proc

[daniel]

Issue #16494 has been updated by Dan0042 (Daniel DeLorme).


My alternative proposal to accomplish the same objective: #16511

----------------------------------------
Feature #16494: Allow hash unpacking in non-lambda Proc
https://bugs.ruby-lang.org/issues/16494#change-83892

* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
First of all, I fully understand the value of separating "real" keyword arguments and disallowing implicit and unexpected conversions to/from hashes.

There is, though, one **convenient style which is now broken**:
```ruby
# words is array of hashes:
words
  .map { |text:, paragraph_id:, **rest| 
    {text: text.strip, paragraph_id: paragraph_id.to_i, **rest}
  }
  .reject { |text:, is_punctuation: false, **| text.end_with?('!') || is_punctuation }
  .chunk { |paragraph_id:, timestamp: 0, **| [paragraph_id, timestamp % 60] }
  # ...and so on
```
There is several important elements to this style, making it hard to replace:

* informative errors on unexpected data structure ("missing keyword: text")
* ability to provide default values
* clear separation of declaration "what this block expects" / "what it does with expected data", especially valuable in data processing pipelines

One may argue that in some Big Hairy Very Architectured Application you should instead wrap everything in objects/extract every processing step into method or service/extract validation as a separate concern etc... But in smaller utility scripts, or deep inside of complicated algorithmic libraries, the ability to write short and clear code with explicitly declared and controlled by language arguments is pretty valuable.

This style has *no clean alternative*, all possible alternatives are either less powerful or much less readable. Compare:

```ruby
# Try to rewrite this:
words.map { |text:, paragraph_id:, timestamp: 0, is_punctuation: false|
  log.info "Processing #{timestamp / 60} minute"
  full_text = is_punctiation ? text : text + ' '
  "<span class='word paragraph-#{paragraph_id}' data-time=#{timestamp} data-original-text=#{text}>#{full_text}</span>"
}

# Alternative with just hashes:
words.map { |word|
  # those two used several times
  text = word.fetch(:text)
  timestamp = word.fetch(:timestamp, 0)
  log.info "Processing #{timestamp / 60} minute"
  # Absent is_punctuation is ok, it default to false
  full_text = word[:is_punctiation] ? text : text + ' '
  "<span class='word paragraph-#{word.fetch(:paragraph_id)}' data-time=#{timestamp} data-original-text=#{text}>#{full_text}</span>"
}

# Alternative with pattern-matching: to unpack variables, and handle default values, it will be something like...
case word
in text:, paragraph_id:, timestamp:
  # skip, just unpacked
in text:, paragraph_id: # no timestamp:
  timestamp = 0
end
# I am even not trying to handle TWO default values
```

As shown above, `Hash#fetch`/`Hash#[]` style makes it much harder to understand what block expects hash to have, and how it uses hash components — and just makes the code longer and less pleasant to write and read. Pattern-matching (at least for now) is just not powerful enough for this particular case (it also has non-informative error messages, but it obviously can be improved).

My **proposal** is to **allow implicit hash unpacking** into keyword arguments in **non-lambda procs**. It would be **consistent** with implicit array unpacking, which is an important property of non-lambda procs, useful for reasons *very similar to described above*.



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

[ruby-core:96886] [Ruby master Feature#16494] Allow hash unpacking in non-lambda Proc

[matz]

Issue #16494 has been updated by matz (Yukihiro Matsumoto).

Status changed from Open to Rejected

I admit the recent change disables something once we theoretically could. But there's no big usage for this particular feature and it doesn't worth adding even more complexity.

Matz.


----------------------------------------
Feature #16494: Allow hash unpacking in non-lambda Proc
https://bugs.ruby-lang.org/issues/16494#change-83898

* Author: zverok (Victor Shepelev)
* Status: Rejected
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
First of all, I fully understand the value of separating "real" keyword arguments and disallowing implicit and unexpected conversions to/from hashes.

There is, though, one **convenient style which is now broken**:
```ruby
# words is array of hashes:
words
  .map { |text:, paragraph_id:, **rest| 
    {text: text.strip, paragraph_id: paragraph_id.to_i, **rest}
  }
  .reject { |text:, is_punctuation: false, **| text.end_with?('!') || is_punctuation }
  .chunk { |paragraph_id:, timestamp: 0, **| [paragraph_id, timestamp % 60] }
  # ...and so on
```
There is several important elements to this style, making it hard to replace:

* informative errors on unexpected data structure ("missing keyword: text")
* ability to provide default values
* clear separation of declaration "what this block expects" / "what it does with expected data", especially valuable in data processing pipelines

One may argue that in some Big Hairy Very Architectured Application you should instead wrap everything in objects/extract every processing step into method or service/extract validation as a separate concern etc... But in smaller utility scripts, or deep inside of complicated algorithmic libraries, the ability to write short and clear code with explicitly declared and controlled by language arguments is pretty valuable.

This style has *no clean alternative*, all possible alternatives are either less powerful or much less readable. Compare:

```ruby
# Try to rewrite this:
words.map { |text:, paragraph_id:, timestamp: 0, is_punctuation: false|
  log.info "Processing #{timestamp / 60} minute"
  full_text = is_punctiation ? text : text + ' '
  "<span class='word paragraph-#{paragraph_id}' data-time=#{timestamp} data-original-text=#{text}>#{full_text}</span>"
}

# Alternative with just hashes:
words.map { |word|
  # those two used several times
  text = word.fetch(:text)
  timestamp = word.fetch(:timestamp, 0)
  log.info "Processing #{timestamp / 60} minute"
  # Absent is_punctuation is ok, it default to false
  full_text = word[:is_punctiation] ? text : text + ' '
  "<span class='word paragraph-#{word.fetch(:paragraph_id)}' data-time=#{timestamp} data-original-text=#{text}>#{full_text}</span>"
}

# Alternative with pattern-matching: to unpack variables, and handle default values, it will be something like...
case word
in text:, paragraph_id:, timestamp:
  # skip, just unpacked
in text:, paragraph_id: # no timestamp:
  timestamp = 0
end
# I am even not trying to handle TWO default values
```

As shown above, `Hash#fetch`/`Hash#[]` style makes it much harder to understand what block expects hash to have, and how it uses hash components — and just makes the code longer and less pleasant to write and read. Pattern-matching (at least for now) is just not powerful enough for this particular case (it also has non-informative error messages, but it obviously can be improved).

My **proposal** is to **allow implicit hash unpacking** into keyword arguments in **non-lambda procs**. It would be **consistent** with implicit array unpacking, which is an important property of non-lambda procs, useful for reasons *very similar to described above*.



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