the borrow checker is one of the most important features of Rust. as part of my work on field projections, we need to come up with a way to generalize it and expose its inner workings via traits. in this post, I’m presenting my model of the borrow checker in the current design for field projections (which has moved to https://github.com/rust-lang/beyond-refs now). in this post, I’m focusing on the more basic pointers that we’ll support; mainly custom &T, &mut T and Box<T>. more advanced pointers will come later in another post.
the field projection project goal is about designing a language feature to make custom pointer types as ergonomic as the builtin reference types &T and &mut T. I’m working on this goal together with Tyler Mandry, Nadrieril, and Xiangfei Ding as well as many others on the Rust Zulip. this blog post gives a short introduction of the idea, shows what we’re currently working on, and offers links to more resources.
note: I wrote this post back in august and did not upload it until now. most of the information is still up to date, but you might find some minute differences to my current work.
In this blog post, I present an idea on how we can specify the borrow checker behavior in the context of the field projection design effort. This work builds upon the blog post The Algebra of Loans in Rust by Nadrieril. I will give a more field projection focused proposal, whereas that blog post looked at the general way the borrow checker works.
In this blog post, I am going to go over how in-place constructors could be added to Rust. Doing this will enable better ergonomics for embedded and kernel-space programs. There are two distinct problems that this feature will cater to:
- safe pinned initialization,
- ergonomic in place initialization of big structs.
I explained in my overview blog post why the first point is needed. The second point is also wanted by Linux kernel developers, because they need exact control over where something gets initialized. As the kernel has very limited stack size – compared to userland programs – and thus cannot allocate big structs (multiple KB in size) on the stack.
In this blog post I will try to explain the problem of Safe Pinned Initialization. I am going to tackle the issue from two perspectives:
- Rust language design: how can we make Safe Pinned Initialization ergonomic for as many people as possible?
- Linux kernel design: how can we satisfy the kernel’s needs with Rust?
In order to aid the second perspective, I will try to cater specifically to C-only kernel developers. While this document is written with C developers in mind, it does not explain the basic concepts of Rust. So if you are not at all familiar with Rust, I would recommend reading at least chapters 3 and 4 of the Rust book.
This is a collection of thoughts/ideas on the placement-by-return RFC.