From c3ee5c6dbc10510b6b91f53bd582755024690b3d Mon Sep 17 00:00:00 2001 From: Erich Gubler Date: Wed, 5 Jun 2024 12:54:20 -0400 Subject: [PATCH] fix(2024-06-02): correct formatting and broken link in RFC 2229/view types footnote --- content/blog/2024-06-02-the-borrow-checker-within.markdown | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/content/blog/2024-06-02-the-borrow-checker-within.markdown b/content/blog/2024-06-02-the-borrow-checker-within.markdown index 36e998c..d67ab77 100644 --- a/content/blog/2024-06-02-the-borrow-checker-within.markdown +++ b/content/blog/2024-06-02-the-borrow-checker-within.markdown @@ -156,7 +156,9 @@ impl WidgetFactory { This allows the compiler to compile `count_widgets` just fine, since it can see that iterating over `self.widgets` while modifying `self.counter` is not a problem.[^2229] -[^2229]: In fact, view types will also allow us to implement the "disjoint closure capture" rules from [RFC 2229][] in a more efficient way. Currently a closure using `self.widgets` and `self.counter` will store 2 references, kind of an implicit "view struct". Although [we found this doesn't really affect much code in practice](https://rust-lang.zulipchat.com/#narrow/stream/189812-t-compiler.2Fwg-rfc-2229/topic/measure.20closure.20sizes)), it still bothers me. With view types they could store 1. +[^2229]: In fact, view types will also allow us to implement the "disjoint closure capture" rules from [RFC 2229][] in a more efficient way. Currently a closure using `self.widgets` and `self.counter` will store 2 references, kind of an implicit "view struct". Although [we found this doesn't really affect much code in practice](https://rust-lang.zulipchat.com/#narrow/stream/189812-t-compiler.2Fwg-rfc-2229/topic/measure.20closure.20sizes), it still bothers me. With view types they could store 1. + +[RFC 2229]: https://rust-lang.github.io/rfcs/2229-capture-disjoint-fields.html ### View types also address phased initialization