The Long-Awaited Return Type Notation RFC Is Here!
Today’s Issue: The Martial Art of Version Control, Building Plain Old Data from Scratch, and Making robots plan faster with SIMD and Rust
Hello Rustacean!
Welcome to another edition of the Rust Bytes newsletter. In this issue, we’ll discuss the newly approved Return Type Notation RFC, present a Rust challenge, spotlight an amazing Rust project, and highlight some incredible links of the week.
Welcome to issue 34.
Subscribe to the newsletter on our Substack if you haven’t already!
THE MAIN THING
RFC: Return Type Notation in Rust
This Rust RFC introduces a new feature called Return Type Notation (RTN). RTN allows you to specify or constrain the type of value returned by a trait method.
So I know you might be asking what problem does this Return Type Notation solve? Currently, specifying bounds on the return types of trait methods can be cumbersome. For instance, ensuring that asynchronous functions (async fn) in traits return Future types requires verbose workarounds. RTN aims to simplify this process and in a clean way.
How does RTN work?
Return Type Notation will use a new syntax, <T as Trait>::method(..) (or <T>::method(..) if the trait is inferred), to refer to the type returned by the method method on trait Trait for a value of type T. This notation can then be used in bounds and where-clauses.
For example, with RTN you could write:
where <T as Trait>::method(..): SendThis indicates that the type returned by method on any implementer of Trait must be Send.
Benefits of RTN
- RTN makes specifying return type bounds more concise and easier to understand.
- Better support for asynchronous functions ensuring that asynchronous trait methods return
Futuretypes.
Open questions and future directions
The RFC acknowledges some open questions and areas for future exploration, such as:
- Whether
T::method(..)should also be usable as a standalone type projection. - How to handle potential ambiguity with existing syntax like
Fn().
Current status
The RFC is still under discussion but has received positive feedback. It’s currently in the final comment period, where reviewers can raise any last concerns before merging.
CHALLENGE: RUST QUIZ❓
In our previous challenge you were tasked to efficiently reverse a string in place. We were hoping to see more solutions, but maybe everyone was busy flexing their coding muscles on other projects. Here is our solution.
Here is a challenge for you.
IP Validation
Description:
Write an algorithm that will identify valid IPv4 addresses in dot-decimal format. IPs should be considered valid if they consist of four octets, with values between 0 and 255, inclusive.
Valid inputs examples:
Examples of valid inputs:
1.2.3.4
123.45.67.89Invalid input examples:
1.2.3
1.2.3.4.5
123.456.78.90
123.045.067.089Notes:
- Leading zeros (e.g.
01.02.03.04) are considered invalid - Inputs are guaranteed to be a single string
Share your solution in the reply and link your code snippet as a Rust playground.
PROJECT SPOTLIGHT 💡
Jujutsu: The Martial Art of Version Control (But Without Throwing People Around)
Jujutsu is a powerful version control system for software projects. You use it to get a copy of your code, track changes to the code, and finally publish those changes for others to see and use.
It is designed from the ground up to be easy to use — whether you’re new or experienced, working on brand new projects alone, or large scale software projects with large histories and teams.
Here’s what makes Jujutsu fun:
- Git compatible so you can still use all your favorite Git tools. It’s like speaking a new language, but you can still order pizza in the old one.
- Automatic commits so no more worrying about a messy working copy. Every change is a commit, making your history a clean record of awesomeness.
- Conflicts happen, but Jujutsu helps you untangle conflict resolutions with grace (think less and more ).
- Rebasing your commits is a breeze, and Jujutsu automatically handles any conflicts that arise.
Jujutsu is still under active development, if you are curious check out the project on Github.
AWESOME LINKS OF THE WEEK 🔗
- Remember way back in our 20th issue, when we were just getting to know Inline Const in nightly builds? Well, buckle up because we’ve got some inline-credible news! The API is now officially stable in release 1.79.0. Const-ratulations, everyone!
- Clayton Ramsey wrote about Making robots plan faster with SIMD and Rust.
- Mistral.rs has just merged support for their first vision model: Phi-3 Vision. Kudos to Eric Buehler and the team.
- The Rust Foundation joined forces in a new group Consortium dedicated to the responsible use of Rust in safety-critical software (e.i cars, planes).
- Rou from Legend of Worlds team blogged about How he spent 2 years building a custom game engine named Toxoid.
- Forget Mr. Robot, SHRS is the new weapon of choice. Daniel Liu just released this rusty shell toolkit, fit for any hacker’s Elliot Alderson cosplay.
- One Variable team blogged about Building Plain Old Data from Scratch.
- Ashley Mannix released emit — A structured log event emitter for Rust.
- Tired of terminal envy? Rio’s here to cure it! This bad boy runs native on desktops and even chills in the browser thanks to WebAssembly. Multitasking never looked so geeky.
- Say goodbye to manual updates! Misty’s axoupdater is the WD-40 of cargo-dist, keeping your projects on fleek.
Do you have a challenging Rust problem or a helpful tip you’d like to share with fellow Rustaceans? We’d be delighted to feature them in a future issue, with full credit given to you. Submit your challenges or tips to us via email.
BEFORE YOU GO 👋
You’re our biggest fans, and we love to see it.
Here are a few ways you can help us spread the word:
- ❤️ Recommend Rust Bytes to your friends.
- 🤳 Connect with us on our socials: X, Rustaceans Publication.
- 📨 Contact us through rustaceanseditors@gmail.com feedback is welcome.
- ☕️ Buy Us Coffee.
That’s all for now, Rustaceans. Hope you’re having an amazing pride month!
John & Elley.\
