Related Issues

• x/tools/go/ast/astutil : Unparen bad use of go/ast Unparen #69361 (closed)
• go/ast: formally deprecate Object #52463 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

What did you expect to see?
Either: Having deprecated types consistently replaced in the stdlib. Thus, let ParseDir() use the recommended replacement type.

ParseDir cannot be compatibly changed to return the recommended replacement type.

Or: Having ParseDir() marked as deprecated to.

I think parser.ParseDir is almost never the best solution to a problem, and it returns deprecated data structures, so it does make sense to deprecate it. A more robust solution is to use packages.Load, which invokes go list (or the appropriate build metadata query tool) to get the correct answer.

It sounds like ast.Package is deprecated, parser.ParseDir returns ast.Package, and we agree that people should not use parser.ParseDir anymore. So it seems like we should as a matter of logic also deprecate parser.ParseDir.

Have all remaining concerns about this proposal been addressed?

The proposal is to mark parser.ParseDir deprecated. It will still exist and be usable, but it returns ast.Package which is already deprecated.

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

It seems a shame to lose “parse directory” functionality in the stdlib. Package wasn’t that useful, but I’d rather un-deprecate it if it meant keeping ParseDir. Perhaps an alternative is to make a ParseFiles function that returns a slice of Files that ParseDir calls under the hood.

It seems a shame to lose “parse directory” functionality in the stdlib. Package wasn’t that useful, but I’d rather un-deprecate it if it meant keeping ParseDir. Perhaps an alternative is to make a ParseFiles function that returns a slice of Files that ParseDir calls under the hood.

We won't be losing any functionality; the function will still be there. But users will be informed that it's really not a satisfactory solution to most problems.

I know, I meant non-deprecated functionality. Aside from the container type the Files are returned in, it’s a perfectly satisfactory solution to parsing a directory. If there’s an argument that it’s harmful because people should use the packages package instead, that would be interesting, but I haven’t heard it.

parser.ParseDir doesn't respect go:build tags or build tags derived from file names. packages.Load handles them the same way that the go tool does. Or you can handle build tags yourself using the go/build/constraint package, and use parser.ParseFile for each file rather than parser.ParseDir. In any case the point is that ParseDir is a bit of a footgun that will work for many packages but also fail for many.

parser.ParseDir reads the Go files in a single directory, but returns a slice of packages. In today's Go world, that is weird; a directory holds a single package.

Should the “packages” package’s functionality be added to the “parser” package to provide a working package parser in the stdlib?

The parser works. But it doesn't know which files to parse. ParseDir is based on outdated build logic that may work for most packages (most being simple) but it doesn't handle lots of edge cases. There's go/build which handles more cases but basically at this point you need to get the list of what files to parse from the go command as that is what ultimately handles all the build logic. This is what go/packages does.

(It would be nice if there were a golang.org/x lib for the go command that handled all the encoding decoding and executing of all the subcommands as that's tedious to do and makes it hard to keep up with changes... cough cough)

Should the “packages” package’s functionality be added to the “parser” package to provide a working package parser in the stdlib?

No, because they have different responsibilities: the parser parses the content of a file; the go/packages package loads and optionally parses and type-checks a set of packages, and perhaps their dependencies. The implementation of go/packages is fairly substantial.

It would be nice if there were a golang.org/x lib for the go command

I agree. x/tools has an internal one but it's not nearly in a state to share.

It's fine to wish it was better, but it's not. This is marking it with the truth that it's not that great.
The better thing is packages.Load.

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

The proposal is to mark parser.ParseDir deprecated. It will still exist and be usable, but it returns ast.Package which is already deprecated.

Change https://go.dev/cl/649275 mentions this issue: go/parser: deprecate parser.ParseDir

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

The proposal is to mark parser.ParseDir deprecated. It will still exist and be usable, but it returns ast.Package which is already deprecated.

go/ast also has few functions that accept *ast.Package. Should we deprecate them also?

func FilterPackage(pkg *Package, f Filter) bool
func PackageExports(pkg *Package) bool
func MergePackageFiles(pkg *Package, mode MergeMode) *File

Also in go/doc:

func New(pkg *ast.Package, importPath string, mode Mode) *Package

Seems like NewFromFiles should be used now instead.

I agree that doc.New should be deprecated, but I don't think we can retroactively sneak it into this proposal.