deploy: 9375a64eeb

index.xml

@@ -142,7 +142,7 @@ be said that <code>Box<T></code> <em>is</em> a very sp
 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 “reference that manages its own lifetime”, which doesn’t imply uniqueness.</p>
 <h1 id="noalias-noslow">noalias, noslow</h1>
-<p>There is one clear potential benefit from this box behaviour. ✨Optimizations✨. <code>noalias</code> doesn’t exist for fun, it’s something
+<p>There is one clear potential benefit from this box behaviour: ✨Optimizations✨. <code>noalias</code> doesn’t exist for fun, it’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<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>
@@ -152,15 +152,14 @@ grateful if anyone wanted to pick that up and report the results.</p>
 <p>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<T></code>, which is used by the self-referential type helper crate <a href="https://crates.io/crates/ouroboros">ouroboros</a>.</p>
 <h1 id="a-way-forward">a way forward</h1>
-<p>Based on all of this, I do have a solution that, in opinion, will fix all of this, even potential performance regressions with
-box. First of all, I think that even if there are some performance regressions in ecosystem crates, the overall tradeoff goes
-against the current box behaviour. Unsafe code wants to use box, and it is reasonable to do so. Therefore I propose to completely
+<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 in ecosystem crates,
+the overall tradeoff goes against the current box behaviour. Unsafe code wants to use box, and it is reasonable to do so. Therefore I propose to completely
 remove all uniqueness from <code>Box<T></code>, and treat it just like a <code>*const T</code> for the purposes of aliasing. This will make it more
 predictable for unsafe code, and comes at none or only a minor performance cost.</p>
-<p>But this performance cost may be real, and especially the future optimization value can’t be certain. I do think that there
-should be a way to get the uniqueness guarantees in some other way than through box. One possibility would be to use a
+<p>But this performance cost may be real, and especially the future optimization value can’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>&'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, maybe 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 though.</p>
-<p>I guess what I am wishing for are some good and flexible raw pointer types. That’s still in the stars…</p>
+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.</p>
+<p>I guess what I am wishing for are some good and flexible raw pointer types. But that’s still in the stars…</p>
 &lt;p>For more information about this topic, see &lt;a href="https://github.com/rust-lang/unsafe-code-guidelines/issues/326">https://github.com/rust-lang/unsafe-code-guidelines/issues/326&lt;/a>&lt;/p></content></item></channel></rss>

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="/"><meta property="og:image:width" content="2048"><meta property="og:image:height" content="1024"><meta property="article:published_time" content="2022-07-22 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-22</span>
 <span class=post-author>:: Nilstrieb</span>
