proposal: conclude field tracking experiment

[nightlyone]

I propose to decide whether field tracking becomes an official feature and is available by default or can be removed.

Background

The field tracking experiment (activated via GOEXPERIMENT=fieldtrack runs since about 10 years now and leads to quite some special cases in the compilers (go and gccgo) as well as unique bugs like #42686. Usefulness and shape didn't change much. It looks more like an obscure feature to me at the moment than a real experiment where someone is active collecting data and analysing the impacts of it.

Maybe it is time to wrap it up, document the results and make a decision of whether Go should have this feature or not and act on that decision.

[beoran]

This feature seems to be obscure and not well documented. What was it intended to do?

[ianlancetaylor]

The best docs for GOEXPERIMENT=fieldtrack are probably still the CL that introduced it: https://codereview.appspot.com/6749064.

It's used within Google for large scale handling of protobufs, which is why people keep reporting bugs about it. Any other large scale user of protobufs could use it too if they wanted, and for all I know some do; there is some support for it in the google.golang.org/protobuf package. So I don't think it's going to go away.

But we could discuss ways of moving it out of GOEXPERIMENT. See also #42681.

[mdempsky]

I think the way forward is to simply have better regression tests for fieldtrack. We are interested in continuing to support its existing users, but I don't think we want to make it a more generally supported feature than that. E.g., I think we'd still like the flexibility to be able to change its semantics if necessary.

[rsc]

This mode is available for users who want it, much like dev.boringcrypto is.
Google uses both of them.
But neither is appropriate for Go proper, and neither is going to be enabled in the main Go distribution by default.

[mdempsky]

FWIW, a couple days I worked on https://go-review.googlesource.com/c/go/+/275034, and I would have accidentally broken fieldtracking again; except it was caught by the (super basic) test case I previously added in https://go-review.googlesource.com/c/go/+/271217.

So I already have a lot more confidence that field tracking should cause less maintenance pain going forward.