This summer, I participated in the inaugural Swift Mentorship with @hborla as my mentor, and together we worked on Compiler Development and Language Design. Here’s what I learned and accomplished during this amazing opportunity!
During the first half of the mentorship, we studied a series of previously accepted Swift Evolution proposals so that I could better understand technical terms of art and concepts in the proposals that I found to be murky or entirely new, and were thwarting my own ability to understand the motivations and benefits of these language changes. In the latter half, I began working on the Swift compiler to better understand the code that builds some of these language change proposals. So far, I have fixed a property wrapper bug, am currently working on the implementation to allow defer initialization for property wrappers with multiple arguments, and have joined two welcoming veteran co-authors on a new pitch to further streamline property wrapper initialization.
To date in my iOS career, I had used the developer forums and TSPL guide as a reference but only learned of the Swift Evolution process after I joined the Swift forums upon the announcement of Diversity in Swift. My understanding of the Swift compiler at this point could have been summed up as "something that builds Swift...somehow." Then the Diversity in Swift panel at the Community.o Summit event introduced me to LLVM and piqued my curiosity when I discovered more women engineers doing interesting work with various compilers and toolchains. At this point, I started reading more Swift forum posts and even attempted to build the Swift toolchain before running into build issues, but felt out of my depth in doing both. So when the Swift mentorship was announced, I jumped at the chance to work on language design and compiler development with a mentor.
Holly has been an incredibly generous and supportive mentor during this time and with her direction, I have been able to take a wandering interest and turn it into actionable contributions to Swift. I was able to start from the drawing board with concepts like initialization, type checking, overloads in context, coercions vs dynamic casts, and more because she created a welcoming and constructive environment. I can’t thank her enough for getting me this far! Over the last few months, I've covered significant ground and discovered how much more there is to learn. Here are a few reflections on the compiler and language design.
On the Compiler
The Swift compiler is massive. This is definitely not a small/medium codebase that you can quickly familiarize yourself with while staying abreast of every new addition. While it's possible to understand top-level compiler terminology like Decls or Requests or how these build Swift types and typecheck their values, compilers have multiple parts (or ends), and it’s possible to spend your entire career working on just one part or end. And as someone who initially found the Swift compiler daunting in complexity and size, this realization helped me stay grounded while working with the codebase.
And like any massive codebase, there is no better way to get to know it than to step through the actual code. I spent quite a bit of time reading about compiler infrastructure like the Type Checker or Request Evaluators, but a lot of it did not make any sense until I started poking around and breaking code in the constraint system. While there is plenty that I still do not fully grasp, I have no doubt that more of it will fall into place as I continue to walk about the code with future contributions.
On Language Design
Language design is an acquired skill. At first glance, it would seem like you need to know multiple programming languages, have formal computer science education, and past experience in language design to do this kind of work. While these are all undoubtedly handy qualifications to have for major language changes, there is also opportunity to participate in language design at a lower, more accessible level. After all, language design work iterates and improves upon a language that we are all writing regularly. Sharing points of frustration with an existing Swift type on the Swift forum can lead to language design proposals that are easier to understand, simpler in their scope and a much friendlier place to start.
That being said, language design also requires a deeper understanding of Swift Evolution so far. It's entirely possible to write Swift without getting too deep into the whys of the language. For example, as an iOS engineer, I'm typically more concerned about making sure my code works and my additions to work projects are nonbreaking and valuable. Prior to this mentorship, I had written property wrappers but had not considered every single way a property wrapper can be initialized or why synthesized storage should be an implementation detail vs API (or what that difference even meant). But better understanding these finer points gives me the background needed to get ahead of that particular language concept so that I can start thinking about how to change it to make it more user-friendly or efficient. I will admit that I still find language design to be challenging, but it is a compelling and "thinky" challenge.
What’s Next?
This has been an extraordinary experience for me as an iOS engineer who is interested in compilers but was unsure how to get started in this work. Thank you to the Diversity in Swift team for creating this opportunity! I look forward to building on everything I’ve learned so far and finding more ways to contribute to the Swift compiler in the coming months.