deploy: 51573c9e72

2026-01-14 12:35:00 +01:00 · 2022-07-23 19:28:14 +00:00 · 2022-07-23 19:28:14 +00:00 · f9229ee20a
commit f9229ee20a
parent 73d8f12885
5 changed files with 24 additions and 2 deletions
--- a/index.xml
+++ b/index.xml
@ -148,6 +148,11 @@ So if box stayed unique, people could also just pick up that crate as a dependen
 having to write their own. Interestingly, this crate also provides a &lt;code>Vec&amp;lt;T&amp;gt;&lt;/code>, even though &lt;code>Vec&amp;lt;T&amp;gt;&lt;/code> can currently be aliased in practice and
 in the current version of stacked borrows. just fine, although it&amp;rsquo;s also not clear whether we want to keep it like this, but I
 don&amp;rsquo;t think this can reasonable be changed.&lt;/p>
 &lt;blockquote>
 &lt;p>One thing was just pointed out to me after releasing the post: Mutation usually goes through &lt;code>&amp;amp;mut T&lt;/code> anyways, even when the value
 is stored as a &lt;code>Box&amp;lt;T&amp;gt;&lt;/code>. Therefore, all the guarantees of uniqueness are already present when mutating boxes, making the uniqueness
 of box even less important.&lt;/p>
 &lt;/blockquote>
 &lt;h1 id="noalias-noslow">noalias, noslow&lt;/h1>
 &lt;p>There is one clear potential benefit from this box behaviour: ✨Optimizations✨. &lt;code>noalias&lt;/code> doesn&amp;rsquo;t exist for fun, it&amp;rsquo;s something
 that can bring clear performance wins (for &lt;code>noalias&lt;/code> on &lt;code>&amp;amp;mut T&lt;/code>, those were measureable). So the only question remains:
--- a/posts/box-is-a-unique-type/index.html
+++ b/posts/box-is-a-unique-type/index.html
@ -1,6 +1,6 @@
 <!doctype html><html lang=en><head><title>Box Is a Unique Type :: nilstriebs blog</title><meta charset=utf-8><meta name=viewport content="width=device-width,initial-scale=1"><meta name=description content="About better aliasing semantics for `Box`"><meta name=keywords content="box,noalias"><meta name=robots content="noodp"><link rel=canonical href=/posts/box-is-a-unique-type/><link rel=stylesheet href=/assets/style.css><link rel=apple-touch-icon href=/img/apple-touch-icon-192x192.png><link rel="shortcut icon" href=/img/favicon/orange.png><meta name=twitter:card content="summary"><meta property="og:locale" content="en"><meta property="og:type" content="article"><meta property="og:title" content="Box Is a Unique Type"><meta property="og:description" content="About better aliasing semantics for `Box`"><meta property="og:url" content="/posts/box-is-a-unique-type/"><meta property="og:site_name" content="nilstriebs blog"><meta property="og:image" content="/img/favicon/orange.png"><meta property="og:image:width" content="2048"><meta property="og:image:height" content="1024"><meta property="article:published_time" content="2022-07-23 00:00:00 +0000 UTC"></head><body class=orange><div class="container center headings--one-size"><header class=header><div class=header__inner><div class=header__logo><a href=/><div class=logo>nilstriebs blog</div></a></div></div></header><div class=content><div class=post><h1 class=post-title><a href=/posts/box-is-a-unique-type/>Box Is a Unique Type</a></h1><div class=post-meta><span class=post-date>2022-07-23</span>
 <span class=post-author>:: Nilstrieb</span>
-<span class=post-reading-time>:: 12 min read (2381 words)</span></div><span class=post-tags>#<a href=/tags/rust/>rust</a>&nbsp;
+<span class=post-reading-time>:: 12 min read (2429 words)</span></div><span class=post-tags>#<a href=/tags/rust/>rust</a>&nbsp;
 #<a href=/tags/unsafe-code/>unsafe code</a>&nbsp;</span><div class=post-content><div><p>We have all used <code>Box&lt;T></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> {
@ -114,7 +114,9 @@ provide an aliasable version of <code>Box&lt;T></code>, which is used by the sel
 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></code>, even though <code>Vec&lt;T></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><h1 id=noalias-noslow>noalias, noslow<a href=#noalias-noslow class=hanchor arialabel=Anchor>&#8983;</a></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
+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>&mut T</code> anyways, even when the value
 is stored as a <code>Box&lt;T></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<a href=#noalias-noslow class=hanchor arialabel=Anchor>&#8983;</a></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>&mut T</code>, those were measureable). So the only question remains:
 <strong>How much performance does <code>noalias</code> on <code>Box&lt;T></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>
