> > I also considered this and I think the "multiple lets" and "multiple > reduces" could get confusing. Can I have both? Can I declare them > anywhere? The answer is no. Given you can't combine them and only use them > at the beginning, it feels like having only one is the more appropriate > choice. >
Yeah, that makes sense. I'm all for it. Especially doing this year's advent of code, this would have cleaned up *tons* of code, so I'm very excited about this proposal. Sent via Superhuman ( https://sprh.mn/?vip=zachary.s.dan...@gmail.com ) On Tue, Dec 21, 2021 at 6:12 PM, José Valim < jose.va...@dashbit.co > wrote: > > Thanks everybody for the feedback. Replies below! > > > > I will say, I'm still not a fan of using new qualifiers. I'm not sure > why we need to introduce a new special form for this, > > since we can do whatever we need to in the macro? What's wrong with: for > count = 0, count < 5, x <- element do {x, count + 1} end > > > I did consider this. However, using "count = ... " as a filter anywhere > does not change the return type of the comprehension. Why does setting the > variable at the beginning change the return type? Given it has a strong > impact on the return type, I think we need a clearer indicator. > > > Aso, "var = expr" in a comprehension means that, if expr is false or nil, > then no further code is executed. If we were to keep the semantics, then I > couldn't set an initial accumulator to nil. > > > In other words, the semantics are just too different for us to rely on the > existing behaviour. > > > > I really like this, and would be happy with it as is 😁 I have one > thought though, with the way > > that we are already doing a bit of “magic” (I don’t mean that in a > negative way) to map the “let” > > variable to the second element of the tuple, could we support multiple > assignments without the > > tuple in the let? > > > > I also considered this and I think the "multiple lets" and "multiple > reduces" could get confusing. Can I have both? Can I declare them > anywhere? The answer is no. Given you can't combine them and only use them > at the beginning, it feels like having only one is the more appropriate > choice. > > > > I was just wondering how it could be used from EEx/Phoenix templates, > looking at the previous example from Chris: > > > Phoenix will most likely need to use the implicit accumulator to make this > work. Then it becomes a question to ask the Phoenix team. However, given > it is exclusive to the template, it is probably fine to be implicit. > > > > > > -- > 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 elixir-lang-core+unsubscribe@ googlegroups. com ( > elixir-lang-core+unsubscr...@googlegroups.com ). > To view this discussion on the web visit https:/ / groups. google. com/ d/ > msgid/ elixir-lang-core/ > CAGnRm4%2BmRv0%2BptoVoKSN11y_C%2B56QP1vKBqXVdDFvoZQpqh7qQ%40mail. > gmail. com ( > https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BmRv0%2BptoVoKSN11y_C%2B56QP1vKBqXVdDFvoZQpqh7qQ%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 elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/kxgx52a7.422f0e4e-2702-4534-b049-b3963bbb48fd%40we.are.superhuman.com.
