On Sun, 17 Aug 2025 at 07:14, Ruslan Semagin <pixel.365...@gmail.com> wrote:
> What I meant to highlight is the *mental model* programmers already use: > when reading `f(xs...)` it is commonly understood as “take all the elements > and pass them along.” My thought was that `ch <- xs...` extends that same > intuition into channel sends, even though the mechanics differ internally. > > So the comparison was more about readability and consistency from the > user’s perspective > I really do not think this is consistent semantically. ch <- x... means, in your suggestion ch <- x[0] ch <- x[1] … ch <- x[len(x)-1] That is not what f(x...) means at all. Functions don't even always range over their varargs - fmt.Printf, for example, really does use its argument as a slice with random accesses. > In that sense, `ch <- xs...` is intended as a lightweight, expressive > shorthand for a very common loop > I also would like to say that in more than ten years of using almost exclusively Go, I think I have written that loop less than ten times. Of course, it all depends on what kind of Go code you write. But I would actually argue that if this is a very common loop to write, we are doing something wrong. I don't think people should use channels directly very often, because they have pretty ambiguous semantics and it tends to be hard to get channel code right. So if people very commonly (commonly enough to justify this language change) use raw channels, that's an indication that there probably is some easier to use primitive of structured concurrency (akin to errgroup.Group) that we are missing and should be adding instead. > > > воскресенье, 17 августа 2025 г. в 02:25:47 UTC+3, Ian Lance Taylor: > >> On Sat, Aug 16, 2025 at 1:21 AM Ruslan Semagin <pixel....@gmail.com> >> wrote: >> > >> > I understand the concern about implicit loops and the general bias >> against them in the language design. >> > My thought here was that this case might be closer to the existing >> slice expansion at call sites (f(xs...)). In both cases we’re conceptually >> saying “apply this operation elementwise.” One is a function call, the >> other is a channel send. >> >> But the function call is not applied elementwise. As I tried to >> explain, the slice is passed directly, not element by element. See >> https://go.dev/play/p/R4B1wHZMTuL. >> >> Ian >> > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/golang-nuts/9e3f90a5-5c3f-444f-a2b8-0b93840253d7n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/9e3f90a5-5c3f-444f-a2b8-0b93840253d7n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHXKxBxUfaWmYJkEdMT6nshYSkd%2B-K0Y45H2PoiRswdCQ%40mail.gmail.com.
