From: "baweaver (Brandon Weaver) via ruby-core" Date: 2026-07-04T03:01:09+00:00 Subject: [ruby-core:125923] [Ruby Feature#22111] Non-symbolic hash keys with `expr : value` syntax Issue #22111 has been updated by baweaver (Brandon Weaver). I'd like to comment on the broader goal here, rather than the specific syntax, to start. I've written about this subject before in [The Case for Pattern Matching Key Irreverence in Ruby](https://baweaver.com/writing/2022/06/11/the-case-for-pattern-matching-key-irreverence-in-ruby-1oll/) and I think that the goal of matching against non-Symbol keys in pattern matching is a missing feature. That said I do have concerns with the proposed syntax. ## The `{ a : 1 }` vs `{ a: 1 }` Distinction Is Confusing I'll be direct: disambiguating semantics based on *whitespace around a colon* is going to be a source of bugs and confusion. ```ruby { a: 1 } # => {:a => 1} symbol key { a : 1 } # => {1 => 1} expression key (where a = 1) ``` These are visually near-identical and semantically opposite. Code formatters, copy-paste, and a single keystroke can silently change the meaning of your program. nobu's [comment #28](https://bugs.ruby-lang.org/issues/22111#note-28) ("These look very confusing") captures my reaction as well. Ruby has a history of being generous with whitespace, so to encode meaning into spacing would be a deviation from the language design, I feel. It optimizes more for syntactic completeness at the cost of readability. ## But the Goal Is Right: Pattern Matching Needs String Key Support Where I *strongly* agree is with the underlying motivation, particularly what yertto demonstrates in [comment #32](https://bugs.ruby-lang.org/issues/22111#note-32): ```ruby case JSON.parse(data) in {"admin" : {"first name" : String => name, "privileges" : {"write" : true}}} puts "#{name} is an admin with write access" end ``` Existing pattern matching cannot capture String-keyed hashes without `deep_symbolize_keys` or similar methods, and that feels like an ergonomic miss. JSON, CSV, YAML, HTML headers, and other concepts especially around serialization arrive with String keys, making them incompatible with pattern matching as-is. The problem we have is that hash rockets have been overloaded to mean both `key => value` and `value => variable`, blocking us from leveraging this for String keys. Kazuki Tsujimoto acknowledged this in his [RubyKaigi talk](https://speakerdeck.com/k_tsj/pattern-matching-new-feature-in-ruby-2-dot-7?slide=58), listing "Non-symbol keys for hash patterns" as explicit future work. ## There Is Deep Precedent for Key Irreverence Ruby has a long tradition of being irreverent about the Symbol/String distinction when intent is clear: - **`send`, `define_method`, `instance_variable_get`, `const_get`**: all accept either Strings or Symbols because Ruby prioritizes "knowing what you meant." - **Keyword arguments**: evolved from `Hash` coercion into their own thing. - **Punning** (`{ x:, y: }`): the Symbol functions as a method call, not a literal. - **`Hash#with_indifferent_access`** in Rails: the most popular framework in the ecosystem decided this distinction shouldn't matter. I'm inclined to agree with them. As *Polished Ruby Programming* puts it: "when Ruby needs a symbol, it will often accept a string and convert it for the programmer's convenience." **It is established Ruby precedent to favor convenience over explicitness.** Pattern matching's `deconstruct_keys` already compromises on Symbol literalism. When you match against a `Point`: ```ruby Point.new(x: 1, y: 2) in x: 0..5 ``` The `:x` passed here to `deconstruct_keys` does not represent a Symbol hash key, it represents an instance variable or a method call. The Symbol is functioning as a **query parameter**, not a type-literal key. Pattern matching is a query language against available fields, not a Hash-to-Hash comparison. ## What I'd Prefer to See Rather than whitespace-sensitive disambiguation, I'd prefer one or both of: 1. **The `(expr): value` syntax from Feature [#22108](https://bugs.ruby-lang.org/issues/22108)**: ```ruby case JSON.parse(data) in {("admin"): {("first name"): String => name}} # ... end ``` 2. **A semantic convention that `deconstruct_keys` should be key-irreverent**: implementations coerce String���Symbol as appropriate for the object's internal representation. This is the approach I advocated in my original post and in discussions on [CSV#246](https://github.com/ruby/csv/issues/246). For `Hash` specifically, try the Symbol key first, fall back to the String variant. The performance cost is potentially acceptable and could be JIT'd or optimized: ```ruby # Don't do this in production code # So we have a "Ruby" implementation to level against, rather than the C # one. class HashOriginal < Hash def deconstruct_keys(keys) return self unless keys keys.each_with_object({}) do |key, matches| matches[key] = self[key] if key?(key) end end end class HashPrime < Hash def deconstruct_keys(keys) if keys.nil? self.transform_keys(&:to_sym) else keys.each_with_object({}) do |key, matches| if key?(key) matches[key] = self[key] elsif key?(key.to_s) matches[key] = self[key.to_s] end end end end end Benchmark.ips do |x| x.report("Hash") do Hash[a: 1, b: 2] in { a: 1, b: 2, c: 3 } end x.report("HashOriginal") do HashOriginal[a: 1, b: 2] in { a: 1, b: 2, c: 3 } end x.report("HashPrime") do HashPrime[a: 1, b: 2] in { a: 1, b: 2, c: 3 } end x.report("HashPrime String") do HashPrime[a: 1, "b" => 2] in { a: 1, b: 2, c: 3 } end end # Warming up -------------------------------------- # Hash 299.651k i/100ms # HashOriginal 103.085k i/100ms # HashPrime 85.180k i/100ms # HashPrime String 80.537k i/100ms # Calculating ------------------------------------- # Hash 2.951M (�� 3.0%) i/s - 14.983M in 5.081797s # HashOriginal 1.057M (�� 2.6%) i/s - 5.360M in 5.075552s # HashPrime 924.234k (�� 3.8%) i/s - 4.685M in 5.076900s # HashPrime String 784.882k (�� 4.9%) i/s - 3.946M in 5.041825s ``` Option 1 solves the parser problem without introducing whitespace ambiguity. Option 2 solves it at the semantic layer for objects like CSV::Row, MatchData, and custom classes. Ideally, both. ## The Historical Arc Supports This The colon family has been expanding for almost 20 years: | Version | Feature | |---------|---------| | 1.9 | `foo: value`: Symbol key shorthand | | 2.2 | `"quoted": value`: Quoted symbol labels | | 3.1 | `name:`: Value omission (punning) | Each one was met with resistance when added, but each grew on the Ruby community over time. I believe it's time to consider completing this arc for non-Symbol keys, but I want to make sure to do it in a way that does not give distinct meaning to whitespace that could cause errors and confusion. ---------------------------------------- Feature #22111: Non-symbolic hash keys with `expr : value` syntax https://bugs.ruby-lang.org/issues/22111#change-117893 * Author: yertto (_ yertto) * Status: Open ---------------------------------------- # Non-symbolic hash keys with `expr : value` syntax Allow `expr : value` for non-symbolic hash keys. Almost 20 years in the making, the missing puzzle piece for Hash's "new" colon syntax: ```ruby h = { name: "symbol shorthand", # Ruby 1.9+ "quoted label": "symbol label", # Ruby 2.2+ (Feature #4935) value_omission: , # Ruby 3.1+ (Feature #14579) expr : "non symbol", # THIS PROPOSAL } ``` ## Motivation Ruby has several colon-based hash key syntaxes for symbolic keys, but the `=>` ("hash rocket") is still needed for non-symbolic keys. Adding `expr : value` is a backwards compatible leap forward toward allowing all-colon hashes for all key types: ```ruby ## Before -- mixed styles n = 42; { key1: "symbol", "key-#{2}": "quoted symbol", RUBY_VERSION:, n => "bar" }.keys # => [:key1, :"key-2", :RUBY_VERSION, 42] ## After -- uniform colon syntax n = 42; { key1: "symbol", "key-#{2}": "quoted symbol", RUBY_VERSION:, n : "bar" }.keys # => [:key1, :"key-2", :RUBY_VERSION, 42] ``` Could this be what we need to one day retire our old friend "hash rocket" from Hashes entirely? ### Completing the colon family Ruby has two hash key syntax families: `=>` (hash rocket) and `:` (hash colon). | Key form | Rocket syntax | Colon syntax | |----------------|-------------------|--------------------| | Static symbol | `:foo => value` | `foo: value` | | Quoted symbol | `:"foo" => value` | `"foo": value` | | Value omission | N/A | `name:` | | Non-symbolic | `expr => value` | ��� **`expr : value` (proposed)** | The gap for non-symbolic keys means they're forced to use rocket syntax. This proposal is to finally complete the hash colon family for all key types. | Example | Ruby | Feature | Key type | |---------|------|---------|----------| | `{ name: value }` | [v1.9](https://docs.ruby-lang.org/en/3.4/NEWS/NEWS-1_9_1.html) | | Symbol | | `{ "quoted label": value }` | [v2.2](https://docs.ruby-lang.org/en/3.4/NEWS/NEWS-2_2_0.html) | [Feature #4935](https://bugs.ruby-lang.org/issues/4935) | Symbol (quoted label) | | `{ value_omission: }` | [v3.1](https://docs.ruby-lang.org/en/3.4/NEWS/NEWS-3_1_0_md.html) | [Feature #14579](https://bugs.ruby-lang.org/issues/14579) | Value omission | | `{ expr : value }` | *???* | [Feature #22111](https://bugs.ruby-lang.org/issues/22111) | Non-symbolic | ### Reducing `=>` overloading The `=>` token is now being used to serve more purposes than just the Hash literal (aka "Hash rocket") it was originally used for. - rightward assignment ``` expr => var ``` - pattern capture ``` case {name: "Alice", role: "admin"} in {name: String => name, role:} # capture the name String value into `name` p name # => "Alice" end ``` - rescue variables ``` rescue SomeExceptionClass => e ``` ``` rescue => e ``` Reducing the rocket's use in Hashes simplifies the language, especially for newcomers. ## Design ### Disambiguation A symbol eligible expression (bareword identifier or quoted string) followed by `:` with **no space** becomes a symbol key. The same expression followed by `:` with **a space** cannot be a label, so it becomes a computed key: ```ruby { a: 1 } # => {:a => 1} symbol { a : 1 } # => {1 => 1} where variable `a=1` (expr-colon where the space disambiguates from a symbol) { "a": 1 } # => {:a => 1} quoted symbol key { "a" : 1 } # => {"a" => 1} string (expr-colon where the space disambiguates from a symbol) ``` Expressions that cannot become symbols will work **with or without a space**, as there is no ambiguity to resolve: ```ruby { 42 : 1 } # => {42 => 1} { 42: 1 } # => {42 => 1} { Math::PI : 1 } # => {3.141592653589793 => 1} { Math::PI: 1 } # => {3.141592653589793 => 1} ``` ## Relationship to Feature #22108 The earlier proposal [Feature #22108](https://bugs.ruby-lang.org/issues/22108) suggested `{ (expr): value }` using parenthesized expressions with a lexer-generated label token (`tLABEL_END`). I assumed there'd be too many dragons to fight with whitespace sensitivity. However, after making the code changes somehow it just worked for all the test cases I threw at it. ��\\_(���)_/�� | | [Feature #22108](https://bugs.ruby-lang.org/issues/22108)
`(expr): value` | [Feature #22111](https://bugs.ruby-lang.org/issues/22111)
`expr : value` | |---|---|---| | Parser changes | Lexer + grammar | Grammar only | | New fields | `hash_nest` | None | | LALR conflicts | 0 | 0 | | Parens required? | Yes | No | | Interpolated key | `("key-#{n}"): val` | `"key-#{n}" : val` | | Integer key | `(42): val` | `42: val` | This version is strictly more general, has a simpler implementation, and requires no lexer changes. ## More examples ```ruby key3 = "key3" def key12 = "key12" key13 = -> { "key13" } h = { key1: 1, "key-2": :two, key3 : "3-expr", "key4" : "4-String", (5+0): "5-parentheses", 6: "6-Integer", 7.001: "7-Float", "key" + "8": "8-String expr", 9+0: "9-Integer expr", [10, 0]: "10-Array", true ? 11 : 0 : "11-ternary", key12(): "12-method", key13[]: "13-lambda[]", -> { "key14" }.call: "14-lambda.call" } p h #=> {key1: 1, "key-2": :two, "key3" => "3-expr", "key4" => "4-String", 5 => "5-parentheses", 6 => "6-Integer", 7.001 => "7-Float", "key8" => "8-String expr", 9 => "9-Integer expr", [10, 0] => "10-Array", 11 => "11-ternary", "key12" => "12-method", "key13" => "13-lambda[]", "key14" => "14-lambda.call"} p h.keys #=> [:key1, :"key-2", "key3", "key4", 5, 6, 7.001, "key8", 9, [10, 0], 11, "key12", "key13", "key14"] ``` ### Familiar to developers from other languages Python dicts have always allowed any hashable key types with `:` syntax. With this proposal something like `{200: "OK", 404: "Not Found"}` can be used in either language. ## Edge cases ```ruby { %"a": 1 } # => {"a" => 1} percent string as computed key { :a: 1 } # => {a: 1} symbol as a symbolic key { :a : 1 } # => {a: 1} symbol as a symbolic key { (:a): 1 } # => {a: 1} symbol as a symbolic key { :"a": 1 } # => {a: 1} quoted symbol as a symbolic key { n : } # syntax error value omission not supported { n : 1, } # => {42 => 1} trailing comma ok ``` ## Implementation Two files (plus tests): - **`parse.y`**: One new production in `assoc`: `| arg_value ':' arg_value` - **`prism/prism.c`**: In `parse_assocs`, accept `PM_TOKEN_COLON` when `pm_symbol_node_label_p` returns false Zero lexer changes, zero new fields, zero LALR conflicts. Reference implementation: [feature/expr-colon-hash-keys](https://github.com/ruby/ruby/pull/17318) PR on GitHub. ## Historical context A version of this was discussed on ruby-core in October 2007 (as part of ["General hash keys for colon notation"](https://public-inbox.org/ruby-core/E1ImQBE-00033s-IZ@x31/T/), murphy). Unfortunately it was brought up during the v1.9 feature freeze, but it looks like [Matz's invitation to discuss for v2.0](https://public-inbox.org/ruby-core/E1ImQA8-00033T-8c@x31/) didn't end up going anywhere. Since then, `{"quoted label": value}` ([Ruby v2.2](https://docs.ruby-lang.org/en/3.4/NEWS/NEWS-2_2_0.html), [Feature #4935](https://bugs.ruby-lang.org/issues/4935)) and `{ value_omission: }` ([Ruby v3.1](https://docs.ruby-lang.org/en/3.4/NEWS/NEWS-3_1_0_md.html), [Feature #14579](https://bugs.ruby-lang.org/issues/14579)) have expanded the colon family, making the computed-key gap more conspicuous. This proposal fills that gap with a [minimal grammar change](https://github.com/ruby/ruby/pull/17318/changes#diff-60e6f0aa6e190c54f6cb0ac74148ced3cf0ef8703e1c3824a07a82dc54654953R6635-R6639) that requires no new lexer states. ## Open questions - Is this syntax acceptable to the community? ## Future directions All colon-based key syntaxes would now be available. This opens up the possibility of eventually deprecating `=>` from Hash literals (while keeping it for rescue, pattern matching, and rightward assignment). This proposal does not require that change ��� it is simply the enabling step, and any deprecation timeline could be a separate discussion. -- https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/