Ruby 3.4, No More TypeError with **Nil as It Is Treated as an Empty Hash

Re:Ruby 3.4, No More TypeError with **Nil as It Is Treated a... by lcnPylGDnU4H9OF on Monday May 13, 2024 @05:54PM (#40348951)

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

[ Parent | on HN ]

Re:Ruby 3.4, No More TypeError with **Nil as It Is Treated a... by kazinator on Tuesday May 14, 2024 @02:29AM (#40352230)

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.

[ Parent | on HN ]

Re:Ruby 3.4, No More TypeError with **Nil as It Is Treated a... by yunohn on Tuesday May 14, 2024 @05:23AM (#40353197)

That’s not breakage. It’s a canary test that should help you make the decision to remove your workaround code and related tests.

[ Parent | on HN ]