The Capture Checking Experiment Gets a Little More Real

Another month, another cool experiment.

For some time now, Martin et al have been putting a bunch of effort into a new concept called “capture checking” — basically, a flexible compiler distinction between “pure” and “impure” code, allowing you to formally describe the side-effects that a function is allowed to have.

The high concept (as I understand it: I am very much just an onlooker here) is that any given body of code has access to some number of “capabilities”: things that this code can do that aren’t simply part of the usual input-parameters to output-results. If the capture-checker is turned on, you can write code in such a way that the compiler will actually check your work, and not allow you to cheat. (Either intentionally or by accident.)

There are two new key bits of syntax:

• An alternate function-signature arrow -> that means “this function is pure, except as stated otherwise”.
• A new usage of curly braces, letting you describe those “stated otherwise” exceptions: the capabilities that this function has access to.

This is all quite neat, because modern Scala idiom has increasingly been favoring pure functional-style code, with all side-effects captured, but so far it depends on programmers not cheating and not making mistakes. These new mechanisms seem like they should allow us to evolve to a place where the compiler is actually enforcing FP style, and that should result in more correct and maintainable code. (And better error messages when you do something wrong.)

For more details, see the Dotty Docs, which get pretty deeply into what’s going on here.

Mind, none of this is going to happen overnight. This is all wildly experimental at this point, hidden behind a compiler flag, and I suspect it will take at least a number of months (likely a couple of years) before it is ready to become part of the language for real. And making effective use of it will probably require significant adjustments to code, so it is likely to be more useful for new projects than legacy ones. But we have to start somewhere, and I’m quite excited by the possibilities.

This will be coming in Scala 3.2.1, and is in the current release candidate.