-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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
Comments
A Question: Am I correct to assume that the package will stay frozen? |
Yes, the package will remain frozen. This is only about not marking it as deprecated. |
This proposal has been added to the active column of the proposals project |
Why not port those to x/sys then and make it complete? |
@willfaught The point is that other packages such as |
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.) |
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. |
Based on the discussion above, this proposal seems like a likely accept. |
No change in consensus, so accepted. 🎉 |
Change https://go.dev/cl/520018 mentions this issue: |
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 ofos/exec.Cmd.SysProcAttr
)syscall.Signal
(referenced by documentation ofos.Signal
)syscall.WaitStatus
(referenced by documentation ofos.(*ProcessState).Sys
)syscall.Stat_t
(type returned byos.(*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.
The text was updated successfully, but these errors were encountered: