On Tue, 19 Aug 2025 at 06:49, Ruslan Semagin <pixel.365...@gmail.com> wrote:
> 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. > I think that is a misreading of the responses. They where very specific to your suggestion. I do not understand how you can possibly come to this conclusion. 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. That is, to be clear, categorically untrue. *Every* addition to the syntax complicates the language, by definition. You might feel that the complication is justified by the benefit, but it is a complication. > 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. I don't think any of these are actually in doubt by anyone. None of these actually address any of the reasons given, not to introduce this change, though. > > > вторник, 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 > <https://groups.google.com/d/msgid/golang-nuts/eb580a6d-74ab-4b9b-be94-fcdeb25ad2b1n%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/CAEkBMfFWCShysKmT%2BDEnQPdvacygOEksuVwY3szgynH600DuyQ%40mail.gmail.com.
