Public initializer ergonomics for Draft types after 33.0

[woodymelling]

After upgrading past 0.32, I’m running into a source-breaking issue where I can no longer initialize Draft values from outside the target where the @Table type is defined.

From Slack, I understand that making the macro-generated Draft memberwise initializer internal was intentional, since relying on that compiler behavior was not something StructuredQueries should have committed to publicly supporting. That makes sense.

The awkward part is that I also seem unable to layer on the exact public initializer myself in some cases. In my app this means I cannot expose the same ergonomic construction surface for domain-heavy draft models from another target.

A rough shape of the problem:

@Table
public struct MyModel {
  public var id: UUID
  public var title: String
  // ...
}

// In another target:
let draft = MyModel.Draft(
  id: id,
  title: title
  // ...
)

This worked on 0.32, but no longer compiles after the initializer visibility change.
I tried adding an explicit public initializer for the draft type, but hit a compiler error when matching the generated draft shape. I can put together a minimal repro, but wanted to first ask:
Is the recommended path now to manually define public initializers on Draft types when they need to cross module boundaries?
Is there an expected pattern for doing that when the draft type has generated/lazy/optionalized fields?

I’m not asking for the generated memberwise initializer to become public again if that was an intentional correction. I’m more looking for the blessed way to recover a public construction API for drafts in multi-target apps.

[stephencelis]

@woodymelling This came up in an issue recently: #309

I'll restate things here:

---

We don't think it should be a macro's job to manage the complexities of memberwise initializer generation, capturing all the nuance of the Swift compiler, and it also seems to go against the spirit of the language, which requires you to explicitly add public surface area like those memberwise initializers.

Unfortunately the big footgun here is that if you try to define the equivalent memberwise initializer in an extension you will get hit with the following error:

extension MyTable.Draft {
  public init(…) { … }
}

Invalid redeclaration of synthesized memberwise 'init(…)'

There are workarounds, though:

1. You can define a public static func returning Self instead (like .draft or .create)
2. You can reorder the type's fields or init parameters so the init ordering doesn't conflict with the ordering of the fields
3. Or you can introduce a weird unused parameter, like _: Void = () to disambiguate your public initializer

The first is probably the most straightforward solution with the fewest compromises.

I also opened an issue in the language here if you'd like to follow it: swiftlang/swift#90519

It does seem like this is a bug that could be fixed in the language with same-file extension support.

[stephencelis]

We've pitched a fix in the language for this issue here: https://forums.swift.org/t/same-file-memberwise-initializer-extensions/88466