This post is a continuation of my posts discussing the topic of associated type constructors (ATC) and higher-kinded types (HKT): The first post focused on introducing the basic idea of ATC, as well as introducing some background material. The second post showed how we can use ATC to model HKT, via the “family” pattern. The third post did some exploration into what it would mean to support HKT directly in the language, instead of modeling them via the family pattern.

This post is a continuation of my posts discussing the topic of associated type constructors (ATC) and higher-kinded types (HKT): The first post focused on introducing the basic idea of ATC, as well as introducing some background material. The second post showed how we can use ATC to model HKT, via the “family” pattern. This post dives into what it would mean to support HKT directly in the language, instead of modeling them via the family pattern.

Hello. This post is a continuation of my posts discussing the topic of associated type constructors (ATC) and higher-kinded types (HKT): The first post focused on introducing the basic idea of ATC, as well as introducing some background material. This post talks about some apparent limitations of associated type constructors, and shows how we can overcome them by making use of a design pattern that I call “family traits”. Along the way, we introduce the term higher-kinded type for the first time, and show (informally) that family traits are equally general.

So for the end of last week, I was at Rust Belt Rust. This was awesome. And not only because the speakers and attendees at Rust Belt Rust were awesome, though they were. But also because it gave aturon, withoutboats, and I a chance to talk over a lot of stuff in person. We covered a lot of territory and so I wanted to do a series of blog posts trying to write down some of the things we were thinking so as to get other people’s input.