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.
