Rewrite the Swift compiler in Swift: This would be a lot of fun someday, but (unless you include rewriting all of LLVM) requires the ability to import C++ APIs into Swift. Additionally, there are lots of higher priority ways to make Swift better.
Well, there is a C API for LLVM. And there are several wrappers for that API, like LLVMSwift.
So, are we getting closer to possibly self-host? (There has been another thread on this, long ago.) It does depend if the C API is (significantly) behind the primary C++ API.
Just concerned that reading up on Swift have atrophied my C++ skills (missing what's different
with C++14, let alone what's going on with C++17 and 2x). It may be easier to implement my ideas myself (like strong type-aliases, sum tuples, or scoped-storage arrays with compile-time extents) if Swift was written in Swift.
I think it'd be an interesting project for sure. But that is a pretty big undertaking that not many people are really wanting to invest time and (possibly money) in. The only way I could (maybe) see that getting traction is if a group of developers band together to bang out the implementation themselves rather than an Apple-team lead rewrite, which I doubt is on any roadmap.
That being said, I would totally lend some of my spare time to help! I agree that a Swift compiler written in Swift would greatly increase the willingness to contribute. I don't have any statistics, but my gut tells me a lot of people who know Swift very well, and want to contribute, find C++ as a pretty big barrier to contribution. (It was for me, and still is to some extent, I'm still learning!)
I really doubt this, my gut tells me the venn diagram of people who are into Swift and people who know C++ is pretty close to a perfect circle given how common C++ is in schools and how similar the two languages are (in terms of the target audience). I think the main barrier is language theory and compiler knowledge (eg “wtf is a generalized existential”)
I agree. Regardless of the number of people who find C++ a barrier, the language and compiler knowledge barrier is certainly there. And it's something that even people with Swift knowledge would need. Although to some extent rewriting the compiler in Swift would be helped by the fact we already have an existing compiler to glean knowledge from. I'm not saying we should directly translate the existing compiler and all the C++isms, but the concepts encoded could still be translated without a master's in compiler theory.
this is probably true (and from what i’ve heard from swift team devs) the compiler has a lot of technical debt that could be ironed out with enough effort but without too much domain knowledge. i doubt it would pull in more contributors capable of implementing those stubborn SE pitches we keep asking for though
Right, I'm not advocating we really do this rewrite (now at least). We have a working compiler now, and a fine group of contributors happily donating their time and resources to make Swift better. I don't see much benefit in a self hosting compiler other than it's a neat idea for a project.
tbh if someone has the time for this i would much rather they spend it implementing variadic generics or contiguous tuples than rewriting a working compiler in another language.
Well, LLVM is a really amazing platform. It is a giant on which to stand. Not using it on the official compiler would require a really compelling alternative.
I've asked some of the compiler devs (I think mainly @codafi) and it seems that rewriting LLVM would be a lot of redundant work: it has tons of people-hours invested in it.
What the "Swift-related" part of the whole compiler is, is the Frontend. If we could rewrite the Frontend in Swift, that'd be amazing. Even for an alternative compiler. For that, we need a good wrapper API that allows us to interact with the LLVM pieces. The LLVMSwift project is getting a good amount of work on it, and the silt-lang project is a proof of how far can you go with just that API. The frontend of that compiler is entirely written in Swift, and that's something that maybe some day Swift itself could get.
i definitely think it’s doable i just don’t think it’s worth it the opportunity cost. the compiler is fine. we have like 15 blocked proposals that everyone wants but no one has the time or expertise to implement and that’s the bigger problem
And tons of technical debt in the compiler (compiling speed, performance inconsistencies and tons of hacks and quirks), the package manager (test discovery support w/o ObjC runtime) and Foundation (NSUnimplemented APIs)
I know @Chris_Lattner3 likes to talk about this, but I consider it basically uninteresting except as a proof that Swift has achieved pretty good C++ interop, which I think there are probably better ways to demonstrate.
I think that's an idealised view, for several reasons:
not everyone has done a (complete) CS degree, and not every CS degree will involve C++ (I personally did some CS classes as part of my math degree, but none of them involved C++)
even if someone did touch C++ in school, that doesn't mean they were/are comfortable with it
even if someone was comfortable with it in school/when they last used it, that could be many years ago, and
C++ is a moving standard: the original C++ is quite different to the modern iterations, from C++11 onward, and LLVM/Clang/Swift use the latter fairly heavily
I agree with the original post that C++ is a fairly large filter for contributions to the compiler. However, any language self-hosting comes with downsides, and I think there's even more downsides for Swift in particular, such as:
it requires careful infrastructure and thought for providing pre-built compilers to start the bootstrap
language changes get more fiddly, if they affect aspects that the compiler is using (this is less of a concern as Swift gets more stable, but still something to think about)
the double (or triple) compile of the compiler means full builds are much slower and only the first of those builds can be incremental
Swift is more intimately tied to the LLVM and Clang C++ codebases than most compilers (in particular, it's slightly unusual because it uses clang-as-a-library directly for C/Objective-C interop), and interfacing with C++ (especially that with heavy template use) is hard from any language other than C++ itself
even ignoring those consequences of self-hosting, there's ~550kloc of C++ (summing the "C++" and "C/C++ header" parts of the output of cloc) in the current Swift compiler, and a rewrite of that much code is a sizeable effort
(Don't get me wrong: there's also upsides beyond just the contribution thing. Swift would be a much nicer language to be writing day-to-day, e.g. swiftc has way too many manual enum-with-payloads.)
Hrm? MHO is that we shouldn't do this until we have C++ interop. I also don't see why people are so afraid of C++ interop, it should be done progressively one step at a time. It isn't "all or nothing".
I totally agree that we should get started on C++ interop; there's a lot of useful low-hanging-fruit there. I just don't think we should talk about rewriting the compiler in Swift as something that's on the roadmap, because it really isn't.
Speaking only for myself, but I had exactly one class in University that used C++, and that was at least 20 years ago. I am not comfortable with it, and it's a huge barrier to me because I don't have the energy to concentrate on it.
tl;dr: I agree that C++ itself is a barrier to would-be contributors.
I think we could get a good chunk of the benefits of a full rewrite at a tiny fraction of the cost if we built a way to write compiler plugins in Swift. These would run as part of the frontend and manipulate the AST, which we're already trying to expose to Swift through the SwiftSyntax module. The key things I'd like plugins to do include:
Synthesizing conformances—the Sema/DerivedConformance*.cpp files are a couple thousand lines of unsafe, non-essential, probably-non-performance-critical code.
Parsing files and generating declarations based on them—imagine if you could put a .storyboard file in your compiler invocation and it would extend each view controller with enums of all the segue identifiers, etc. they used.
Doc comment handling
Migrators
Nonessential warnings and linting
Possibly IDE support
Basically, anything that isn't used to compile the standard library could be written in Swift, making it accessible to more of the community and probably making it less crash-prone.
I'd like to offer my €0.02 here, as someone who teaches higher education.
I can of course only speak for my school/region/country, but we are the biggest provider of CS graduates in the country, so I think this does have some weight.
I teach a Bachelor of Applied Computer Science curriculum at the college level. There is zero mention of C or C++ in this curriculum (nor has there been for quite some time) as we focus on Java, .NET, web and mobile development.
In the Bachelor/Master of Computer Science curriculum at our associated university, there is one course that covers C and C++. When I took this course, the focus was mainly on C, as subsequent courses on computer architecture, operating systems and compilers only used C. In the 4 years I spent at university, I think I spent only about 2 weeks learning and using C++.
In my country (again, I can't speak for others), most schools use either Java, C# or Python as the primary (first) programming language. C++ generally isn't taught any more in computer science. It does still have a strong presence in certain fields, such as engineering and game development, but even those are looking for alternatives.
So in my opinion, self-hosting is something that should be done at some point in the future, as it will become increasingly harder to find contributors to a C/C++ project. However, I don't consider this a high priority item. For education, Windows support is by far the highest priority item (it's basically a blocking issue).
It's the same here. In my university they don't do C++ at all anymore. It's C for a couple of system-level courses, and the rest is Python, Java, Ruby, JS...
And I'm planning on replacing what's doable in C++ with Rust
