Bakul Shah, Similarly, you can make a counter-argument that this is just specific business logic and you can continue to use the usual loop.
вторник, 19 августа 2025 г. в 08:23:03 UTC+3, Ruslan Semagin: > 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/2bd1c30c-dc2e-4fda-bd23-00a1ad91a859n%40googlegroups.com.
