Automatic Requirement Satisfaction in plain Swift

[dabrahams (Dave Abrahams)]

@Joe_Groff

Instead of thinking about things in terms of type system vs. compile-time evaluation, I think we should think about how these two mechanisms can work together and strengthen each other.

I would love to hear your ideas about that!

I think you'd agree that one of the most frustrating things about C++'s evolution is how the different strands of template metaprogramming and constexpr have never quite managed to dovetail.

Actually I had to stop programming in C++—and, with gratitude, also got to stop worrying about its evolution—when I joined the Swift project in 2013. IIUC that was fairly early in the evolution of constexpr and all kinds of new TMP stuff has happened since, so I guess I never had the privilege of being frustrated by that problm. But I can imagine what it must be like for you

I think we're in a good position to do better than that in Swift, since the generics system already has a compile-time/runtime duality, and compile-time evaluation gives us opportunities to give the rest of the language that same power to span compile time and runtime.

As far as I know, the rest of the language already has that power, at least in principle. There's no law in the non-existent language specification that prevents the compiler from deducing whatever it wants about what runtime code will do, and I/O aside, moving that computation to compile-time where possible.

But I'm really not focused on when computation happens. Nothing being proposed here—other than optimizability—depends on being able to do more at compile time than the type system already does in a debug build. We don't have a problem with crossing that boundary. There's a boundary with the type system that's more of a problem: once computation leaves the type system, you can't fully get it back in. We can construct different types depending on computation outside the type system (example), but you can never use computation outside the type system to decide which of these types will be bound to a typealias or associatedtype.

When trying to address the problem of metadata bloat, one approach we considered aside from scoped conformances was to think about ways a programmer could demand that certain things happen at compile-time. We decided not to propose those approaches because they clash with Swift's non-monomorphizable model, and so can't be composed with regular Swift code. The lesson for me in that is that it may be a red herring to focus on the compile-time/run-time distinction.

Getting to the matter at hand here, I'm concerned that we're growing a lot of different reflection-ish interfaces in different directions. What I'd like to figure out is what the best foundational interface for exploring type structures, and constructing new ones, would look like. I think it should be possible to have a mechanism that can use compile-time information when available, but also fall back to runtime reflection when spanning ABI boundaries (or just when opting out of specialization for any other reason).

Doesn't what's being proposed here achieve exactly that? It works just fine with code composed across resilience boundaries.

I also think that that will be necessary for success, because Swift's type system is never really fully "static" in the way C++'s is, once you have dynamic reflection or multiple ABI-independent libraries in play.

You don't need anything nearly that esoteric for the problem to arise; the example I pointed at above is enough. It's why decided not to pursue “compile-time features:” the inability to monomorphize generics in the general case affects the type system pervasively.