I am Minh Pham, a student in Maths and CS hoping to join GSC 2023. I found the subjects of Swift the most interesting for me and I like how the community works and supports each other. I am particularly intrigued by the Swift/C++ Interoperate project. As I knew about GSC quite late, I spent the last few days going through all the materials on the GitHub source code, previous threads discussions, etc. I managed to gain a reasonable understanding of the aim and scope of the project. I am working on the proposal right now as well as trying out the local demonstration. However, I have a few questions in order to extend the content of the solution.
I get that we want to implement additional methods to make the use of the std containers more convenient, (similar to the example given before about converting std::string to swift string and vice versa). So it is pretty clear that we would go on to develop the same methods for the other containers (std::deque, std::map, etc). However, as the STL has other 4 elements (algorithms, functors, iterators, and adapters), is it reasonable to take them into account as well? I raise this question as I did not have a lot of experience with Swift yet; therefore I would not be fully aware of some particular use cases for them. On the other, if we should mainly focus on the conversion of containers, what do you expect to see more in a proposal since everyone might have a relatively similar list of things to build?
Hi Minh,
Paging @egor.zhdan the mentor for this project.
Minh, please make sure to submit your proposal before the April 4th 18:00 UTC (!) deadline, or otherwise we won't be able to consider your application. I suggest that even if you don't hear back from Egor with all the details, please submit a proposal as soon as possible anyway. I believe you can still "edit" the proposal after submitted but not finalized.
You mention that you've read through topics already, but to make sure: the tag contains somewhat more posts than gsoc the forums category: Topics tagged gsoc-2023
Hi Minh,
It's great to know you're interested in the project!
This sounds very reasonable to me!
Bridging C++ iterators into Swift is an interesting task because of the differences in memory model between Swift and C++. In C++, iterator types often store a pointer to an item of the collection as one of the fields. This doesn't work well with Swift: the Swift compiler can implicitly copy or move the collection, making the pointer invalid. For this reason we don't expose raw C++ iterators into Swift, instead, we provide a special bridging mechanism implemented here: swift/CxxSequence.swift at main · apple/swift · GitHub. If you have ideas on making this solution better, that's wonderful! If you don't, that's fine, we don't expect that as part of the GSoC project.
With respect to C++ algorithms, I think the question is: can you think of any reasons why Swift clients would prefer to use C++ algorithms instead of Swift algorithms? Is there a way to make Swift algorithms work better with C++ types, instead of forcing the client to call into C++ stdlib algorithms?
It's totally fine if you decide to leave algorithms out of the proposal for this project.
Thank you very much for your reply and recommendations. I have included them in the proposal that I have newly submitted. I hope you can look and give me some feedback if time allows. Sorry for the short notice. Have a nice day!