-<span class=post-reading-time>:: 10 min read (2121 words)</span></div><span class=post-tags>#<a href=/tags/rust/>rust</a>&nbsp;
+<span class=post-reading-time>:: 10 min read (2110 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 flexibitility. 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> {
@@ -108,20 +108,19 @@ many missing language features away from this being the case, the <code>noalias<
 user code ever having access to it.</p><p>There are also 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></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><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
+and I prefer the mental model of &ldquo;reference that manages its own lifetime&rdquo;, which doesn&rsquo;t imply uniqueness.</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
 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>
 from being compiled with <code>noalias</code> on <code>Box&lt;T></code>.</p><p>I have not yet benchmarked ecosystem crates without box noalias and don&rsquo;t have the capacity to do so right now, so I would be very
 grateful if anyone wanted to pick that up and report the results.</p><p>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></code>, which is used by the self-referential type helper crate <a href=https://crates.io/crates/ouroboros>ouroboros</a>.</p><h1 id=a-way-forward>a way forward<a href=#a-way-forward class=hanchor arialabel=Anchor>&#8983;</a></h1><p>Based on all of this, I do have a solution that, in opinion, will fix all of this, even potential performance regressions with
-box. First of all, I think that even if there are some performance regressions in ecosystem crates, the overall tradeoff goes
-against the current box behaviour. Unsafe code wants to use box, and it is reasonable to do so. Therefore I propose to completely
+provide an aliasable version of <code>Box&lt;T></code>, which is used by the self-referential type helper crate <a href=https://crates.io/crates/ouroboros>ouroboros</a>.</p><h1 id=a-way-forward>a way forward<a href=#a-way-forward class=hanchor arialabel=Anchor>&#8983;</a></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 in ecosystem crates,
+the overall tradeoff goes against the current box behaviour. 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></code>, and treat it just like a <code>*const T</code> for the purposes of aliasing. This will make it more
-predictable for unsafe code, and comes at none or only a minor performance cost.</p><p>But this performance cost may be real, and especially the future optimization value can&rsquo;t be certain. I do think that there
-should be a way to get the uniqueness guarantees in some other way than through box. One possibility would be to use a
+predictable for unsafe code, and comes at none or only a minor performance cost.</p><p>But this 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>&'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, maybe 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 though.</p><p>I guess what I am wishing for are some good and flexible raw pointer types. That&rsquo;s still in the stars&mldr;</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></div></div></div></div><footer class=footer><div class=footer__inner><div class=copyright><span>© 2022 Powered by <a href=http://gohugo.io>Hugo</a></span>
+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.</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&mldr;</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></div></div></div></div><footer class=footer><div class=footer__inner><div class=copyright><span>© 2022 Powered by <a href=http://gohugo.io>Hugo</a></span>
 <span>:: Theme made by <a href=https://twitter.com/panr>panr</a></span></div></div></footer><script src=/assets/main.js></script>
 <script src=/assets/prism.js></script></div></body></html>

posts/index.xml

@@ -142,7 +142,7 @@ be said that <code>Box<T></code> <em>is</em> a very sp
 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 “reference that manages its own lifetime”, which doesn’t imply uniqueness.</p>
 <h1 id="noalias-noslow">noalias, noslow</h1>
-<p>There is one clear potential benefit from this box behaviour. ✨Optimizations✨. <code>noalias</code> doesn’t exist for fun, it’s something
+<p>There is one clear potential benefit from this box behaviour: ✨Optimizations✨. <code>noalias</code> doesn’t exist for fun, it’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<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>
@@ -152,15 +152,14 @@ grateful if anyone wanted to pick that up and report the results.</p>
 <p>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<T></code>, which is used by the self-referential type helper crate <a href="https://crates.io/crates/ouroboros">ouroboros</a>.</p>
 <h1 id="a-way-forward">a way forward</h1>
-<p>Based on all of this, I do have a solution that, in opinion, will fix all of this, even potential performance regressions with
-box. First of all, I think that even if there are some performance regressions in ecosystem crates, the overall tradeoff goes
-against the current box behaviour. Unsafe code wants to use box, and it is reasonable to do so. Therefore I propose to completely
+<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 in ecosystem crates,
+the overall tradeoff goes against the current box behaviour. Unsafe code wants to use box, and it is reasonable to do so. Therefore I propose to completely
 remove all uniqueness from <code>Box<T></code>, and treat it just like a <code>*const T</code> for the purposes of aliasing. This will make it more
 predictable for unsafe code, and comes at none or only a minor performance cost.</p>
-<p>But this performance cost may be real, and especially the future optimization value can’t be certain. I do think that there
-should be a way to get the uniqueness guarantees in some other way than through box. One possibility would be to use a
+<p>But this performance cost may be real, and especially the future optimization value can’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>&'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, maybe 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 though.</p>
-<p>I guess what I am wishing for are some good and flexible raw pointer types. That’s still in the stars…</p>
+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.</p>
+<p>I guess what I am wishing for are some good and flexible raw pointer types. But that’s still in the stars…</p>
 &lt;p>For more information about this topic, see &lt;a href="https://github.com/rust-lang/unsafe-code-guidelines/issues/326">https://github.com/rust-lang/unsafe-code-guidelines/issues/326&lt;/a>&lt;/p></content></item></channel></rss>

tags/rust/index.xml

@@ -142,7 +142,7 @@ be said that <code>Box<T></code> <em>is</em> a very sp
 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 “reference that manages its own lifetime”, which doesn’t imply uniqueness.</p>
 <h1 id="noalias-noslow">noalias, noslow</h1>
-<p>There is one clear potential benefit from this box behaviour. ✨Optimizations✨. <code>noalias</code> doesn’t exist for fun, it’s something
+<p>There is one clear potential benefit from this box behaviour: ✨Optimizations✨. <code>noalias</code> doesn’t exist for fun, it’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<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>
@@ -152,15 +152,14 @@ grateful if anyone wanted to pick that up and report the results.</p>
 <p>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<T></code>, which is used by the self-referential type helper crate <a href="https://crates.io/crates/ouroboros">ouroboros</a>.</p>
 <h1 id="a-way-forward">a way forward</h1>
-<p>Based on all of this, I do have a solution that, in opinion, will fix all of this, even potential performance regressions with
-box. First of all, I think that even if there are some performance regressions in ecosystem crates, the overall tradeoff goes
-against the current box behaviour. Unsafe code wants to use box, and it is reasonable to do so. Therefore I propose to completely
+<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 in ecosystem crates,
+the overall tradeoff goes against the current box behaviour. Unsafe code wants to use box, and it is reasonable to do so. Therefore I propose to completely
 remove all uniqueness from <code>Box<T></code>, and treat it just like a <code>*const T</code> for the purposes of aliasing. This will make it more
 predictable for unsafe code, and comes at none or only a minor performance cost.</p>
-<p>But this performance cost may be real, and especially the future optimization value can’t be certain. I do think that there
-should be a way to get the uniqueness guarantees in some other way than through box. One possibility would be to use a
+<p>But this performance cost may be real, and especially the future optimization value can’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>&'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, maybe 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 though.</p>
-<p>I guess what I am wishing for are some good and flexible raw pointer types. That’s still in the stars…</p>
+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.</p>
+<p>I guess what I am wishing for are some good and flexible raw pointer types. But that’s still in the stars…</p>
 &lt;p>For more information about this topic, see &lt;a href="https://github.com/rust-lang/unsafe-code-guidelines/issues/326">https://github.com/rust-lang/unsafe-code-guidelines/issues/326&lt;/a>&lt;/p></content></item></channel></rss>

tags/unsafe-code/index.xml

@@ -142,7 +142,7 @@ be said that <code>Box<T></code> <em>is</em> a very sp
 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 “reference that manages its own lifetime”, which doesn’t imply uniqueness.</p>
 <h1 id="noalias-noslow">noalias, noslow</h1>
-<p>There is one clear potential benefit from this box behaviour. ✨Optimizations✨. <code>noalias</code> doesn’t exist for fun, it’s something
+<p>There is one clear potential benefit from this box behaviour: ✨Optimizations✨. <code>noalias</code> doesn’t exist for fun, it’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<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>
@@ -152,15 +152,14 @@ grateful if anyone wanted to pick that up and report the results.</p>
 <p>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<T></code>, which is used by the self-referential type helper crate <a href="https://crates.io/crates/ouroboros">ouroboros</a>.</p>
 <h1 id="a-way-forward">a way forward</h1>
-<p>Based on all of this, I do have a solution that, in opinion, will fix all of this, even potential performance regressions with
-box. First of all, I think that even if there are some performance regressions in ecosystem crates, the overall tradeoff goes
-against the current box behaviour. Unsafe code wants to use box, and it is reasonable to do so. Therefore I propose to completely
+<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 in ecosystem crates,
+the overall tradeoff goes against the current box behaviour. Unsafe code wants to use box, and it is reasonable to do so. Therefore I propose to completely
 remove all uniqueness from <code>Box<T></code>, and treat it just like a <code>*const T</code> for the purposes of aliasing. This will make it more
 predictable for unsafe code, and comes at none or only a minor performance cost.</p>
-<p>But this performance cost may be real, and especially the future optimization value can’t be certain. I do think that there
-should be a way to get the uniqueness guarantees in some other way than through box. One possibility would be to use a
+<p>But this performance cost may be real, and especially the future optimization value can’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>&'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, maybe 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 though.</p>
-<p>I guess what I am wishing for are some good and flexible raw pointer types. That’s still in the stars…</p>
+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.</p>
+<p>I guess what I am wishing for are some good and flexible raw pointer types. But that’s still in the stars…</p>
 &lt;p>For more information about this topic, see &lt;a href="https://github.com/rust-lang/unsafe-code-guidelines/issues/326">https://github.com/rust-lang/unsafe-code-guidelines/issues/326&lt;/a>&lt;/p></content></item></channel></rss>