Awesome Unstable Rust Features

Mon, 26 Jul 2021 00:00:00 +0000

Introduction</h1>
This article describes several unstable Rust compiler features. It is intended to explain the basics of these features without diving into too much detail.</p>

What is unstable Rust?</h2>

Rust releases come in three channels; stable, beta and nightly.</p>

Not only does the nightly compiler come out every day, but it also is the only compiler that allows you to unlock unstable Rust features.</p>

This article discusses unstable compiler features. Unstable library features are another topic for another day.</p> </blockquote>

Why use unstable features</h2>

Unstable Rust can enable you to write API's that you could not express in stable Rust. Unstable features are used within both the compiler and standard library for that very reason.</p>

Using unstable features always comes with some risk. They can often behave in unexpected ways, sometimes even breaking Rust's memory safety guarantees and resulting in undefined behaviour. Parts of features can be well developed while other parts left undeveloped.</p>

It is not uncommon for a nightly compiler using unstable features, to hit an "internal compiler error" often called an ICE</a>. This happens when, during compilation, the compiler panics. This could be due to data and queries becoming malformed by incomplete features or even just hitting a todo!</code> on part of a feature that has not been worked on yet. If you run into an ICE it is often helpful to check if the issue is known about and if it is not, to report it to thebug tracker</a>. </p>

Rust provides no guarantee that it will continue to support its unstable features into the future. As Rust developers, we are spoilt with excellent backwards compatibility and stability. When unstable features are enabled, all of those guarantees are thrown out. What works today may work very differently tomorrow.</p>

I decided to look into unstable features not because I need them to solve a particular problem. I sought them out because I thought they were fun. Using unstable features for me was an interesting way of getting more involved in the development process of the language itself.</p>


A comprehensive list of unstable features can be found in the  compilers source code</a>.</p>
</blockquote>
Enabling unstable features</h2>
To start using unstable features the first thing you'll need to do is install a nightly toolchain by running the command:</p>
rustup</span> toolchain install nightly
</span></code></pre>
To use the nightly-toolchain run commands with the +nightly</code> modifier. </p>
<rust-command> +nightly <args>
</span></code></pre>
For example:</p>
cargo</span> +nightly run
</span></code></pre>
Alternatively, you can change your default compiler to nightly so that you won't need to use the +nightly</code> modifier.
I've often done this as I haven't found the nightly compiler to be too unstable, even for my projects that also compile fine on stable.</p>
rustup</span> default nightly
</span></code></pre>
Once you are using the nightly compiler you can just start using unstable features.
Let's give it a go.</p>
fn </span>main</span>() {
    </span>let</span> my_box = box </span>5</span>;
}
</span></code></pre>
Which results in this complier error:</p>
error[</span>E0658</span>]: box expression syntax is experimental; you can call `Box::new` instead
 --> src/main.rs:</span>2</span>:</span>18
  </span>|
</span>2 </span>|     </span>let</span> my_box = box </span>5</span>;
  |                  ^^^^^
  |
  = note: see issue #</span>49733 </span><https:</span>//github.com/rust-lang/rust/issues/49733> for more information
  </span>= help: add `#![</span>feature</span>(box_syntax)]` to the </span>crate</span> attributes to enable
</span></code></pre>
As is so often the case in Rust the help</code> message tells us exactly what we need to do.
We need to enable the feature using #![feature(box_syntax)]</code>.</p>
#![</span>feature</span>(box_syntax)]
</span>fn </span>main</span>() {
    </span>let</span> my_box = box </span>5</span>;
}
</span></code></pre>
All unstable features will need to be enabled with #![feature(..)]</code> before they can be used.
If you forget, the compiler is often able to point you in the right direction, however, this is not always the case.</p>
Now let's get started talking about some of the features themselves.
I've placed the names of the features that you need to enable in code blocks</code> in the headings for each feature while omitting them from the code snippets to keep them concise.</p>
Control flow, patterns and blocks</h1>
destructuring_assignment</code></h2>
It is very common in Rust to destructure a type when binding it to a definition.
This is most commonly done with a let</code> binding.</p>
// Create two "variables", one for x, one for y 
</span>let</span> Point { x, y } = Point::random();
</span></code></pre>
Traditionally this pattern has only been possible when instantiating a new definition.
destructuring_assignment</code> extends this to work when mutating values.
In other words, we can use destructuring without using let</code>.</p>
let </span>(</span>mut</span> x, </span>mut</span> y) = (</span>0</span>, </span>0</span>);

