Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: slices: add Channel #66409

Closed
3052 opened this issue Mar 19, 2024 · 5 comments
Closed

proposal: slices: add Channel #66409

3052 opened this issue Mar 19, 2024 · 5 comments
Labels
Milestone

Comments

@3052
Copy link

3052 commented Mar 19, 2024

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)
   }
}
@3052 3052 added the Proposal label Mar 19, 2024
@seankhliao
Copy link
Member

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
Copy link
Contributor

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.

@ianlancetaylor ianlancetaylor changed the title slices: Channel proposal: slices: add Channel Mar 19, 2024
@ianlancetaylor ianlancetaylor added this to the Proposal milestone Mar 19, 2024
@3052
Copy link
Author

3052 commented Mar 19, 2024

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
Copy link
Member

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants