Would this work for destructuring too? 

```elixir
%{foo:, bar:} = my_map # assigns `foo` and `bar`
```

On Sun, Dec 21, 2025, at 17:07, Ryan Winchester wrote:
> I wish for this often.
> 
> I would happily settle for this just to have it, although I don’t like the 
> syntax and also prefer the %{a, b} syntax like other languages (JS/TS, Rust, 
> ...)
> 
> On Sunday, December 21, 2025 at 2:12:13 AM UTC-4 [email protected] wrote:
>> I'm in support of this 👌
>> 
>> It's a reasonable trade off from other concerns and as someone who works 
>> with people moving from other languages to Elixir often, they are 
>> *constantly* looking for this syntax. Given that this exact syntax is used 
>> in other languages also adds some regularity to it, despite my personal 
>> preference for js style %{a, b}. The "accidentally being a tuple" issue with 
>> that syntax goes away for 99% of cases conveniently with the type system 
>> FWIW :)
>> 
>> 
>> 
>> 
>> 
>> On Sun, Dec 21, 2025 at 10:58 AM, Danila Poyarkov <[email protected]> wrote:
>>> Hi everyone,
>>> 
>>> José Valim suggested I move the discussion here from my PR: 
>>> https://github.com/elixir-lang/elixir/pull/15023
>>> 
>>> I've implemented shorthand syntax for atom-keyed maps and keywords:
>>> 
>>> ```elixir
>>> %{user:, conn:}  # => %{user: user, conn: conn}
>>> [foo:, bar:]     # => [foo: foo, bar: bar]
>>> f(name:, age:)   # => f(name: name, age: age)
>>> %{map | a:, b:}  # => %{map | a: a, b: b}
>>> ```
>>> 
>>> I know this topic has been discussed many times before:
>>> 
>>> - Proposal: Short Hand Property Names (2017): 
>>> https://groups.google.com/g/elixir-lang-core/c/XxnrGgZsyVc
>>> - Consider supporting a map shorthand syntax (2018): 
>>> https://groups.google.com/g/elixir-lang-core/c/NoUo2gqQR3I
>>> - ES6-ish property value shorthands for maps? (2016): 
>>> https://elixirforum.com/t/es6-ish-property-value-shorthands-for-maps/1524
>>> - Has Map shorthand syntax caused you any problems? (2018): 
>>> https://elixirforum.com/t/has-map-shorthand-syntax-in-other-languages-caused-you-any-problems/15403
>>> 
>>> Most of these discussed the ES6-style `%{a, b}` syntax, which José made 
>>> clear had "zero chance" of being accepted — mainly because `%{a, b}` vs 
>>> `{a, b}` differs by one character, making maps and tuples too easy to 
>>> confuse.
>>> 
>>> The colon-based syntax `%{a:, b:}` is different. The `:` that signals "this 
>>> is a key-value pair" stays there. There's no visual confusion with tuples 
>>> because `{a:, b:}` is not valid Elixir syntax anyway.
>>> 
>>> José mentioned in the PR that he actually prefers this approach over bare 
>>> variables, but it was "deemed not acceptable by most people" in a previous 
>>> discussion. I'd like to understand what the objections were.
>>> 
>>> Reading through the old threads, I found these concerns:
>>> 
>>> - "Removing explicitness for the sake of brevity doesn't appeal to me." 
>>> (Chris Keathley)
>>> - "Shorthand syntax makes that coupling even less obvious" — if you change 
>>> a key, you need to find all functions that relied on that variable name. 
>>> (Chris Keathley)
>>> - "This will just add complexity to the language to save a few keystrokes 
>>> for advanced users." (Matt Widmann)
>>> 
>>> These discussions happened in 2016-2018. Since then, Ruby 3.1 shipped this 
>>> exact syntax in December 2021 — almost 4 years ago. The syntax is `{x:, 
>>> y:}` for hashes and `foo(x:, y:)` for keyword arguments, exactly what I'm 
>>> proposing for Elixir.
>>> 
>>> The Ruby reception was mixed at first — Bozhidar Batsov (RuboCop 
>>> maintainer) was critical 
>>> (https://batsov.com/articles/2022/01/20/bad-ruby-hash-value-omission/) but 
>>> still allowed it in RuboCop defaults. Four years later, the syntax is 
>>> widely used.
>>> 
>>> The same pattern (sometimes called "field punning") also exists in Rust and 
>>> OCaml.
>>> 
>>> `%{user: user, conn: conn}` is already common in Elixir — this just removes 
>>> the repetition. The colon stays visible, so it's not as "magic" as the bare 
>>> variable approach. And Ruby has been using it for 4 years now without 
>>> issues.
>>> 
>>> The implementation is ready and all tests pass. I'm curious whether 
>>> opinions have changed since 2018.
>>> 
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "elixir-lang-core" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to [email protected].
>>> To view this discussion visit 
>>> https://groups.google.com/d/msgid/elixir-lang-core/995a7fec-5992-484a-88c2-5aae3844f60fn%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/elixir-lang-core/995a7fec-5992-484a-88c2-5aae3844f60fn%40googlegroups.com?utm_medium=email&utm_source=footer>.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "elixir-lang-core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> To view this discussion visit 
> https://groups.google.com/d/msgid/elixir-lang-core/e74caae5-3239-4c68-a0e9-5a3046450accn%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/elixir-lang-core/e74caae5-3239-4c68-a0e9-5a3046450accn%40googlegroups.com?utm_medium=email&utm_source=footer>.

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/elixir-lang-core/8f903968-880c-44d2-8d4c-4c5a20be3c61%40app.fastmail.com.

Reply via email to