Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
[red-knot] Add a
read_directory()
method to theruff_db::system::System
trait #12289[red-knot] Add a
read_directory()
method to theruff_db::system::System
trait #12289Changes from 6 commits
363c563
5d2038e
be11d86
00ea6b9
bbaca9b
ffb0bd9
96c1028
c93ffa4
c3583b0
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like to have named return types (over
impl
) because callers can then name those types (and e.g. store it in aStruct
).I would suggest introducing a
ReadDirectory
struct similar tostd::fs::read_dir
that is a thin wrapper aroundstd::vec::IntoIter
(or whatever the type of your wild iter chain below is)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see the value in doing that generally, but here I wonder if an opaque return type might actually be better? If you're e.g. relying on the exact type being returned from this method in a test (for example), you might get into difficulties if you later switch the test to using the
OsSystem
and find that a different type is returned from that struct'sread_directory()
method. I think there's some value in saying that the only API guarantee we give here is that some kind of iterator is returned.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the argument is API compatibility with
System
than the method should also return aBox<dyn...>
(and accept&SystemPath
instead ofAsRef<SystemPath>
as the argument). I think it's rare that we would switch between systems in tests and the change would be minimal. But having a concrete type can be helpful for a system implementation that's based on the memory file system (e.g. WASM).Anyway, I don't feel strongly (except that we shouldn't change the return type to
Box<dyn>
)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't feel strongly either. But I propose we add it when we need it