[#106355] [Ruby master Bug#18373] RBS build failure: '/include/x86_64-linux/ruby/config.h', needed by 'constants.o'. — "vo.x (Vit Ondruch)" <noreply@...>
Issue #18373 has been reported by vo.x (Vit Ondruch).
28 messages
2021/12/01
[ruby-core:106855] [Ruby master Bug#16908] Strange behaviour of Hash#shift when used with `default_proc`.
From:
"jeremyevans0 (Jeremy Evans)" <noreply@...>
Date:
2021-12-27 22:46:38 UTC
List:
ruby-core #106855
Issue #16908 has been updated by jeremyevans0 (Jeremy Evans).
I've submitted a pull request to make `Hash#shift` return `nil` if the hash is empty: https://github.com/ruby/ruby/pull/5360
Not sure if we want that behavior in 3.2, or if we want to issue a deprecation warning in 3.2 and change in 3.3. Considering there would be no way to avoid the deprecation warning if the hash has a default value, I think it's best to just change the behavior without deprecation.
----------------------------------------
Bug #16908: Strange behaviour of Hash#shift when used with `default_proc`.
https://bugs.ruby-lang.org/issues/16908#change-95665
* Author: ioquatix (Samuel Williams)
* Status: Open
* Priority: Normal
* ruby -v: 2.7.0
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN
----------------------------------------
I don't have any strong opinion about this, but I observed the following behaviour which I thought was confusing. Maybe it's okay, or maybe we should change it to be more consistent.
```
hash = Hash.new{|k,v| k[v] = 0}
hash.shift # => 0
hash.shift # => [nil, 0]
```
My feeling was, both cases should return `[nil, 0]`.
--
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>