> On Aug 18, 2025, at 9:41 PM, Ruslan Semagin <pixel.365...@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+unsubscr...@googlegroups.com > <mailto: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 > > <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/9C2EB19C-216E-4641-8359-BE8BB31D31D2%40iitbombay.org.
