Caterpillar

Having region-based memory management, and providing different kinds of regions with different memory management strategies, would require having different types of handles for referring into these regions. This implies that we're going to need higher-kinded types to deal with those types.

At least that's what I thought. My original plan for today was to explain higher-kinded types and why they're needed. But all I've managed to do is to confuse myself instead.

I started with this motivating example in Rust:

struct Person<H: Handle> {
    name: String,
    parents: [H; 2],
}

A person that refers to its parents using some kind of handle. It doesn't care where its parents are stored, meaning it also doesn't care what kind of handle it's using. So it accepts a type parameter H to represent the handle. It only expects that H conforms to a Handle trait (not shown here), that provides some way to access the data it refers to.

But this isn't type-safe. The parents would also be Persons, but we don't encode that requirement anywhere. My plan was to use this as a starting point and show how this could be solved with higher-kinded types.

Except, I can write this:

struct Person<H: Handle<Person<H>>> {
    name: String,
    parents: [H; 2],
}

trait Handle<T> {
    fn get(&self) -> &T;
}

Which is just regular Rust. And by all accounts, Rust doesn't have higher-kinded types.

And now I'm confused about what this is, and why it's not a higher-kinded type, and what exactly higher-kinded types actually are, and whether I have any business working on a programming language. (Probably a firm "no" on that last one, but who cares.)

I'm taking this as a sign to take a step back and think about something else for a bit. By the time I get to this part of the language (which likely is a long way off), I might have a better understanding. And even if not, it's important to remember that the goal isn't to implement higher-kinded types. The goal is to make memory management work in the way I need it to.