GSoC: Re-implement Swift Property Wrappers with Macros (Seeking Mentor Guidance)

[Renishavaiya (RAY)]

Hi everyone,

I’m Renish, a recent M.S. Computer Science graduate from UT Arlington (Dec 2025), and I’m very interested in working on the “Re-implement property wrappers with macros” project for GSoC.

I’ve been following the recent progress around Swift Macros and init accessors, and I’m excited about the possibility of removing property-wrapper-specific logic from the compiler and rebuilding the feature using existing language mechanisms. This feels like a great opportunity to improve compiler code health while keeping behavior stable for users.

What I’m thinking about for the project:

Property wrappers today rely on compiler-special cased behavior across parsing, semantic analysis, and SIL generation. With macros + init accessors, the core idea seems to be expressing the wrapper transformation explicitly as a macro expansion: synthesizing backing storage, generating accessors for wrappedValue/projectedValue, and handling initialization rules (including wrapper stacking). The main challenge, as I understand it, is achieving full parity with existing wrapper semantics — especially for edge cases where current macro/init-accessor capabilities may not yet cover all use scenarios.

I’d love to hear from the mentors and community about the current direction and what the “must-cover” scope looks like.

1. What’s the minimum viable success for GSoC here — full removal of all property-wrapper-specific compiler code, or a staged migration with a roadmap?

2. Are there known gap scenarios today where macros/init accessors cannot express existing property wrapper behavior (examples/tests I should start from)?

3. Is there a recommended starting point in the compiler codebase for identifying wrapper-specific logic (Sema vs SILGen vs synthesis paths)?

4. For evaluation, should success be measured primarily by test-suite parity, compiler code removed, or also compile-time performance parity?

Thanks for all the work enabling these newer features—I'm excited to learn from the community, especially @xedin as a potential mentor, and I’d really appreciate your guidance as I contribute to the macros effort and become an active part of this community.

Renish

[xedin (Pavel Yaskevich)]

Hello, Renish! Thank you for the interest in the project!

@Renishavaiya

• What’s the minimum viable success for GSoC here — full removal of all property-wrapper-specific compiler code, or a staged migration with a roadmap?

I think a staged migration with clearly defined steps is the best way to approach this. I don't think we can completely replace the implementation in the course of GSoC.

@Renishavaiya

• Are there known gap scenarios today where macros/init accessors cannot express existing property wrapper behavior (examples/tests I should start from)?

Yes, there are a few scenarios like that, we have discussed this in the previous threads about this project last year. You should be able to find them in this category.

@Renishavaiya

Is there a recommended starting point in the compiler codebase for identifying wrapper-specific logic (Sema vs SILGen vs synthesis paths)?

Could you please elaborate to help me understand exactly what you mean here?

@Renishavaiya

For evaluation, should success be measured primarily by test-suite parity, compiler code removed, or also compile-time performance parity?

I think it's feature parity and amount of ad-hoc code removed from the compiler.