Brandon Gillespie <[email protected]> schrieb am Mo., 22. Dez. 2025, 16:52:

> 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.
>

That's a good point. The human expects that colon ":" is followed by
something.

There is no reason to repeat Ruby's mistakes, nor other languages doing the
> same. "because they are doing it" is not a reason.
>
In Ruby, it's more orthogonal. You already have it in the way keyword
arguments are declared:

def my_fun(a:, b:)

So adding {a:} to mean {a: a} is actually fine for Ruby. When you see "a:"
in Ruby, this could already mean that "a" is both a Symbol and a local
variable.

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"}`
>
I like this in general. But, if asdf is a Map itself, I'd expect that it to
be flattened. The "*" already has a meaning when coming from Ruby, so be
careful with that.


Actually, I'd rather do this:

```
%{asdf: ^}
```

which means, put in the variable of the same name as the key. Replace the
"^" with whatever other sigil you want.

Just my 5 cents...



> ```
> %{*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/CAKjimWJDOn4uZatdQxHOFs2ogrKj1asxSDnQvbFSzhkhe8G2hw%40mail.gmail.com.

Reply via email to