Ok, I guess somebody has to provide the youngsters/uninitiated with some context. What is going on here can be viewed as part of a process of Rust (potentially) incrementally adopting the C++ model, because the Rust model is limited in important ways.
Specifically, Rust's "necessarily-trivial-destructive" moves make it possible for a memory location previously holding a valid object to become invalid without a destructor (or any other handler) being called. Accommodating this possibility resulted in unforeseen (by many) limitations, particularly in the safe subset. (See "the leakpocalypse".) This was partially addressed by the introduction of "pinning" into the Rust language. The posted github page suggests that this sort of pinning is not the ideal approach, and that it is more effective to make the "unmovability" of an object a property of the object's type, rather than a property of the reference to the object, as is the case with the pinning approach.
To be clear, we're talking about Rust-style "necessarily-trivial-destructive" movability here. Traditionally, C++ doesn't really support this sort of movability. That is, even if an object's contents are ("conceptually") moved to a different location, the original source object remains (at its original location) until it is otherwise destroyed (and its destructor called). So in C++, all types are "immovable" in the sense of the posted github page.
The github page notes how these "immovable" types can support self-references completely in the safe subset in a way that pinning can't.
> This unblocks patterns that are currently impossible in safe Rust.
For an idea of some other unblocked patterns, you can consider so-called "norad" pointers [1] (and proxy pointers [2]) in the SaferCPlusPlus library. Analogous to how `RefCell` references can be used to express references that cannot be statically verified to conform to Rust's "aliasing-xor-mutability" restrictions, "norad" pointers can be used to express references that cannot be statically verified to be lifetime safe. This would include, for example, all manner of cyclic references beyond just "self-references".
I think you could implement a version of these norad pointers in Rust that can safely target these immovable types (whose destructor is guaranteed to be called while the object is still in its original location). But note that the C++ implementation uses static inheritance (which Rust does not support) to avoid the noise having to access the target object as "interior" content (like with `RefCell`s).
With the availability of these flexible references, one could imagine immovable types becoming popular in things like games / entity component systems, GUI frameworks, browser engines, and any place where "back pointers" would be convenient. One might even imagine that at some point, types being "immovable" could become the popular default for object types in Rust (among biological and/or non-biological Rust programmers). At which point, people may decide that actually they do want (the contents of) some of their immovable types to be "movable", but they don't necessarily need the object to be destructively movable. So you could imagine the introduction of standard `nondestructive_move()` (and `nondestructive_move_from()`) methods that would be companions of the existing `clone()` (and `clone_from()`) methods. At which point Rust would have counterparts for C++ copy and move constructors (and assignment operators).
In my view, this adoption of the C++ model (potentially) addresses Rust's main limitation. With one consequence being to potentially make automated translation of C and C++ code to (reasonable code in) the safe subset of Rust much more feasible than seems to be currently.
I agree with most of that, but there's one important detail (that I'm sure the designers of this proposal are thinking about): The current contract of Pin in Rust (the only standard support for expressing immobility) doesn't just cover the object's own location, but also any references derived from the object, commonly called "pin projection".
For example, if you have a `Pin<Box<Vec<u8>>>`, it's safe to turn that into a `Pin<&mut [u8]>`.
Any system that replaces `Pin` will probably have to maintain that same property, which wouldn't naïvely happen using C++-like move semantics, right? Or maybe I'm overassuming?
Hmm, I'm not sure if you're concerned about the "norad"-style run-time checked references I'm imagining or raw references. In either case, the property we (and `Pin<>`) are concerned about is whether an object can be (destructively) moved. You're pointing out a reference derived from a pinning reference essentially inheriting the pinning property. (I.e. the property that the target won't be inappropriately (destructively) moved.)
But with this proposal, the property that the object won't be (destructively) moved is (solely) a property of the object's type. Specifically, it doesn't depend on any property of any reference to the object, and certainly not on any other reference that that reference was derived from, right?
> Any system that replaces `Pin` will probably have to maintain that same property
Maybe any system that compatibly replaces `Pin`. Maybe. But I'm not sure that this proposal is overly concerned with compatibility with `Pin`. That github page explicitly mentions the desire to deprecate `Pin`, right? And like I suggested, if successful enough, it's conceivable that it could end up de facto deprecating Rust's necessarily-trivial-destructive moves in general. Conceivably.
My sense of sentiment in the project right now is that people want to keep the invariant that assignment (to an ordinary memory location) is always just a memcpy and never calls arbitrary user-defined code, because if that code does something unexpected, debugging (at least if a human's doing it) is likely to be hampered by the syntactic invisibility of the call site. This is why the most obvious ergonomic-reference-counting proposal (have a trait that lets types opt into implicit clones) ran aground, and they're now experimenting with (conceptually clunkier, in my opinion) alternatives that aim to make reference counting ergonomic but still syntactically visible.
So if Rust ever gains move constructors, you'll probably have to call them explicitly, the way you have to explicitly call .clone(). (There's actually already a third-party library that does something like this (https://docs.rs/moveit), and I think Crubit is using a similar API to let Rust code call C++ move constructors.)
One of the main reasons Rust needs this capability is because C++ has it, and Rust wants to interop with it. It's not that better model (enabling it additionally can bring benefits, but also complications; enabling it by default, like C++ does, is a terrible idea).
Well, there is another safe option for flexible pointers if you can compile as C++ [1]. In C++ you can have non-owning "smart" pointers with run-time-checked lifetimes [2][3]. Importantly, there is no run-time overhead to dereference them. (That is for the "never-null" versions, otherwise there's a null check.) Assignment has additional run-time cost, but pointer assignments are generally much less prevalent in performance-sensitive inner loops than dereferences, right?
And you can statically verify [4] your raw pointers, so that you only need to use the run-time-checked pointers for the more exotic lifetime relationships.
(That said, for the situations where Fil-C acceptably solves your problem, it's probably the more practical, complete and well-supported solution. And since not many seem to be explicitly mentioning it, the recent Fil-C demonstration of memory-safe linux userspace is rather impressive, right? I've heard that IT security is a $100B industry. I'm guessing an inappropriately low proportion of those resources are being invested in Fil-C. :)
Interesting, this is pretty cool! I'm guessing it doesn't work with pointer to int casts though? I'm using NaN packing, so I necessarily have to cast it to an integer.
EDIT: though I'm considering switching to a tag + 64 bit union, because of 54 bit addressing and pointer tagging. It makes it tricky to get my data layout right though, since it makes all of the structures larger.
If the concern is memory safety, I'd invite comparison with migration to the scpptool-enforced memory-safe subset of C++ [1]. If your C++ code is "idiomatic modern" C++, then the changes required to conform to the safe subset (in an idiomatic way) are often modest, and as demonstrated in the link, often something an LLM can handle for you. Since the safe subset does not impose a universal restriction on mutable aliasing the way Rust does, it doesn't require wrapping everything in `RefCell<>`s or anything like that (unless the objects in question are being shared between threads).
If your C++ code is more "legacy" than "modern", the migration is generally still straightforward, but will often involve additional run-time overhead, like it does with this cpp2rust, but to a lesser degree I think. Objects allocated on the stack can (safely) remain allocated on the stack even when they are the target of pointers. And still, no `RefCell<>` equivalents are required for objects that aren't shared between threads.
But are we necessarily limited to native integer types? At least with C++, the type system is powerful enough to support integer replacement types (eg. [0][1]) that don't inherit these issues. (Where, for example, the subtraction of an unsigned from another unsigned returns a value of signed integer type.) Another advantage being the ability to customize the overflow/underflow handling policy per declaration (rather than relying on a compiler flag that applies globally).
I would rather do away with signed vs unsigned integer types completely, and instead have sign-agnostic integers like down on the assembly level (the world has settled on two's-complement anyway). Signed-vs-unsigned only matters in one situation: when extending a narrow integer type to a wider integer type (e.g. "sign-extension"), and this could be an explicit operation.
Beyond that, the decision whether a number is signed or unsigned is only needed for string formatting (e.g. it's like Schroedingers integers: whether a number is signed or unsigned only matters when you actually look at the number).
Yeah ok got me, but AFAIK at least multiplication is sign-agnostic when the result is clamped to the width of the inputs (e.g. the result of multiplying two 64-bit values being clamped to 64-bits). Not sure about division though.
But in any case: with 'sign-agnostic' integer types high level languages would simply need separate signed vs unsigned mul/div operators. Not a big thing when modern languages already have different operators for wraparound vs overflow-checked arithmetic (for instance + vs +% in Zig).
If the source language is C++, another option might be to use AI agents to port to a memory-safe subset of C++ [1]. For the most part, this involves surgical changes and glorified find-and-replace operations. And I'm guessing way fewer tokens :)
If the source language is legacy C, then another option might be (deterministic) transpilation to a memory-safe subset of C++ [2]. The resulting code wouldn't necessarily be performance-optimal, but it can be used for the majority of code that isn't really performance-sensitive.
You might be interested in the scpptool feature to help convert C code to a subset of C that will also compile as C++ (under clang++ at least) [1]. While many of the necessary modifications are fairly trivial, some of them aren't completely so. For example, C++ does not allow `goto`s that would skip over the declaration/initialization of a variable that would be accessible after the jump. So getting the C code to work as C++ can involve some (automatic) code restructuring.
Another annoying detail is that C++ doesn't seem to like forward references of `enum`s. That is, while
struct A* a_ptr;
is fine in both C and C++ even before `struct A` has been defined, apparently
enum A* a_ptr;
is not cool in C++ until after `enum A` has been defined.
One arguable benefit of keeping your C code compatible with (or at least convertible to) C++, is that you can theoretically use scpptool's auto-translation feature as build step to produce memory-safe executables from C code via transpilation to a memory-safe subset of C++.
> It's in many cases as simple as renaming a file from .c to .cpp.
That is rather optimistic, but, for example, scpptool has a feature [1] that auto-converts from C to a subset of C that can (hopefully) be compiled with clang++. If the original C source uses C11 extensions, clang++ seems to generally produce warnings rather than compile errors.
> But for writing something from scratch it's better to use Rust.
scpptool attempts to make C++ a more viable option by enforcing a memory and data race safe subset using a similar safety strategy.
I think the concern is that the writing may be on the wall for (the current memory-unsafe version of) Coreutils. Despite the bugs and incompatibilities, Canonical seems to have decided that the memory safety of uutils is worth it. And those two downsides, the bugs and incompatibilities, will likely attenuate quickly, compelling the other distros to follow suit in adopting uutils before long.
So the continued popularity of Coreutils might, I think, depend on Coreutil's near-term publicly announced and actual memory safety strategy. As I suggested in my other comment, there are (somewhat nascent) options for memory safety that do not require a rewrite of the code base. (For linux x86_64 platforms, depending on your requirements, that might include the "fanatically compatible" Fil-C.) And given the high profile of Coreutils, there are likely people willing to work with the Coreutils team to help in the deployment of those memory safety options.
I don't know if you're aware, but there is a demonstration of wget (a fellow "gnu utility", right?) being auto-translated to a memory-safe subset of C++ [1]. Because the translation essentially does a one-for-one substitution of potentially unsafe C elements with safe C++ counterparts that mirror the behavior, the translation should be much less susceptible to the introduction of new bugs and behaviors in the way a rewrite would be.
With a little cleaning-up of the original code, the code translation ends up being fully automatic and so can be used as a build step to produce (slightly slower) memory-safe executables from the original C source.
Filesystem access is mostly treated by users as serialized ACID transactions on "files in directories."
"Managing this resource centrally" is where unix syscalls came from. An OS kernel can be used like a specialized library for ACID transactions on hardware singletons.
People then got fancy with virtual memory, interrupts, signals, time-slicing, re-entrancy, thread-safety, and injectivity.
It doesn’t matter, whether you call the "kernel library" from C, C++, Fortan, BASIC, Golang, bash, Rust, etc.
Interestingly, I recently auto-translated wget from C to a memory-safe subset of C++ [1], which involves the intermediate step of auto-converting from C to the subset of C that will also compile under clang++. You end up with a bunch of clang++ warnings about various things being C11 extensions and not ISO C++ compliant, but it does compile.
Specifically, Rust's "necessarily-trivial-destructive" moves make it possible for a memory location previously holding a valid object to become invalid without a destructor (or any other handler) being called. Accommodating this possibility resulted in unforeseen (by many) limitations, particularly in the safe subset. (See "the leakpocalypse".) This was partially addressed by the introduction of "pinning" into the Rust language. The posted github page suggests that this sort of pinning is not the ideal approach, and that it is more effective to make the "unmovability" of an object a property of the object's type, rather than a property of the reference to the object, as is the case with the pinning approach.
To be clear, we're talking about Rust-style "necessarily-trivial-destructive" movability here. Traditionally, C++ doesn't really support this sort of movability. That is, even if an object's contents are ("conceptually") moved to a different location, the original source object remains (at its original location) until it is otherwise destroyed (and its destructor called). So in C++, all types are "immovable" in the sense of the posted github page.
The github page notes how these "immovable" types can support self-references completely in the safe subset in a way that pinning can't.
> This unblocks patterns that are currently impossible in safe Rust.
For an idea of some other unblocked patterns, you can consider so-called "norad" pointers [1] (and proxy pointers [2]) in the SaferCPlusPlus library. Analogous to how `RefCell` references can be used to express references that cannot be statically verified to conform to Rust's "aliasing-xor-mutability" restrictions, "norad" pointers can be used to express references that cannot be statically verified to be lifetime safe. This would include, for example, all manner of cyclic references beyond just "self-references".
I think you could implement a version of these norad pointers in Rust that can safely target these immovable types (whose destructor is guaranteed to be called while the object is still in its original location). But note that the C++ implementation uses static inheritance (which Rust does not support) to avoid the noise having to access the target object as "interior" content (like with `RefCell`s).
With the availability of these flexible references, one could imagine immovable types becoming popular in things like games / entity component systems, GUI frameworks, browser engines, and any place where "back pointers" would be convenient. One might even imagine that at some point, types being "immovable" could become the popular default for object types in Rust (among biological and/or non-biological Rust programmers). At which point, people may decide that actually they do want (the contents of) some of their immovable types to be "movable", but they don't necessarily need the object to be destructively movable. So you could imagine the introduction of standard `nondestructive_move()` (and `nondestructive_move_from()`) methods that would be companions of the existing `clone()` (and `clone_from()`) methods. At which point Rust would have counterparts for C++ copy and move constructors (and assignment operators).
In my view, this adoption of the C++ model (potentially) addresses Rust's main limitation. With one consequence being to potentially make automated translation of C and C++ code to (reasonable code in) the safe subset of Rust much more feasible than seems to be currently.
[1] https://github.com/duneroadrunner/SaferCPlusPlus/blob/master...
[2] https://github.com/duneroadrunner/SaferCPlusPlus/blob/master...