Point { x, y } = Point::random();
</span></code></pre>Early return from any block with label_break_value</code></h2>
One of the less well-known Rust features is the fact that loop</code>s can break with a value</a>.
Like many of the constructs in Rust loops are not just statements, but expressions</a>.</p>
// Keep asking the user to input an number until they give us a valid one
</span>let</span> number: </span>u8 </span>= </span>loop </span>{
    </span>if let </span>Ok(n) = </span>input</span>().</span>parse</span>() {
        </span>break</span> n;
    } </span>else </span>{
        println!("</span>Invaid number, Please input a valid number</span>");
    }
};
</span></code></pre>
label_break_value</code> extends this to work on any labelled block, not just loops.
This acts as a kind of early return</code> that works on any block of code, not just function bodies. </p>
To label a block you use a syntax similar to lifetimes.</p>
'block: {
     </span>// This block is now labelled "block"
</span>}
</span></code></pre>
It is already possible to label loops</a> much in the same way. </p>
We can put the same label on our break</code> to early return from that block.</p>
let</span> number = 'block: {
    </span>if</span> s.</span>is_empty</span>() {
	</span>break 'block </span>0</span>; </span>// Early return from block
    </span>}
    s.</span>parse</span>().</span>unwrap</span>()
}
</span></code></pre>

This feature is not equivalent to goto</a>.
It does not have the same damaging effects as goto as it only goes forward and breaks from a block.</p>
</blockquote>
Inlining the power of the ?</code> operator using try_blocks</code></h2>
The edition guide</a> uses this example to illustrate how the question mark operator works:</p>
fn </span>read_username_from_file</span>() -> Result<String, io::Error> {
    </span>let</span> f = File::open("</span>username.txt</span>");

    </span>let mut</span> f = </span>match</span> f {
        Ok(file) => file,
        Err(e) => </span>return </span>Err(e),
    };

    </span>let mut</span> s = String::new();

    </span>match</span> f.</span>read_to_string</span>(&</span>mut</span> s) {
        Ok(_) => Ok(s),
        Err(e) => Err(e),
    }
}
</span></code></pre>
Simplifying using the ?</code> operator, results in this equivalent code:</p>
fn </span>read_username_from_file</span>() -> Result<String, io::Error> {
    </span>let mut</span> f = File::open("</span>username.txt</span>")?;
    </span>let mut</span> s = String::new();

    f.</span>read_to_string</span>(&</span>mut</span> s)?;

    Ok(s)
}
</span></code></pre>
?</code> is used in the context of functions to early return an Err</code> if encountered.
try_blocks</code> unlock the same power but for any block of code rather than just functions.
With try_blocks</code> we can inline our read_usernames_from_file</code> function.</p>
try_blocks</code> relate to ?</code> in the same way that label_break_value</code> relates to return</code>.
The RFC for try_blocks</code> mentions label_break_value</code> as a potential way of desugaring  try_blocks</code>.</p>
Let's rewrite our read_username_from_file</code> function as a simple let</code> binding with a try</code> block.</p>
let</span> read_username_from_file: Result<String, io::Error> = try {
    </span>let mut</span> f = File::open("</span>username.txt</span>")?;
    </span>let mut</span> s = String::new();

    f.</span>read_to_string</span>(&</span>mut</span> s)?;

    Ok(s)
}
</span></code></pre>
I love this kind of thing especially for smaller expressions that can be made easier to read when not extracted into functions.</p>
inline_const</code></h2>
Currently, the way to get a value to be evaluated at compile time is by defining a constant.</p>
const </span>PI_APPROX</span>: </span>f64 </span>= </span>22.0 </span>/ </span>7.0</span>;

