goroutines getting the return

[callbre...@gmail.com]

Hi,

I picked up Go a few months ago and have been enjoying developing in this language. I especially enjoy the ease of multi-threading with the go statement. But since return values of the function are discarded, I find that I keep repeating the same form to get the return value back from the thread. I think a lot of code could be streamlined if go statements returned an unbuffered channel for each return value of the function. Conceptually the channels that the go statement would return could be thought of as a "promise" that the calling function could ask for once it required the value.

Example

//F is a function with no parameters that returns an int
out := go F()

//would be equivalent to
out := make(chan int)
go func(){
   defer func() {
      close(out)
   }()
   out <- F()
}()

//condensing 7 lines into 1

Also, for the sake of efficiency and backwards compatibility. if variables are missing or the code uses '_' then no channel is created for that return value

Example

//G is a function that has the following signiture:
func G() (string, int)

//case 1: you want a channel for both the string and the int
s, i := go G()

//2: you want a channel for just the string
s := go G()

//3: you want a channel for just the int
_, i := go G()

//4: you don't want either return value
go G()
//in this case no channels are created

I did some quick searches on the forums if anyone else has brought up this discussion, and I didn't find anything. I'd love to help develop this behavior for future versions of Go, but I wanted to ask if this idea had been explored before? I'm not sure what would be the best way to handle errors in the thread. My initial idea is that you could add the ability to put defer statements directly after a go statement that could house a recover statement for that thread: "go F() defer G()"

In conclusion I think my idea would be a great addition to the language to streamline go statement even further and would still be backwards compatible. I'd love to help implement this if you agree, but I don't want to waste my time if this has already been explored or if there is another planned feature for assignment from go statements.

Let me know what you think.

[Lucio De Re]

Problem is, there isn't a "one size fits all" and channels have
drawbacks, so whereas you may be satisfied with channels, others may
want different synchronised ways to access the return values.

One could, for example, have a return "type" and a single channel of
that type, then one may want the type to be returned as a single value
instead of in a channel, in which case one may want to use a Mutex for
synchronisation. Or one may not want to block: is it going to be a
buffered or unbuffered channel?

My recent thoughts have been rather around a "Go" method that is
implemented along the lines you presented. That took me on a
galaxy-wide quest: why not have "If" or "Switch" or even "Func"
methods?

It's a curious language, Go is, if you scratch the surface a bit.

Lucio.

> --
> 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.
>


--
Lucio De Re
2 Piet Retief St
Kestell (Eastern Free State)
9860 South Africa

Ph.: +27 58 653 1433
Cell: +27 83 251 5824
FAX: +27 58 653 1435

[matthe...@gmail.com]

Here's the official proposal guidelines: https://github.com/golang/proposal#readme

And a list of open proposals: https://github.com/golang/go/labels/Proposal

This proposal may fall under Go 2: https://blog.golang.org/toward-go2, https://github.com/golang/go/labels/Go2

My suggestion for your proposal is to write out an example of the problem that you've faced from real code. I wasn't able to find any dupes in the issue tracker, but there could be an existing issue for this already. Please link to this thread in the proposal if you decide to open one.

Matt