[#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:106430] [Ruby master Bug#16908] Strange behaviour of Hash#shift when used with `default_proc`.
From:
"naruse (Yui NARUSE)" <noreply@...>
Date:
2021-12-03 02:23:14 UTC
List:
ruby-core #106430
Issue #16908 has been updated by naruse (Yui NARUSE).
ioquatix (Samuel Williams) wrote in #note-8:
> Should we introduce some kind of deprecation or warning in 3.1?
Not allowed.
Ruby 3.1 shouldn't introduce anything which requests application developers to change something in their application code.
Deprecation warning is just a way of communications to request application developers to fix their application code.
----------------------------------------
Bug #16908: Strange behaviour of Hash#shift when used with `default_proc`.
https://bugs.ruby-lang.org/issues/16908#change-95072
* 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>