</span>fn </span>main</span>() {
     </span>let</span> value = </span>func</span>(</span>PI_APPROX</span>);
}
</span></code></pre>
With inline_const</code> we can do the same as an anonymous expression.</p>
fn </span>main</span>() {
     </span>let</span> value = </span>func</span>(</span>const </span>{ </span>22.0 </span>/ </span>7.0 </span>});
}
</span></code></pre>
With this simple example, the const</code> block is almost certainly not necessary, due to compiler optimisations such as constant propagation</a>,
however, with more complex constants, it may be helpful to be explicit with the block.</p>
This feature also allows for these blocks to be used in pattern position.
match x { 1 + 3 => {} }</code> results in a syntax error while match x { const { 1 + 3 } => {} }</code>does not.</p>
if_let_guard</code></h2>
Extends the if</code> guards</a> that you can use with match</code> statements to be able to use if let</code>.</p>
let_chains</code></h2>
Currently, if let</code> and while let</code> expressions can not be chained with ||</code> or &&</code>.
This feature adds that support.</p>
Traits</h1>
associated_type_bounds</code></h2>
Let's take this stable Rust function:</p>
fn </span>fizzbuzz</span>() -> impl Iterator<Item = String> {
    (</span>1</span>..).</span>map</span>(|</span>val</span>| </span>match </span>(val % </span>3</span>, val % </span>5</span>) {
        (</span>0</span>, </span>0</span>) => "</span>FizzBuzz</span>".</span>to_string</span>(),
        (</span>0</span>, _) => "</span>Fizz</span>".</span>to_string</span>(),
        (_, </span>0</span>) => "</span>Buzz</span>".</span>to_string</span>(),
        (_, _) => val.</span>to_string</span>(),
    })
}
</span></code></pre>
With the associated_type_bounds</code> feature we can use an anonymous type in this context:</p>
fn </span>fizzbuzz</span>() -> impl Iterator<Item: Display> { ... }
</span></code></pre>
Let's take a look at this horribly repetitive type signature:</p>
fn </span>flatten_twice</span><T>(</span>iter</span>: T) -> Flatten<Flatten<T>>
</span>where
</span>    T: Iterator,
    <T as Iterator>::Item: IntoIterator,
    <<T as Iterator>::Item as IntoIterator>::Item: IntoIterator,
{
    iter.</span>flatten</span>().</span>flatten</span>()
}
</span></code></pre>
With this feature, we can write it simply as:</p>
fn </span>flatten_twice</span><T>(</span>iter</span>: T) -> Flatten<Flatten<T>>
</span>where
</span>    T: Iterator<Item: IntoIterator<Item: IntoIterator>>,
{
    iter.</span>flatten</span>().</span>flatten</span>()
}
</span></code></pre>
Which is far easier for me to reason about.</p>
default_type_parameter_fallback</code>, associated_type_defaults</code> and const_generics_defaults</code></h2>
These features allow you to specify default values for generic types</a>, associated types</a> and const variables</a> respectively in more places.</p>
This allows you as a developer to create nicer APIs.
If a crate user is not interested in a detail and that item has a default then the detail can be omitted.
This also makes it easier to extend APIs without making breaking changes for your users.</p>
negative_impls</code> and auto_traits</code></h2>
Both of these features are used in the standard library. The traits Send</code></a> and Sync</code></a> are both examples of auto traits.</p>
The trait Send</code> is defined in the standard library as so</a>:</p>
pub unsafe</span> auto </span>trait </span>Send {
    </span>// empty.
</span>}
</span></code></pre>
Note the use of the auto</code> keyword.
This tells the compiler to automatically implement the Send</code> trait for any struct/enum/union as long as all the types that make up said type also implement Send</code>.</p>
Auto traits would not be very useful if simply every type always implemented them.
That is where negative_impls</code> come in.</p>
negative_impls</code> allows for a type to opt-out from implementing an auto trait.
Take for example UnsafeCell</code>. It would be very unsafe for an unrestricted UnsafeCell</code> to be shared across threads, therefore it would be very unsafe for it to be Sync</code>.</p>
impl</span><T: </span>?</span>Sized> !Sync for UnsafeCell<T> {}
</span></code></pre>
Note the creative use of !</code> to express "not Sync</code>".</p>
marker_trait_attr</code></h2>
This feature adds the #[marker]</code> attribute for traits.</p>
Rust disallows the defining of traits implementations that could overlap.
This is so that the compiler will always know which implementation to use because there will always be only one.</p>
Traits marked with #[marker]</code> cannot override anything in their implementations.
That way they are allowed to have overlapping implementations because all implementations will be the same.</p>
type_alias_impl_trait</code>, impl_trait_in_bindings</code> and trait_alias</code></h2>
impl Trait</code> tells the compiler to infer a concrete type to replace it with that implements Trait</code>.
Currently, impl Trait</code> is only used in the context of function arguments or return types.</p>
type_alias_impl_trait</code> and impl_trait_in_bindings</code> extend the places impl trait</code> can be used to include type aliases and let</code> bindings respectively.</p>
trait_alias</code> is subtlely different to type_alias_impl_trait</code>.
Everywhere you use a type alias the type must remain constant.
A single concrete type must be inferred by the compiler that works in all those places.
Trait aliases are more forgiving as they can be a different type in each place they are used.</p>
fn_traits</code> and unboxed_closures</code></h2>
The three traits Fn</code>, FnMut</code> and FnOnce</code> are known as the fn traits.
They are automatically implemented for any functions or closures that you create and are what provides the ability to pass arguments to them.</p>
An automatic implementation is currently the only way to implement those traits.
The fn_traits</code> feature allows for custom implementations on any type.
This is very similar to operator overloading but customising the use of ()</code>.</p>
#![</span>feature</span>(unboxed_closures)] </span>// required to implement a function with `extern "rust-call"`
</span>#![</span>feature</span>(fn_traits)]

