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/d4fb4b80-108d-4673-9347-7a352590f843n%40googlegroups.com.

Reply via email to