SaferCPlusPlus

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...

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. :) [1] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla... [2] https://github.com/duneroadrunner/SaferCPlusPlus#norad-point... [3] https://github.com/duneroadrunner/SaferCPlusPlus#tnoradproxy... [4] https://github.com/duneroadrunner/scpptool

e with more overhead [3]. Pointers that can be verified (by the static analyzer) to conform to "scope lifetime" rules (akin to Rust) can remain zero-overhead pointers. New code written in the safe subset would generally have performance in the ballpark of traditional C++ [4]. [1] https://github.com/duneroadrunner/scpptool [2] https://github.com/duneroadrunner/SaferCPlusPlus#norad-point... [3] https://github.com/duneroadrunner/SaferCPlusPlus#registered-... [4] https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG... (note that the benchmark code is quite old and will be updated soon)

ame kinds of "severe" usage restrictions that the lifetime profile checker (or, say, the Rust compiler) does. [1] https://devblogs.microsoft.com/cppblog/lifetime-profile-upda... [2] https://github.com/duneroadrunner/SaferCPlusPlus edit: grammar

but reasonably modest [3]. [1] https://github.com/duneroadrunner/SaferCPlusPlus#registered-... [2] https://github.com/duneroadrunner/SaferCPlusPlus#norad-point... [3] https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG...

d memory access (though it could just as easily return an optional<>, and you can always query if the target is valid), and one that terminates the program if its target is ever deallocated prematurely (and thus (technically) satisfies your criteria). (The latter has less/minimal overhead.) > A Cone programmer would need to use raw pointers to throw off the shackles of lifetime constraints Or reference counting pointers or GC, right? The features needed to implement the pointers I mentioned is either support for calling a destructor on move operations or the ability to make an object non-movable, and, support for copy constructors or the ability to make an object uncopyable. Does/could your language support some combination of those features? I explain the reason the pointers are important in an article called "Implications of the Core Guidelines lifetime checker restrictions" [1]. Specifically, I give an example of reasonable C++ code [2] that historically had no corresponding efficient implementation in Safe Rust. (I think it's still the case, but I haven't fully investigated the implications of Rust's new "pinning" feature.) It can, however, be implemented in a memory safe way using the SaferCPlusPlus pointers in question [3]. Basically the example just temporarily inserts a reference to a (stack allocated) local variable into a list (or whatever dynamic container), given that the local variable does not outlive the container. > especially given that borrowed references and raw pointers are both able to point inside an allocated object SaferCPlusPlus has the equivalent of "borrowed references"[4] (though even more restricted until C++'s "borrow checker" (the aforementioned "lifetime profile checker") is completed), and they can safely point "inside" (allocated) objects. Note that the second safe pointer type (the one that potentially terminates the program), is a "strong" pointer, and there is a simple mechanism for obtaining a "borrowed reference" from a strong pointer [5]. And from there, a simple mechanism for obtaining a reference to an (interior?) member [6]. The other pointer (the one that potentially throws an exception) would be considered a "weak" pointer, and you cannot obtain a "borrowed reference" directly from a weak pointer. But often, the weak pointer is used to target an object that can yield a borrowed reference (like a strong pointer, for example), or a borrowed reference directly. > all the best with getting others to learn about and adopt your language. You too :) I can see the appeal of this sort of clean, flexible language. But in the case of SaferCPlusPlus the goal is not necessarily (just) for programmers to adopt it. In part it's maybe a demonstration (to language designers such as yourself :) of a set of language elements that use run-time safety enforcement mechanisms but are a little more flexible than (and might be a good / (unintuitively) needed complement to) their counterparts that rely on strictly compile-time safety enforcement. Oh and if you do get around to checking out SaferCPlusPlus in more depth, apologies for the inadequate documentation in advance. Feel free to post any questions you might have. :) [1] https://github.com/duneroadrunner/misc/blob/master/201/8/Jul... [2] https://github.com/duneroadrunner/misc/blob/master/201/8/Jul... [3] https://github.com/duneroadrunner/misc/blob/54204445bc099987... [4] https://github.com/duneroadrunner/SaferCPlusPlus#txscopeitem... [5] https://github.com/duneroadrunner/SaferCPlusPlus#make_xscope... [6] https://github.com/duneroadrunner/SaferCPlusPlus#make_pointe...