</span>struct </span>Multiply;

#[</span>allow</span>(non_upper_case_globals)]
</span>const</span> multiply: Multiply = Multiply;

</span>impl </span>FnOnce<(</span>u32</span>, </span>u32</span>)> </span>for </span>Multiply {
    </span>type </span>Output = </span>u32</span>;
    </span>extern </span>"</span>rust-call</span>" </span>fn </span>call_once</span>(</span>self</span>, </span>a</span>: (</span>u32</span>, </span>u32</span>)) -> </span>Self::</span>Output {
        a.</span>0 </span>* a.</span>1
    </span>}
}

</span>impl </span>FnOnce<(</span>u32</span>, </span>u32</span>, </span>u32</span>)> </span>for </span>Multiply {
    </span>type </span>Output = </span>u32</span>;
    </span>extern </span>"</span>rust-call</span>" </span>fn </span>call_once</span>(</span>self</span>, </span>a</span>: (</span>u32</span>, </span>u32</span>, </span>u32</span>)) -> </span>Self::</span>Output {
        a.</span>0 </span>* a.</span>1 </span>* a.</span>2
    </span>}
}

</span>impl </span>FnOnce<(&</span>str</span>, </span>usize</span>)> </span>for </span>Multiply {
    </span>type </span>Output = String;
    </span>extern </span>"</span>rust-call</span>" </span>fn </span>call_once</span>(</span>self</span>, </span>a</span>: (&</span>str</span>, </span>usize</span>)) -> </span>Self::</span>Output {
        a.</span>0.</span>repeat</span>(a.</span>1</span>)
    }
}

</span>fn </span>main</span>() {
    assert_eq!(</span>multiply</span>(</span>2</span>, </span>3</span>), </span>6</span>);
    assert_eq!(</span>multiply</span>(</span>2</span>, </span>3</span>, </span>4</span>), </span>24</span>);
    assert_eq!(</span>multiply</span>("</span>hello </span>", </span>3</span>), "</span>hello hello hello </span>");
}
</span></code></pre>
Notice that this is being used to create a hacky version of function overloading</a> and variadic functions</a>.</p>
Sugar</h1>
box_patterns</code> and box_syntax</code></h2>
These two features make constructing and destructing Box</code>es easier.
The box</code> keyword replaces Box::new(..)</code> and allows for the dereferencing Box</code>es when pattern matching.</p>
struct </span>TrashStack<T> {
    </span>head</span>: T,
    </span>body</span>: Option<Box<TrashStack<T>>>,
}

</span>impl</span><T> TrashStack<T> {
    </span>pub fn </span>push</span>(</span>self</span>, </span>elem</span>: T) -> </span>Self </span>{
        </span>Self </span>{
            head: elem,
            body: Some(box </span>self</span>),
        }
    }

    </span>pub fn </span>peek</span>(</span>self</span>) -> Option<T> {
        </span>if let</span> TrashStack {
            body: Some(box TrashStack { head, .. }),
            ..
        } = </span>self
        </span>{
            Some(head)
        } </span>else </span>{
            None
        }
    }
}
</span></code></pre>
This makes things a little more ergonomic but I don't think there is much chance that this feature will ever be stabilised.
It seems to have existed forever with no plan for stabilisation but instead a little discussion about removing the feature.
box_synatx</code> is used heavily in the compiler's source and a little in the standard library.</p>
It is interesting to note that box</code> does not desugar to Box::new</code> but Box::new</code> is implemented in the standard library with box</code>.</p>
impl</span><T> Box<T> {
    ...
    </span>pub fn </span>new</span>(</span>x</span>: T) -> </span>Self </span>{
        box x
    }
    ...
}
</span></code></pre>async_closure</code></h2>
Currently to be async inside of a closure you have to use an async block.</p>
app.</span>at</span>("</span>/</span>").</span>get</span>(|_| async { Ok("</span>Hi</span>") });
</span></code></pre>
async_closure</code> allows you to mark the closure itself as async just like you would a async function.</p>
app.</span>at</span>("</span>/</span>").</span>get</span>(async |_| Ok("</span>Hi</span>"));
</span></code></pre>in_band_lifetimes</code></h2>
To use a lifetime it must be explicitly brought into scope.</p>
fn </span>select</span><</span>'data</span>>(</span>data</span>: &</span>'data</span> Data, </span>params</span>: &Params) -> &</span>'data</span> Item;
</span></code></pre>
With in_band_lifetimes</code> the lifetimes can be used without bringing them into scope first.</p>
fn </span>select</span>(</span>data</span>: &</span>'data</span> Data, </span>params</span>: &Params) -> &</span>'data</span> Item;
</span></code></pre>
Interestingly enough this was how lifetimes used to work</a> pre 1.0.0</code>.</p>
format_args_capture</code></h2>
This allows for named arguments to be placed inside of strings inside any macro that depends on std::format_args!</code>.
That includes print!</code>, format!</code>, write!</code> and many more.</p>
let</span> name = "</span>Ferris</span>";
</span>let</span> age = </span>11</span>;
println!("</span>Hello </span>{name}</span>, you are </span>{age}</span> years old</span>");
</span></code></pre>
It is likely that this will be stabilised with or soon after edition 2021.</p>
crate_visibility_modifier</code></h2>
With this feature you can write crate struct Foo</code> rather than pub(crate) struct Foo</code> and have it mean exactly the same thing.</p>
This makes pub(crate)</code> easier to write, encouraging the use of crate visibility when full pub</code> is not necessary.</p>
Types</h1>
type_ascription</code></h2>
Take for example the collect</code> method on Iterator</code>.
Collect transforms an interator into a collection.</p>
let</span> word = "</span>hello</span>".</span>chars</span>().</span>collect</span>();
println!("</span>{:?}</span>", word);
</span></code></pre>
This does not compile because Rust is unable to infer the type of word</code>.
This can be fixed by replacing the first line with:</p>
let</span> word: Vec<</span>char</span>> = "</span>hello</span>".</span>chars</span>().</span>collect</span>();
</span></code></pre>
With type_ascription</code> the let</code> binding is no longer necessary and one can simply:</p>
println!("</span>{:?}</span>", "</span>hello</span>".</span>chars</span>().</span>collect</span>(): Vec<</span>char</span>>);
</span></code></pre>
The : Type</code> syntax can be used anywhere to hint at the compiler "I want this type at this point".</p>
never_type</code></h2>
It is possible to define enum</code>s with zero variants.
Such an enum exists stable in the standard library.</p>
pub enum </span>Infallible {}
</span></code></pre>
It is possible to use this type in generics and function signatures but never possible for it to be constructed.
There are simply no variants to construct.</p>
The unit type, ()</code> would be equivalent to an enum with a single variant.
never_type</code> introduces a new type, !</code> which is equivalent to our Infallible</code> enum with zero variants.</p>
Because !</code> can never be constructed it can be given special powers.
We don't have to handle the case of !</code> because we have proven it will never exist.</p>
fn </span>main</span>() -> ! {
    </span>loop </span>{
        println!("</span>Hello, world!</span>");
    }
}
</span></code></pre>
Loops without a break</code> "return !</code>" because they don't ever return.</p>
!</code> can be very useful for expressing impossible outcomes in the type system.
Take for example the FromStr</code> implementation on this UserName</code> type.
This implementation is infallible because its implementation can never fail.
This allows us to set the Err</code> variant to type !</code>.</p>
struct </span>UserName(String);

</span>impl </span>FromStr </span>for </span>UserName {
    </span>type </span>Err = !;
    </span>fn </span>from_str</span>(</span>s</span>: &</span>str</span>) -> Result<</span>Self</span>, </span>Self::</span>Err> {
        Ok(</span>Self</span>(s.</span>to_owned</span>()))
    }
}
</span></code></pre>
It is then possible to use an empty match</code> on the Err</code> variant because !</code> has no variants.</p>
let</span> user_name = </span>match </span>UserName::from_str("</span>ethan</span>") {
    Ok(u) => u,
    Err(e) => </span>match</span> e {},
};
</span></code></pre>
With the feature exhaustive_patterns</code> the type system becomes smart enough for us to eliminate the Err</code> branch altogether.</p>
let</span> user_name = </span>match </span>UserName::from_str("</span>ethan</span>") {
    Ok(u) => u,
};
</span></code></pre>
We can combine this with destructuring to remove the match</code> leaving a beautiful line of code.</p>
let </span>Ok(user_name) = UserName::from_str("</span>ethan</span>");
</span></code></pre>Attributes</h1>
optimize_attribute</code></h2>
It is possible to specify how you want your binary to be optimised with Cargo.toml</code> using opt-level</code></a>.</p>
The opt-level</code> affects the entire crate while the optimize_attribute</code> can control optimization for individual items.</p>
#[</span>optimize</span>(speed)]
</span>fn </span>fast_but_large</span>() {
     ...
}
#[</span>optimize</span>(size)]
</span>fn </span>slow_but_small</span>() {
     ...
}
</span></code></pre>
This would be very useful for fine-tuning applications where the trade off between size and performance is particularly pronounced such as when using web assembly</a>.</p>
stmt_expr_attributes</code></h2>
This feature allows you to place attributes almost everywhere not just top-level items. For example with this feature, you are able to place an optimize attribute</a> on a closure.</p>
cfg_version</code></h2>
This feature allows for conditional compilation based on compiler version.</p>
#[</span>cfg</span>(</span>version</span>("</span>1.42</span>"))] </span>// 1.42 and above
</span>fn </span>a</span>() {
    </span>// ...
</span>}

#[</span>cfg</span>(</span>not</span>(</span>version</span>("</span>1.42</span>")))] </span>// 1.41 and below
</span>fn </span>a</span>() {
    </span>// ...
</span>}
</span></code></pre>
This allows crates to make use of the latest compiler features while still keeping fallback support for old compilers.</p>
no_core</code></h2>
It has been possible to opt-out of using the standard library using #![no_std]</code> for a while.
This is important for applications that don't run in a full environment such as embedded systems.
Embedded systems often don't have an operating system or even dynamic memory so many of the functions in std</code> wouldn't work.</p>
#![no_core]</code> takes it further by opting out of libcore.
That leaves you with almost nothing, you can't even use libc.
This makes it very difficult to implement anything useful.</p>
Other</h1>
Const Generics</h2>
I spoke about the future of const_generics at my talk for Rust Dublin</a>.
Rather than me reiterating what I said there, I encourage you to watch that talk</a>.</p>
Macros 2.0</h1>
Rust's declarative macros are very powerful however some of the rules around macro_rules!</code> have always confused me.</p>
For one, macro_rules!</code> acts as a simple token transformation.
It takes a list of tokens and outputs a new list of tokens, nothing smarter than that.
The publicity rules end up being the rules of where the macro is being called.
This is obvious because the codes is being simply pasted into that place.</p>
Macros 2.0 is an rfc describing a replacement to macro_rules!</code> with a new construct simply using the keyword macro</code>.</p>
One of the main improvements the new syntax introduces is macro hygiene which allows macros to use the publicity rules of where they are written rather than where they are called.</p>
generators</code></h2>
Generators/coroutines provide a special kind of function that can be paused during execution to "yield" intermediate values to the caller.</p>
Generators can return multiple values using the yield</code> keyword, each time pausing the function and returning to the caller.
A generator can then return</code> a single value after which it can no longer be resumed.</p>
About three years ago I attempted to write an algorithm to traverse an infinite matrix along its diagonals.
I found it very difficult to write that with Rust's iterators and ended up giving up.</p>
Here is an implementation using Rust's generators/coroutines along with a number of other features we've discussed already.</p>
#![</span>feature</span>(
    try_blocks,
    generators,
    generator_trait,
    associated_type_bounds,
    type_ascription
)]

