proposal: io/fs: SkipFiles to skip current directory files but not subdirectories

[pjebs]

Proposal Details

Docs: https://pkg.go.dev/io/fs#WalkDirFunc and https://pkg.go.dev/path/filepath#WalkFunc

WalkDirFunc supports the return values SkipDir which skips traversing the current directory and the current directory's sub-directories.

SkipAll basically stops traversing the remaining files and directories.

Proposal:

Implement SkipDirFiles to skip traversing the current files in the current directory BUT NOT sub-directories.

[seankhliao]

Unlike SkipDir or SkipAll, this doesn't reduce the amount of calls made, WalkDir still needs to read the entire directory to find the nested directory.

it seems too specialized, and more appropriate for the callback to just do early returns as appropriate

[gabyhelp]

Related Issues

• proposal: io/fs,path/filepath: add iterator form of WalkDir #64341
• path/filepath: add SkipAll #47209 (closed)
• path/filepath: function filepath.Walk() handle filepath.SkipDir incorrectly #10533 (closed)
• proposal: io/fs, filepath: add more efficient Walk alternative #41974 (closed)
• path/filepath: add WalkDir (Walk using DirEntry) #42027 (closed)
• path/filepath: SkipDir does not work as expected for non-directory files #16280 (closed)
• proposal: path/filepath: Deprecate Walk #69604

Related Code Changes

• path/filepath: don't return SkipDir at top

Related Documentation

• Go 1 Release Notes > Minor changes to the library > The path/filepath package

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

[pjebs]

Note: https://pkg.go.dev/path/filepath#WalkFunc does read the entire list of files/directories in a particular directory.
https://pkg.go.dev/io/fs#WalkDirFunc does not as sean noted.

So for the first package, his argument would not be valid and it would be sensible, beneficial and simple to implement. Secondly, there seems to be a "vibe" to keep the 2 functions similar in functionality. Perhaps it can be implemented in the second package to keep them consistent. If not, then at least implement it in the first package and give another point of difference to choose between the two.