The Next Steps for Single Ownership and RAII

While diving the depths of single ownership, we discovered a hidden gem from the most unlikely of places. With it, we were able to reassemble C++ into something that really unleashes the full potential of RAII.

Recall these ancient mantras, known to any C++ developer:

• "Who destroyed that object I was pointing at?"
• "Blasted segfaults!"
• "We need to influence the destructor, but destructors take no parameters!"
• "Who's still holding a shared_ptr to my object? It should be dead!"
• "I can't throw from a destructor, or have multiple exceptions in flight?"
• "Destructors can't return a status, either?!"

In this journey, we discovered language solutions for all of these.

This article is about C++'s RAII and single ownership, and how we can take it even further. 0

C++'s syntax often makes single ownership look more difficult than it is, so we also use Vale to illustrate how easy and powerful single ownership can be. 1

Single Ownership

Our journey started in 2011, when C++11's unique_ptr brought single ownership and move semantics to C++ programmers worldwide, and changed our lives forever. 2

In one fell swoop, it basically single-handedly solved memory leaks. Single-ownership is one of those notions that, once it clicked, felt right. It was probably because this is how we already think: in C, we would mentally track ownership, to know whose responsibility it was to free an object. Even in GC'd languages, we would implicitly track who's responsible for calling .dispose().

We slowly discovered that we could use RAII for things other than freeing memory! We could:

• Remove self from an observers list. 3
• Close a file stream, or clean up a temp file.
• Close a mutex's lock.
• Stop an ongoing calculation in another thread.
• Roll-back or commit a transaction.
• Cancel a retrying network request.
• Remove some UI elements from the view.
• Resolve or reject a future.
• Notify others that we're being freed.
• Enforce that we actually handled an error, rather than dropping it on the floor.

We realized: RAII wasn't just a way to track who should free an object, and these weren't just neat tricks. RAII is much more, it's a way to track responsibility. 4

It's a promise that's enforced by the compiler. Instead of just "The compiler will make sure we free this," RAII is "The compiler will make sure that we XYZ" where XYZ is whatever we want. 5

Safe Handling of Aliases

Single ownership in modern C++ uses owning unique_ptr<T>s, and non-owning T* raw pointers.

Where unique_ptr is the sheriff, the raw pointer is the infamous mercenary who rides into town and makes everyone mighty nervous. When things go well, he's useful... but if things get dicey, he might just decide to dereference that pointer and cause all sorts of chaos.

class BigClass {
public:
  unique_ptr<A> a;
  unique_ptr<B> b;
  unique_ptr<C> c;
  unique_ptr<D> d;
  BigClass() :
    a(make_unique<A>()),
    b(make_unique<B>(a.get())),
    c(make_unique<C>(a.get())),
    d(make_unique<D>(a.get(), c.get()))
  { }
};

struct BigClass {
  a A; 7
  b B;
  c C;
  d D;
  func BigClass() {
    this.a = A(); 8
    this.b = B(&this.a); 9
    this.c = C(&this.a);
    this.d = D(&this.a, &this.c);
  }
}

Interestingly, in this picture, there are never any dangling pointers. It's even better than never dereferencing any dangling pointers: rather the pointers never become dangling to begin with!

Indeed, every reference to an object is destroyed before the object itself is.

Constraint References

This kind of "non-outliving pointer" is everywhere. Some examples:

• A PhoneCall points to two Accounts. The PhoneCall shouldn't outlive the Accounts; we should delete the PhoneCall before deleting either Account.
• In a graph, an edge points to its nodes. The edge shouldn't outlive the nodes, we should delete the edge before deleting any of its nodes.
• A HandShake should only exist while the two Hands exist.

This pointer, which shouldn't outlive what it's pointing to, may seem oddly familiar to many of us: SQL has them! 10

In SQL, a foreign key constraint is a reference that cannot outlive the object (otherwise, it aborts the current transaction).

For that reason, we call this kind of pointer a constraint reference. 11

We've used constraint references in C++! 12 We simply:

• Wrapped shared_ptr in a class called owning_ptr which uses move semantics like unique_ptr and, when destroyed, checks the ref count to assert 13 that it's the last pointer to the object.
• Made another wrapper around shared_ptr called constraint_ptr.
• In release mode, compiled owning_ptr to a unique_ptr, and compiled constraint_ptr to a raw pointer.

We fell in love with the approach instantly:

• It was memory safe! We never had a use-after-free once we switched to constraint references.
• It was conservative! In development mode, we couldn't even make pointers dangle, much less dereference them. It caught risky behavior much earlier and made it extremely unlikely to have unsafe behavior in release mode.
• It was zero-cost! They compiled to a unique_ptr and raw pointers, so there was no extra overhead in release mode.
• It was easy! We could alias 14 with freedom, and most of our pointers didn't outlive what they were pointing to anyway, so there was no learning curve to struggle against!

With raw pointers, if someone deletes the object your raw pointer is pointing to, you won't see the problem until much later, when you try and dereference it. Constraint refs answer the question "who destroyed that object I'm pointing to?" much sooner; 15 we get a nice debugger pause or stack trace when someone accidentally frees what we're pointing at.

To summarize, we can get speed and memory safety with ease by, when developing and testing, making the program halt when we free an object that any constraint reference is pointing at.

Constraint Behavior Modes

Assist Mode is used in development and testing, where we halt the program when we accidentally free an object that a constraint reference is pointing at.

Fast Mode is used for release, and compiles the references down to raw pointers.

If someone prefers absolute safety, then they could use Resilient Mode for release, where we compile constraint_ptr to use a weak_ptr internally, and it will halt the program when we try to dereference a freed object instead. This is similar to running a program with Valgrind or ASan.

Unfortunately, C++'s shared_ptr and weak_ptr use atomic ref-counting under the hood, which would make these new constraint references very slow.

Luckily, Vale's region isolation allows Assist Mode and Resilient Mode to use non-atomic ref counting, which is much faster. 16 17

Fast Mode could be useful for high performance computing like games, and areas where we have other measures for safety, like webassembly or other sandboxes. Vale's Resilient Mode is still incredibly fast and has zero unsafety, which would make it perfect for use in servers and apps.

Emerging Patterns

We coded in this style for years, to see how far constraint refs could go. Whenever we reached for shared_ptr, we stopped, and pondered if there was a way to solve the problem with single ownership.

We suddenly started discovering certain recurring patterns, like nuggets of gold, deep in the mines.

Clasp

class INetworkCallback {
public:
  virtual void handleResponse(
    const std::string& resp) = 0;
  virtual ~INetworkCallback() = default;
};
class Network {
public:
  void request(
    const std::string& url,
    INetworkCallback* callback)
  { ... }
};

interface INetworkCallback {
  func handleResponse(&this, resp Str);
  func drop(this);
}
struct Network {
  func request(
    &this, 19
    url Str,
    callback &!INetworkCallback)
  { ... }
}

Instead, we made two tiny classes, Request and RequestHandle.

Each had only a pointer to the other. Thing owned one, Network owned the other.

When one was destroyed, it would reach into the other to null out the pointer, thus severing the connection.

This pattern of having two mutual constraint references was so common that we gave it a name: the clasp pattern. It obviated a vast swath of our shared_ptr usage.

We iterated on it, simplified it, and even made a one-to-many version, which was so useful that we promoted it to its own reference type, the weak reference.

Weak Reference

Sometimes, we want a pointer to outlive what it points to.

For example, a missile launched by a spaceship should keep flying, even if its targeted asteroid disappears.

We can use a weak reference for this. 20

Note that this is very different from C++'s weak_ptr:

• When you lock a weak_ptr, you get a shared_ptr which will delay destruction and extend the lifetime of the object if the other shared_ptrs disappear.
• When you lock a weak reference, you get a constraint reference, which will halt the program if the owning reference disappears.

Simplification

In our quest, single ownership unexpectedly solved a major recurring problem.

We previously had a system where a shared_ptr'd object's destructor would remove it from the display when the last reference to it disappeared. This was a terrible thing; Every month, there would be a fresh bug saying "I hit the delete button, but the thing is still in the view!" and it'd take forever to figure out "who is keeping my object alive?" 21

The ironic part was that we knew who the owner should be. We knew the exact line that should have had the last reference... 22 but apparently, it wasn't. Somewhere, another reference was preventing the destructor call.

This problem evaporated, because constriant references would notify us of the problem much earlier. 23

Surprise!

We were new to this way of thinking, so we expected that maybe a quarter of our references could become constraint refs. We were shocked when we were able to get rid of every single raw pointer and shared_ptr, and make it into either a constraint ref, or occasionally a weak ref. 24

We didn't know it at the time, but we had found the key to unlock the next steps for RAII. Below, we explain how Vale and a hypothetical C++++ could harness this new freedom.

Language Implications

Destructor Parameters!

