Bakul Shah, >The other issue is information loss. If the channel is closed *while* ch<-xs... is active, you don't know *how many* elements were passed.
The reader has this information, and can also find out at any time how many elements are already in the channel. вторник, 19 августа 2025 г. в 07:09:25 UTC+3, Ruslan Semagin: > Jason, thanks for the reply and advice, but I don't think I wrote anything > about the semantics of channels being ambiguous. > I think your reply is taking the discussion a bit off-track > > вторник, 19 августа 2025 г. в 04:16:20 UTC+3, Jason E. Aten: > >> 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/d4fb4b80-108d-4673-9347-7a352590f843n%40googlegroups.com.