Ruby 3.4, No More TypeError with **Nil as It Is Treated as an Empty Hash(blog.saeloun.com)
blog.saeloun.com
Ruby 3.4, No More TypeError with **Nil as It Is Treated as an Empty Hash
https://blog.saeloun.com/2024/05/13/ruby-3-4-no-more-type-error-with-nil/
13 comments
Ruby is such a malleable language that its syntactic use cases are still being figured out and refined today. I'm loving this language every new iteration I see. A pleasure to use as my go to language.
Interestingly, JavaScript has the opposite problem: {...null} is fine (returns {}), but [...null] is not (TypeError: Spread syntax requires ...iterable not be null or undefined).
Thanks for making me aware of this. I guess {...something ?? {} } and [...something ?? [] ] are then appropriate to avoid any trouble for now.
This tricks me all of the time. Part of me wants for it to work to avoid allocating an empty array object in situations like `[...opts?.foo.map(format)]`. On the other hand I appreciate the stricter type safety.
I was quite surprised by this, I was certain it wasn’t true, but I checked and it is!
This sounds like it might cause bugs but seems like a good idea in general. Clojure treats nil the same way where "assoc"ing to it turns it into a hashmap and "cons"ing it turns it i to a list. Nil as basically the "empty data structure of undefined type" is actually quite useful in a lot of contexts to make coding simpler and not have to special case the base case in an if-statement every time.
I think changing the behaviour of nil in general for an existing language with tons of code already in the world would be beyond insane, on the verge of willfully destructive. Fortunately, that’s not what as happening here. This only applies in the case of using nil as a splat, which is narrow enough that I think it’s probably safe and it’s a sensible default behaviour.
I'm not sure what currently working code would be broken by this. If anything, it seems like it would just obviate workarounds.
Though, now that I'm thinking about it, I have written and read absolute monstrosities. This could break something somewhere but I'm confident it would land squarely in the realm of "well yeah, but don't do that".
Though, now that I'm thinking about it, I have written and read absolute monstrosities. This could break something somewhere but I'm confident it would land squarely in the realm of "well yeah, but don't do that".
If you make something work which previously threw an error, it affects programs in which that error happens but is handled (whether by fluke or design).
One obvious example is a regression test case which confirms that the error is generated; that test now fails and must be removed.
It could sneak into an application.
They are just willing to crack those eggs to make their omelette.
One obvious example is a regression test case which confirms that the error is generated; that test now fails and must be removed.
It could sneak into an application.
They are just willing to crack those eggs to make their omelette.
That’s not breakage. It’s a canary test that should help you make the decision to remove your workaround code and related tests.
Seems roughly appropriate (thinking in zero-values):
nil.to_i => 0
nil.to_s => ""
nil.to_a => []
nil.to_h => {}
nil.to_set # error; nil.to_a.to_set => #<Set: {}>I don’t know how to feel about this, when I get this error then I know I haven’t thought about a certain case that could happen and I should handle it.
Ruby is such an ugly monstrosity of a languages; proudly flying the crunchy fried meme of “developer productivity”