--- a/posts/index.xml
+++ b/posts/index.xml
@ -148,6 +148,11 @@ So if box stayed unique, people could also just pick up that crate as a dependen
 having to write their own. Interestingly, this crate also provides a &lt;code>Vec&amp;lt;T&amp;gt;&lt;/code>, even though &lt;code>Vec&amp;lt;T&amp;gt;&lt;/code> can currently be aliased in practice and
 in the current version of stacked borrows. just fine, although it&amp;rsquo;s also not clear whether we want to keep it like this, but I
 don&amp;rsquo;t think this can reasonable be changed.&lt;/p>
 &lt;blockquote>
 &lt;p>One thing was just pointed out to me after releasing the post: Mutation usually goes through &lt;code>&amp;amp;mut T&lt;/code> anyways, even when the value
 is stored as a &lt;code>Box&amp;lt;T&amp;gt;&lt;/code>. Therefore, all the guarantees of uniqueness are already present when mutating boxes, making the uniqueness
 of box even less important.&lt;/p>
 &lt;/blockquote>
 &lt;h1 id="noalias-noslow">noalias, noslow&lt;/h1>
 &lt;p>There is one clear potential benefit from this box behaviour: ✨Optimizations✨. &lt;code>noalias&lt;/code> doesn&amp;rsquo;t exist for fun, it&amp;rsquo;s something
 that can bring clear performance wins (for &lt;code>noalias&lt;/code> on &lt;code>&amp;amp;mut T&lt;/code>, those were measureable). So the only question remains:
--- a/tags/rust/index.xml
+++ b/tags/rust/index.xml
@ -148,6 +148,11 @@ So if box stayed unique, people could also just pick up that crate as a dependen
 having to write their own. Interestingly, this crate also provides a &lt;code>Vec&amp;lt;T&amp;gt;&lt;/code>, even though &lt;code>Vec&amp;lt;T&amp;gt;&lt;/code> can currently be aliased in practice and
 in the current version of stacked borrows. just fine, although it&amp;rsquo;s also not clear whether we want to keep it like this, but I
 don&amp;rsquo;t think this can reasonable be changed.&lt;/p>
 &lt;blockquote>
 &lt;p>One thing was just pointed out to me after releasing the post: Mutation usually goes through &lt;code>&amp;amp;mut T&lt;/code> anyways, even when the value
 is stored as a &lt;code>Box&amp;lt;T&amp;gt;&lt;/code>. Therefore, all the guarantees of uniqueness are already present when mutating boxes, making the uniqueness
 of box even less important.&lt;/p>
 &lt;/blockquote>
 &lt;h1 id="noalias-noslow">noalias, noslow&lt;/h1>
 &lt;p>There is one clear potential benefit from this box behaviour: ✨Optimizations✨. &lt;code>noalias&lt;/code> doesn&amp;rsquo;t exist for fun, it&amp;rsquo;s something
 that can bring clear performance wins (for &lt;code>noalias&lt;/code> on &lt;code>&amp;amp;mut T&lt;/code>, those were measureable). So the only question remains:
--- a/tags/unsafe-code/index.xml
+++ b/tags/unsafe-code/index.xml
@ -148,6 +148,11 @@ So if box stayed unique, people could also just pick up that crate as a dependen
 having to write their own. Interestingly, this crate also provides a &lt;code>Vec&amp;lt;T&amp;gt;&lt;/code>, even though &lt;code>Vec&amp;lt;T&amp;gt;&lt;/code> can currently be aliased in practice and
 in the current version of stacked borrows. just fine, although it&amp;rsquo;s also not clear whether we want to keep it like this, but I
 don&amp;rsquo;t think this can reasonable be changed.&lt;/p>
 &lt;blockquote>
 &lt;p>One thing was just pointed out to me after releasing the post: Mutation usually goes through &lt;code>&amp;amp;mut T&lt;/code> anyways, even when the value
 is stored as a &lt;code>Box&amp;lt;T&amp;gt;&lt;/code>. Therefore, all the guarantees of uniqueness are already present when mutating boxes, making the uniqueness
 of box even less important.&lt;/p>
 &lt;/blockquote>
 &lt;h1 id="noalias-noslow">noalias, noslow&lt;/h1>
 &lt;p>There is one clear potential benefit from this box behaviour: ✨Optimizations✨. &lt;code>noalias&lt;/code> doesn&amp;rsquo;t exist for fun, it&amp;rsquo;s something
 that can bring clear performance wins (for &lt;code>noalias&lt;/code> on &lt;code>&amp;amp;mut T&lt;/code>, those were measureable). So the only question remains: