-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
impl Pattern for char array #86336
impl Pattern for char array #86336
Conversation
r? @dtolnay (rust-highfive has picked a reviewer for you, use r? to override) |
@@ -601,6 +608,17 @@ where | |||
} | |||
} | |||
|
|||
impl<const N: usize> MultiCharEq for &[char; N] { |
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.
This might be a silly question, but why for &[char; N]
instead of for [char; N]
?
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.
Actually that's what I started with, but then I figured this is more flexible/performant for large arrays. Definitely open to discussion on that. Maybe add both?
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 think you do want the reference to solve those bugs where one intends to write a literal &[char]
slice pattern, but it's really &[char; N]
.
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 think both -- ['o', 'l']
for the simple case, and &[...]
for the case cuviper mentions.
(I might just delegate both to the impl for slices, though, if there's an easy way to do that.)
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.
Okay, added both. Unfortunately lifetimes force a lot of separate structs and impls to satisfy into_searcher
.
@rust-lang/libs-api: This PR adds "...".find([' ', '\r', '\n'])
// or:
"...".find(&[' ', '\r', '\n']) whereas before, due to #39511, it would have had to be written as: "...".find(&[' ', '\r', '\n'][..]) |
Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
c26aed0
to
28f7890
Compare
Squashed a fixup commit |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon. |
It looks like this PR just needs a final review now that FCP has finished. |
Should |
@dtolnay you approved the changes in Github. Is that grounds to |
(Adding |
@bors r+ |
📌 Commit 28f7890 has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (c7e4740): comparison url. Summary: This change led to small relevant regressions 😿 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression |
visiting for triage. The only benchmarks that regressed did so by a small amount, percentage wise 0.2-0.6%; the benchmarks that did regress in that fashion are deeply-nested-async, helloworld, unify-linearly. I am surprised that this change caused even this minor regression, but I don't think its worth investing effort trying to figure out why, unless someone wants to take it on as a self-educating exercise. @rustbot label: +perf-regression-triaged |
Closes #39511
Closes #86329