Impossible to extend macro-generated type with public memberwise initializer

[stephencelis]

Description

An existing diagnostic prevents you from defining a public memberwise initializer for a type in an extension:

invalid redeclaration of synthesized memberwise 'init'

…but this is the only reasonable way to do so for a type generated by a macro.

Six years ago a suggestion was made on the forums that same-file extensions should be able to define memberwise initializers: https://forums.swift.org/t/why-doesn-t-an-init-in-an-extension-suppress-the-synthesized-init/35182/ It didn't get traction but it also didn't have pushback.

This limitation seems more relevant than ever with macros now in the language.

Reproduction

public struct A {
}

extension A {
  public init() {}  // 🛑
}

Expected behavior

I expect a same-file extension to be able to define the memberwise initializer publicly.

Environment

swift-driver version: 1.168.4 Apple Swift version 6.4 (swiftlang-6.4.0.25.4 clang-2100.3.25.1)
Target: arm64-apple-macosx26.0

Additional information

No response

[hamishknight]

Yeah I also find this behavior surprising, I believe it predates SE-0169 and should be revisited. I think this will likely require evolution discussion before we can change it though.

[stephencelis]

@hamishknight I asked on the forums if it requires evolution, but no response yet. Since it's a change that simply fixes a diagnostic that prevents code from compiling today, and since it doesn't seem to impact existing compiling code, I was wondering if evolution is necessary.

[hamishknight]

I guess it depends on the design, but my hope here is to generally say that initializers in extensions within the same file suppress the synthesized initializers for a type, which would be a source breaking change and would require an evolution proposal. If we want to do a narrower change where only exact re-declarations cause the suppression, then that may not require a full evolution proposal, but I suspect it would still be worth evolution discussion to determine if we're happy with doing the narrower change without the more general change (i.e as thread in Evolution Discussion that the LSG can decide on).

[stephencelis]

I guess it depends on the design, but my hope here is to generally say that initializers in extensions within the same file suppress the synthesized initializers for a type, which would be a source breaking change and would require an evolution proposal.

This is definitely not the behavior I'm suggesting or wanting. I'm suggesting a non-source breaking change where a user-defined initializer in a same-file extension that matches the signature of the synthesized memberwise initializer would take precedence over that synthesized memberwise initializer. Effectively the same behavior of defining such an initializer in the main declaration, extended to same-file extensions.