Capture Checking in Scala

Summary

Hands on Capture CheckingThe full code for this article can be viewed here.IntroductionI gave a live coding session on capture checking at Scala Days 2025. Let’s be honest: it was essentially a failure, mostly because I have very little live coding experience and woefully underestimated how long it’d take to go through the material. I was stopped maybe 10% in, much to my annoyance and that of Martin Odersky, who’d kindly agreed to be there and help with the questions I was likely to get. This article is a form of apology for my failure: at least the material is available somewhere!The rest of this introduction is how the whole talk came about, because I find it entertaining, but it’s also mostly irrelevant to the actual content of the article. If you’re interested in capture checking more than my life - why would you be?! - you should probably skip to the technical bits.I never really intended to give a talk on capture checking - or even study it, to be honest. Not for a long while, at least. Capture checking is still actively being worked on, and I hate aiming at a moving target, struggling to understand a concept just to find out it’s outdated by the time I’m done.But then I noticed something which captured (wink, nudge) my interest: whenever Martin would go on stage to talk about capabilities and how they will allow us to use a direct style of programming without losing any of the nice properties afforded us by continuation passing style or monadic style, he would invariably say something along the lines of and of course for all this to work reliably we’ll need capture checking, but that’s really a detail. That’s really a detail. I’ve used that exact phrasing many times, and it was always either a grand act of self delusion, or me attempting to convince some manager to approve a project they really shouldn’t approve. It was interesting to hear Martin use these words.So I decided to try and see if I could understand what the fuss was all about. To give some contex...