Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tweet us at @ThisWeekInRust or send us a pull request. Want to get involved? We love contributions.
This Week in Rust is openly developed on GitHub. If you find any errors in this week's issue, please submit a PR.
This week's crate is zoxide, a smarter cd
command.
Thanks to Ajeet D'Souza for the self-suggestion!
Please submit your suggestions and votes for next week!
Always wanted to contribute to open-source projects but didn't know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!
Some of these tasks may also have mentors available, visit the task page for more information.
If you are a Rust project owner and are looking for contributors, please submit tasks here.
188 pull requests were merged in the last week
Backtrace::enabled
atomic from SeqCst
to Relaxed
ObligationCauseData
~const Drop
boundscore::intrinsics::black_box
and core::hint::black_box
PTR::as_ref
and similar methods const
entry_insert
#[cfg(test)]
to a test moduleneg_multiply
lintiter_skip_next
false positivesunwrap_or_else_default
when handling unwrap_or_else(XXX::new)
shadow_reuse
false negative for if let bindingsinit-numbered-fields
Relatively quiet week, mostly rustdoc improvements.
Triage done by @simulacrum. Revision range: 3d57c61a..e91ad5fc62
2 Regressions, 1 Improvements, 6 Mixed; 0 of them in rollups
26 comparisons made in total
Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:
Every week the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.
#[no_link]
attribute on name resolutionRusty Events between 12/29/2021 - 1/31/2022 🦀
If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.
The Daily Edit
Spruce
Parity Technologies
Tweet us at @ThisWeekInRust to get your job offers listed here!
One reason we keep certain things as hard errors rather than lints: it establishes a baseline that you can safely assume about other people's code, since it can't be turned off. And as a result, that baseline can become part of people's mental model of Rust itself, rather than something that might or might not be true in any given codebase.
We have to take care to not use that lightly, because that places work on all users of Rust to maintain code to that baseline. But there are cases where we do. We don't allow using one integer type where another was expected. We don't allow certain operations outside an unsafe block. ...
I think the standard we should apply is asking whether something is part of the baseline that people should be able to assume about all Rust code, and if that's worth the tradeoff of requiring that baseline of all Rust users.
– Josh Triplett on rust-internals
Thanks to Josh Triplett for the self-suggestion!
Please submit quotes and vote for next week!
This Week in Rust is edited by: nellshamrell, llogiq, cdmistman, ericseppanen, extrawurst, andrewpollack, U007D, kolharsam, joelmarcey, mariannegoldin.
Email list hosting is sponsored by The Rust Foundation