passing multiple values

[Martin Hurton]

Now a channel can be use to send a single value.
I wonder if it would make sense to extend the language so that one
could pass multiple values.
Did Go authors consider this option?

- Martin

[Russ Cox]

The language provides statement blocks, for loops,
and struct types, which cover all the possible meanings
of "pass multiple values" that I can think of.
Did you have something else in mind?

Russ

[Rich Wareham]

Can you not send structs down a channel?

--
Dr Rich Wareham

[Martin Hurton]

For example:

var c chan (int, os.Error)

then:
c<- 42, nil
or
val, err := <-c

- Martin

[Dave Cheney]

Hi Martin,

If you want to send multiple values through a channel, you need to
create a new struct type and send that

type s struct {
i int
err os.Error
}

c <- s{ i: 1, err: nil }

Cheers

Dave

[Ugorji Nwoke]

Though it's possible to send a struct, it feels like idiomatic GO supports sending multiple values. A function can return multiple values, even though the same argument could have been made that a function does not need to support returning multiple values (ie just package them in a struct).

I think Martin is asking if GO could be extended to allow channels support this same idiomatic mode which is currently supported for return values of functions.

[Jan Mercl]

On Friday, September 9, 2011 4:55:49 PM UTC+2, Ugorji Nwoke wrote:

Though it's possible to send a struct, it feels like idiomatic GO supports sending multiple values. A function can return multiple values, even though the same argument could have been made that a function does not need to support returning multiple values (ie just package them in a struct).

I think Martin is asking if GO could be extended to allow channels support this same idiomatic mode which is currently supported for return values of functions.

Let me disagree. I think what OP is asking is more similar to support for multiple values in an array/slice item. That is done using a struct or a pointer to a struct or by an interface valued item, not by some 'var a [](int, string); a[i] = 42, "foo";'.

In other words: -1

[Steven Blenkinsop]

On Fri, Sep 9, 2011 at 11:14 AM, Jan Mercl <jan....@nic.cz> wrote:

Let me disagree. I think what OP is asking is more similar to support for multiple values in an array/slice item. That is done using a struct or a pointer to a struct or by an interface valued item, not by some 'var a [](int, string); a[i] = 42, "foo";'.

In other words: -1

I'd say channel send/receive is more like a function call/return than storing in an array. I think the key factor is whether there's any value in handling the object, or if you're just using it as a medium for transmission. If the latter, then giving it a name and requiring it to be explicitly packed and, more significantly, unpacked, is syntactically awkward, to say the least. This is equally likely to be the case for functions and channels. If you're storing the object in an array, then it seems much more likely that there is value in handling the object itself (though there are always exceptions).

What get's in the way of multivalued channels is the comma-ok idiom. And I think multiple assignment was used overzealously here, and to detrimental effect, since having expressions with a variable number of values does wonky things to the regularity of the language.

[Paul Borman]

If the compiler knows the type of the channel (and it should, this is a statically typed language) then the compiler would have no problem with the comma syntax.  If the channel gives N values then the Nth + 1 value is the ok value.

BTW, C can easily return multiple values from a function call.  You just put them in a struct.  I don't know if I would want channels to be able to be defined as a multi-value channel or not.  But as Steven points out, the simple fact you can pack/unpack into/from a structure is probably not a sufficient argument against it (otherwise the same argument could be used against functions).

[Steven Blenkinsop]

On Monday, September 12, 2011, Paul Borman <bor...@google.com> wrote:
> If the compiler knows the type of the channel (and it should, this is a statically typed language) then the compiler would have no problem with the comma syntax.  If the channel gives N values then the Nth + 1 value is the ok value.

The problem isn't the compiler. It's a question of whether the *human* can parse it.

v, ok := <-ch

Is this checking for closed, or some other, potentially non-terminal "ok" condition? Of course, in the latter case, you have to look for what the condition means anyways, so I suppose this might not be a critical problem.