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

syscall: undeprecate #60797

Closed
ianlancetaylor opened this issue Jun 14, 2023 · 10 comments
Closed

syscall: undeprecate #60797

ianlancetaylor opened this issue Jun 14, 2023 · 10 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. Proposal Proposal-Accepted
Milestone

Comments

@ianlancetaylor
Copy link
Contributor

The syscall package was marked as deprecated by https://go.dev/cl/127657 (at the time, no proposal was required). A consequence is that various IDEs and similar tools express concern about code that uses the syscall package. However, while most of the functionality of the syscall package is available in various golang.org/x/sys packages, some are not:

  • syscall.SysProcAttr (type of os/exec.Cmd.SysProcAttr)
  • syscall.Signal (referenced by documentation of os.Signal)
  • syscall.WaitStatus (referenced by documentation of os.(*ProcessState).Sys)
  • syscall.Stat_t (type returned by os.(*File).Stat().Sys() on Unix systems)

It is difficult for certain kinds of code to avoid using these types. This list is not comprehensive; there may be other such types.

Therefore, I propose that we revert https://go.dev/cl/127657. This will have no effect on how programs behave, but will avoid unnecessary complains from IDEs.

If we come up with a syntax for "new code should use this instead", we can apply that to most of the names exported by the syscall package.

@ulikunitz
Copy link
Contributor

A Question: Am I correct to assume that the package will stay frozen?

@ianlancetaylor
Copy link
Contributor Author

Yes, the package will remain frozen. This is only about not marking it as deprecated.

@rsc
Copy link
Contributor

rsc commented Aug 2, 2023

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

@willfaught
Copy link
Contributor

However, while most of the functionality of the syscall package is available in various golang.org/x/sys packages, some are not

Why not port those to x/sys then and make it complete?

@gophun
Copy link

gophun commented Aug 3, 2023

@willfaught The point is that other packages such as os use types from syscall in their public API, so you sometimes have to import syscall and not golang.org/x/sys.

@ianlancetaylor
Copy link
Contributor Author

Also we don't particularly want the standard library to depend on the x/sys/unix package. We could if we had to, but so far we've avoided it. (That said, the standard library tools do vendor in x/sys/unix, because cmd/pprof depends on it via golang.org/x/term.)

@rsc
Copy link
Contributor

rsc commented Aug 9, 2023

Go code has to use types like syscall.Signal. It is untenable to call all of syscall deprecated when it flags real uses like that.

@rsc
Copy link
Contributor

rsc commented Aug 9, 2023

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

@rsc
Copy link
Contributor

rsc commented Aug 16, 2023

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

@rsc rsc changed the title proposal: syscall: undeprecate syscall: undeprecate Aug 16, 2023
@rsc rsc modified the milestones: Proposal, Backlog Aug 16, 2023
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Aug 16, 2023
@gopherbot
Copy link

Change https://go.dev/cl/520018 mentions this issue: syscall: remove deprecation notice

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. Proposal Proposal-Accepted
Projects
Status: Accepted
Development

No branches or pull requests

7 participants