Can it be mixed with the normal type of pattern matching?, e.g. %{a:, b:,
c: %{d:, e: e_data} = c, f:} = something. If not, that's a hard no for
me. Otherwise, I would probably use it and am not strongly against it but
I would err on the side of caution. I get the appeal of shortcuts but I
think I prefer to suffer typing it all out than to add more syntax.
I'm training someone [in something other than Elixir] and I notice myself
explaining all the caveats as I go. It would be easier for us both if
there weren't so many caveats to explain. For me, this is one of those
caveats. I can imagine questions like: why can't I do %{"a" => , "b" => }
= map or how does [a:, b:] = kw work with ordering?
FWIW, doesn't gleam use the a: syntax? I prefer that to the bare variables
or adding more complexity with an * or other symbol. It seems more
obviously a syntactical shortcut than bare variables.
I tend to do all the extraction as the first line in the function, where I
want it to line wrap. As opposed to in the function head, where I would
rather it did not wrap and where I may be pattern matching to dispatch to
specific function heads. As far as I know, the dot syntax is slower than
pattern matching on a map. I would prefer that penalty was removed, which
is not feasible IIRC, to adding this syntax.
IMO, the ~w[a b c]a syntax should be avoided because you won't find it when
searching for :a and it doesn't line wrap.
On Wednesday, 24 December 2025 at 12:48:39 am UTC+11 [email protected]
wrote:
> I’m going to chime in but not in the official capacity of a member of the
> core team—this is just my personal opinion.
>
> Elixir is a *very* flexible and extensible language. In my experience
> with coworkers, OSS, and quite a few codebases, I find that folks tend to
> lean on *simpler constructs* whenever possible. My prime example of this
> is the ~w sigil; most of the time I see folks leaving comments on things
> like
>
> ~w[started completed errored]a
>
> asking to rewrite it as
>
> [:started, :completed, :errored]
>
> so that readers don't have to know or care about ~w. I find myself
> agreeing quite a lot.
>
> With a feature like this, I get that some folks coming from Ruby or JS can
> feel "at home" but it's going to be one more thing to have to think and
> reason about for everyone else. If you see:
>
> def create(%{user:, conn:}) do
> end
>
> now you'll have to think through:
>
>
> 1. This only matches if this is a map that has :user and :conn atom
> keys in it
> 2. If it is, then this will introduce user and conn variables
>
> For me that is too big of a cognitive burden for the reader (myself
> included).
>
> Other things I found net negatives:
>
> - If you want to change the variable name, because say you want it to
> become user_with_preloaded_stuff, now you have to change syntax
> because the previous one doesn't work anymore.
> - We have very few (if any?) constructs that introduce variable names
> that are not "pattern matching" where the variable name is explicit. This
> breaks that expectation.
> - ^ is yet another cognitive thing to keep in mind.
>
> The type system will let you do params.user and params.conn "just as
> safely", as others mentioned in the thread.
>
> Final thoughts: others have mentioned something along these lines, but to
> me a stable and mature language like Elixir should default to *not*
> adding stuff. To add features, and *especially* syntax, there should be
> such a strong case in favor of it that not adding it becomes the worst
> option. I don't think this is the case, by far.
>
> On Mon, Dec 22, 2025, at 6:41 PM, Brandon Gillespie wrote:
>
> I'm trying to avoid being too argumentative here, but leaning back on "its
> used in ruby so it can't be hard to learn" just doesn't correlate. That it
> is in ruby doesn't implicitly make it easy to learn. As I said: we don't
> have to repeat another language's mistakes 😂
>
> FWIW, I have never liked ruby. 😂 I don't code in it, despite trying a few
> times. I don't think of Elixir as still a derivative of Ruby, and I'd
> suggest decoupling that notion, TBH. We should focus on Elixir, as itself.
> not as a derivative of something else. And I think we should focus on
> expanding the dev pool /outside/ of ruby, not limiting within it.
>
> As I hire new devs and train them into things, they come knowing other
> popular languages like python and javascript. I generally don't target ruby
> devs. And they're as rare as Elixir devs, TBH.
>
> I hadn't considered a spread assignment (or whatever you want to call it)
> as it would apply to keywords. Me personally? I'd only ever use it with
> maps, so I'd be 100% fine if it was simply limited to maps. Keywords
> already have a lot of differences from maps anyway. On that assertion, I'm
> not sure what other objects there are to using it only with maps.
>
> Splat operator: Sure. It was just an off-the-cuff suggestion. Saying there
> could be something else. Fixation on something that's a broken syntax in
> any of the top3 languages just makes it harder and more eldritch, also
> raising the bar for new devs.
>
> All the arguments I've heard for the colon syntax center around "Ruby & a
> few others do it this way" (and IMHO because somebody else does it isn't
> ever a good reason), and "I want it, so is this a good enough concession?"
>
> If this type of feature is really needed, I'd suggest even a working group
> session of interested parties, and just wipe the slate clean. Star by
> clearly defining the core desire/need, then talk through all the various
> challenges, throw out 5~10 more options, discuss, etc. (I don't know if
> this is already a thing the community does, or not).
>
> But to me this isn't something that should be done via a PR and an email
> conversation with a few people who happened to be noticing things on the
> list during a holiday season.
>
> Just my "two cents" as it were, from one normally watching in the peanut
> gallery.
>
> -Brandon Gillespie
>
>
> On 12/22/25 10:07 AM, Allen Madsen wrote:
>
> Another language doing something certainly isn't a reason to adopt it.
> However, widespread usage of a feature in a language speaks to its
> usefulness and learnability. As stated previously, usage of this syntax is
> used pretty widely in the ruby community. So, I don't personally buy the
> "this is hard to learn" argument, because there's evidence to the contrary.
>
> It's also worth noting that Elixir would have the same reason as ruby to
> use the non-bare word syntax. In elixir you can do:
> def foo(bar, baz: baz) do
> end
>
> Where the keyword arguments are gathered into a keyword list. Barewords
> here wouldn't make sense by themselves even if you wrap them in a list.
>
> # not the same
> def foo(bar, baz) do
> end
>
> # is this matching [baz] or [baz: baz]
> def foo(bar, [baz]) do
> end
>
> The colon doesn't have that problem.
>
> def foo(bar, :baz) do
> end
>
> Towards the recommendation for using *, I think that is a less good option
> because it looks like the splat operator in ruby and the pointer operator
> in other languages.
>
> Allen Madsen
> http://www.allenmadsen.com
>
>
> On Mon, Dec 22, 2025 at 10:52 AM Brandon Gillespie <[email protected]>
> wrote:
>
> Please do not do this WITH THIS SYNTAX (but I really do want
> destructuring/etc).
>
> It looks like an error, no matter how hard you squint, nor rationalize.
>
> There is no reason to repeat Ruby's mistakes, nor other languages doing
> the same. "because they are doing it" is not a reason.
>
> The other problem with this is it is optimizing for the /advanced/ user,
> and not the common and new user. The community should be focused on making
> it EASIER to get into elixir, not harder.
>
> New users coming from the biggest languages out there are what we should
> consider, not those with less popular languages. And like it or not, the
> popular languages are Java, Python, Javascript. None of them support the
> proposed visually borked syntax.
>
> if anything, of those top three languages, Javascript does it with bare
> variables—so the only argument with weight (imho) that "other languages do
> it" would be for bare vars. But José has declined that syntax (I forget the
> reasons).
>
> If the option for bare vars is off the table completely and forever,
> perhaps consider another token?
>
> Asterisk almost could work. In spirit it almost hearkens back to C's
> pointer. And in this case used as a unary operation it wouldn't collide
> with multiplication, which is a binary operation.
>
> I don't love it, but fwiw:
>
> ```
> asdf = "foo"
> %{*asdf}
> ```
> => `%{asdf: "foo"}`
>
> ```
> %{*foo, *bar} = %{foo: "narf", bar: "boop"}
> IO.inspect({foo,bar})
> ```
>
> => {"narf", "boop"}
> But just in my own opinion, anything extending the core syntax should
> always keep "new programmers" as a key metric for if it'll work well.
>
> -Brandon Gillespie
>
>
> On 12/21/25 10:15 PM, Allen Madsen wrote:
>
> It'd be nice to support pinning as well.
>
> x = 1
> %{^x:} = %{x: 2} #=> %{x: ^x} = %{x: 2}
>
> Allen Madsen
> http://www.allenmadsen.com
>
>
> On Sun, Dec 21, 2025 at 10:42 PM Данила Поярков <[email protected]> wrote:
>
> Yes, you can try that on my PR:
>
> bin/elixir -e '%{foo:, bar:} = %{foo: 1, bar: 2}; IO.inspect({foo, bar})'
>
>
> On 22 Dec 2025 at 04:15:02, Joseph Lozano <[email protected]> wrote:
>
> 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 a topic in the
> Google Groups "elixir-lang-core" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elixir-lang-core/qyB5diWvJh8/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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
>
> <https://groups.google.com/d/msgid/elixir-lang-core/8f903968-880c-44d2-8d4c-4c5a20be3c61%40app.fastmail.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/CAL2xsVjSNWTRBL9Cu9oU_%2BEyH6rKMFYCuwezuZufBcK09TyyKg%40mail.gmail.com
>
> <https://groups.google.com/d/msgid/elixir-lang-core/CAL2xsVjSNWTRBL9Cu9oU_%2BEyH6rKMFYCuwezuZufBcK09TyyKg%40mail.gmail.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/CAK-y3CtYjGhq5LpAK%2BVD%3Dtdpgpi8kDYVk%3DND5NAAS8BRwH-HWQ%40mail.gmail.com
>
> <https://groups.google.com/d/msgid/elixir-lang-core/CAK-y3CtYjGhq5LpAK%2BVD%3Dtdpgpi8kDYVk%3DND5NAAS8BRwH-HWQ%40mail.gmail.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/61b6c3c4-add7-4ee4-85f4-13273c49d07d%40cold.org
>
> <https://groups.google.com/d/msgid/elixir-lang-core/61b6c3c4-add7-4ee4-85f4-13273c49d07d%40cold.org?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/CAK-y3CtcdBWnHKJkafmS8rtyCZYbbO053Asw2XsPtMgO5x4cOg%40mail.gmail.com
>
> <https://groups.google.com/d/msgid/elixir-lang-core/CAK-y3CtcdBWnHKJkafmS8rtyCZYbbO053Asw2XsPtMgO5x4cOg%40mail.gmail.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/bb6af636-7fae-4ff2-b5da-eb766c755279%40cold.org
>
> <https://groups.google.com/d/msgid/elixir-lang-core/bb6af636-7fae-4ff2-b5da-eb766c755279%40cold.org?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/c346cee1-4a8a-48f9-8a2e-b5b457e3a35dn%40googlegroups.com.
