Bug #10315: Override policy for duplicated keywords

• Status: Closed
• Assignee: matz (Yukihiro Matsumoto)
• Target version: 2.2.0
• ruby -v: 2.2-2.0
• Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN

[ko1 (Koichi Sasada)]

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.

[matz (Yukihiro Matsumoto)]

Agreed.

Matz.

[nobu (Nobuyoshi Nakada)]

• 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]

[whitequark (whitequark *)]

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.

[wanabe (_ wanabe)]

• Related to Bug #11501: About priority of a hash element when using {**hash1, **hash2} literal added