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. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/5ae54324-3904-441d-b3c4-ae41819dc437n%40googlegroups.com.
