Skip to content

Conversation

adetaylor
Copy link
Contributor

This PR is not intended to make any functional difference, but it replaces a reference with an owned Vec for a slight code simplification. This will become more useful in subsequent work towards arbitrary self types, RFC 3519 (#44874).

This PR is not intended to make any functional difference, but it
replaces a reference with an owned Vec for a slight code
simplification. This will become more useful in subsequent work towards
arbitrary self types.
@rustbot
Copy link
Collaborator

rustbot commented Aug 2, 2024

r? @davidtwco

rustbot has assigned @davidtwco.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 2, 2024
@adetaylor
Copy link
Contributor Author

The commit in this PR is also the first commit in #128548.

r? @wesleywiser

@rustbot rustbot assigned wesleywiser and unassigned davidtwco Aug 2, 2024
@@ -1093,7 +1086,7 @@ impl<'a, 'tcx> ProbeContext<'a, 'tcx> {
&self,
step: &CandidateStep<'tcx>,
self_ty: Ty<'tcx>,
unstable_candidates: Option<&mut Vec<(Candidate<'tcx>, Symbol)>>,
unstable_candidates: &mut Option<Vec<(Candidate<'tcx>, Symbol)>>,
Copy link
Member

Choose a reason for hiding this comment

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

Why did you invert this?

I think Option<&mut T> is generally preferred over &mut Option<T>, unless you intend to modify the value of the Option itself. Passing &mut Option<T> implies the wrong intention with this IMO, since passing in unstable_candidates indicates that that the caller wants unstable candidates recorded -- I don't expect the callee to ever, e.g., set *unstable_candiates = Some(vec![]).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fair enough - I'll close this PR.

It happens to simplify some of the subsequent work on arbitrary self types, but I'll find another way to do it. Most likely I'll make a newtype wrapper for this Option.

Copy link
Member

@compiler-errors compiler-errors Aug 2, 2024

Choose a reason for hiding this comment

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

I mean, I don't mind the other half of this PR, i.e. passing Option<Vec<..>> at the top level of pick -- I don't necessarily see why these had to change from Option<&mut Vec<>> to &mut Option<Vec<>> as a consequence though?

@adetaylor adetaylor closed this Aug 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants