Consider this scenario:
func foo(arg int) { .... }
...
foo(slice...)
The runtime will *complain* if slice has too many or too few elements compared
the number of args to foo. The runtime *does not* call foo as many times as the
number of elements in slice. You can think of <- as kind of a function that
takes two arguments, a channel and a value. So if you want to send N values,
you have to call it N times.
What you want would more cleanly fit in an array language, not Go!
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. Similarly in
select { case ch<-xs...: ... ; default: ... }
You don't know how many elements were passed before the default case became
active.
If sending multiple values is a common thing in an application, it can always
create a channel of slices as someone else also suggested.
> On Aug 17, 2025, at 5:36 AM, Ruslan Semagin <pixel.365...@gmail.com> wrote:
>
> Go already has places where a developer must understand a small semantic
> nuance. Take the example above, for example, `F(1, 2, 3)` allocates a new
> slice, while `F(s...)` passes an existing slice by reference, changes to
> which are visible outside the function. Developers learn this once, and it
> becomes natural.
>
> `ch <- xs...` is a similar case: the semantics are well-defined (element-wise
> dispatch with the usual channel behavior of blocking/closing), backwards
> compatible, and optional. Those who prefer an explicit loop can continue to
> write it, while others can use a more concise form that does not introduce
> ambiguity.
>
> In the comments on GitHub, it was also noted that it would be possible to
> support `ch <- 1, 2, 3` (link
> <https://github.com/golang/go/issues/75023#issuecomment-3192285316>)
>
> воскресенье, 17 августа 2025 г. в 08:49:16 UTC+3, Kurtis Rader:
>> On Sat, Aug 16, 2025 at 10:14 PM Ruslan Semagin <pixel....@gmail.com <>>
>> wrote:
>>> Thanks for clarifying, Ian. You are right, variadic expansion doesn’t
>>> literally apply element by element — the slice is passed as-is.
>>>
>>> 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, not about the underlying implementation. In that sense,
>>> `ch <- xs...` is intended as a lightweight, expressive shorthand for a very
>>> common loop, similar to how variadics provide an expressive shorthand for
>>> building argument lists.
>>
>> FWIW, it is far from obvious to me whether your proposed change is
>> equivalent to iterating over the list and injecting each element
>> individually or the channel is locked, every element injected, then the
>> channel is unlocked. Especially in light of the comparison to function calls
>> where that isn't an issue (beyond the usual race considerations involving
>> slices). Not to mention how the proposed syntax interacts with the edge case
>> of the channel being closed during the injection of the values. I appreciate
>> why you made the proposal (and might have made it myself) but at the end of
>> the day I feel the explicit loop is preferable.
>>
>> --
>> Kurtis Rader
>> Caretaker of the exceptional canines Junior and Hank
>
>
> --
> 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/5ae54324-3904-441d-b3c4-ae41819dc437n%40googlegroups.com
>
> <https://groups.google.com/d/msgid/golang-nuts/5ae54324-3904-441d-b3c4-ae41819dc437n%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/CE5B310D-ACF9-4B64-AA7C-1C22A9D89EDF%40iitbombay.org.
