Allow attached macros to not suppress the memberwise initializer

Evolution Discussion
2

In my understanding, this new attribute would decorate initializers. This would work.

Another option would be to make @attached macros able to wrap their added members in an extension (since initializers declared in extensions do not remove the memberwise init).

Actually, it might be interesting for macros that combine the member and conformance roles to be able to wrap the new members inside the added conformances.

So instead of having:

@MyMacro
struct MyStruct {
    // Generated by the `member` role inside MyStruct
    func myConformance() { }
}

// Generated by the `conformance` role as a peer to MyStruct
extension MyStruct: MyProtocol { }

We'd have:

@MyMacro
struct MyStruct { }

// Generated by the `member + conformance` roles
extension MyStruct: MyProtocol {
    func myConformance() { }
}

(I can see how difficult it is to build this on top of the existing ConformanceMacro and MemberMacro protocols.)

Yet this would improve the legibility of the generated code, and that's important. And I know one well-appreciated pitch that would profit for this kind of generation (conformance extensions that wrap the matching requirements). And several members of the steering group have expressed in this pitch that they love to wrap protocol requirements in dedicated extensions :-)

Now this would be a rather big change… and it is not my interest to wait too long. Destroying the memberwise init is not acceptable for GRDB users. I would be so disappointed to see the lib excluded from the macros game for months, years, just because of this "little" issue that was glossed over during the review of attached macros. :confounded:

Attempting at generating the memberwise init myself looks like fighting the language, spilling a lot of energy, and just an opportunity to create bugs or odd mismatches.

What can I do?

1 Like