Skip to content

refactor(shell): generate rc paths on demand - #5102

Closed
Cloud0310 wants to merge 1 commit into
rust-lang:mainfrom
Cloud0310:shell-rc-paths
Closed

Cloud0310 wants to merge 1 commit into
rust-lang:mainfrom
Cloud0310:shell-rc-paths

Conversation

@Cloud0310

Copy link
Copy Markdown
Contributor

Replace current rc_candidates logic of allocate upon every candidate as a iter for consuming lazily.

@rustbot

rustbot commented Sep 23, 2026

Copy link
Copy Markdown
Collaborator

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

Generate shell rcfile candidates lazily and consume them directly during
installation, removal, and pre-install messages.

Share first-candidate selection where applicable and preserve the existing
Bash, Zsh, and Tcsh selection rules.

@djc djc left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the motivation for this? It doesn't obviously seem like an improvement to me. It is less code which is nice, but not if it makes the code harder to understand. And exchanging a Vec allocation for Box<dyn> allocation hardly seems like a substantial improvement.

View changes since this review

Comment on lines +447 to +452
let host_profiles = config_dir
.into_iter()
.flat_map(|dir| dir.read_dir().into_iter().flatten())
.filter_map(Result::ok)
.map(|entry| entry.path())
.filter(|path| path.is_file() && path.ends_with("_profile.ps1"));

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't seem like an improvement.

@rami3l

rami3l commented Sep 23, 2026

Copy link
Copy Markdown
Member

Firstly I think Box<dyn xxx> is generally an anti-pattern here, as we should use impl xxx instead.

Secondly even if we use impl xxx here the stable way to write it will involve a lot of combinators. I think my previous consensus with @djc in maintaining this project is that we should write more imperative code and less functional code. As generator expressions are not stabilized yet, I would consider this change to be premature.

Conclusion: I'm inclined to closing this PR for now, but it might be worth another try when generator expressions are live.

@djc Would you agree?

@rami3l

rami3l commented Sep 23, 2026

Copy link
Copy Markdown
Member

@djc Aside: I think generator expressions will also allow us to avoid the use of Either::{Left,Right} in many cases where iterators are used.

@rami3l rami3l closed this Sep 23, 2026
@rami3l
rami3l deleted the shell-rc-paths branch September 23, 2026 14:43
@djc

djc commented Sep 23, 2026

Copy link
Copy Markdown
Contributor

I agree that this is not an improvement. I don't like describing it as "imperative" vs "functional", perhaps because "imperative" to me sounds like "old-school" and "functional" has a more positive connotation.

In my mind we want to write code that is easy to understand. Using combinators with (ideally short) callbacks can sometimes be a good way to do that, but IMO are often overused by (usually less experienced) Rust engineers.

Having code that is concise is a good goal, but sometimes code that is a little more verbose can be easier to follow, and in those cases I prefer the latter approach. Some of this is subjective, but a lot of it is not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants