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 poem-openapi, a framework to implement OpenAPI services.
llogiq is very pleased with his 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.
Ockam
If you are a Rust project owner and are looking for contributors, please submit tasks here.
244 pull requests were merged in the last week
Folder::Error
trait A where for<'a> Self: 'a
Layout::array
TypeFolder::fold_*
return Result
duration_consts_2
nonzero_is_power_of_two
MaybeUninit
behavior as constis_descendant_of
needless_late_init
lintneedless_question_mark
if_then_some_else_none
with early returnstrlen_on_c_string
non_ascii_literal
to cover charsOverall, many changes this week, but overall an improvement on multiple benchmarks over the week from a number of pull requests dedicated to optimizations of certain patterns. We are still seeing a large number of spurious changes due to rustc-perf#1105, which has yet to be addressed.
Triage done by @simulacrum. Revision range: 22c2d9d..1c028783
4 Regressions, 4 Improvements, 9 Mixed; 5 of them in rollups 41 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.
Rusty Events between 12/01-12/15 π¦
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.
Tangram
Flaps
CoBloX
Globelise
Bionaut Labs
Massa Labs
Tweet us at @ThisWeekInRust to get your job offers listed here!
The design of the safe/unsafe split means that there is an asymmetric trust relationship between Safe and Unsafe Rust. Safe Rust inherently has to trust that any Unsafe Rust it touches has been written correctly. On the other hand, Unsafe Rust cannot trust Safe Rust without care.
As an example, Rust has the
PartialOrd
andOrd
traits to differentiate between types which can "just" be compared, and those that provide a "total" ordering (which basically means that comparison behaves reasonably).
BTreeMap
doesn't really make sense for partially-ordered types, and so it requires that its keys implementOrd
. However,BTreeMap
has Unsafe Rust code inside of its implementation. Because it would be unacceptable for a sloppyOrd
implementation (which is Safe to write) to cause Undefined Behavior, the Unsafe code in BTreeMap must be written to be robust againstOrd
implementations which aren't actually total β even though that's the whole point of requiringOrd
.
β Gankra citing the Rustonomicon on github
Thanks to robin for the 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, marriannegoldin.
Email list hosting is sponsored by The Rust Foundation