Obviously channel semantics aren't ambiguous. Ruslan, channels do require perhaps an hour of careful study and memorization to use effectively.
You cannot yolo-code or guess your way to working with channels. There isn't anything to build intuition on--nothing prior to compare to. You simply must memorize the rules for buffered and unbuffered channels, both naked and inside a select statement. There is a 3x3 table for each. See the link below. It helps to write little programs to test each scenario. You can see my notes and an exercise that should clear things up pretty quickly here. https://github.com/glycerine/thinkgo?tab=readme-ov-file#channel-lifecycle Best wishes, Jason On Monday, August 18, 2025 at 9:28:02 AM UTC+1 Bushnell, Thomas wrote: > What part of the semantics of a channel are “ambiguous”? > > > > *From:* 'Axel Wagner' via golang-nuts <golan...@googlegroups.com> > *Sent:* Sunday, August 17, 2025 6:45 AM > *To:* Ruslan Semagin <pixel....@gmail.com> > *Cc:* golang-nuts <golan...@googlegroups.com> > *Subject:* Re: [go-nuts] Slice expansion in channel send statements (ch > <- X...) > > > > This message was sent by an external party. > > > > On Sun, 17 Aug 2025 at 07:14, Ruslan Semagin <pixel....@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...@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...@googlegroups.com. > > To view this discussion visit > https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHXKxBxUfaWmYJkEdMT6nshYSkd%2B-K0Y45H2PoiRswdCQ%40mail.gmail.com > > <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHXKxBxUfaWmYJkEdMT6nshYSkd%2B-K0Y45H2PoiRswdCQ%40mail.gmail.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/cce5c04c-50f5-47a5-953a-7cdda618bae6n%40googlegroups.com.
