Self-hosting Swift?

That's a very cool idea. Something like that could be our version of the C preprocessor/macro system, and also solve the LinuxMain issue.

If the plugins are written in Swift, you could also more easily imagine them being bundled with SwiftPM packages.


Okay maybe C++ isn’t as common as I thought, but if you look at the SO dev survey, C++ basically is the most widely used mid-level language in the world. Since no one writes compilers in javascript it makes sense when starting a new project, to start it in C++. Interestingly, Swift has since become the 2nd most popular mid-level language (if we consider C low-level), and of course the Swift community is going to have an above-average number of Swift programmers, so maybe porting the codebase to Swift could increase its accessibility. I still think the effort needed could be better spent on other features and fixing existing architectural issues though.

1 Like

Have you seen @Joe_Groff’s reflection talk? He laid out a compelling case for using variadic generics to write reflective implementations of protocol requirements as ordinary generic code rather than using code generation.

Totally agree with your general point, though. The lack of reflection or code generation support (and the high amount of boilerplate as a result) is probably my single biggest gripe with Swift at the moment. I think if it were possible to do the things you mentioned in user-level code (whether through compiler extensions, new generics features, macros or all of the above), most people wouldn’t care that the compiler isn’t written in a language they know, because most of the “language features” they really want could just be implemented as libraries.


Those skills may not necessarily be transferrable.

And maybe the team to implement variadic generics and/or contiguous needs to work in Swift for the code generation first. :wink:

Yeah, I'm not that crazy (yet).

I was thinking of completely punting on C++ interop here, by using the C-level interfacing libraries for LLVM (and Clang too, if we need that).

Self-hosting, like kernel mode, bare metal/no-std-lib, and scripting, has a lot of tricky requirements that no one working on Swift is even thinking about addressing right now. It would involve writing several Swift compilers: A phase 1 compiler written in some other language that compiles the phase 2 compiler, progressively adding more features until your phase 3-5 compiler can compile the current compiler. You can see Rust's bootstrapping support for a reasonable example on how this can be done.

It seems clear we need ABI stability, concurrency, 1st class reflection, and completion of the Generics Manifesto before we should worry about self-hosting.

@John_McCall Self-hosting has benefits, not the least of which is the core team would spend more time writing Swift code and I might finally get my generalized existentials :rofl: But if you asked me, should we spend time on self-hosting or reviving property behaviors I know which one I'd get more use out of.


i remember that Russ Cox of Golang team said something like this:

if i can’t write Go compiler in Go, i’d have quit long time ago


My understanding is that the Swift compiler depends on a lot more of Clang and LLVM than is exposed through the C bindings.

1 Like

One item I think is a prerequisite for a self-hosting swift compiler that I think is both useful on it's own and probably achievable by at most Swift 6, and something I would like to try participating in, is creating a Swift library for the (ABI locked) Swift runtime structures.

Since libllvm and libclang are supposed the way for non-C++ clients to access LLVM and Clang, any exposure deficiencies should be considered bugs (unless C++-interop is supposed to be more equal than others).