</span>use </span>std::{
    iter,
    ops::{Generator, GeneratorState},
    pin::Pin,
};

</span>/// Input
/// [[1, 2, 3]
/// ,[4, 5, 6]
/// ,[7, 8, 9]]
/// Output
/// [1, 2, 4, 3, 5, 7]
</span>fn </span>diagonalize</span><T>(
    </span>mut </span>matrix</span>: impl Iterator<Item: Iterator<Item = T>>,
) -> impl Generator<Yield = T, Return = ()> {
    </span>move </span>|| {
        </span>let mut</span> rows = Vec::new();
        (try {
            rows.</span>push</span>(matrix.</span>next</span>()?);
            </span>for</span> height in </span>0</span>.. {
                </span>for</span> row in </span>0</span>..height {
                    </span>if</span> row >= rows.</span>len</span>() {
                        rows.</span>push</span>(matrix.</span>next</span>()?);
                    }
                    </span>yield</span> rows[row].</span>next</span>()?;
                }
            }
        }): Option<()>;
    }
}

</span>fn </span>main</span>() {
    </span>let</span> matrix = (</span>0</span>..).</span>map</span>(|</span>x</span>| iter::once(x).</span>cycle</span>().</span>enumerate</span>());
    </span>let mut</span> diagonals = </span>diagonalize</span>(matrix);
    </span>while let </span>GeneratorState::Yielded(value) = Pin::new(&</span>mut</span> diagonals).</span>resume</span>(()) {
        dbg!(value);
    }
}
</span></code></pre>

