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
allKeyPathsAPIs 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
allKeyPathsor 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 withallKeyPathsto 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.