What does a generic T actually mean?

The implications of ‘static

T: ‘static is some T that can be safely held indefinitely long, including up until the end of the program. T: ‘static includes all &’static T however it also includes all owned types, like String, Vec, etc. The owner of some data is guaranteed that data will never get invalidated as long as the owner holds onto it, therefore the owner can safely hold onto the data indefinitely long, including up until the end of the program. T: ‘static should be read as “T can live at least as long as a ‘static lifetime” not “T has a ‘static lifetime”.

T: ‘a vs &’a T

Eliding Lifetimes

A type is send if and only if it’s safe to send across threads. Most types are send - the only types that break this inference are types that make assunptions on how they’re used.

Sync

A type T is sync if and only if &T is Send. Everything but the interior mutatbility types and RC are Sync.

The special case of RC

RC is a particular type that makes strong assumptions on being single threaded. It leverages an innerstate and a counter to mantain how many references exist. Once the last reference is dropped, the entire type is dropped.

impl<T> !Send for RC<T>
impl<T> !Sync for RC<T>

Arc

Arc is the primary way to share immutable pointers across threads, and implementation wise, it’s almost entirely the same as RC. However, since we’re in a multithreaded context, we must have the reference counter be atomic, thus the name Atomic Reference Counter.

Arc is interesting since we need it to be both Sync and Send. Sync is for the obvious reasons of being the primary method of sharing references across threads. Send, however, is necessary because we need drop permissions on the inner object.

impl<T: Send + Sync> Send for Arc<T>
impl<T: Send + Sync> Sync for Arc<T>

Interior Mutability Types

These types allow mutable access to occur with only an immutable reference. Yet again, what we’re seeing here is a single threaded assumption on the usage for these types. And it makes complete sense! Afterall, we want to avoid data races entirely. In order to achieve this though, the following strict assumptions are made:

1. The T in the Interior Mutability type is never used outside once it’s placed in the Cell itself. Indeed, we see the enforcement of this by the Interior Mutability type taking ownership of the passed in T:

pub const fn new(value: T) -> Cell<T>

1. Interior Mutability types are not sync. Afterall, all it takes is one immutable pointer to mutate the inner type and we can’t have that happening.

impl<T: Send> Send for Cell<T>
impl<T> !Sync for Cell<T>

Mutex

At this point, there’s an important distinction be drawn between a Mutex and Mutex Guard. A Mutex is the type that encaplsulates thread safety primitives and provides methods on getting a lock safely. The only way to get the Guard is to call the lock function (this is an instance of a super useful pattern called typestate! It’s another topic I’ll be covering in a future post).

The actual thread safety trait bounds of a mutex are dictated entirely by if the inner type T is Send. The reason for the send bound is fairly obvious from the above passage but why is the Mutex not requiring T to be Sync? Afterall, it sounds counterintuitive considering that we can create any number of immutable pointers but still mutate the underlying item! This again ties back to the fact that access to the innter type first requires a lock to be taken. This means that a mutex is inherintly single threaded! Using this assumption we can safely drop the Sync requirement for a Mutex.

impl<T: Send> Send for Mutex<T>
impl<T: Send> Sync for Mutex<T>

Mutex Guard

MutexGuard is not Send because it explicitly requires the thread that took the lock to drop it on certain OS. However, the guard itself can be shared via sync since an immutable pointer cannot be used to drop or mutate it’s interior structure.

impl<T> !Send for MutexGuard<T>
impl<T: Sync> Sync for MutexGuard<T>

Jon Gjengset did an indepth stream about lifetimes and did a deep dive on StrSplit, a C Library that takes a string and a delimeter and splits the passed in string at the first occurrence. StrSplit also mutates the input in the process, which also turns out to be especially important.

The port of the code that I wrote up while going through his stream can be found in my rust-playground repo. The rest of this post will go over the issues that were discussed and how variance played a big role at guranteeing safety.

What is a lifetime?

Defining Lifetimes

Generic Lifetimes

struct StrSplit<'a> {
    remainder: &'a str,
    delimeter: &'a str
}

impl<'a> StrSplit<'a> {
    ...
}

<’_> Lifetime

Variance

I’ll be making a future post on variance going over yet another port of a C library but briefly variance consists of the following types:

• Covariance
• CounterVariance
• Invariance

The Rustonomican does a fantastic job going over the definitions and I highly recommend reviewing that.

A brief summary of this can be found here:

Multiple Lifetimes!

struct StrSplit<'a, 'b> {
    remainder: &'a str,
    delimeter: &'b str
}

impl<'a, 'b> StrSplit<'a, 'b> {
    ...
}