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

Multiple return values of function can't be correctly handled by fmt.Println #662

Closed
gopherbot opened this issue Mar 12, 2010 · 8 comments
Closed

Comments

@gopherbot
Copy link

by hou.danwu:

What steps will reproduce the problem?
---------------
Compile and run the attached program


What is the expected output? What do you see instead?
---------------
Expected: 
[1 2 3] false
[1 2 3] false
[1 2 3] false

Got:
[1 2 3] false
[1 2 3] false
{[] true}


What is your $GOOS?  $GOARCH?
--------------
$GOOS=linux
$GOARCH=386


Which revision are you using?  (hg identify)
--------------
changeset:   5040:bd4b0edb8c55
tag:         tip

Please provide any additional information below.

Attachments:

  1. test.go (571 bytes)
@griesemer
Copy link
Contributor

Comment 1:

Status changed to Accepted.

@griesemer
Copy link
Contributor

Comment 2:

The spec is not very precise about what should happen when you pass a function 
returning two results as the actual parameter for a ...T formal parameter. We should 
be clarifying this.
Superficially, this looks like a compiler bug. The following modification of your 
program seems to hang:
package main
import (
    "fmt"
)
// Foo and Bar are never actually called
// If they were commented out, the wrong behavior will disappear
func foo(string) ([]byte, bool) { return nil, false }
func bar()                      { fmt.Println(foo("test")) }
func sample_data() ([]byte, bool) { return []byte{1, 2, 3}, false }
func println(args ... interface{}) {
    println("len = ", len(args))
}
func main() {
    // This is correct of course
    //fmt.Println([]byte{1, 2, 3}, false)
    println([]byte{1, 2, 3}, false)
    // If we reference the return value at first, it works fine
    r, e := sample_data()
    //fmt.Println(r, e)
    println(r, e)
    //fmt.Println(sample_data()) // <-- strange result happens
    println(sample_data()) // <-- strange result happens
}

Owner changed to r...@golang.org.

@griesemer
Copy link
Contributor

Comment 3:

The modified version I should have used is this one:
package main
import (
    "fmt"
)
// Foo and Bar are never actually called
// If they were commented out, the wrong behavior will disappear
func foo(string) ([]byte, bool) { return nil, false }
func bar()                      { fmt.Println(foo("test")) }
func sample_data() ([]byte, bool) { return []byte{1, 2, 3}, false }
func f(args ... interface{}) {
    println("len = ", len(args))
}
func main() {
    // This is correct of course
    //fmt.Println([]byte{1, 2, 3}, false)
    f([]byte{1, 2, 3}, false)
    // If we reference the return value at first, it works fine
    r, e := sample_data()
    //fmt.Println(r, e)
    f(r, e)
    //fmt.Println(sample_data()) // <-- strange result happens
    f(sample_data()) // <-- strange result happens
}
which doesn't hang. It appears that the previous version was calling the built-in 
println instead of the user-defined one (which would be another compiler bug).

@griesemer
Copy link
Contributor

Comment 4:

The spec is not very precise about what should happen when you pass a function 
returning two results as the actual parameter for a ...T formal parameter. We should 
be clarifying this.
Superficially, this looks like a compiler bug.

@rsc
Copy link
Contributor

rsc commented Apr 28, 2010

Comment 5:

Labels changed: added compilerbug.

@rsc
Copy link
Contributor

rsc commented Apr 28, 2010

Comment 6:

Labels changed: added priority-high.

@rsc
Copy link
Contributor

rsc commented Apr 28, 2010

Comment 7:

Labels changed: removed priority-medium.

@rsc
Copy link
Contributor

rsc commented Apr 30, 2010

Comment 8:

This issue was closed by revision 253fd30.

Status changed to Fixed.

@golang golang locked and limited conversation to collaborators Jun 24, 2016
@rsc rsc removed their assignment Jun 22, 2022
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants