Swift pitch allows memberwise inits in same-file extensions

Swift developers Stephen Celis and Brandon Williams have pitched a language change that would let a struct’s memberwise initializer be declared in a same-file extension, not only in the type’s primary declaration.

Today the compiler synthesizes a memberwise initializer that is internal by default. Exposing it as public or package requires a handwritten init in the base declaration; the same signature in an extension is rejected as a redeclaration. That rule bites harder now that macros can emit nested structs: the generated type cannot carry a public init in its primary declaration, and an extension is illegal, so libraries have no clean way to publicize the initializer users already get inside the module.

The proposal would accept the memberwise form in a same-file extension, an additive rule with no ABI impact. Authors say it restores the same organizational flexibility ordinary structs already have and matches how other same-file synthesis works.

Forum review has mixed the idea with a longer-standing request for explicit public default-init syntax. Some argue that feature would be the better fix for macros, because it would let the generator or the user opt into a public memberwise form without rewriting the body, and would keep responsibility for stored properties and initialization aligned. Celis and co-author Brandon Williams counter that same-file extensions remain useful even if default-init lands: access control stays with the call site instead of becoming a configuration flag on every macro, and certain protocol conformances that demand a matching public init are impossible under today’s rules. Workarounds such as dummy private inits or static factory methods either suppress the synthesized initializer or fail protocol checks.

The pitch is presented as a narrow lift of an existing restriction rather than a redesign of memberwise synthesis.