Unexpectedly, getting rid of shared ownership made destructor parameters possible!

Let's back up a step and talk about shared_ptr. Anyone who has a shared_ptr<X> might be the unlucky one to call Xs destructor. This is why destructors don't have parameters: every time you let go of a shared_ptr, you would have to somehow obtain the right arguments to pass them in to the destructor, somehow. 25 Owning and constraint references are different: you know exactly who should be calling the destructor.

There were other reasons C++ couldn't have destructor parameters, but they all have easy solutions from a language design standpoint:

• Exceptions: We need to call an object's destructor automatically when an exception is in flight, where do we get the parameters for that?
• We don't use exceptions anyway! In fact, entire companies' style guides prohibit them. Use Result instead. 26
• If we implicitly call the destructor at the end of a block, how do we know what parameters to pass in?
• If the destructor requires parameters, don't implicitly call it, and require us to explicitly call its destructor! 27 28
• If we have a vector<MyObj>, how would ~vector() know what to pass into ~MyObj()?
• Destructors can have parameters now, so pass a "consumer" functor std::function<void(std::unique_ptr<MyObj>)>) (or fn(MyObj)Void), and the vector could give each element to it to destroy.

Destructor Overloads

Destructor Returns

class Transaction {
public:
  ReadResult read(ReadQuery query);

  virtual void ~commit() { ... }

  virtual RollbackStatus ~rollback(
      RollMode mode) {
    ...;
    return SUCCESS;
  }
};

As you use this kind of improved RAII more, you start to see opportunities for it everywhere.

Imagine if std::thread's destructor could return the result of a thread's calculation!

Imagine a std::function-like class where its destructor called the underlying lambda and destroyed this at the same time, thus guaranteeing it could only be called once. The possibilities are endless!

Recently, C++17 added the nodiscard attribute, which was useful for functions like Result<ImportantResult, ImportantError> doSomethingImportant();, to prevent the user from ignoring the Result.

C++ wouldn't have needed a special attribute if it had this kind of improved RAII: Simply don't provide a default destructor, and provide other destructors, with return values:

• ImportantResult ~getResult();
• ImportantError ~getError();
• void ~printResult();

Non-destroying Destructors

We might want to return a object to a free-list, instead of free()ing it.

Normally, we would need to use an allocator. But instead, we could take in the free-list as a parameter, and move this into it.

This is impossible in C++'s syntax (we don't get to move this), 32 so we'll use Vale syntax:

struct Transaction {
  func read(&!this, query ReadQuery) ReadResult { ... }

  func commit(this, list &TransactionList) {
    ...
    list.reclaim(this); // move this into a different function
  }

  func rollback(this, list &TransactionList, mode RollMode) RollbackStatus {
    ...
    list.reclaim(this); // move this into a different function
    return SUCCESS;
  }
}

What even is a destructor?

By now you've noticed that Destructors can have overloads, take parameters, return values, and even decline to destroy this! There's hardly anything that separates them from regular functions.

In fact, in Vale, the whole "destructor" side of the language is built from one small rule:

In one fell swoop, by removing our dependence on shared_ptr, we had taken one of the thorniest corners of C++ and completely simplified it away.

RAII: Past, Present, Future

Using constraint references, we unleashed the power of single ownership and found the next steps for RAII:

• Multiple destructors: Mark errors handled in different ways, rollback or commit a transaction, end things how you want!
• Destructor parameters: Resolve or reject futures with certain values, set a priority for a close operation, you name it!
• Destructor return values: Return error status, return the result of a thread's calculation, whatever you need!
• Non-destroying destructors: Reuse objects, give out ownership without risking freeing, sky's the limit!

With C++'s existing RAII, destructors can do very little. With improved RAII, an object can offer multiple options for destructors, each with return values and parameters.

Someday, we might be able to add these features to C++, but before that can happen, we need to show the world that single ownership is powerful, and we don't need shared ownership as much as we thought.

We made Vale for exactly that reason. It's still in alpha, so if you want to help bring improved RAII into the world, come by the r/Vale subreddit or the Vale discord! 33

This isn't even the end of the single ownership saga! In the coming weeks, we'll explain how this consistent single ownership approach enables other unique capabilities in Vale, such as cross-compilation, the region borrow checker, and lightning fast memory management.

Until then, we want to hear from you! We'd love to hear your thoughts on single ownership, RAII, Vale, and any ideas you have! Come share your thoughts in the Reddit posts, the Hacker News post, and come join the r/Vale subreddit subreddit and the Vale discord!