deploy: 379f1b93cb

index.xml

@@ -125,7 +125,7 @@ this comparison doesn’t make sense to me. While <code>Box<T&
 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>&mut T</code> (maybe that’s also because that
 one makes intuitive sense, “shared xor mutable” 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 intiutive.</p>
+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’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
@@ -137,18 +137,20 @@ other box-exclusive features it offers. Even worse is <code>string_cache</
 <p>Then last but not least, there’s the opinionated fact that <code>Box<T></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>
-<h1 id="noalias-noslow">noalias, noslow</h1>
 <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<T></code> <em>is</em> a very special type. It’s just like a <code>T</code>, but on the heap. Using this mental model, it’s very easy to
-justify all the box magic and its unique behaviour.</p>
+justify all the box magic and its unique behaviour. But in my opinion, this is not a useful mental model regarding unsafe code,
-<p>This mental model is one that many people have, but what does this bring us? This is just one mental model of box, and
+and I prefer the mental model of “reference that manages its own lifetime”, which doesn’t imply uniqueness.</p>
-there are other mental models of it (like “a reference that manages its lifetime itself” or “a safe RAII pointer”).</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
 that can bring clear performance wins (for <code>noalias</code> on <code>&mut T</code>, those were measureable). So the only question remains:
-How much performance does <code>noalias</code> on <code>Box<T></code> give us now, and how much potential performance improvements could we get in the
+<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? 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<T></code>.</p>
+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<T></code>.</p>
 <p>I have not yet benchmarked ecosystem crates without box noalias and don’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<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
@@ -156,6 +158,9 @@ against the current box behaviour. Unsafe code wants to use box, and it is reaso
 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 <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>
+should be a way to get the uniqueness guarantees in some other way than through box. One possibility would be 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>
 &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 (2108 words)</span></div><span class=post-tags>#<a href=/tags/rust/>rust</a>&nbsp;
+<span class=post-reading-time>:: 10 min read (2121 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> {
@@ -97,7 +97,7 @@ this comparison doesn&rsquo;t make sense to me. While <code>Box&lt;T></code> usu
 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>&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 intiutive.</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
+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></code>) instead of a box, and using the constructor and drop to allocate and deallocate the backing box.
@@ -105,18 +105,23 @@ This is fairly inconvenient, but totally acceptable. There are bigger problems t
 that want to expose a generic interface over any type. Users like to choose box, and sometimes <em>have</em> to chose 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></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><h1 id=noalias-noslow>noalias, noslow<a href=#noalias-noslow class=hanchor arialabel=Anchor>&#8983;</a></h1><p>There are also several arguments in favour of box being unique and special cased here. To negate the last argument above, it can
+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.</p><p>This mental model is one that many people have, but what does this bring us? This is just one mental model of box, and
+justify all the box magic and its unique behaviour. But in my opinion, this is not a useful mental model regarding unsafe code,
-there are other mental models of it (like &ldquo;a reference that manages its lifetime itself&rdquo; or &ldquo;a safe RAII pointer&rdquo;).</p><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:
-How much performance does <code>noalias</code> on <code>Box&lt;T></code> give us now, and how much potential performance improvements could we get in the
+<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? 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
+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>
-grateful if anyone wanted to pick that up and report the results.</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
+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
 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 <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>
+should be a way to get the uniqueness guarantees in some other way than through box. One possibility would be 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>
 <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

@@ -125,7 +125,7 @@ this comparison doesn’t make sense to me. While <code>Box<T&
 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>&mut T</code> (maybe that’s also because that
 one makes intuitive sense, “shared xor mutable” 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 intiutive.</p>
+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’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
@@ -137,18 +137,20 @@ other box-exclusive features it offers. Even worse is <code>string_cache</
 <p>Then last but not least, there’s the opinionated fact that <code>Box<T></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>
-<h1 id="noalias-noslow">noalias, noslow</h1>
 <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<T></code> <em>is</em> a very special type. It’s just like a <code>T</code>, but on the heap. Using this mental model, it’s very easy to
-justify all the box magic and its unique behaviour.</p>
+justify all the box magic and its unique behaviour. But in my opinion, this is not a useful mental model regarding unsafe code,
-<p>This mental model is one that many people have, but what does this bring us? This is just one mental model of box, and
+and I prefer the mental model of “reference that manages its own lifetime”, which doesn’t imply uniqueness.</p>
-there are other mental models of it (like “a reference that manages its lifetime itself” or “a safe RAII pointer”).</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
 that can bring clear performance wins (for <code>noalias</code> on <code>&mut T</code>, those were measureable). So the only question remains:
-How much performance does <code>noalias</code> on <code>Box<T></code> give us now, and how much potential performance improvements could we get in the
+<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? 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<T></code>.</p>
+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<T></code>.</p>
 <p>I have not yet benchmarked ecosystem crates without box noalias and don’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<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
@@ -156,6 +158,9 @@ against the current box behaviour. Unsafe code wants to use box, and it is reaso
 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 <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>
+should be a way to get the uniqueness guarantees in some other way than through box. One possibility would be 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>
 &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

@@ -125,7 +125,7 @@ this comparison doesn’t make sense to me. While <code>Box<T&
 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>&mut T</code> (maybe that’s also because that
 one makes intuitive sense, “shared xor mutable” 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 intiutive.</p>
+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’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
@@ -137,18 +137,20 @@ other box-exclusive features it offers. Even worse is <code>string_cache</
 <p>Then last but not least, there’s the opinionated fact that <code>Box<T></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>
-<h1 id="noalias-noslow">noalias, noslow</h1>
 <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<T></code> <em>is</em> a very special type. It’s just like a <code>T</code>, but on the heap. Using this mental model, it’s very easy to
-justify all the box magic and its unique behaviour.</p>
+justify all the box magic and its unique behaviour. But in my opinion, this is not a useful mental model regarding unsafe code,
-<p>This mental model is one that many people have, but what does this bring us? This is just one mental model of box, and
+and I prefer the mental model of “reference that manages its own lifetime”, which doesn’t imply uniqueness.</p>
-there are other mental models of it (like “a reference that manages its lifetime itself” or “a safe RAII pointer”).</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
 that can bring clear performance wins (for <code>noalias</code> on <code>&mut T</code>, those were measureable). So the only question remains:
-How much performance does <code>noalias</code> on <code>Box<T></code> give us now, and how much potential performance improvements could we get in the
+<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? 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<T></code>.</p>
+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<T></code>.</p>
 <p>I have not yet benchmarked ecosystem crates without box noalias and don’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<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
@@ -156,6 +158,9 @@ against the current box behaviour. Unsafe code wants to use box, and it is reaso
 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 <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>
+should be a way to get the uniqueness guarantees in some other way than through box. One possibility would be 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>
 &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

@@ -125,7 +125,7 @@ this comparison doesn’t make sense to me. While <code>Box<T&
 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>&mut T</code> (maybe that’s also because that
 one makes intuitive sense, “shared xor mutable” 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 intiutive.</p>
+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’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
@@ -137,18 +137,20 @@ other box-exclusive features it offers. Even worse is <code>string_cache</
 <p>Then last but not least, there’s the opinionated fact that <code>Box<T></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>
-<h1 id="noalias-noslow">noalias, noslow</h1>
 <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<T></code> <em>is</em> a very special type. It’s just like a <code>T</code>, but on the heap. Using this mental model, it’s very easy to
-justify all the box magic and its unique behaviour.</p>
+justify all the box magic and its unique behaviour. But in my opinion, this is not a useful mental model regarding unsafe code,
-<p>This mental model is one that many people have, but what does this bring us? This is just one mental model of box, and
+and I prefer the mental model of “reference that manages its own lifetime”, which doesn’t imply uniqueness.</p>
-there are other mental models of it (like “a reference that manages its lifetime itself” or “a safe RAII pointer”).</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
 that can bring clear performance wins (for <code>noalias</code> on <code>&mut T</code>, those were measureable). So the only question remains:
-How much performance does <code>noalias</code> on <code>Box<T></code> give us now, and how much potential performance improvements could we get in the
+<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? 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<T></code>.</p>
+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<T></code>.</p>
 <p>I have not yet benchmarked ecosystem crates without box noalias and don’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<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
@@ -156,6 +158,9 @@ against the current box behaviour. Unsafe code wants to use box, and it is reaso
 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 <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>
+should be a way to get the uniqueness guarantees in some other way than through box. One possibility would be 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>
 &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>