CC @randall77

I'd rather leave the special cases as is. Yes, it is a wart that we'll have to live with ~forever. But it isn't a big wart - you'll just have to use 0 instead of nil in a few places.
But leaving the special cases in means no one has to rewrite their code. Adding a go1.16 to the go.mod (presumably, for other unrelated reasons) won't trigger any required code changes. And we won't have a one-way gate from 1.15 to 1.16 that when people walk through, they can't walk back.

And we won't have a one-way gate from 1.15 to 1.16 that when people walk through, they can't walk back.

Can you elaborate? As explained in my proposal, you can make your code compatible with both Go 1.16 and previous versions by using implicitly zeroed variables of the special cased types.

True, if people adopt that pattern then their code will work in both 1.15 and 1.16.
There is no way to enforce that adoption, however. You'd have to test on both 1.15 and 1.16 to make sure you got it. I imagine some package authors will not do that. They'll have a = 0 or = nil assignment somewhere, and someone importing their package and using a different Go version will end up hitting a compile error.

We could in principle use the language version in the go.mod file to control how we handle these types. Then you might get a compilation error when updating to a new language version, but at least people importing your module wouldn't see a problem.

I guess if you put a 1.16 in your go.mod file, then anyone importing your package must be building with >= 1.16, so that works.
Then the trick Elias uses to avoid 0 or nil isn't really necessary. Just use nil everywhere.
But then you've forced all of the users of your package to upgrade to 1.16 (or keep using an old version of your package).

Or you don't use go.mod, but then you have to ensure you've used Elias's trick correctly, or use buildtags, ... Possible, but also not ideal.

So while I understand the motivation, the benefit seems minor and there's a real cost.

I guess if you put a 1.16 in your go.mod file, then anyone importing your package must be building with >= 1.16, so that works.

This is not strictly speaking true. Go 1.15 will still try to compile the code, it will just include "by the way the module says it wants Go 1.16" along with any compile error. Maybe that's enough.

We could also wait on this until GOPATH is gone (so everyone has go.mod).

It sounds like in the long term it would be good to clean up, but we need to wait for GOPATH to be gone so that all Go code is versioned at least at the top module (and then we'll define the implicit Go version for module dependencies without go.mod, but we can't do that yet). Putting on hold for now.

Gentle ping. Can this proposal be moved back on track given recent work on forwards/backwards compatibility, GODEBUG etc.? Waiting for GOPATH to be removed seems to me a too high bar.

Taking off hold.

It sounds like we know how to roll this out compatibly, in the sense that we could key off the go.mod go version to avoid breaking old code. We'd just always have the distinction between, say, "pre-Go 1.21 cgo" and "Go 1.21+ cgo" behaviors.

Is it worth the churn? Keith said above that maybe it was better to just have the wart forever. What are the benefits to cleaning this up?

The motivation above says:

When the Go garbage collector sees a non-pointer value, it may crash with a fatal error: invalid pointer found on stack.

But for these special types that's no longer the case. So is there any other motivation for re-changing them?

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

It sounds like we know how to roll this out compatibly, in the sense that we could key off the go.mod go version to avoid breaking old code. We'd just always have the distinction between, say, "pre-Go 1.21 cgo" and "Go 1.21+ cgo" behaviors.

Is it worth the churn? Keith said above that maybe it was better to just have the wart forever. What are the benefits to cleaning this up?

The motivation above says:

When the Go garbage collector sees a non-pointer value, it may crash with a fatal error: invalid pointer found on stack.

But for these special types that's no longer the case. So is there any other motivation for re-changing them?

Other than cleaning up big wart in Cgo, none, but it's pretty big wart.

It will never be entirely cleaned up - we have to keep the old code around and document that when go.mod says 'go 1.20' or earlier you get the old behavior (and say what that behavior is). That's a different kind of wart.

It doesn't seem like there is enough benefit here for the churn.

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

No change in consensus, so declined.
— rsc for the proposal review group