Project

General

Profile

Actions

Bug #10315

closed

Override policy for duplicated keywords

Added by ko1 (Koichi Sasada) about 10 years ago. Updated about 10 years ago.

Status:
Closed
Target version:
ruby -v:
2.2-2.0
[ruby-core:65368]

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.


Related issues 1 (0 open1 closed)

Related to Ruby master - Bug #11501: About priority of a hash element when using {**hash1, **hash2} literalClosednagachika (Tomoyuki Chikanaga)Actions

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.

Actions #4

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

Also available in: Atom PDF

Like0
Like0Like0Like0Like0