Re: [elixir-core:11476] [Proposal] Overload capture operator to support tagged variable captures

I was catching up with the other discussions about this, and I'm having seconds thoughts about Elixir having this syntax sugar for maps. It all sums up to what Austin pointed out here . The bottom line, IMO (and agreeing

Re: [elixir-core:11474] [Proposal] Overload capture operator to support tagged variable captures

: is not an operator at the user level for JS but it behaves like one syntactically. You can add or remove spaces on either side and it works. That’s not true for Ruby or Elixir as moving the spaces around is either invalid or has a different meaning. -- You received this message because you are

Re: [elixir-core:11473] [Proposal] Overload capture operator to support tagged variable captures

On Thu, Jun 29, 2023 at 3:02 AM José Valim wrote: > Hi Chris Keele, thank you for the excellent proposal. I just want to add > that I agree with Paul that we don't need to support both strings and > atoms, but it must be clear that it applies to either strings or atoms (if > it supports only one

Re: [elixir-core:11472] [Proposal] Overload capture operator to support tagged variable captures

On Thu, Jun 29, 2023 at 2:51 AM Paul Schoenfelder < paulschoenfel...@fastmail.com> wrote: > For reasons explained in Austin's reply > , > a "barewords" implementation is not viable in Elixir, because of the > prevalence of

Re: [elixir-core:11472] [Proposal] Overload capture operator to support tagged variable captures

> This is a separate convo but I don’t see value in adding a primary syntax for sets given we can’t really use it in pattern matching. A syntax for only adding and removing set elements is, IMO, not worth it. I whole-heartedly agree. The indirection of our set implementation and lack of

Re: [elixir-core:11470] [Proposal] Overload capture operator to support tagged variable captures

This is a separate convo but I don’t see value in adding a primary syntax for sets given we can’t really use it in pattern matching. A syntax for only adding and removing set elements is, IMO, not worth it. On Thu, Jun 29, 2023 at 11:21 Christopher Keele wrote: > > Just throwing it out there

Re: [elixir-core:11470] [Proposal] Overload capture operator to support tagged variable captures

> Just throwing it out there that this notation would make for a very nice MapSet literal. :) :D I am deeply convinced that this is why python, in its walrus operator attempt to keep up with Ruby features, has not offered a

Re: [elixir-core:11468] [Proposal] Overload capture operator to support tagged variable captures

> %{foo, bar} Just throwing it out there that this notation would make for a very nice MapSet literal. :) > On 29 Jun 2023, at 10:05, Christopher Keele wrote: > > > There is another idea here, which is to fix this at the tooling level. > > > > For example, we could write %{foo, bar} and have

Re: [elixir-core:11468] [Proposal] Overload capture operator to support tagged variable captures

> There is another idea here, which is to fix this at the tooling level. > > For example, we could write %{foo, bar} and have the formatter automatically expand it to: %{foo: foo, bar: bar}. I do like this notion, but am worried about fragmentation at the tooling level. I see a syntax

Re: [elixir-core:11466] [Proposal] Overload capture operator to support tagged variable captures

It is probably a path at least worth exploring. It may address the issue, without changes to the language, in a way it also feels natural without impacting code readability. On Thu, Jun 29, 2023 at 10:59 Christopher Keele wrote: > > Another idea is to improve Elixir LS itself to suggest the

Re: [elixir-core:11466] [Proposal] Overload capture operator to support tagged variable captures

> Another idea is to improve Elixir LS itself to suggest the variable name itself after ":". So if I type "%{foo:", it immediately suggests " foo". So, once again, easy to write, easy to read. I think this is part of the popularity of the opinion that some such syntax should only work for

Re: [elixir-core:11464] [Proposal] Overload capture operator to support tagged variable captures

There is another idea here, which is to fix this at the tooling level. For example, we could write %{foo, bar} and have the formatter automatically expand it to: %{foo: foo, bar: bar}. So you get the concise syntax when writing, the clear syntax when reading. Since most editors format on save

Re: [elixir-core:11464] [Proposal] Overload capture operator to support tagged variable captures

> As a counter point: Ruby has added this feature as {foo:, bar:}, which would have a direct translation to Elixir. Source: https://bugs.ruby-lang.org/issues/14579 As a Rubyist who came to Elixir in the early days for personal projects before that Ruby syntax was implemented, and has only been

Re: [elixir-core:11462] [Proposal] Overload capture operator to support tagged variable captures

> I would argue that if we want to support only atoms, but make it clear that the syntax only applies to atoms, before an Elixir 2.0, we must leverage atom literals in the feature. The addition of a new operator (or, overloading of the capture operator in previous incarnations of this proposal) is

Re: [elixir-core:11462] [Proposal] Overload capture operator to support tagged variable captures

Honestly, I do not adore the syntax of the proposed solution, in either capture or $ operator incarnation. I would also prefer barewords. *Re: Paul's note:* > It is not at all clear to me why supporting string keys is critical to the feature 100%, Phoenix params parsing support. This is the

Re: [elixir-core:11460] [Proposal] Overload capture operator to support tagged variable captures

Hi Chris Keele, thank you for the excellent proposal. I just want to add that I agree with Paul that we don't need to support both strings and atoms, but it must be clear that it applies to either strings or atoms (if it supports only one of them) and the reason for that is because otherwise it

Re: [elixir-core:11459] [Proposal] Overload capture operator to support tagged variable captures

> For reasons explained in Austin's reply > , > a "barewords" implementation is not viable in Elixir, because of the > prevalence of both atom and string key types. > > IMO, discussing the nuance of if a barewords

Re: [elixir-core:11459] [Proposal] Overload capture operator to support tagged variable captures

> In reference to this discussion : > >> This is going to be a big deal for Phoenix. In our channels where we're matching against the message, we have lines like this pervasively: >> >> def handle_in(event, %{"chat" =>