From: shevegen@... Date: 2020-01-31T14:29:30+00:00 Subject: [ruby-core:97030] [Ruby master Feature#16601] Let `nil.to_a` and `nil.to_h` return a fixed instance Issue #16601 has been updated by shevegen (Robert A. Heiler). I somewhat agree with the explanation, so I think the suggestion in itself is fine as such. I believe there may be a language design consideration, though, e. g. whether matz thinks that this makes sense from a language-design point of view (see the other explanation about the various attr* methods and why there is no attr* variant that e. g. combines reader methods with a trailing '?' character). Another smaller issue, if it is an issue, may be for ruby newcomers. For example, say that a new user comes to ruby and asks about nil.to_a and nil._to_h specifically - will there be an explanation somewhere? I am really just thinking about the new-ruby-user situation in this regard, e. g. they may like to understand why .to_a and .to_h may be special but not other .to_* (if there are any ... I don't even know how many exist for nil). Note that these two points are not meaning that I am against the suggestion at all - it is only meant to "carve out more details" from the proposal if possible. :) In my own code I usually check first for nil, before doing any further checks, even "boolean checks" (if a variable is true or false). Not sure if that is the best practice, different people write code differently, but I sort of adopted that a long time ago. So I may not be the ideal target audience either as I currently don't quite seem to do much on nil, except actually I do indeed sometimes do .to_s, to ensure that I have a string. This can indeed be a bit complicated sometimes, if we have to distinguish between nil, string and a symbol. But I still agree with your basic statement - it somewhat makes sense to me since nil.to_a and nil.to_h will always "reproduce" the same result just as .to_s would (and should, since it is nil). ---------------------------------------- Feature #16601: Let `nil.to_a` and `nil.to_h` return a fixed instance https://bugs.ruby-lang.org/issues/16601#change-84124 * 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: