proposal: slices: add Channel

[3052]

Proposal Details

a function that turns a slice into a channel:

package slices

func Channel[S ~[]E, E any](s S) chan E {
   c := make(chan E)
   go func() {
      for _, value := range s {
         c <- value
      }
      close(c)
   }()
   return c
}

example:

package slices

import (
   "fmt"
   "testing"
)

func TestChannel(t *testing.T) {
   hello := []int{1, 2, 3, 4, 5}
   for world := range Channel(hello) {
      fmt.Println(world)
   }
}

[seankhliao]

is this a common operation that should be in the standard library?
Channel as a name is ambiguous, why is it sending to a channel and not reading from a channel?
How would this proposal be impacted with the introduction of iterators?

[ianlancetaylor]

I think this is a dup of #61899 combined with #61898. We are more likely to route this through an iterator than add a special purpose slice-to-channel operation.

[3052]

is this a common operation that should be in the standard library?

yes

Channel as a name is ambiguous, why is it sending to a channel and not reading from a channel?

the function creates a channel that will return data from the given slice. the resulting channel would be read by the user of this function.

How would this proposal be impacted with the introduction of iterators?

channels aren't going away, and I think a big hurdle for new users is they dont "get them", so it might help to have a high visible function that uses channels. people can use the function as is, or look at the implementation to better understand a real use case of channels.

[seankhliao]

yes

generally, we like to see assertions backed up with evidence.

the function creates a channel that will return data from the given slice. the resulting channel would be read by the user of this function.

you've described the function, but that doesn't clear up the directional ambiguity.

channels aren't going away, and I think a big hurdle for new users is they dont "get them", so it might help to have a high visible function that uses channels. people can use the function as is, or look at the implementation to better understand a real use case of channels.

this points to having better guides / tutorials / examples, not a new function in the standard library which may arguably not be best practice to use.

[randall77]

I agree this looks dubiously useful at best. The usage example is certainly not motivating. Why put all items into a channel and iterate over the channel, instead of iterating over the slice directly?
Channel makes the channel internally, which is problematic because there is no way to set the buffering. (As opposed to some sort of Send function, which takes the channel and a slice as input.)

I think any path forward here would require a use case different than the one in the OP's example. Can someone provide a use case where this would simplify user code? Some pattern in real codebases would help.

In any case, this needs to be declined until iterators are sorted. Any such function would take an iterator, not a slice.