[#97063] [Ruby master Bug#16608] ConditionVariable#wait should return false when timeout exceeded — shugo@...

Issue #16608 has been reported by shugo (Shugo Maeda).

10 messages 2020/02/05

[#97084] [Ruby master Feature#16614] New method cache mechanism for Guild — ko1@...

Issue #16614 has been reported by ko1 (Koichi Sasada).

18 messages 2020/02/07

[#97248] [Ruby master Bug#16651] Extensions Do Not Compile on Mingw64 — cfis@...

Issue #16651 has been reported by cfis (Charlie Savage).

17 messages 2020/02/24

[#97289] [Ruby master Bug#16658] `method__cache__clear` DTrace hook was dropped without replacement — v.ondruch@...

Issue #16658 has been reported by vo.x (Vit Ondruch).

9 messages 2020/02/27

[#97307] [Ruby master Feature#16663] Add block or filtered forms of Kernel#caller to allow early bail-out — headius@...

Issue #16663 has been reported by headius (Charles Nutter).

29 messages 2020/02/28

[#97310] [Ruby master Feature#16665] Add an Array#except_index method — alexandr1golubenko@...

Issue #16665 has been reported by alex_golubenko (Alex Golubenko).

12 messages 2020/02/29

[ruby-core:97036] [Ruby master Feature#16601] Let `nil.to_a` and `nil.to_h` return a fixed instance

From: jean.boussier@...
Date: 2020-02-01 10:12:59 UTC
List: ruby-core #97036
Issue #16601 has been updated by byroot (Jean Boussier).


I'm not sure if `nil.to_a` and `nil.to_h` are actually frequent sources of allocations, but I agree with the general premise.

When profiling Ruby applications, it's frequent to see 30% of the time being spent in GC, which makes me think reducing useless allocations could lead to increased performance.

However as we've seen with [#16150] (freezing the return of `Symbol#to_s`), there are backward compatibility concerns.

So maybe the priority would be to implement [#16153] so that this kind of changes can go through a normal deprecation cycle.

----------------------------------------
Feature #16601: Let `nil.to_a` and `nil.to_h` return a fixed instance
https://bugs.ruby-lang.org/issues/16601#change-84129

* Author: sawa (Tsuyoshi Sawada)
* Status: Open
* Priority: Normal
----------------------------------------
Now, `nil.to_s` returns a fixed instance:

```ruby
nil.to_s.object_id # => 440
nil.to_s.object_id # => 440
nil.to_s.object_id # => 440
...
```

This is useful when we have some variable `foo` which may be either `nil` or a string, and we want to check its emptiness in a condition:

```ruby
if foo.to_s.empty?; ... end
```

By this feature, we do not (need to) create a new instance of an empty string each time we check `foo`, even when it happens to be `nil`.

There are similar situations with arrays and hashes. We may have variable `bar` which may be either `nil` or an array, or `baz` which may be either `nil` or a hash, and we want to check their emptiness in conditions as follows:

```ruby
if bar.to_a.empty?; ... end
```

```ruby
if baz.to_h.empty?; ... end
```

But unlike `nil.to_s`, the methods `nil.to_a` and `nil.to_h` create new instances of empty array or hash each time they are called:

```ruby
nil.to_a.object_id # => 540
nil.to_a.object_id # => 560
nil.to_a.object_id # => 580
...

nil.to_h.object_id # => 460
nil.to_h.object_id # => 480
nil.to_h.object_id # => 500
...
```

The fact that this is somewhat inefficient discourages the use of `foo.to_a` or `foo.to_h` in such use cases.

I request `nil.to_a` to `nil.to_h` to return a fixed empty instance.



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

In This Thread

Prev Next