why "for range channle" has one receiver but "for range array|slice|map" has two?

[T L]

why not unify them when designing them? "for dataIndex, data = range aChannel" looks great.

[Matthew Dempsky]

The "for k, v = range x" syntax iterates over all entries where x[k] == v.  Channels aren't indexable though, so that convention doesn't make sense for them.

On Wed, Jul 13, 2016 at 9:10 AM, T L <tapi...@gmail.com> wrote:

why not unify them when designing them? "for dataIndex, data = range aChannel" looks great.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[T L]

On Wednesday, July 13, 2016 at 11:38:19 PM UTC+8, Matthew Dempsky wrote:

The "for k, v = range x" syntax iterates over all entries where x[k] == v.  Channels aren't indexable though, so that convention doesn't make sense for them.

I think aChannel[dataIndex] == data is not unreasonable.
 

[Jan Mercl]

On Wed, Jul 13, 2016 at 5:56 PM T L <tapi...@gmail.com> wrote:

> I think aChannel[dataIndex] == data is not unreasonable.

Data race.

--

-j

[T L]

I don't we need the aChannel[dataIndex] == data syntax, I just mean returning dataIndex along with data is meaningful and makes range syntax unified.
 

--

-j

[Brad Fitzpatrick]

Regardless of whether this is a good idea, it's over 4 years too late for this discussion, due to https://golang.org/doc/go1compat

Let's move this to the more chatty golang-nuts@ mailing list, since the golang-dev list is reserved for code reviews.

 

[Michael Jones]

Because channel values do not have indices. They are a stream of values and each iteration of the for loop is “the” value.

 

If you made it with an index that counts up from zero, then you could be creating an iteration loop index that has nothing to do with the value in the channel. You could do that yourself:

 

dataIndex := 0

for data := range aChannel {

…

dataIndex++

--

[T L]

Then, is ti ok for Go2?

https://github.com/golang/go/issues/19978

[jtc...@gmail.com]

On Wednesday, July 13, 2016 at 11:10:46 AM UTC-4, T L wrote:

why not unify them when designing them? "for dataIndex, data = range aChannel" looks great.

Making both case able to return two values would require writing

 for _, value := range chanVar {}

for the much commoner case of just using the value. 

Jonathan

[T L]

Yes, most cases we do need one value. But sometimes, the value order is really useful.
For example:  for a channel with multiple senders and multiple receivers, each receiver will check the value order if the a multiple of N. If true, print a log.


 

[Jan Ziak]

On Wednesday, July 13, 2016 at 5:10:46 PM UTC+2, T L wrote:

why not unify them when designing them? "for dataIndex, data = range aChannel" looks great.

A channel:

• has potentially infinite lifetime, which means dataIndex could overflow
• isn't directly a key-value data structure

An array or slice:

• is finite because it is tied to the size of the address space (2**32 on 32-bit machines, and 2**64 on 64-bit machines), which means that it is impossible for the index to overflow uint32/uint64 (unless the element is smaller than a byte (which is unsupported by Go and many other programming languages))
  
• is directly a key-value data structure

[T L]

On Wednesday, April 19, 2017 at 2:14:56 AM UTC+8, Jan Ziak wrote:

On Wednesday, July 13, 2016 at 5:10:46 PM UTC+2, T L wrote:

why not unify them when designing them? "for dataIndex, data = range aChannel" looks great.

A channel:

• has potentially infinite lifetime, which means dataIndex could overflow

Yes, I see. This is why I propose this on the assumption that "the arbitrary precision int" proposal will get approved.
https://github.com/golang/go/issues/19623