In general, it seems to me that much of the opposition here comes from a general reluctance to introduce *any* new syntax into the language. If I try to summarize the proposal clearly, it is nothing more than syntactic sugar for a very specific case.
This syntactic sugar: 1. Does not complicate the language. 2. Does not break backward compatibility. 3. Leaves the choice to the programmer which form to use in a given situation. 4. Reduces boilerplate in places where the pattern occurs. 5. Does not introduce new semantics or unexpected side effects—its behavior is exactly that of the explicit loop. 6. Can be fully and clearly documented in the language specification, as with other small sugars. It is not a revolutionary change. It is simply an additional, optional way of writing code in a specific situation. вторник, 19 августа 2025 г. в 07:41:31 UTC+3, Ruslan Semagin: > 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/eb580a6d-74ab-4b9b-be94-fcdeb25ad2b1n%40googlegroups.com.
