Hello, my name is Alejandro Alonso and I'm currently studying computer science. For GSoC 2020, I want to propose building a new reflection solution for Swift. Now that Swift 5 has declared ABI stability for Darwin targets, it seems feasible to start building more powerful reflection solutions for Swift. Mirror has given developers a taste of the many capabilities that Swift can provide in the reflection space. However, there is much to be desired from Mirror that it currently doesn't support such as inspecting a type without an instance or dynamically setting an instance's field given a field name. I plan to publish a reflection manifesto, work with Swift evolution to design a reflection API, and implement some of the designed reflection capabilities.
Although this project idea was not a suggested, it's a topic that I've been very passionate about recently and would really appreciate it if someone would be willing to mentor me if this application is selected!
You’d be doing an enormous favor to the Swift community, Alejandro! Thank you for taking up this topic! I’ve been trying to implement a type-safe dynamically dispatched event bus framework for a while and I keep running into the lack of proper reflection! I event went as far as attempting to analyze type relationships at runtime and parsing strings generated by String(reflecting: Value.self). This approach technically gets the job done, but its’s incredibly slow, hard to do right and easy to mess up, not to mention, incredibly tedious to use, since the type graph analyzer needs to “see” each type at least once (and in case of protocols, it also needs to see the protocol’s “conformance metatype”, a.k.a MyProto.Type as opposed to MyProto.Protocol, since it can’t be accessed from a generic context), so you’d have to manually call something like analyze(MyStruct.self) and analyze(MyProto.self, MyProto.Type.self) for each and every type in existence, in order to have full knowledge of the entire type graph.
I started using Swift when it first came out and still love writing programs in it. For server development however, it’s hard to justify using Swift when compared to say, ASP.NET Core.
In particular, these are some of features I find missing in Swift:
Dependency injection
Automatically discovering controller methods
Mapping plain old classes to configuration settings in app settings.
Applying attributes to classes, methods and properties to affect functionality such as Authorization and input validation.
Automatically discovering unit test methods
Admittedly, there are property wrappers which can be used for dependency injection, but the part that’s missing is scoping each class to a container (which requires the container to have some knowledge about the classes’ constructor).
Hi Alejandro, thank you for your interest! It'd be great to invest in new, more capable reflection APIs for Swift, and a manifesto and design discussion would be valuable for exploring the design space, establishing direction, and keeping momentum. Without further parameters, though, that's a fairly open-ended project that could go on indefinitely without a clear completion criterion, which is somewhat at odds with the framework of GSoC. For a GSoC project, I think we'd want to establish a more concrete project with specific goals that can be achieved in the timeframe of a few months. Here are some ideas that come to my mind:
We could build on one of the existing proposals that have already undergone some design discussion and implementation work, and see them through to completion. For instance, the allKeyPaths APIs proposed by @rxwei and @dan-zheng has already seen a fair amount of iteration, and they may appreciate some help getting the implementation done, proposal written, and evolution review completed.
Alternatively, we could develop self-contained features that could act as accessories to help bring allKeyPaths or other in-flight projects to parity with Mirror's current capability. For instance, key paths currently lack the ability to be rendered as strings or indices and to iterate over their components, which could be useful in conjunction with allKeyPaths to support reflecting parts of types by name or index.
Something along these lines, with a well-defined scope and code deliverables, would be a better fit for GSoC. If you're also interested in opening up broader discussion topics about reflection outside of the strictures of GSoC, I would encourage you to do so as well.
Hi @Alejandro, FYI student applications are open, please coordinate with @Joe_Groff to come up with concrete project deliverable(s) that fit into the timeline of GSoC.