Had to pick either spec or cmd/vet for a prefix; picked spec but can still consider vet here.

It's surprisingly tricky to detect "weakly used" variables in the general case. In the simple example above, where x is a variable of struct type T and its field f field is not a reference, it suffices to prove that all references to x occur "on the left side" of an assignment. However, this simple check is inadequate for selections that are indirect. If the type of x.f is a pointer or reference, then the sequence of assignments x.f = y; x.f.g = 1 makes x appear to be "weakly used" (that is, only assigned) but it has the additional effect y.g = 1, which could be visible to other functions, as in this example:

type T struct { u *U }
type U struct { i int }

var global = T{u: new(U)}

func f() {
        var t T
        t = global
        t.u.i = 1
}

A sound check strong enough to catch the bug that motivated this proposal would require SSA form and a simple escape analysis, which is more complex than belongs in the language spec, but possibly appropriate for vet.

Would it be possible to make this a compiler error without including the restriction in the spec? Or is that generally avoided? (This is assuming that when a spec change was mentioned, it would be the compiler enforcing it, not vet)

I've sketched a simpler heuristic for vet in https://go-review.googlesource.com/c/47670.

@mvdan Unless a compiler accepts exactly the set of programs the spec requires it to accept, it is implementing a dialect of the language. Dialects cause problems for users because programs that work with one compiler or analysis tool don't work with another.

CL https://golang.org/cl/47670 mentions this issue.

We can't detect all possible bugs, but if we only count x.f = 1 as an assignment and don't count x.f1.f2 = 1 as one, perhaps we can at least do that.