Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reflect: do not deprecate Ptr APIs just yet #48665

Open
mvdan opened this issue Sep 28, 2021 · 7 comments
Open

reflect: do not deprecate Ptr APIs just yet #48665

mvdan opened this issue Sep 28, 2021 · 7 comments

Comments

@mvdan
Copy link
Member

@mvdan mvdan commented Sep 28, 2021

In basically all of my modules, I support the two latest major Go versions - right now, this means 1.16 and 1.17.
I develop on Go master, for the sake of helping with testing and developing new features.

In one of the codebases that must still support Go 1.16, I got the following warning from staticcheck:

$ staticcheck ./...
cmd/shfmt/json.go:27:7: reflect.Ptr is deprecated: use the new spelling, Pointer.  (SA1019)
syntax/walk.go:269:7: reflect.Ptr is deprecated: use the new spelling, Pointer.  (SA1019)

Staticcheck is right: the type is marked as deprecated.
Unfortunately for me, this is a warning that will be bothering me for six to twelve months before I can fix it.
reflect.Pointer won't appear until Go 1.18, and I won't drop support for 1.17 until 1.19 comes out.

I think the standard library needs to at least wait one major release before formally deprecating APIs.
That is, the earliest we could deprecate reflect.Ptr would be in Go 1.19, when the majority of module authors can stop worrying about Go 1.17 and older.

Alternatively, to be extra conservative towards module authors who move slowly, we could make the general rule to wait two major releases.

I thought this rule was already common knowledge, as https://go-review.googlesource.com/c/go/+/284777/ was rejected for deprecating io/ioutil too early.
We seem to have dealt with the reflect API changes differently, though.
Perhaps this means we should write down this general standard library deprecation rule?

Marking as NeedsDecision for 1.18, as making a decision after 1.18 would be a bit late :)

cc @ianlancetaylor @bradfitz @rsc

@mvdan mvdan added this to the Go1.18 milestone Sep 28, 2021
@mvdan
Copy link
Member Author

@mvdan mvdan commented Sep 28, 2021

Oh, and CC @dominikh for staticcheck, though I'm still fairly sure that it's correct here. At least as long as deprecation notices don't carry Go version information.

@bcmills
Copy link
Member

@bcmills bcmills commented Sep 28, 2021

At least as long as deprecation notices don't carry Go version information.

See previously #38149.

@mvdan
Copy link
Member Author

@mvdan mvdan commented Oct 22, 2021

I'm going to mark this as a release blocker, because some time has passed and I fear it might go under the radar given all that's happening for 1.18. We definitely need to make a choice before 1.18 comes out, and ideally before the first beta is out as well.

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Oct 22, 2021

I didn't realize tools would be so aggressive about this.

I'm fine tweaking the docs to a pattern recognizable to humans but not to tools for a few releases.

Want to send a change?

@randall77
Copy link
Contributor

@randall77 randall77 commented Oct 22, 2021

We'll need the same for CL 350691 which deprecated reflect.Value.Pointer.

@dominikh
Copy link
Member

@dominikh dominikh commented Oct 22, 2021

Oh, and CC @dominikh for staticcheck, though I'm still fairly sure that it's correct here. At least as long as deprecation notices don't carry Go version information.

FWIW, Staticcheck maintains a handwritten mapping of Go identifiers to 1) when they were deprecated 2) when their recommended alternative became available. As such, Staticcheck won't flag uses of a deprecated identifier if the user is targeting an older version of Go.

We usually update that mapping close to a Go release (either closely before or closely after...) and make a new release.

I thought this rule was already common knowledge, as https://go-review.googlesource.com/c/go/+/284777/ was rejected for deprecating io/ioutil too early.

Generally speaking, Go has always immediately deprecated things when alternatives became available. io/ioutil is the odd one out here.

@dominikh
Copy link
Member

@dominikh dominikh commented Oct 22, 2021

(as an aside, the reflect documentation still mentions Ptr and PtrTo in various places, such as in the documentation of New and UnsafePointer; someone should fix that)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants