syscall: undeprecate

[ianlancetaylor]

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]

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

[ianlancetaylor]

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

[rsc]

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]

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]

@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]

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]

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]

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