Feature #22108: Computed hash keys with (expr): syntax

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

[yertto (_ yertto)]

Warning

This has potentially been obsoleted by Feature #22111

Computed hash keys with (expr): syntax

Allow { (expr): value } as a computed hash key.
Almost 20 years in the making, the missing puzzle piece for Hash's "new" colon notation:

h = {
  name: "symbol shorthand",          # Ruby 1.9+
  "quoted label": "symbol label",    # Ruby 2.2+ (Feature #4935)
  value_omission: ,                  # Ruby 3.1+ (Feature #14579)
  (expr): "computed",                # THIS PROPOSAL
}

Motivation

Ruby has several colon-based hash key syntaxes but the => ("hash rocket") is still needed for non-symbolic keys.
Adding (expr): is a baby step toward allowing all-colon hashes:

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

(And maybe a step closer to one day retiring our old friend "hash rocket" from Hashes entirely?)

Completing the colon family

Example	Ruby	Feature	Key type
{ name: value }	v1.9		Symbol
{ "quoted label": value }	v2.2	Feature #4935	Symbol (quoted label)
{ value_omission: }	v3.1	Feature #14579	Value omission
{ (expr): value }	???	Feature #22108	Computed

Readability for computed-key-heavy code

Code that builds dynamic hashes currently forces a style break midway through a literal.
This is especially noticeable with interpolated keys, numeric keys, or variable-driven keys.

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 its use in Hashes simplifies the language, especially for newcomers.

Design

(expr): vs [expr]:

Parenthesized expressions were chosen over square bracket delimited:

• Idempotent wrapping: ((x)) = (x), but [[x]] != [x] (nested array)
• Array keys: {(["a"]): "b"} reads naturally vs {[["a"]]: "b"} requiring extra wrapping
• jq precedent: the JSON query language uses identical {("a"+"b"): 59} syntax (since jq 1.6, 2018)
• Parentheses signals a grouping or "evaluate this", whereas square brackets signals an Array/container

Improving on JavaScript

JavaScript's "computed property names" { [expr]: value } were introduced in ECMAScript 2015 (ES6), 3 years before the jq version.
However in Ruby, [] already means Array literal and method call.
Rather than overloading [] further, (expr): (from jq) improves on the JavaScript design.
Parentheses naturally signal evaluation, (): inside {} is unambiguous to the lexer, and it matches the well-established jq convention.

Edge cases handled

• (expr) : value (space before colon) -- syntax error (consistent with name : value)
• { (expr): } (value omission) -- syntax error (runtime expression, no compile-time local to infer)
• Mixed styles: { (1): "one", two: "two", "three": "three" } -- valid
• Nested parens: { ((1 + 2) * 3): "nested" } -- valid
• Nested hashes: { ({(1): "one"}): "two" } -- valid

Implementation

Three changes to parse.y (Lrama LALR(1) parser, zero new conflicts):

1. Lexer: emit tLABEL_END when EXPR_ENDFN state, no space before :, and inside brace_nest > 0
2. Grammar: new assoc alternative -- tLPAREN compstmt ")" tLABEL_END arg_value
3. Precedence: %nonassoc ')' to disambiguate

