[barkbyte]

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.

[lcnPylGDnU4H9OF]

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

[kazinator]

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.

[yunohn]

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