proposal: io/ioutil: Annotate functions with "Deprecated: "
#51927
Labels
Milestone
Comments
jeffwidman
changed the title
"Deprecated: "
|
On Thu, Mar 24, 2022 at 1:12 PM Jeff Widman ***@***.***> wrote:
go 1.16 deprecated io/ioutil.
However, the relevant code never got the "Deperecated: " marker: https://tip.golang.org/src/io/ioutil/ioutil.go
Is there are a reason for this?
We've found in our own source code that it's easy for someone to reuse a code snippet, forgetting that ioutil is deprecated, and accidentally introduce it again and again into our code base.
Today the only way to remember to not let this creep have to implement special checks which seems like a lot of extra effort compared to leveraging the built-in deprecated marker.
Now that 1.18 has dropped, and the core team no longer support 1.16, would it be okay to mark these functions as deprecated starting with 1.19?
This way linters start reminding folks to move away from this code.
I'd be happy to submit a PR, but wanted to get approval in case there's a reason this hasn't been done yet.
For the reason it wasn't done before, see the discussion in
https://go.dev/cl/284777.
I think it's fine to do it now for 1.19. Thanks.
Ian
|
|
Sounds good. I nudged the author of #43799 and will give him a few days. If he's not interested or unreachable then I'll open a PR next week for this. |
This was referenced Mar 25, 2022
|
Change https://go.dev/cl/395918 mentions this issue: |
|
Change https://go.dev/cl/399854 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Apr 19, 2022
All APIs in the now-deprecated io/ioutil package have a direct replacement in either the io or os package with the same signature, with the notable exception of ioutil.ReadDir, as os.ReadDir has a slightly different signature with fs.DirEntry rather than fs.FileInfo. New code can easily make use of []fs.DirEntry directly, but existing code may need to continue using []fs.FileInfo for backwards compatibility reasons. For instance, I had a bit of code that exposed the slice as a public API, like: return ioutil.ReadDir(name) It took me a couple of minutes to figure out what the exact equivalent in terms of os.ReadDir would be, and a code sample would have helped. Add one for future reference. For #42026. For #51927. Change-Id: I76d46cd7d68fc609c873821755fdcfc299ffd56c Reviewed-on: https://go-review.googlesource.com/c/go/+/399854 Reviewed-by: Bryan Mills <[email protected]> Run-TryBot: Bryan Mills <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]> Run-TryBot: Ian Lance Taylor <[email protected]> Auto-Submit: Ian Lance Taylor <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
go 1.16 deprecated
io/ioutil.However, the relevant code never got the
"Deprecated: "marker: https://tip.golang.org/src/io/ioutil/ioutil.goIs there are a reason for this?
We've found in our own source code that it's easy for someone to reuse a code snippet, forgetting that
ioutilis deprecated, and accidentally introduce it again and again into our code base.Today the only way to remember to not let this creep have to implement special checks which seems like a lot of extra effort compared to leveraging the built-in deprecated marker.
Now that
1.18has dropped, and the core team no longer supports1.16, would it be okay to mark these functions as deprecated starting with1.19?This way linters start reminding folks to move away from this code, and prevent new uses of it.
I'd be happy to submit a PR, but wanted to get approval in case there's a reason this hasn't been done yet.
Related: #45557
The text was updated successfully, but these errors were encountered: