Actions
Bug #10315
closedOverride policy for duplicated keywords
Description
p({k1: 'a', k1: 'b'}) #=> {:k1=>"b"}
p({k1: 'a'}.merge({k1: 'b'})) #=> {:k1=>"b"}
p(k1: 'a', k1: 'b') #=> {:k1=>"b"}
p(k1: 'a', **{k1: 'b'}) #=> {:k1=>"a"}
IMO the last case should also output {:k1=>"b"}.
Nobu said that we should show warning for such duplication (especially for 1st and 3rd cases) because we can detect duplication while parsing/compiling.
Updated by matz (Yukihiro Matsumoto) about 10 years ago
Agreed.
Matz.
Updated by nobu (Nobuyoshi Nakada) about 10 years ago
- Status changed from Open to Closed
- % Done changed from 0 to 100
Applied in changeset r47877.
parse.y: precedence of duplicated keys
- parse.y (assocs): concatenate splatted literal hashes. the
former key has precedence even if duplicated literal keys
follow. [ruby-core:65368] [Bug #10315]
Updated by whitequark (whitequark *) about 10 years ago
Nobuyoshi Nakada wrote:
Applied in changeset r47877.
parse.y: precedence of duplicated keys
- parse.y (assocs): concatenate splatted literal hashes. the
former key has precedence even if duplicated literal keys
follow. [ruby-core:65368] [Bug #10315]
There is a problem with this solution. Namely, duplicate key-value pairs are removed at parsing stage, and if they had side effects (like printing), the semantics changes.
For example:
p({k1: p('a'), k1: p('b')}) #=> {:k1=>"b"}
p({k1: p('a')}.merge({k1: p('b')})) #=> {:k1=>"b"}
p(k1: p('a'), k1: p('b')) #=> {:k1=>"b"}
p(k1: p('a'), **{k1: p('b')}) #=> {:k1=>"a"}
In 2nd and 4th cases, 'a' and 'b' will be printed. In 1st and 3rd cases, only 'b' will be printed. This behavior is inconsistent.
Updated by wanabe (_ wanabe) about 9 years ago
- Related to Bug #11501: About priority of a hash element when using {**hash1, **hash2} literal added
Actions
Like0
Like0Like0Like0Like0