Axel, thanks for the answer. I should clarify, I really expressed myself too generally, this is not true. I just wanted to convey the main idea that the change does not complicate the language that much, but this is of course a debatable issue.
In general, I think that the discussion is useful, it corresponds to the spirit of open source. I personally want to take a break on this issue, I need time to think over additional arguments for implementing this change. For now, I think that the time for this change has probably not come, because as practice often shows, many ideas need time to accumulate weight. To be more specific, I will cite `wg.Go` #18022 <https://github.com/golang/go/issues/18022> here, it took nine years to implement it in the library code, and here is a whole addition to the language syntax. So it's not time yet. вторник, 19 августа 2025 г. в 08:12:48 UTC+3, Bakul Shah: > > On Aug 18, 2025, at 9:41 PM, Ruslan Semagin <pixel....@gmail.com> wrote: > > 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. > > > You need that information on the *sending* side. > > > вторник, 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...@googlegroups.com. > > To view this discussion visit > https://groups.google.com/d/msgid/golang-nuts/d4fb4b80-108d-4673-9347-7a352590f843n%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/d4fb4b80-108d-4673-9347-7a352590f843n%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/b7ce7f7a-ff13-4951-bb4d-a7bff8c171d7n%40googlegroups.com.