Reference implementation: feature/computed-hash-keys 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", murphy).
Unfortunately it was brought up during the v1.9 feature freeze, but it looks like Matz's invitation to discuss for v2.0 didn't end up going anywhere.
Since then, "quoted label": (Ruby 2.2, Feature #4935) and value omission (Ruby 3.1, Feature #14579) have expanded the colon family, making the computed-key gap more conspicuous.
Meanwhile, jq introduced the identical {("a"+"b"):59} syntax in jq 1.6 (2018), demonstrating real-world viability.

Open questions

• Is this syntax acceptable to the community?
• Is the jq precedent compelling enough to address the "no language does this" objection?

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.

[yertto (_ yertto)]

• Description updated (diff)

[yertto (_ yertto)]

• Description updated (diff)

[yertto (_ yertto)]

• Description updated (diff)

[nobu (Nobuyoshi Nakada)]

Is it same as "#{expr}": value?

P.S. pattern capture and rightward assignment are the same thing.

[yertto (_ yertto)]

No, its different from { "#{expr}": value }.

That would produce a Symbol for the key.
eg.

expr = "key"; value = "val"
{ "#{expr}": value }.keys
# => [:key]

Whereas using (): the key stays unchanged (ie. as a String in this case),

expr = "key"; value = "val"
{ (expr): value }.keys
# => ["key"]

ie. an alternative to using =>:

expr = "key"; value = "val"
{ expr => value }.keys
# => ["key"]

[yertto (_ yertto)]

• Description updated (diff)

[yertto (_ yertto)]

• Description updated (diff)

[yertto (_ yertto)]

• Description updated (diff)

[yertto (_ yertto)]

• Description updated (diff)

[yertto (_ yertto)]

• Description updated (diff)

[yertto (_ yertto)]

• Description updated (diff)

[yertto (_ yertto)]

• Description updated (diff)

[yertto (_ yertto)]

• Description updated (diff)

[yertto (_ yertto)]

• Description updated (diff)

[yertto (_ yertto)]

• Description updated (diff)

[yertto (_ yertto)]

• Description updated (diff)

[kddnewton (Kevin Newton)]

I am not very in favor of adding yet another hash assoc syntax, especially not by overloading the meaning of the colon. Right now a colon suffix always means a symbol (indeed I've seen static analysis tools that check slice[-1] == ":" to determine if it's a symbol). It's not an operator like this commit attempts to treat it.

Realistically, I don't see hash rockets ever going away (indeed some people have their linters enforce usage in all places because they prefer the consistency), so I don't think that argument has any real weight to it. With that in mind, I think the goal of simplifies the language, especially for newcomers is very much not met, because there is already a way to do this and this just bloats the grammar even further.

[yertto (_ yertto)]

yet another hash assoc syntax

You're right — : is not an operator. And this change doesn't treat it as one.

: works the same way it always has: you put something on the left, put : after it, and that something becomes the hash key.

The change isn't about adding an operator, it's about completing an existing syntax family that currently stops at two left-hand forms.

Ruby already has two hash key syntax families: => (hash rocket) and : (hash colon).
The proposal I'm making here is whether the hash colon family should be complete or remain half-implemented.

Today, the hash colon covers most key forms but has a gap:

Key form	Rocket style	Colon style
Static symbol	:foo => value	foo: value
Quoted symbol	:"foo" => value	"foo": value
Value omission	N/A	name:
Computed key	expr => value	❌ (expr): value (proposed)

The incomplete table forces every computed key into rocket syntax, which is the real asymmetry in modern Ruby.

Adding (expr): doesn't increase bloat, it fills the one hole that prevents the hash colon family from being a complete, consistent syntax.

---

colon suffix always means a symbol

You're right that foo: and "foo": both produce symbols. But the colon isn't what makes them symbols, the grammar production is.

Ruby has three separate grammar rules for the left side of : in a hash:

Left side	What happens	Key type
foo	Bareword interpreted as a symbol	Symbol :foo
"foo"	String wrapped into a symbol	Symbol :"foo"
(expr)	Expression evaluated, result used directly (new)	result of expr

The colon does the same thing in all three: it marks the key boundary.
What happens to the left-hand value depends on which rule matched, not on anything the colon does.

"foo": proves this. The colon doesn't turn "foo" into a symbol; the rule for strings wraps it into one.
(expr): simply omits the wrapping step; the expression result is used as-is, which is the most honest interpretation.

So the claim "colon suffix always means symbol" is true as its currently observed but still questionable at the mechanism level.
(expr): doesn't break the rule, it reveals to us that the rule was about the production, not the colon.

---

(I've seen static analysis tools that check slice[-1] == ":" to determine if it's a symbol.)

(This side note seems like a distraction. The debate about what : means is better had on linguistic grounds than by how heuristics happen to work today. I'd prefer to focus on what the syntax should mean, not on what existing tools happen to do.)

---

there is already a way to do this (=> already works)

"Already works" sets the bar at syntax correctness, ignoring ergonomics, readability, and consistency.

=> does work, but the question is whether Ruby should continue to force such a stark style break at non-symbol keys.
Every tutorial teaches label: syntax as the default for symbol keys. Style guides recommend it. The community shifted preference decades ago.
Telling users "use rockets for anything that isn't a bare symbol" is the actual inconsistency, not the addition of one missing form.

---

the goal of "simplifies the language, especially for newcomers" is very much not met

Ruby has baggage: two separators, and : has an association with Symbol coercion, but things don't have to stay that way.
There's a path forward...

1. Add (expr): a form where : acts purely as a key boundary, with zero coercion. Establishes the precedent that : doesn't inherently mean Symbol.
2. Shift the mental model. Clarify the colon's role. Currently : does double duty - it marks the key boundary and coerces bare words and Strings to Symbols. (expr): cleanly separates these: for foo: and "foo":, the left-hand form still triggers Symbol coercion; for (expr):, it doesn't. The colon itself is just a key boundary marker in all three cases and the coercion is a property of the left-hand form, not the colon.
3. The door opens for future cleanup.

(expr): is uniquely valuable in this trajectory because it's the least committal form.
It doesn't paint us into any corner.
It's compatible with Symbol keys, String keys, or any future type decision.

I guess for the newcomer it comes down to which would be simpler.

A. Without (expr):
"So : makes a symbol key: { name: "Alice" }. That's the modern way. But if you want a computed key, you have to switch to =>: { expr => value }. Different rules, different separator. You'll get used to it, or you could just use the rocket everywhere. No wait ... then you miss out on the value_omission: case, so that also needs to use the colon."

B. With (expr):
": after any expression means what comes before it is the key. If it's a bare word, it gets converted to a symbol. If it's a string, same thing, it converts to a symbol. If it's an expression, the result is used directly as the key. One consistent rule: : means key boundary."

IMO, the latter would be simpler to teach, simpler to remember, and reduces context switches.
The implementation cost (a handful of lines in the parser) seems trivial compared to the gain in clarity.

(BTW, I had considered making whitespace the disambiguator. ie. { foo: bar } for symbol keys, { foo : bar } for computed keys, but I came up with a few reasons against it, and so went with the parentheses design instead. Someone else is welcome to argue for that case separately, but I suspect there be too many dragons introducing space sensitivity to Ruby.)

---

I think the real debate that you are raising here is whether or not the => (hash rocket) is here to stay forever, or could one day be deprecated.

My gut feeling is that (expr): is a step toward reducing => usage.
While your gut feeling is that => will never go away and so (expr): is just more syntax for the same thing.

Is that a fair assessment?

While neither of us can prove our gut feelings will eventuate.
One thing is certain: without some kind of addition like (expr):, deprecation of Hash's rocket is structurally impossible.
Every computed key today requires =>, guaranteeing rocket usage in perpetuity.

(expr): is a minimum viable step to find out whether rockets can fade.
It costs a handful of lines in the grammar.
And if => usage doesn't decline, nothing is lost.
But if we never try, we'll never know.

And for those folks who currently enforce rockets everywhere via their linters, this change means they now have the option to shift toward the hash colon instead (if they want to).
That's not the language forcing change; it's the language enabling choice.

Rejecting an addition like (expr): isn't pragmatism, it's guaranteeing rockets within Hashes will stay forever.

[yertto (_ yertto)]

• Description updated (diff)

[yertto (_ yertto)]

(BTW, I had considered making whitespace the disambiguator. ie. { foo: bar } for symbol keys, { foo : bar } for computed keys, but I came up with a few reasons against it, and so went with the parentheses design instead. Someone else is welcome to argue for that case separately, but I suspect there be too many dragons introducing space sensitivity to Ruby.)

Turns out the implementation didn't have the dragons I was expecting.
The only space sensitivity it introduces is for the existing symbol-label syntax.

And somehow computed keys need no disambiguation at all. ¯\(ツ)/¯

This simple addition was all that was needed for the parser.

Just wondering if someone else is able to throw some horrific show-stopping edge case at it and break it?

Otherwise, perhaps we should close this issue and discuss the proposal in #22111 instead?

[yertto (_ yertto)]

• Description updated (diff)

[yertto (_ yertto)]

• Description updated (diff)