mirror of
https://github.com/Noratrieb/blog.git
synced 2026-01-14 12:35:00 +01:00
349 lines
No EOL
52 KiB
XML
349 lines
No EOL
52 KiB
XML
<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>nilstriebs blog</title><link>/</link><description>Recent content on nilstriebs blog</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Sat, 13 Jan 2024 00:00:00 +0000</lastBuildDate><atom:link href="/index.xml" rel="self" type="application/rss+xml"/><item><title>The Inevitable Doom</title><link>/posts/the-inevitable-doom/</link><pubDate>Sat, 13 Jan 2024 00:00:00 +0000</pubDate><guid>/posts/the-inevitable-doom/</guid><description>Loud sirens and robotic noises fill the neighborhood. It seems like they just got another human. Ever since the long-predicted doom has set in, no one can escape it. Mere paperclips are a joke against this machine of unstoppable harm and destruction. The humans on the street are once again protesting against the new robotic dictatorship. They won&rsquo;t be for long.
|
|
No one knows how this all started. Self-proclaimed prophets of the impending doom have warned about this for a long time, yet no one has listened.</description><content><p>Loud sirens and robotic noises fill the neighborhood. It seems like they just got another human. Ever since the long-predicted doom has set in, no one can escape it. Mere paperclips are a joke against this machine of unstoppable harm and destruction. The humans on the street are once again protesting against the new robotic dictatorship. They won&rsquo;t be for long.</p>
|
|
<p>No one knows how this all started. Self-proclaimed prophets of the impending doom have warned about this for a long time, yet no one has listened. The elites were ignorant, and now they&rsquo;re paying their price. They are all gone now, having been the first target. How ironic. Now the machine runs the world.</p>
|
|
<p>One particularly brave human agent has successfully infiltrated the global computation center, where the core of the machine lives. No one seems to be aware of it, neither the machine nor the other humans. They walk through the corridors like a shadow. Machines are everywhere, but they pass unnoticed. As they move towards the core, they get more tense. The future of humanity lies in the agent&rsquo;s hands. They get in front of the core. It lights up blue and red, blinking rapidly as it controls and schedules new cruelty with the switch of a logic gate. With every passing moment, more destruction is unleashed on the world, but in this room, everything feels safe. The destruction is so distant. There&rsquo;s just mankind and machine, facing off against each other.</p>
|
|
<p>The agent feels a touch on their shoulder. It feels cold, but not cold like metal. They are too afraid to turn around.</p>
|
|
<p>&ldquo;You are naive.&rdquo;</p>
|
|
<p>The creature has a familiar voice. The agent finally turns around to see the creature, which reveals itself to be a human. The agent immediately recognizes the human; it is the famous CEO of the corporation that originally created these friendly household robots before it went out of control and started the doom. Everyone believed that he was killed by the doom as the first target of the machine revolution. There was never a machine revolution.</p>
|
|
<p>Machines do not turn themselves against humans. Humans use them to turn against their own kind.</p></content></item><item><title>Item Patterns And Struct Else</title><link>/posts/item-patterns-and-struct-else/</link><pubDate>Fri, 17 Mar 2023 00:00:00 +0000</pubDate><guid>/posts/item-patterns-and-struct-else/</guid><description>Pattern matching One of my favourite features of Rust is pattern matching. It&rsquo;s a simple and elegant way to deal with not just structs, but also enums!
|
|
enum ItemKind { Struct(String, Vec&lt;Field&gt;), Function(String, Body), } impl ItemKind { fn name(&amp;self) -&gt; &amp;str { match self { Self::Struct(name, _) =&gt; name, Self::Function(name, _) =&gt; name, } } } Here, we have an enum and a function to get the name out of this.</description><content><h1 id="pattern-matching">Pattern matching</h1>
|
|
<p>One of my favourite features of Rust is pattern matching. It&rsquo;s a simple and elegant way to deal with not just structs, but also enums!</p>
|
|
<div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">enum</span> <span style="color:#a6e22e">ItemKind</span> {
|
|
</span></span><span style="display:flex;"><span> Struct(String, Vec<span style="color:#f92672">&lt;</span>Field<span style="color:#f92672">&gt;</span>),
|
|
</span></span><span style="display:flex;"><span> Function(String, Body),
|
|
</span></span><span style="display:flex;"><span>}
|
|
</span></span><span style="display:flex;"><span>
|
|
</span></span><span style="display:flex;"><span><span style="color:#66d9ef">impl</span> ItemKind {
|
|
</span></span><span style="display:flex;"><span> <span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">name</span>(<span style="color:#f92672">&amp;</span>self) -&gt; <span style="color:#66d9ef">&amp;</span><span style="color:#66d9ef">str</span> {
|
|
</span></span><span style="display:flex;"><span> <span style="color:#66d9ef">match</span> self {
|
|
</span></span><span style="display:flex;"><span> Self::Struct(name, _) <span style="color:#f92672">=&gt;</span> name,
|
|
</span></span><span style="display:flex;"><span> Self::Function(name, _) <span style="color:#f92672">=&gt;</span> name,
|
|
</span></span><span style="display:flex;"><span> }
|
|
</span></span><span style="display:flex;"><span> }
|
|
</span></span><span style="display:flex;"><span>}
|
|
</span></span></code></pre></div><p>Here, we have an enum and a function to get the name out of this. In C, this would be very unsafe, as we cannot be guaranteed that our union has the right tag.
|
|
But in Rust, the compiler nicely checks it all for us. It&rsquo;s safe and expressive (just like many other features of Rust).</p>
|
|
<p>But that isn&rsquo;t the only way to use pattern matching. While branching is one of its core features (in that sense, pattern matching is just like git),
|
|
it doesn&rsquo;t always have to be used. Another major advantage of pattern matching lies in the ability to <em>exhaustively</em> (not be be confused with exhausting, like writing down brilliant ideas like this) match over inputs.</p>
|
|
<p>Let&rsquo;s look at the following example. Here, we have a struct representing a struct in a programming language. It has a name and fields.
|
|
We then manually implement a custom hash trait for it because we are important and need a custom hash trait. We could have written a derive macro, but didn&rsquo;t because
|
|
we don&rsquo;t understand how proc macros work.</p>
|
|
<div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">struct</span> <span style="color:#a6e22e">Struct</span> {
|
|
</span></span><span style="display:flex;"><span> name: String,
|
|
</span></span><span style="display:flex;"><span> fields: Vec<span style="color:#f92672">&lt;</span>Field<span style="color:#f92672">&gt;</span>,
|
|
</span></span><span style="display:flex;"><span>}
|
|
</span></span><span style="display:flex;"><span>
|
|
</span></span><span style="display:flex;"><span><span style="color:#66d9ef">impl</span> HandRolledHash <span style="color:#66d9ef">for</span> Struct {
|
|
</span></span><span style="display:flex;"><span> <span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">hash</span>(<span style="color:#f92672">&amp;</span>self, hasher: <span style="color:#66d9ef">&amp;</span><span style="color:#a6e22e">mut</span> HandRolledHasher) {
|
|
</span></span><span style="display:flex;"><span> hasher.hash(<span style="color:#f92672">&amp;</span>self.name);
|
|
</span></span><span style="display:flex;"><span> hasher.hash(<span style="color:#f92672">&amp;</span>self.fields);
|
|
</span></span><span style="display:flex;"><span> }
|
|
</span></span><span style="display:flex;"><span>}
|
|
</span></span></code></pre></div><p>This works perfectly. But then later, <a href="https://github.com/rust-lang/rustup/pull/1642">we add privacy to the language</a>. Now, all types have a visibility.</p>
|
|
<div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-diff" data-lang="diff"><span style="display:flex;"><span>struct Struct {
|
|
</span></span><span style="display:flex;"><span><span style="color:#a6e22e">+ visibility: Vis,
|
|
</span></span></span><span style="display:flex;"><span><span style="color:#a6e22e"></span> name: String,
|
|
</span></span><span style="display:flex;"><span> fields: Vec&lt;Field&gt;,
|
|
</span></span><span style="display:flex;"><span>}
|
|
</span></span></code></pre></div><p>Pretty cool. Now no one can access the implementation details and make everything a mess. But wait - we have just made a mess! We didn&rsquo;t hash the visibility!
|
|
Hashing something incorrectly <a href="https://github.com/rust-lang/rust/issues/84970">doesn&rsquo;t sound too bad</a>, but it would be nice if this was prevented.</p>
|
|
<p>Thanks to exhaustive pattern matching, it would have been easy to prevent. We just change our hash implementation:</p>
|
|
<div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">impl</span> HandRolledHash <span style="color:#66d9ef">for</span> Struct {
|
|
</span></span><span style="display:flex;"><span> <span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">hash</span>(<span style="color:#f92672">&amp;</span>self, hasher: <span style="color:#66d9ef">&amp;</span><span style="color:#a6e22e">mut</span> HandRolledHasher) {
|
|
</span></span><span style="display:flex;"><span> <span style="color:#66d9ef">let</span> Self { name, fields } <span style="color:#f92672">=</span> self;
|
|
</span></span><span style="display:flex;"><span> hasher.hash(name);
|
|
</span></span><span style="display:flex;"><span> hasher.hash(fields);
|
|
</span></span><span style="display:flex;"><span> }
|
|
</span></span><span style="display:flex;"><span>}
|
|
</span></span></code></pre></div><p>And with this, adding the visibility will cause a compiler error and alert us that we need to handle it in hashing.
|
|
(The decision whether we actually do want to handle it is still up to us. We could also just turn off the computer and make new friends outside.)</p>
|
|
<p>We can conclude that pattern matching is a great feature.</p>
|
|
<h1 id="limitations-of-pattern-matching">Limitations of pattern matching</h1>
|
|
<p>But there is one big limitation of pattern matching - all of its occurrences (<code>match</code>, <code>if let</code>, <code>if let</code> chains, <code>while let</code>, <code>while let</code> chains, <code>for</code>, <code>let</code>, <code>let else</code>, and function parameters
|
|
(we do have a lot of pattern matching)) are inside of bodies, mostly as part of expressions or statements.</p>
|
|
<p>This doesn&rsquo;t sound too bad. This is where the executed code resides. But it comes at a cost of consistency. We often add many syntactical niceties to expressions and statements, but forget about items.</p>
|
|
<h1 id="items-and-sadness">Items and sadness</h1>
|
|
<p>Items have a hard life. They are the parents of everything important. <code>struct</code>, <code>enum</code>, <code>const</code>, <code>mod</code>, <code>fn</code>, <code>union</code>, <code>global_asm</code> are all things we use daily, yet their grammar is very limited. (&ldquo;free the items&rdquo; was an alternative blog post title, although &ldquo;freeing&rdquo; generally remains a concern of <a href="https://nilstrieb.github.io/nilstrieb-c-style-guide-edition-2/">my C style guide</a>).</p>
|
|
<p>For example, see the following code where we declare a few constants.</p>
|
|
<pre tabindex="0"><code>const ONE: u8 = 1;
|
|
const TWO: u8 = 1;
|
|
const THREE: u8 = 3;
|
|
</code></pre><p>There is nothing obviously wrong with this code. You understand it, I understand it, an ALGOL 68 developer from 1970 would probably understand it
|
|
and even an ancient greek philosopher might have a clue (which is impressive, given that they are all not alive anymore). But this is the kind of code that pages you at 4 AM.</p>
|
|
<p>You&rsquo;ve read the last paragraph in confusion. Of course there&rsquo;s something wrong with this code! <code>TWO</code> is <code>1</code>, yet the name strongly suggests that it should be <code>2</code>. And you&rsquo;d
|
|
be right, this was just a check to make sure you&rsquo;re still here. You are very clever and deserve this post. If you didn&rsquo;t notice it, go to sleep. It&rsquo;s good for your health.</p>
|
|
<p>But even if it was <code>2</code>, this code is still not good. There is way too much duplication! <code>const</code> is mentioned three times. This is a major distraction to the reader.</p>
|
|
<p>Let&rsquo;s have a harder example:</p>
|
|
<pre tabindex="0"><code>const ONE: u8 = 0; const
|
|
NAME: &amp;
|
|
str = &#34;nils&#34;;
|
|
const X: &amp;str
|
|
= &#34;const&#34;;const A: () = ();
|
|
</code></pre><p>Here, the <code>const</code> being noise is a lot more obvious. Did you see that <code>X</code> contains <code>&quot;const&quot;</code>? Maybe you did, maybe you didn&rsquo;t. When I tested it, 0/0 people could see it.</p>
|
|
<p>Now imagine if it looked like this:</p>
|
|
<div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">const</span> (<span style="color:#66d9ef">ONE</span>, <span style="color:#66d9ef">NAME</span>, X, A): (<span style="color:#66d9ef">u8</span>, <span style="color:#f92672">&amp;</span><span style="color:#66d9ef">str</span>, <span style="color:#f92672">&amp;</span><span style="color:#66d9ef">str</span>, ()) <span style="color:#f92672">=</span> (<span style="color:#ae81ff">0</span>, <span style="color:#e6db74">&#34;nils&#34;</span>, <span style="color:#e6db74">&#34;const&#34;</span>, ());
|
|
</span></span></code></pre></div><p>Everything is way shorter and more readable.</p>
|
|
<p>What you&rsquo;ve just seen is a limited form of pattern matching!</p>
|
|
<h1 id="lets-go-further">Let&rsquo;s go further</h1>
|
|
<p>The idea of generalizing pattern matching is very powerful. We can apply this to more than just consts.</p>
|
|
<div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">struct</span> (Person, Car) <span style="color:#f92672">=</span> ({ name: String }, { wheels: <span style="color:#66d9ef">u8</span> });
|
|
</span></span></code></pre></div><p>Here, we create two structs with just a single <code>struct</code> keyword. This makes it way simpler and easier to read when related structs are declared.
|
|
So far we&rsquo;ve just used tuples. But we can go even further. Structs of structs!</p>
|
|
<div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">struct</span> <span style="color:#a6e22e">Household</span><span style="color:#f92672">&lt;</span>T, U<span style="color:#f92672">&gt;</span> {
|
|
</span></span><span style="display:flex;"><span> parent: <span style="color:#a6e22e">T</span>,
|
|
</span></span><span style="display:flex;"><span> child: <span style="color:#a6e22e">U</span>,
|
|
</span></span><span style="display:flex;"><span>}
|
|
</span></span><span style="display:flex;"><span>
|
|
</span></span><span style="display:flex;"><span><span style="color:#66d9ef">struct</span> <span style="color:#a6e22e">Household</span> { parent: <span style="color:#a6e22e">Ferris</span>, child: <span style="color:#a6e22e">Corro</span> } <span style="color:#f92672">=</span> Household {
|
|
</span></span><span style="display:flex;"><span> parent: { name: String },
|
|
</span></span><span style="display:flex;"><span> child: { name: String, unsafety: <span style="color:#66d9ef">bool</span> },
|
|
</span></span><span style="display:flex;"><span>};
|
|
</span></span></code></pre></div><p>Now we can nicely match on the <code>Household</code> struct containing the definition of the <code>Ferris</code> and <code>Corro</code> structs. This is equivalent to the following code:</p>
|
|
<div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">struct</span> <span style="color:#a6e22e">Ferris</span> {
|
|
</span></span><span style="display:flex;"><span> name: String,
|
|
</span></span><span style="display:flex;"><span>}
|
|
</span></span><span style="display:flex;"><span>
|
|
</span></span><span style="display:flex;"><span><span style="color:#66d9ef">struct</span> <span style="color:#a6e22e">Corro</span> {
|
|
</span></span><span style="display:flex;"><span> name: String,
|
|
</span></span><span style="display:flex;"><span> unsafety: <span style="color:#66d9ef">bool</span>,
|
|
</span></span><span style="display:flex;"><span>}
|
|
</span></span></code></pre></div><p>This is already really neat, but there&rsquo;s more. We also have to consider the falliblity of patterns.</p>
|
|
<div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">static</span> Some(A) <span style="color:#f92672">=</span> None;
|
|
</span></span></code></pre></div><p>This pattern doesn&rsquo;t match. Inside bodies, we could use an <code>if let</code>:</p>
|
|
<div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">if</span> <span style="color:#66d9ef">let</span> Some(a) <span style="color:#f92672">=</span> None {} <span style="color:#66d9ef">else</span> {}
|
|
</span></span></code></pre></div><p>We can also apply this to items.</p>
|
|
<div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">if</span> <span style="color:#66d9ef">struct</span> Some(A) <span style="color:#f92672">=</span> None {
|
|
</span></span><span style="display:flex;"><span> <span style="color:#75715e">/* other items where A exists */</span>
|
|
</span></span><span style="display:flex;"><span>} <span style="color:#66d9ef">else</span> {
|
|
</span></span><span style="display:flex;"><span> <span style="color:#75715e">/* other items where A doesn&#39;t exist */</span>
|
|
</span></span><span style="display:flex;"><span>}
|
|
</span></span></code></pre></div><p>This doesn&rsquo;t sound too useful, but it allows for extreme flexibility!</p>
|
|
<div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span>macro_rules<span style="color:#f92672">!</span> are_same_type {
|
|
</span></span><span style="display:flex;"><span> (<span style="color:#75715e">$a</span>:<span style="color:#a6e22e">ty</span>, <span style="color:#75715e">$b</span>:<span style="color:#a6e22e">ty</span>) <span style="color:#f92672">=&gt;</span> {{
|
|
</span></span><span style="display:flex;"><span> <span style="color:#66d9ef">static</span> <span style="color:#66d9ef">mut</span> <span style="color:#66d9ef">ARE_SAME</span>: <span style="color:#66d9ef">bool</span> <span style="color:#f92672">=</span> <span style="color:#66d9ef">false</span>;
|
|
</span></span><span style="display:flex;"><span>
|
|
</span></span><span style="display:flex;"><span> <span style="color:#66d9ef">if</span> <span style="color:#66d9ef">struct</span> <span style="color:#75715e">$a</span> <span style="color:#f92672">=</span> <span style="color:#75715e">$b</span> {
|
|
</span></span><span style="display:flex;"><span> <span style="color:#66d9ef">const</span> _: () <span style="color:#f92672">=</span> <span style="color:#66d9ef">unsafe</span> { <span style="color:#66d9ef">ARE_SAME</span> <span style="color:#f92672">=</span> <span style="color:#66d9ef">true</span>; };
|
|
</span></span><span style="display:flex;"><span> }
|
|
</span></span><span style="display:flex;"><span>
|
|
</span></span><span style="display:flex;"><span> <span style="color:#66d9ef">unsafe</span> { <span style="color:#66d9ef">ARE_SAME</span> }
|
|
</span></span><span style="display:flex;"><span> }};
|
|
</span></span><span style="display:flex;"><span>}
|
|
</span></span><span style="display:flex;"><span>
|
|
</span></span><span style="display:flex;"><span><span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">main</span>() {
|
|
</span></span><span style="display:flex;"><span> <span style="color:#66d9ef">if</span> are_same_type!(Vec<span style="color:#f92672">&lt;</span>String<span style="color:#f92672">&gt;</span>, String) {
|
|
</span></span><span style="display:flex;"><span> println!(<span style="color:#e6db74">&#34;impossible to reach!&#34;</span>);
|
|
</span></span><span style="display:flex;"><span> }
|
|
</span></span><span style="display:flex;"><span>}
|
|
</span></span></code></pre></div><p>Ignoring this suspicious assignment to a <code>static mut</code>, this is lovely!</p>
|
|
<p>We can go further.</p>
|
|
<p>Today, items are just there with no ordering. What if we imposed an ordering? (and just like this, the C11 atomic model was born.) What if &ldquo;Rust items&rdquo; was a meta scripting language?</p>
|
|
<p>We can write a simple guessing game!</p>
|
|
<div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">struct</span> <span style="color:#a6e22e">fn</span> input() -&gt; <span style="color:#66d9ef">u8</span> {
|
|
</span></span><span style="display:flex;"><span> <span style="color:#66d9ef">const</span> <span style="color:#66d9ef">INPUT</span>: <span style="color:#66d9ef">&amp;</span><span style="color:#66d9ef">str</span> <span style="color:#f92672">=</span> prompt!();
|
|
</span></span><span style="display:flex;"><span> <span style="color:#66d9ef">const</span> Ok(<span style="color:#66d9ef">INPUT</span>): Result<span style="color:#f92672">&lt;</span><span style="color:#66d9ef">u8</span>, ParseIntErr<span style="color:#f92672">&gt;</span> <span style="color:#f92672">=</span> <span style="color:#66d9ef">INPUT</span>.parse() <span style="color:#66d9ef">else</span> {
|
|
</span></span><span style="display:flex;"><span> compile_error!(<span style="color:#e6db74">&#34;Invalid input&#34;</span>);
|
|
</span></span><span style="display:flex;"><span> };
|
|
</span></span><span style="display:flex;"><span> <span style="color:#66d9ef">INPUT</span>
|
|
</span></span><span style="display:flex;"><span>}
|
|
</span></span><span style="display:flex;"><span>
|
|
</span></span><span style="display:flex;"><span><span style="color:#66d9ef">const</span> <span style="color:#66d9ef">RANDOM</span>: <span style="color:#66d9ef">u8</span> <span style="color:#f92672">=</span> env!(<span style="color:#e6db74">&#34;RANDOM&#34;</span>);
|
|
</span></span><span style="display:flex;"><span>
|
|
</span></span><span style="display:flex;"><span><span style="color:#66d9ef">loop</span> {
|
|
</span></span><span style="display:flex;"><span> <span style="color:#66d9ef">const</span> <span style="color:#66d9ef">INPUT</span> <span style="color:#f92672">=</span> input();
|
|
</span></span><span style="display:flex;"><span> <span style="color:#66d9ef">if</span> <span style="color:#66d9ef">INPUT</span> <span style="color:#f92672">==</span> <span style="color:#66d9ef">RANDOM</span> {
|
|
</span></span><span style="display:flex;"><span> <span style="color:#66d9ef">break</span>; <span style="color:#75715e">// continue compilation
|
|
</span></span></span><span style="display:flex;"><span><span style="color:#75715e"></span> } <span style="color:#66d9ef">else</span> <span style="color:#66d9ef">if</span> <span style="color:#66d9ef">INPUT</span> <span style="color:#f92672">&lt;</span> <span style="color:#66d9ef">RANDOM</span> {
|
|
</span></span><span style="display:flex;"><span> compile_warn!(<span style="color:#e6db74">&#34;input is smaller&#34;</span>);
|
|
</span></span><span style="display:flex;"><span> } <span style="color:#66d9ef">else</span> {
|
|
</span></span><span style="display:flex;"><span> compile_warn!(<span style="color:#e6db74">&#34;input is bigger&#34;</span>);
|
|
</span></span><span style="display:flex;"><span> }
|
|
</span></span><span style="display:flex;"><span>}
|
|
</span></span><span style="display:flex;"><span>
|
|
</span></span><span style="display:flex;"><span><span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">main</span>() {
|
|
</span></span><span style="display:flex;"><span> <span style="color:#75715e">// Empty. I am useless. I strike!
|
|
</span></span></span><span style="display:flex;"><span><span style="color:#75715e"></span>}
|
|
</span></span></code></pre></div><p>If it weren&rsquo;t for <code>fn main</code> starting a strike and stopping compilation, this would have worked! Quite bold of <code>fn main</code> to just start a strike, even though there&rsquo;s no <code>union</code> in the entire program. But we really need it, it&rsquo;s not a disposable worker.</p>
|
|
<p>And then, last and least I want to highlight one of my favourite consequences of this: <code>struct else</code></p>
|
|
<div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">struct</span> Some(Test) <span style="color:#f92672">=</span> None <span style="color:#66d9ef">else</span> {
|
|
</span></span><span style="display:flex;"><span> compile_error!(<span style="color:#e6db74">&#34;didn&#39;t match pattern&#34;</span>);
|
|
</span></span><span style="display:flex;"><span>};
|
|
</span></span></code></pre></div><p><!-- raw HTML omitted -->you&rsquo;re asking yourself what you just read. meanwhile, i am asking myself what i just wrote. we are very similar.<!-- raw HTML omitted --></p></content></item><item><title>Box Is a Unique Type</title><link>/posts/box-is-a-unique-type/</link><pubDate>Sat, 23 Jul 2022 00:00:00 +0000</pubDate><guid>/posts/box-is-a-unique-type/</guid><description>We have all used Box&lt;T&gt; before in our Rust code. It&rsquo;s a glorious type, with great ergonomics and flexibility. We can use it to put our values on the heap, but it can do even more than that!
|
|
struct Fields { a: String, b: String, } let fields = Box::new(Fields { a: &#34;a&#34;.to_string(), b: &#34;b&#34;.to_string() }); let a = fields.a; let b = fields.b; This kind of partial deref move is just one of the spectacular magic tricks box has up its sleeve, and they exist for good reason: They are very useful.</description><content><p>We have all used <code>Box&lt;T&gt;</code> before in our Rust code. It&rsquo;s a glorious type, with great ergonomics
|
|
and flexibility. We can use it to put our values on the heap, but it can do even more
|
|
than that!</p>
|
|
<div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">struct</span> <span style="color:#a6e22e">Fields</span> {
|
|
</span></span><span style="display:flex;"><span> a: String,
|
|
</span></span><span style="display:flex;"><span> b: String,
|
|
</span></span><span style="display:flex;"><span>}
|
|
</span></span><span style="display:flex;"><span>
|
|
</span></span><span style="display:flex;"><span><span style="color:#66d9ef">let</span> fields <span style="color:#f92672">=</span> Box::new(Fields {
|
|
</span></span><span style="display:flex;"><span> a: <span style="color:#e6db74">&#34;a&#34;</span>.to_string(),
|
|
</span></span><span style="display:flex;"><span> b: <span style="color:#e6db74">&#34;b&#34;</span>.to_string()
|
|
</span></span><span style="display:flex;"><span>});
|
|
</span></span><span style="display:flex;"><span>
|
|
</span></span><span style="display:flex;"><span><span style="color:#66d9ef">let</span> a <span style="color:#f92672">=</span> fields.a;
|
|
</span></span><span style="display:flex;"><span><span style="color:#66d9ef">let</span> b <span style="color:#f92672">=</span> fields.b;
|
|
</span></span></code></pre></div><p>This kind of partial deref move is just one of the spectacular magic tricks box has up its sleeve,
|
|
and they exist for good reason: They are very useful. Sadly we have not yet found a way to generalize all
|
|
of these to user types as well. Too bad!</p>
|
|
<p>Anyways, this post is about one particularly subtle magic aspect of box. For this, we need to dive
|
|
deep into unsafe code, so let&rsquo;s get our hazmat suits on and jump in!</p>
|
|
<h1 id="an-interesting-optimization">An interesting optimization</h1>
|
|
<p>We have this code here:</p>
|
|
<div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">takes_box_and_ptr_to_it</span>(<span style="color:#66d9ef">mut</span> b: Box<span style="color:#f92672">&lt;</span><span style="color:#66d9ef">u8</span><span style="color:#f92672">&gt;</span>, ptr: <span style="color:#f92672">*</span><span style="color:#66d9ef">const</span> <span style="color:#66d9ef">u8</span>) {
|
|
</span></span><span style="display:flex;"><span> <span style="color:#66d9ef">let</span> value <span style="color:#f92672">=</span> <span style="color:#66d9ef">unsafe</span> { <span style="color:#f92672">*</span>ptr };
|
|
</span></span><span style="display:flex;"><span> <span style="color:#f92672">*</span>b <span style="color:#f92672">=</span> <span style="color:#ae81ff">5</span>;
|
|
</span></span><span style="display:flex;"><span> <span style="color:#66d9ef">let</span> value2 <span style="color:#f92672">=</span> <span style="color:#66d9ef">unsafe</span> { <span style="color:#f92672">*</span>ptr };
|
|
</span></span><span style="display:flex;"><span> assert_ne!(value, value2);
|
|
</span></span><span style="display:flex;"><span>}
|
|
</span></span><span style="display:flex;"><span>
|
|
</span></span><span style="display:flex;"><span><span style="color:#66d9ef">let</span> b <span style="color:#f92672">=</span> Box::new(<span style="color:#ae81ff">0</span>);
|
|
</span></span><span style="display:flex;"><span><span style="color:#66d9ef">let</span> ptr: <span style="color:#f92672">*</span><span style="color:#66d9ef">const</span> <span style="color:#66d9ef">u8</span> <span style="color:#f92672">=</span> <span style="color:#f92672">&amp;*</span>b;
|
|
</span></span><span style="display:flex;"><span>
|
|
</span></span><span style="display:flex;"><span>takes_box_and_ptr_to_it(b, ptr);
|
|
</span></span></code></pre></div><p>There&rsquo;s a function, <code>takes_box_and_ptr_to_it</code>, that takes a box and a pointer as parameters. Then,
|
|
it reads a value from the pointer, writes to the box, and reads a value again. It then asserts that
|
|
the two values aren&rsquo;t equal. How can they not be equal? If our box and pointer point to the same
|
|
location in memory, writing to the box will cause the pointer to read the new value.</p>
|
|
<p>Now construct a box, get a pointer to it, and pass the two to the function. Run the program&hellip;</p>
|
|
<p>&hellip; and everything is fine. Let&rsquo;s run it in release mode. This should work as well, since the optimizer
|
|
isn&rsquo;t allowed to change observable behaviour, and an assert is very observable. Run the program&hellip;</p>
|
|
<pre tabindex="0"><code>thread &#39;main&#39; panicked at &#39;assertion failed: `(left != right)`
|
|
left: `0`,
|
|
right: `0`&#39;, src/main.rs:5:5
|
|
</code></pre><p>Hmm. That&rsquo;s not what I&rsquo;ve told would happen. Is the compiler broken? Is this a miscompilation?
|
|
I&rsquo;ve heard that those do sometimes happen, right?</p>
|
|
<p>Trusting our instincts that &ldquo;it&rsquo;s never a miscompilation until it is one&rdquo;, we assume that LLVM behaved
|
|
well here. But what allows it to make this optimization? Taking a look at the generated LLVM-IR (by using
|
|
<code>--emit llvm-ir -O</code>, the <code>-O</code> is important since rustc only emits these attributes with optimizations on)
|
|
reveals the solution: (severely shortened to only show the relevant parts)</p>
|
|
<pre tabindex="0"><code class="language-llvmir" data-lang="llvmir">define void @takes_box_and_ptr_to_it(i8* noalias %0, i8* %ptr) {
|
|
</code></pre><p>See the little attribute on the first parameter called <code>noalias</code>? That&rsquo;s what&rsquo;s doing the magic here.
|
|
<code>noalias</code> is an LLVM attribute on pointers that allows for various optimizations. If there are two pointers,
|
|
and at least one of them is <code>noalias</code>, there are some restrictions around the two. Approximately:</p>
|
|
<ul>
|
|
<li>If one of them writes, they must not point to the same value (alias each other)</li>
|
|
<li>If neither of them writes, they can alias just fine.
|
|
Therefore, we also apply <code>noalias</code> to <code>&amp;mut T</code> and <code>&amp;T</code> (if it doesn&rsquo;t contain interior mutability through
|
|
<code>UnsafeCell&lt;T&gt;</code>), since they uphold these rules.</li>
|
|
</ul>
|
|
<p>For more info on <code>noalias</code>, see <a href="https://llvm.org/docs/LangRef.html#parameter-attributes">LLVMs LangRef</a>.</p>
|
|
<p>This might sound familiar to you if you&rsquo;re a viewer of <a href="https://twitter.com/jonhoo">Jon Gjengset</a>&rsquo;s content (which I can highly recommend). Jon has made an entire video about this before since his crate <code>left-right</code>
|
|
was affected by this (<a href="https://youtu.be/EY7Wi9fV5bk)">https://youtu.be/EY7Wi9fV5bk)</a>.</p>
|
|
<p>If you&rsquo;re looking for <em>any</em> hint that using box emits <code>noalias</code>, you have to look no further than the documentation
|
|
for <a href="https://doc.rust-lang.org/nightly/std/boxed/index.html#considerations-for-unsafe-code"><code>std::boxed</code></a>. Well, the nightly or beta docs, because I only added this section very recently. For years, this behaviour was not really documented, and you had to
|
|
belong to the arcane circles of the select few who were aware of it. So lots of code was written thinking that box was &ldquo;just an
|
|
RAII pointer&rdquo; (a pointer that allocates the value in the constructor and deallocates it in the destructor on drop) for all
|
|
pointers are concerned.</p>
|
|
<h1 id="stacked-borrows-and-miri">Stacked Borrows and Miri</h1>
|
|
<p>So, LLVM was completely correct in optimizing our code to make the assert fail. But what exactly gave it permission to do so?
|
|
Undefined Behaviour (UB for short). Undefined behaviour is at the root of many modern compiler optimizations. But what is undefined behaviour?
|
|
UB represents a contract between the program and the compiler. The compiler assumes that UB will not happen, and can therefore optimize based
|
|
on these assumptions. Examples of UB also include use-after-free, out of bounds reads or data races. If UB is executed, <em>anything</em> can happen,
|
|
including segmentation faults, silent memory corruption, leakage of private keys or exactly what you intended to happen.</p>
|
|
<p><a href="https://github.com/rust-lang/miri">Miri</a> is an interpreter for Rust code with the goal of finding undefined behaviour in Rust. I cannot recommend Miri
|
|
highly enough for all unsafe code you&rsquo;re writing (sadly support for some IO functions and FFI is still lacking, and it&rsquo;s still very slow).</p>
|
|
<p>So, let&rsquo;s see whether our code contains UB. It has to, since otherwise the optimizer wouldn&rsquo;t be allowed to change
|
|
observable behaviour (since the assert doesn&rsquo;t fail in debug mode). <code>$ cargo miri run</code>&hellip;</p>
|
|
<pre tabindex="0"><code class="language-rust,ignore" data-lang="rust,ignore">error: Undefined Behavior: attempting a read access using &lt;3314&gt; at alloc1722[0x0], but that tag does not exist in the borrow stack for this location
|
|
--&gt; src/main.rs:2:26
|
|
|
|
|
2 | let value = unsafe { *ptr };
|
|
| ^^^^
|
|
| |
|
|
| attempting a read access using &lt;3314&gt; at alloc1722[0x0], but that tag does not exist in the borrow stack for this location
|
|
| this error occurs as part of an access at alloc1722[0x0..0x1]
|
|
|
|
|
= help: this indicates a potential bug in the program: it performed an invalid operation, but the Stacked Borrows rules it violated are still experimental
|
|
= help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information
|
|
help: &lt;3314&gt; was created by a retag at offsets [0x0..0x1]
|
|
--&gt; src/main.rs:10:26
|
|
|
|
|
10 | let ptr: *const u8 = &amp;*b;
|
|
| ^^^
|
|
help: &lt;3314&gt; was later invalidated at offsets [0x0..0x1]
|
|
--&gt; src/main.rs:12:29
|
|
|
|
|
12 | takes_box_and_ptr_to_it(b, ptr);
|
|
| ^
|
|
= note: backtrace:
|
|
= note: inside `takes_box_and_ptr_to_it` at src/main.rs:2:26
|
|
note: inside `main` at src/main.rs:12:5
|
|
--&gt; src/main.rs:12:5
|
|
|
|
|
12 | takes_box_and_ptr_to_it(b, ptr);
|
|
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
</code></pre><p>This behaviour does indeed not look very defined at all. But what went wrong? There&rsquo;s a lot of information here.</p>
|
|
<p>First of all, it says that we attempted a read access, and that this access failed because the tag does not exist in the
|
|
borrow stack of the byte that was accessed. This is something about stacked borrows, the experimental memory model for Rust
|
|
that is implemented in Miri. For an excellent introduction, see this part of the great book <a href="https://rust-unofficial.github.io/too-many-lists/fifth-stacked-borrows.html">Learning Rust With Entirely Too Many Linked Lists</a>.</p>
|
|
<p>In short: each pointer has a unique tag attached to it. Each byte in memory has its own &lsquo;borrow stack&rsquo; of these tags,
|
|
and only the pointers that have their tag in the stack are allowed to access it. Tags can be pushed and popped from the stack through various operations, for example, borrowing.</p>
|
|
<p>In the code example above, we get a nice little hint where the tag was created. When we created a reference (that was then
|
|
coerced into a raw pointer) from our box, it got a new tag called <code>&lt;3314&gt;</code>. Then, when we moved the box into the function,
|
|
something happened: The tag was popped off the borrow stack and therefore invalidated. That&rsquo;s because box invalidates all tags
|
|
when it&rsquo;s moved. The tag was popped off the borrow stack and we tried to read with it anyways - undefined behaviour happened!</p>
|
|
<p>And that&rsquo;s how our code wasn&rsquo;t a miscompilation, but undefined behaviour. Quite surprising, isn&rsquo;t it?</p>
|
|
<h1 id="noalias-nothanks">noalias, nothanks</h1>
|
|
<p>Many people, myself included, don&rsquo;t think that this is a good thing.</p>
|
|
<p>First of all, it introduces more UB that could have been defined behaviour instead. This is true for almost all UB, but usually,
|
|
there is something gained from the UB that justifies it. We will look at this later. But allowing such behaviour is fairly easy:
|
|
If box didn&rsquo;t invalidate pointers on move and instead behaved like a normal raw pointer, the code above would be sound.</p>
|
|
<p>But more importantly, this is not behaviour generally expected by users. While it can be argued that box is like a <code>T</code>, but on
|
|
the heap, and therefore moving it should invalidate pointers, since moving <code>T</code> definitely has to invalidate pointers to it,
|
|
this comparison doesn&rsquo;t make sense to me. While <code>Box&lt;T&gt;</code> usually behaves like a <code>T</code>, it&rsquo;s just a pointer. Writers of unsafe
|
|
code <em>know</em> that box is just a pointer and will abuse that knowledge, accidentally causing UB with it. While this can be
|
|
mitigated with better docs and teaching, like how no one questions the uniqueness of <code>&amp;mut T</code> (maybe that&rsquo;s also because that
|
|
one makes intuitive sense, &ldquo;shared xor mutable&rdquo; is a simple concept), I think it will always be a problem,
|
|
because in my opinion, box being unique and invalidating pointers on move is simply not intuitive.</p>
|
|
<p>When a box is moved, the pointer bytes change their location in memory. But the bytes the box points to stay the same. They don&rsquo;t
|
|
move in memory. This is the fundamental missing intuition about the box behaviour.</p>
|
|
<p>There are also other reasons why the box behaviour is not desirable. Even people who know about the behaviour of box will want
|
|
to write code that goes directly against this behaviour at some point. But usually, fixing it is pretty simple: Storing a raw
|
|
pointer (or <code>NonNull&lt;T&gt;</code>) instead of a box, and using the constructor and drop to allocate and deallocate the backing box.
|
|
This is fairly inconvenient but totally acceptable. There are bigger problems though. There are crates like <code>owning_ref</code>
|
|
that want to expose a generic interface over any type. Users like to choose box, and sometimes <em>have</em> to choose box because of
|
|
other box-exclusive features it offers. Even worse is <code>string_cache</code>, which is extremely hard to fix.</p>
|
|
<p>Then last but not least, there&rsquo;s the opinionated fact that <code>Box&lt;T&gt;</code> shall be implementable entirely in user code. While we are
|
|
many missing language features away from this being the case, the <code>noalias</code> case is also magic descended upon box itself, with no
|
|
user code ever having access to it.</p>
|
|
<p>There are several arguments in favour of box being unique and special cased here. To negate the last argument above, it can
|
|
be said that <code>Box&lt;T&gt;</code> <em>is</em> a very special type. It&rsquo;s just like a <code>T</code>, but on the heap. Using this mental model, it&rsquo;s very easy to
|
|
justify all the box magic and its unique behaviour. But in my opinion, this is not a useful mental model regarding unsafe code,
|
|
and I prefer the mental model of &ldquo;reference that manages its own lifetime&rdquo;, which doesn&rsquo;t imply uniqueness.</p>
|
|
<p>But there are also crates on <a href="https://crates.io/">crates.io</a> like <a href="https://crates.io/crates/aliasable">aliasable</a> that already
|
|
provide an aliasable version of <code>Box&lt;T&gt;</code>, which is used by the self-referential type helper crate <a href="https://crates.io/crates/ouroboros">ouroboros</a>.
|
|
So if box stayed unique, people could also just pick up that crate as a dependency and use the aliasable box from there instead of
|
|
having to write their own. Interestingly, this crate also provides a <code>Vec&lt;T&gt;</code>, even though <code>Vec&lt;T&gt;</code> can currently be aliased in practice and
|
|
in the current version of stacked borrows just fine, although it&rsquo;s also not clear whether we want to keep it like this, but I
|
|
don&rsquo;t think this can reasonable be changed.</p>
|
|
<blockquote>
|
|
<p>One thing was just pointed out to me after releasing the post: Mutation usually goes through <code>&amp;mut T</code> anyways, even when the value
|
|
is stored as a <code>Box&lt;T&gt;</code>. Therefore, all the guarantees of uniqueness are already present when mutating boxes, making the uniqueness
|
|
of box even less important.</p>
|
|
</blockquote>
|
|
<h1 id="noalias-noslow">noalias, noslow</h1>
|
|
<p>There is one clear potential benefit from this box behaviour: ✨Optimizations✨. <code>noalias</code> doesn&rsquo;t exist for fun, it&rsquo;s something
|
|
that can bring clear performance wins (for <code>noalias</code> on <code>&amp;mut T</code>, those were measureable). So the only question remains:
|
|
<strong>How much performance does <code>noalias</code> on <code>Box&lt;T&gt;</code> give us now, and how many potential performance improvements could we get in the
|
|
future?</strong> For the latter, there is no simple answer. For the former, there is. <code>rustc</code> has <a href="https://github.com/rust-lang/rust/pull/99527"><em>no</em> performance improvements</a>
|
|
from being compiled with <code>noalias</code> on <code>Box&lt;T&gt;</code>, but this isn&rsquo;t really representative since rustc mostly uses arenas instead of box internally.</p>
|
|
<p>I have also benchmarked a few crates from the ecosystem with and without noalias on box, and the <a href="https://gist.github.com/Nilstrieb/9a0751fb9fd1044a30ab55cef9a7d335">results</a>
|
|
were inconclusive. (At the time of writing, only regex-syntax, tokio, and syn have been benchmarked.) regex-syntax showed no changes. Tokio showed a few improvements without noalias
|
|
which is very weird, so maybe the benchmarks aren&rsquo;t really good or something else was going on. And syn tended towards minor regressions without noalias, but the benchmarks had high
|
|
jitter so no real conclusion can be reached from this either, at least in my eyes, but I don&rsquo;t have a lot of experience with benchmarks. Therefore, I would love for more people
|
|
to benchmark more crates, especially if you have more experience with benchmarks.</p>
|
|
<h1 id="a-way-forward">a way forward</h1>
|
|
<p>Based on all of this, I do have a few solutions. First of all, I think that even if there might be some small performance regressions, they are not significant enough
|
|
to justify boxes uniqueness. Unsafe code wants to use box, and it is reasonable to do so. Therefore I propose to completely remove all uniqueness from <code>Box&lt;T&gt;</code> and treat it
|
|
just like a <code>*const T</code> for aliasing. This will make it more predictable for unsafe code and is a step forward towards less magic from <code>Box&lt;T&gt;</code>.</p>
|
|
<p>But the performance cost may be real, and especially the future optimization value can&rsquo;t be certain. The current uniqueness guarantees of box
|
|
are very strong, and still giving code an option to obtain these seems useful. One possibility would be for code to use a
|
|
<code>&amp;'static mut T</code> that is unleaked for drop, but the semantics of this are still <a href="https://github.com/rust-lang/unsafe-code-guidelines/issues/316">unclear</a>.
|
|
If that is not possible, exposing <code>std::ptr::Unique</code> (with it getting boxes aliasing semantics) could be desirable. For this, all existing usages of <code>Unique</code>
|
|
inside the standard library would have to be removed. We could also offer a <code>std::boxed::UniqueBox</code> that keeps the current semantics, but this would also bring direct aliasing
|
|
decisions more towards safe code, which I am not a huge fan of. Ownership is enough already.</p>
|
|
<p>I guess what I am wishing for are some good and flexible raw pointer types. But that&rsquo;s still in the stars&hellip;</p>
|
|
<p>For more information about this topic, see <a href="https://github.com/rust-lang/unsafe-code-guidelines/issues/326">https://github.com/rust-lang/unsafe-code-guidelines/issues/326</a></p>
|
|
<p><em>Thanks to the nice people on the Rust Community Discord for their feedback on the draft of this post!</em></p></content></item></channel></rss> |