title: Golang goroutine cannot use function return value(s)
body: <p>I wish I could do something like the following code with golang:</p>
  
  <pre><code>package main
  
  import (
      "fmt"
      "time"
  )
  
  func getA() (int) {
  
      fmt.Println("getA: Calculating...")
      time.Sleep(300 * time.Millisecond)
  
      fmt.Println("getA: Done!")
      return 100
  }
  
  func getB() (int) {
  
      fmt.Println("getB: Calculating...")
      time.Sleep(400 * time.Millisecond)
  
      fmt.Println("getB: Done!")
      return 200
  }
  
  func main() {
  
      A := go getA()
      B := go getB()
  
      C := A + B // waits till getA() and getB() return
      fmt.Println("Result:", C)
      fmt.Println("All done!")
  }
  </code></pre>
  
  <p>More specifically, I wish Go could handle concurrency behind the scene.</p>
  
  <p>This might be a bit off topic, but I am curious what people think of having such implicit concurrency support. Is it worth to put some effort on it? and what are the potential difficulties and drawbacks?</p>
  
  <hr>
  
  <p><strong>Edit:</strong></p>
  
  <p>To be clear, the question is not about "what Go is doing right now?", and not even "how it is implemented?" though I appreciate @icza post on what exactly we should expect from Go as it is right now. The question is why it does not or is not capable of returning values, and what are the potential complications of doing that?</p>
  
  <p>Back to my simple example:</p>
  
  <pre><code>   A := go getA()
     B := go getB()
  
     C := A + B // waits till getA() and getB() return
  </code></pre>
  
  <p>I do not see any issues concerning the scope of variables, at least from the syntax point of view. The scope of <code>A</code>, <code>B</code>, and <code>C</code> is clearly defined by the block they are living inside (in my example the scope is the <code>main()</code> function). However, a perhaps more legitimate question would be if those variables (here <code>A</code> and <code>B</code>) are "ready" to read from? Of course they should not be ready and accessible till <code>getA()</code> and <code>getB()</code> are finished. In fact, this is all I am asking for: The compiler could implement all the bell and whistles behind the scene to make sure the execution will be blocked till <code>A</code> and <code>B</code> are ready to consume (instead of forcing the programmer to explicitly implement those waits and whistles using channels).</p>
  
  <p>This could make the concurrent programming much simpler, especially for the cases where computational tasks are independent of each other. The channels still could be used for explicit communication and synchronization, if really needed.</p>