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 pubgrub, a Rust implementation of the state of the art version solving algorithm.
Thanks to Louis Pilfold for the 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.
ockam
Into<T>
generics up to improve compile time and binary sizejsonschema-rs
266 pull requests were merged in the last week
[_]::method
trimmed_def_paths
<...> defined here
note if the source is not availablepre_expansion_lint
Result
and Option
array_methods
BTree
hashesVec::retain
VecDeque
: improve performance for From<[T; N]
>is_sorted
for Range
and RangeInclusive
str::from_utf8()
validation when slice contains multibyte chars and str.chars().count()
in all * Fix read_to_end
to not grow an exact size buffer<[T]>::split_at_unchecked
and <[T]>::split_at_mut_unchecked
publicNonZero*::unchecked_
{add
, mul
} as constOption::
{copied
, take
, replace
}
cases](https://github.com/rust-lang/rust/pull/88834)HashSet
: Debug
numeric_literal::format()
if_then_panic
handle situation of BinOpKind::And || BinOpKind::Or
shadow
lintsdoc_unsafe
warn on unsafe traits as welllarge_enum_variants
equatable_if_let
implicit_hasher
A fairly busy week, with a relatively high percentage of PRs landing with regressions and improvements. The overall trajectory is fairly neutral for this week though.
Triage done by @simulacrum. Revision range: 83f147b..25ec82
5 Regressions, 5 Improvements, 5 Mixed; 1 of them in rollups
43 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:
No RFCs were approved 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 RFCs are currently in the final comment period.
#[repr(i8)]
to OrderingVec::leak
Rc<T>
Vec<u8>
to CString proc_macro::is_available()
alloc::prelude
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.
Grafbase
Jigzi
pganalyze
Oso
Kraken
Subspace Labs
Tweet us at @ThisWeekInRust to get your job offers listed here!
There's a common trope among people unfamiliar with rust where they assume that if you use unsafe at all, then it's just as unsafe as C and rust provided no benefit. Comparing C's approach to safety vs Rust's is like comparing an open world assumption to a closed world assumption in formal logic systems. In C, you publish your api if it's possible to use correctly (open world). In Rust, you publish a safe api if it's im possible to use in correctly (closed world). Rust's key innovation here is that it enables you to build a 'bridge' from open world (unsafe) to a closed world (safe), a seemingly impossible feat that feels like somehow pairwise reducing an uncountable infinity with a countable infinity. Rust's decision to design an analogous closed-world assumption for safe code is extremely powerful, but it seems very hard for old school C programmers to wrap their head around it.
Thanks to Alice Ryhl for the suggestion!
Please submit quotes and vote for next week!
This Week in Rust is edited by: nellshamrell, llogiq, and cdmistman.