@Abhik1998 existing proposals are listed and linked to in the first post here.
There's an idea I'd personally love to tackle, and I'm curious if I could find a mentor for it here.
I would want to improve the documentation of several lower-level and runtime features. Many things are fairly opaque to language users now, but they quite affect the performance and/or semantics of the language and are important to learn. Currently, however, the best way to learn about them is to either read the compiler documentation or inspect the SIL output, which are both fairly inaccessible or (in case of compiler docs) might be outdated. In particular, here are the topics that often make the wider community confused:
- existential containers and why they don't work for protocols with
Selfor associated types;
- stack vs. heap allocation of value types — it is believed by many that "structs are allocated on the stack", which is generally not true;
- overload resolution and dynamic dispatch of default implementations on protocols vs. implementing types;
- capture by-value vs. capture by-reference in closures;
- type layout;
- runtime behaviour of weak/unowned references;
- runtime type metadata generation;
- runtime behaviour of generic functions and various thunks
— and possibly other topics. Some of these features might be intentionally opaque, but given the ABI stability a lot of this stuff is very unlikely to change, while still being important to be aware of to write performant code. Especially that Swift positions itself as a good first programming language, I believe it is important that the documentation provides educational value by unveiling the inner workings of the features users sometimes might take for granted.
Please let me know what you think!
I like this idea! I think it would better to post it in swift.org, not buried deep in the github repository with other unrelated documents.
Yep, that would be ideal. I could imagine this being a whole separate section alongside the language guide and the language reference, titled something like "language internals" — basically, a full overview of the runtime. However, since the community does not control the website, I cannot really propose this as a modification to swift.org itself; most likely the outcome will be just a stack of markdown files that will get incorporated into the website if the maintainers are satisfied with the result.
To perhaps facilitate finding a mentor interested in helping me in that endeavour, I wrote a more formal draft.
Hmm... thanks for the writeup, @wtedst. I don’t mean to let you down, but have to be honest that I (personally) don’t think that this is a good summer of code project.
Documenting such internals requires a lot of knowledge about them and it does not really feel like a right kind of task for someone to “learn and document as they go”, i.e. a student during the summer of code. It would have to very heavily rely on the mentor providing much of the information I feel, making the project somewhat less of an independent project of the student which they are intended to be.
The outcome of a project also should be pretty tangible and well defined. With such documentation tasks it is hard to do so because “they never end” quite often. And making a complete in depth and future proof swift compiler hacker guide seems to me like it would take much more time than available in the GSoC period (it's almost like a book project in some way).
To give it a chance though, I will ask around if someone would be interested in mentoring such idea. Thanks for the writeup again, and perhaps if this idea does not make it you could pick up and focus on one of the proposed ones?
Thanks for your answer! I totally understand your conecrns, so let me try to allay them.
First, I actually expect the demand on the mentor to be quite minimal. All the things we would want to write about are already "documented" — but just in terms of the compiler code or tests and comments therein. I would really only need the mentor to point me at these places ("here's where it happens in SILGen, here are the optimizer passes, here is where it happens in IRGen, here are the tests") so that I don't miss anything and then simply proofread the thing afterwards and maybe suggest some remarks. In other words, I do not expect the potential mentor to explain me anything major or themselves provide a verbatim copy-pasta, since I either already have a mental model for this stuff or am confident enough to close the gaps with relative ease.
Though this is, of course, hard for me to prove just on words, which is why I asked elsewhere if a draft implementation (or in this case, a "chapter") should be provided since this way it would be possible to actually see what the potential outcome could be. At the very least, I totally have enough time before the end of the application period to write an example thing. I also could restrict myself to the topics that are already partially covered: either by the existing docs such as the one on calling conventions or by videos from the LLVM dev meeting such as this one, so that there's reference information I could base the text off and "translate" it from the style intended for compiler developers into a more user-friendly educational format.
Second, about this being a good fit for GSoC: if we generally do agree that such a writeup is desirable for the community to have, then having it started as part of GSoC actually achieves several things: it offloads the bulk of the work (writing and illustrations) off people who simply have more important or interesting things to do, while legitimizing the result quite a bit, as something like this being written in a blog elsewhere will likely not receive the proofreading that we can expect from the more formal engagement of a mentor.
And quite frankly, I just have a personal itch that makes me really want to accomplish this, having spent so much money and time on various courses by authors that are themselves misinformed or under-educated and regretting it quite a bit. I think overall that it is absolutely necessary for people to have accessible knowledge on how their language actually works — but I myself am an even larger noname as of now to be able to make the impact alone.
The project volume is indeed quite vague, so we could restrict ourselves to a more well-defined "table of contents" at first to formalize it for GSoC. However, I don't see anything negative in this eventually becoming a full-blown book, as it would be very nice to have our own Swiftonomicon at some point past GSoC
I understand still that this may not get accepted, but since I'm quite passionate about the idea, I think it won't hurt if I apply with this proposal alongside another one I've been working on already, as GSoC allows for three applications, right? That way, we would not need to discard the idea completely and let the team ultimately decide at proposal evaluation.
A rough idea: Is setting up Windows CI and building a functional build-script for Windows suitable for GSoC? It’s a very specific area, and we need it to make Windows really first-class supported.
Thanks for the idea, I have a feeling that work on CI infrastructure may be hard because it involves access to servers/credentials and in the case of Windows I suppose also includes licensing etc.
@mishal_shah can comment more though if there is any help that would be welcome and enough for a summer of code project to help with windows CI.
Currently, we are using swift/build-windows.bat at main · apple/swift · GitHub in Swift Community-Hosted CI. It would be great to have consistency between all of the platforms (build-script).
@compnerd would be the right person to provide more information about the Windows build system.
If I understand it correctly, the focus for the GSoC project would be to migrate build-windows.bat over to build-script, which can be done without access to the CI servers. Once the build-script is updated to support Windows build, I can update the CI job to use the new build-script preset.
It’s certainly better to use the same build-script across all the platforms if possible. What I originally intend is that the participant may write a more powerful build script for Windows which can support features like cache, test and smoke tests. We can then:
- Make toolchain development on Windows far more efficient;
- Require tests and smoke tests on Windows for future patches, making sure that a change won’t break Windows build;
- Get the Windows toolchain as an artifact of CI, which doesn’t rely on @compnerd ‘s Azure CI any more.
If we can finally use build-script on Windows, another benefit we’ll get is that toolchains on all platforms would share the same layout, though the current layout may be significantly changed on Windows.
This is already effectively done. The build-windows.bat already does the pre-commit CI testing. The commands are also documented.
Could you elaborate on this? I believe that the windows toolchain development is already quite efficient.
This is already done. There is pre-commit CI for the toolchain.
There are additional pieces which are needed for packaging - an unpackaged toolchain is ~10x larger (~4GiB vs 400 MiB) but possible already with the pre-commit CI.
I’ll check it out. It doesn’t quite make sense to me because I’m focusing on Core Libraries and Developer Tools, which
build-windows.bat currently lacks support of.
I suppose there isn’t check for Windows for corelibs and other related projects, due to the same reason addressed above?
The reason for the related projects not being tested is capacity. If you can provide hosts for CI, I think that resolving that it would be quite possible.
I think that what would be more useful than build-script would be reworking the tree layout to not have deep paths. There are a few cases where we have >256 characters in paths which is a bigger problem and crops up more commonly with the CI infrastructure.
Just to post an idea if anyone wants to take it on; SPM dependency pre-built caches.
We have a number of dependencies which take a significant time to build so we pre-build them to a cache for our CI. Each CI job then pulls in the cache and saves a significant time on each CI run.
Currently we do this though a combination of Carthage and our own tooling but really want to use SPM. This is one of the last major stumbling blocks for us to adopt it.
I'm happy to confirm Swift was accepted as participating organization in this years Google Summer of Code!
Now is a good time to continue looking into the project proposals, talk to mentors, and generally prepare for the next milestone, which will be:
- March 30 - April 13 - Student Application Period
Hassan posted a nice experience report from his last year over here: My GSoC Experience
It can be useful for first-time GSoC students – so if that's you – you might want to give it a read
I would like to suggest a few ideas for GSoc 2021 for the Swift world, I hope that this is the right place to make this proposal.
Swift on Windows
Windows now uses a binary format (ECMA-based) to describe the shape of the OS APIs. This capability is now used to produce both Rust and C# APIs that give access to the entire set of Windows APIs.
There are already MIT-licensed C# and Rust implementations of this bridge, and could serve as a blueprint to do this. It would allow Swift to be a first class citizen in Windows.
This can be completed during the summer.
Swift on Android
While there is an effort to support Swift on Android, it would be great to create a binding generator that would surface the Android API to Swift developers. Xamarin's open sourced tools have enough support to turn arbitrary Android APIs into C# APIs, and could be used as a reference.
I do not believe that the summer would be enough to complete the work, but it could certainly make some progress in that direction.
The Tokamak folks have built a SwiftUI engine that runs on WebAssembly and to some extend on Linux. It would be great to fund this effort to get this SwiftUI-like platform to be both more complete, and more polished.
Very good fit for summer of code.
"Swift Tool" support
I would love to have a way of creating command line tools in Swift installed into the system, or for the user, similar to
npm install which can turn the project into a command line tool that is installed into the system. This would make it convenient to distribute Unix commands written in Swift.
This would extend SwiftPM, so I would envision:
$ swift install --global
Very good fit for a summer of code event.
I’ve touched this point in [Pitch] SwiftPM support for Swift scripts (revision), part of which going to be my choice for GSoC project. You can check the “Alternative considered” part for an alternative solution which I think is better.
The student submission period has officially ended -- thanks everyone!
We received a lot of proposals and will take the next weeks to review and decide which we'd like to request slots for and eventually accept.
Please be patient and look forward to the final student+project announcements on May 18th 2021