Feature #22266: Stop warning for duplicate keywords in splatted literal hashes

• Status: Open
• Assignee: -
• Target version: -

[jeremyevans0 (Jeremy Evans)]

Ruby warns for duplicate keywords in the same literal hash:

$ ruby -we '{h: 1, h: 1}'
-e:1: warning: key :h is duplicated and overwritten on line 1

Ruby does not warn for duplicate keywords in splatted hashes:

$ ruby -we 'h = {h:}; {h:, **h}'
$ ruby -we 'h = {h:}; {**h, h:}'
$ ruby -we 'h = {h:}; {**h, h:, **h}'
$ ruby -we 'h = {h:}; {**h, **h}'

However, Ruby warns for for duplicate keywords in splatted literal hashes:

$ ruby -we '{h: 1, **{h: 1}}'
-e:1: warning: key :h is duplicated and overwritten on line 1
$ ruby -we '{**{h: 1}, h: 1}'
-e:1: warning: key :h is duplicated and overwritten on line 1
$ ruby -we '{**{h: 1}, h: 1, **{h: 1}}'
-e:1: warning: key :h is duplicated and overwritten on line 1
-e:1: warning: key :h is duplicated and overwritten on line 1
$ ruby -we '{**{h: 1}, **{h: 1}}'
-e:1: warning: key :h is duplicated and overwritten on line 1

I think Ruby should stop warning in the splatted literal hash case, for two reasons:

• Treatment of splatted literal hashes is inconsistent with treatment of splatted non-literal hashes. Even if the compiler optimizes the splatted literal hash to the same bytecode as a direct keyword, it should not emit the same warning, because fundamentally the duplicate keyword is in a different hash, not in the same hash.
• Warnings are designed to be helpful to the programmer, but unlike the warning for duplicate keywords in the same hash (a common mistake), no Ruby programmer is going to write splatted literal hashes. I can see an automated program generating splatted literal hashes, but in that case, the warnings are likely to be undesirable, just as warning for duplicate keywords in splatted non-literal hashes would be undesirable.

Consider a hypothetical future Ruby compiler that could optimize the h = {h:}; {h:, **h} to the same bytecode as {h: nil, **{h: nil}}. Would we still want to emit the same warning?

If accepted, I'm happy to work on a patch to implement this.