proposal: spec: let := support any l-value that = supports

[bradfitz]

(Pulling this specifically out of #377, the general := bug)

This proposal is about permitting a struct field (and other such l-values) on the left side of :=, as long as there's a new variable being created (the usual := rule).

That is, permit the t.i here:

func foo() {
    var t struct { i int }
    t.i, x := 1, 2
    ...
}

This should be backwards compatible with Go 1.

Edit: clarification: any l-value that = supports, not just struct fields.

/cc @griesemer @ianlancetaylor

[robpike]

I think instead we should aim to eliminate redeclaration, which becomes much less compelling if we can get to a smoother error handling model. Won't happen soon though.

Remove features rather than add them.

[ianlancetaylor]

I think that eliminating redeclaration is a good path, but I'm not sure it affects this proposal. This basically says that you can write

    // Declare err, assign to s.f and err.
    s.f, err := F()

[josharian]

Why only struct fields? slice[i], array[i], map[k]?

Remove features rather than add them.

Removing restrictions can be a net increase in simplicity, if they result in a more uniform application of rules. This proposal would reduce some differences between what can be on the LHS/RHS of = and :=. (Although it is not obvious to me whether describing that set of differences gets easier or harder.)

[bradfitz]

Yeah, sorry, I oversimplified. Any L-value that works with =.

[zigo101]

And *pointer.

If redeclaration is removed, then a if block would become:

    if var x, y = f(); x == y {
        ...
    }

good? Personally, I can accept it.

[griesemer]

@go101 This is not about removing ":=" (which we definitively want to keep), but about the ability to redeclare a previously declared variable (which one can only do using ":=").

[networkimprov]

@robpike, how would you mitigate the millions (?) of lines of code that would be broken by eliminating assignment redeclaration?

[bradfitz]

@networkimprov, slightly off topic, but when we do remove language features, the plan is outlined in https://github.com/golang/proposal/blob/master/design/28221-go2-transitions.md ... language features can be removed (for a user declaring a certain language version), but we can't change language semantics and silently alter programs.

But this isn't a bug about removing language features. This is strictly about increasing the number of programs that are accepted and making := behave more like =.