It is understandable if you found the above snippet hard to interpret.
It makes use of a number of features that you may have just been introduced to.</p>
There is a compelling argument against adding too many new features as they can greatly increase the learning curve.</p>
</blockquote>
Generators make it possible to write implementations that are far more difficult or even impossible to write without them.</p>
Generators were added to implement async-await in the standard library.
It is most likely that the exact semantics will change before any kind of stabilisation but they are very fun to play with.</p>
Final thoughts</h1>
I have to apologise for not including three amazing unstable features; Generic associated types</a>, inline asm</a> and specialization</a>.
I simply did not feel able to give these features justice in this article but I may try to talk about them in future.</p>
If you wish to read more about an unstable feature the best place to start is the unstable book</a> where most of them are listed.
The unstable book then links to a tracking issue</a> which then often, in turn, links to an RFC</a>.
With this combination of sources, you can then build up a picture of the details surrounding a feature.</p>
Thank you for reading my first blog post 😃.
The best way to support me is by following my Twitter</a>.
I am also looking for employment opportunities so please get in touch if you would like to talk about that.</p>

Lazy Codes

Awesome Unstable Rust Features

Introduction</h1>
This article describes several unstable Rust compiler features. It is intended to explain the basics of these features without diving into too much detail.</p>

Attributes</h1>

Const Generics</h2>
I spoke about the future of const_generics at my talk for Rust Dublin</a>. Rather than me reiterating what I said there, I encourage you to watch that talk</a>.</p>

An introduction to const generics

Lazy Codes

Awesome Unstable Rust Features

Introduction</h1> This article describes several unstable Rust compiler features. It is intended to explain the basics of these features without diving into too much detail.</p>

Attributes</h1>

Const Generics</h2> I spoke about the future of const_generics at my talk for Rust Dublin</a>. Rather than me reiterating what I said there, I encourage you to watch that talk</a>.</p>

An introduction to const generics

Introduction</h1>
This article describes several unstable Rust compiler features. It is intended to explain the basics of these features without diving into too much detail.</p>

Const Generics</h2>
I spoke about the future of const_generics at my talk for Rust Dublin</a>. Rather than me reiterating what I said there, I encourage you to watch that talk</a>.</p>