http://play.golang.org/p/IxtYF1rXe9
-----
package main

type T struct {
    x int
    y string
}

func f() (*T, *T) {
    return &T{
            x: 1,
            y: "foo",
        }, &T{
            x: 2,
            y: "bar",
        }
}
-----

This doesn't happen when there's only one return value, or when one of the return values
is "nil".

Comment From: dsymonds

Comment 1:

It also happens if one of the return values is an anonymous func, which is where I keep
tripping over this.

Comment From: rsc

Comment 2:

Labels changed: added suggested, removed release-go1.3maybe.

Comment From: rsc

Comment 3:

Labels changed: added release-none.

Comment From: griesemer

Comment 4:

Labels changed: added repo-main.

Comment From: agnivade

@dsymonds - Just to clarify - you expected something like this ?

func f() (*T, *T) {
    return &T{
        x: 1,
        y: "foo",
    }, &T{
        x: 2,
        y: "bar",
    }
}

i.e. one less indent when arranging the composite literals.

Comment From: dsymonds

Yes, I'd expect those two closing braces for the &T literals to be at the same indentation as the return statement, but also the fields should only get a single level of indent, like what you get when you declare a var in the same way: (https://play.golang.org/p/0pH8-b_MdNI)

package main

type T struct {
    x int
    y string
}

func f() (*T, *T) {
    // Declaring a looks right.
    a := &T{
        x: 1,
        y: "foo",
    }

    // Returning a single composite literal looks right.
    return &T{
        x: 1,
        y: "foo",
    }

    // Returning multiple values looks wrong
    return &T{
            x: 1,
            y: "foo",
        }, &T{
            x: 2,
            y: "bar",
        }
}

Comment From: agnivade

Analysis: This is due to the indentList() function in go/printer/nodes.go L1229. If that function returns false, then the literals line up as intended.

And looking at the comment, it seems to be intentionally written to solve issue https://github.com/golang/go/issues/1207 (which was incidentally filed by @dsymonds yourself :)).

// Heuristic: indentList returns true if there are more than one multi- // line element in the list, or if there is any element that is not // starting on the same line as the previous one ends.

The difference appears if the element is itself a composite literal or not. For example, if that function returns false, this issue is solved. But issue 1207 breaks.

Breaks - 

return &T{
        x:  1,
        y:  "foo",
},
        nil

Fixes-

return &T{
        x:  1,
        y:  "foo",
 }, &T{
        x:  2,
        y:  "bar",
 }

Will leave it to @griesemer to take a final call if we want to add more heuristic to check if the elements are composite literals or not.

Comment From: heykvr

@rsc is this issue still opened ? please assign this to me , if so !