File IO Exercises added and tested - #2321
Conversation
|
Maintainers normally get a notification after every push to a PR. I will unsubscribe from this PR. Next time, please push all commits when ready. There is no need to create a draft PR if the maintainers didn't promise intermediate feedback. |
Hi @mo8it, I wasn't aware of the frequent notifications. Dev-check is not working properly on my Windows computer, so I had to commit a few times. I'm not expecting any more commits from my side if that's okay with you. |
|
I wanted to check in on this PR's status. It's been open since December 2025, all CI checks are passing, and it's mergeable, but there's been no maintainer review or feedback since the initial notification discussion. I also noticed @senekor's comment on the tracking issue (#2233) expressing that file I/O exercises might be out of scope for Rustlings, since the concepts overlap with general std::fs documentation rather than Rust-specific language concepts. That's a fair concern, and I'd rather get clarity now than leave this in limbo. Could you let me know: Whether the maintainers have reached a consensus on file I/O exercises being in/out of scope for Rustlings, and If there's appetite for a scaled-down version of this PR, what that might look like — or if it makes more sense to close this out (along with the related duplicate, #2191). Happy to adjust or close if that's the direction. Just want to avoid this sitting indefinitely. Thanks for your time. |
|
I don't have time to review right now, August should be better. I still have that opinion about file IO exercises in general. We discussed that using file IO for the async exerices, which we do want, would be good. So I'm fine at least with file IO exercises that prepare for the async ones. If Mo thinks more file IO exercises are good on their own, I'm not strongly opposed to adding them either. So, I personally will first work on the async exercises again before deciding what they need in terms of file IO. It would be helpful for future reviews if you could describe the learning goal of each exercise. Then we can first think about if the learning goals themselves are good and well-ordered. In a second step, the individual exercises can be reviewed in terms of how well they actually teach the intended goal. (Side note on LLM usage: There's no official policiy, but I think Mo is not a big fan just like myself. I would prefer you drop the Claude co-author out of your commits. The tools you use don't matter, only you are responsible for the code you submit. Maybe cleanup the commit history in general, while you're at it.) |
Adds three new exercises under exercises/24_file_io/, as proposed in rust-lang#2233: - file_io1: read a whole file with fs::read_to_string and handle the Result. - file_io2: read/write a file efficiently with BufReader/BufWriter. - file_io3: build a path with PathBuf and inspect it with .metadata(). Includes matching solutions and a README describing the learning goal of each exercise.
Adds file_io1-3 (and their solutions) to dev/Cargo.toml's bin list so 'cargo dev check'/'cargo dev update' pick them up, and registers them in rustlings-macros/info.toml with hints that explain each exercise's learning goal and point at the relevant std API.
|
Hi @senekor, Just a quick follow-up. I've cleaned up the branch history (down to 2 commits, no LLM co-author lines) and added learning-goal descriptions for each exercise to the README, per your feedback:
I also expanded the hints in info.toml to point at the relevant concept/API rather than just restating the exercise title. No rush given your August timeline, just wanted this ready and easy to review whenever you get to the async exercises and revisit file I/O scope. Thanks again for the detailed feedback. |
- file_io3: replace the hardcoded expected file size (117) with SAMPLE_TEXT.len(), so the check is derived from the actual content instead of an unexplained magic number. - file_io3: use create_dir_all instead of create_dir, and add a sample_file_path() helper shared by main/create_required_files/ file_cleanup to avoid three separate ad-hoc path constructions. - file_io1/file_io2: hoist the sample text into a SAMPLE_TEXT constant used by both the exercise and its solution, removing duplicated literals. No behavioral change: all three solutions were rebuilt and run locally, producing identical output (file size still 117, permissions still non-readonly) with no leftover files.
dev-check runs clippy with -D warnings against the solutions, which
flagged the nested if let Some(dir_path) = ... { if dir_path.exists() ... }
in file_cleanup as collapsible. Combined into a single if-let with a
let-chain condition (edition = "2024", so this is available).
Verified locally: compiles under --edition 2024, clippy is silent,
and the binary still runs cleanly with file size 117 and no leftover
files.
- file_io2: replace the manual line_number counter with .lines().enumerate(), and replace buffered_file_writer.write(format!(...).as_bytes()) with writeln!, which both formats and guarantees a complete write (write_fmt loops internally, unlike a single Write::write call). - file_io3: replace the manual match on file_path.parent() with .ok_or_else(...)? for a more idiomatic Option-to-Result conversion. Verified locally: both solutions compile under edition 2024, clippy is silent, and running them still produces identical output (3 lines processed / 117-byte file, non-readonly permissions) with no leftover files.
3 participants
Hi,
I've added the exercises as described in the issue 2233
Please feel free to give feedbacks, thanks.
#2233