That's good motivation!
I believe the first task for a prospective GSoC student is to come up with a convincing project proposal.
But before we get to that, if I were you, I would want to make sure I'd enjoy working with the stdlib. A GSoC project takes a lot of commitment. So get some practice -- download and compile Swift, and start breaking things! Some ideas:
- Can you make sense of the code? (The stdlib is written in a somewhat unusual Swift dialect, and it may take some getting used to. It deals a lot with low-level builtins and even some language-level constructs that don't typically occur in regular Swift development. Not to mention gyb!)
- Try adding a new public type, or some extension method -- figure out what the editing/recompiling experience is like. (You'd probably spend a good chunk of time doing it during the project.)
- Try running the test suite; can you figure out where/how it is implemented? Find and look through the tests we run for collection types. Is it easy to make sense of them? Think about how a new Collection type like a deque could be integrated into the existing tests. What tests can we reuse? What new tests will we need to add?
- Make some changes to an existing stdlib method that will obviously break it; does it cause a test failure in the test suite? (If not, please submit a PR with a new test!) What does a test failure look like? Try debugging it while pretending you don't know the cause.
- If you come across a bug you're able to fix, submit a PR for it! This will give you a feel for what our review process is like.
- Select some stdlib algorithm and find its benchmark(s). Try to optimize the algorithm by tweaking its code, and see if it improves benchmark results. (Submit a PR if so!) If you don't find benchmarks for the algorithm you selected, try writing a PR to add one.
- For a more esoteric task: can you figure out how the debugger interprets Swift's collections? It is able to print Arrays, Dictionaries etc without actually running Swift code in the target process. What would it take to add support for a new stdlib type?
(Feel free to ask me to review any PRs you might submit. If you hit a stumbling block, let me know -- I can help (or we can figure it out together), and we may want to add documentation or make changes to smooth it out for the next person. These things make great starter PRs, too.)
Obviously this isn't part of the proposal process, but these experiments will probably tell you whether you'd enjoy spending a few months (or more!) on our codebase, and they will give you a great start on scoping out the potential deliverables in the proposal. As I said, implementing a collection type is just a start -- integrating it into the standard library takes a lot more effort! You need to be aware of the areas that need to be touched, and you need to figure out how much you can reasonably achieve in the time available. Then you need to convincingly communicate this in the proposal.
It would be impressive if the proposal included a draft of the public API for the type you'd like to implement -- just as if you were writing the Motivation and Design Details parts of a Swift Evolution proposal. By doing this well, you'd demonstrate proficiency with Swift's conventions, and a sense of good taste in API design. Naturally the interface you propose would be just a rough draft -- we'd refine it together during the project, and it will evolve even further when we pitch it on the evolution forums.
Please don't hesitate to write; I'm happy to answer questions and to discuss ideas.