encoding/json/v2: keep v2 and jsontext packages buildable under GOEXPERIMENT=nojsonv2

[dmitshur]

In Go 1.26 and older, GOEXPERIMENT=jsonv2 had the effect of "make still-experimental encoding/json/v2, encoding/json/jsontext packages available, and also modify the encoding/json implementation to be implemented via the v2 packages" (release note). GOEXPERIMENT=nojsonv2 was a no-op.

As of CL 773962, JSONv2: true became the baseline. The current trajectory is that in Go 1.27 the aforementioned changes are the default, making it so explicitly setting GOEXPERIMENT=nojsonv2 means:

"The older v1-only implementation [...] can be enabled using GOEXPERIMENT=nojsonv2."

That aspect of GOEXPERIMENT=nojsonv2 seems useful to make it possible to start using the new Go 1.27 toolchain sooner and have temporary fine-grained control over its new behaviors. If someone needs to access the "older v1-only implementation" for some time, they can stay with a 1.27 toolchain and migrate any code that needs attention gradually. (This is in line with https://go.dev/blog/compat.)

As currently implemented at tip, GOEXPERIMENT=nojsonv2 can only be used when the package one is building and all of its dependencies (both direct and indirect) don't import encoding/json/v2 nor encoding/json/jsontext. Otherwise it will fail to compile. This is fine, but may not be as useful of a behavior for Go 1.27+; it just happened to be the natural outcome of making the jsonv2 baseline toggle a very small internal change.

So it might be worth considering removing the "//go:build goexperiment.jsonv2" build constraints in v2 and jsontext packages for Go 1.27, reducing the scope of GOEXPERIMENT=nojsonv2 to be about making the "older v1-only implementation" change only, and not be about making v2 and jsontext packages unavailable to be built. It could also be renamed/flipped to be "GOEXPERIMENT=jsonv1impl" if desired, though that's a bigger change that'd need updating some docs and touching every go:build constraint instead of only deleting some. Filing this issue to consider this.

CC @dsnet, @prattmic.

[prattmic]

At a glance, I think this would be useful for users to use GOEXPERIMENT=nojsonv2 to test if a behavior change in encoding/json is the cause of some failure they see.

If their dependencies already use encoding/json/v2, it won't be possible to use GOEXPERIMENT=nojsonv2, as their dependencies won't build anymore.

The primary arguments I see against this:

• Your dependencies can't be using 1.27 unless you are also using 1.27. So it seems like this would only come up if you run into a problem a while after upgrading to 1.27. Hopefully problems you encounter appear right when you upgrade, so this should be somewhat rare, but still possible.

• Keeping encoding/json/v2 but reverting the encoding/json implementation introduces new possibilities for incompatibility. Notably, if your dependencies use v2 custom marshalers (encoding/json/v2.MarshalerTo), or new v2 struct tags, those will not be supported by the reverted encoding/json. This could cause new, different failures from what you saw before.

[prattmic]

The jsonv2 working group discussed this today.

Our general consensus is that we should not change the status quo for due to the niche benefit, potential for additional incompatibility, and intended short-term use of GOEXPERIMENT=nojsonv2.

In more detail:

• The behavior change only makes a difference when dependencies use encoding/json/v2, which implies that those dependencies must require Go 1.27. Gaining such dependencies implies that you must have successfully run with 1.27 for long enough to upgrade dependencies [1] before noticing a bug that GOEXPERIMENT=nojsonv2 fixes. That makes the applicability quite narrow.
• As I mention in the previous comment, the primary downside of this change is that it introduces new and exciting ways your program may break w.r.t. encoding/json/v2 and encoding/json compatibility.
• There are two obvious alternatives to addressing this problem: don't upgrade to Go 1.27 or don't upgrade the dependency.
• Avoiding upgrading is unfortunate, but GOEXPERIMENT=nojsonv2 is intended as a short-term workaround for problems with encoding/json. It is not a compatibility GODEBUG intended for long term use. We expect that most issues warranting use of GOEXPERIMENT=nojsonv2 would also warrant a backport to fix the problem. So users need to wait for a minor release, but not a full major release.

I'm going to tentatively close this, but we can reconsider if we get more feedback from users that this is painful.

[1] One edge case is that existing versions of your dependencies could have go1.27 build tags guarding use of encoding/json/v2`.