Comment by kgeist

Not exactly because you cannot store the entire tuple in a variable.

To the novice reader in golang, it was an unexpected "wait, where did these symbols come from?" because I wasn't used to being able to look after the function signature for variable names, and that's doubly true for symbol names that didn't come from caller data

I'm sure this solved some Google-y problem but for my tastes it is just needlessly confusing since I have never met a programmer who needed help creating local variables and that's got to be infinitely true now that AI gonna take all our jobs

> Isn't it basically equivalent to an anonymous tuple which is automatically deconstructed on assignment?

Your comment brought up an interesting point: a certain audience may also think those names appear in the caller's scope because they're part of the function's published signature but are an implementation detail

    func Doit() (result int, err error) {
        return 123, nil
    }

    func main() {
        // a, b := Doit()
        // fmt.Printf("In reality %d %+v\n", a, b)
        Doit()
        fmt.Printf("Uh-huh %d %+v\n", result, err)
    }
    ./fred.go:13:32: undefined: result
    ./fred.go:13:40: undefined: err

I also just realized they're one of the places where golang doesn't emit a compile error for unused variables (as in the example above). Now I extra hate it

    func Doit() (result int, err error) {
        result = 123
        return 456, nil
    }