SE-0502: Exclude private initialized properties from memberwise initializer

Evolution Proposal Reviews
1

Hello, Swift community!

The review of SE-0502: Exclude private initialized properties from memberwise initializer begins now and runs through January 22, 2026.

Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me as the review manager by DM. When contacting the review manager directly, please put "SE-0502" in the subject line.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at:

swift-evolution/process.md at main · swiftlang/swift-evolution · GitHub

Thank you,

Tony Allevato
Review Manager

4 Likes
2

I like this improvement a lot. Making the synthesized memberwise init more useful is always helpful, and this definitely solves a real usability cliff.

However, rather than one day causing a source break by removing the existing fileprivate/private memberwise inits, why not keep them and make this proposal additive?

The proposal briefly addresses this in Alternatives Considered:

We don't think this is a good long-term solution though, we think a single overload should be sufficient for the majority of use cases.

I do wonder how much these private / fileprivate inits are getting used in practice. How common / uncommon are they in your source compatibility testing? If they’re quite uncommon then the eventual source break seems reasonable. I do wonder if we’re unnecessarily removing a reasonable pattern though.

I suppose thinking to the macro use case in the motivation section, you probably don’t want private backing properties that are implementation details of macros to show up even in a private memberwise init, and I agree with the principle that macro-expanded code shouldn’t be treated specially. So I see how removing the private memberwise init seems like the best long-term solution.

2 Likes
3

Looks good! Although I would remove the future-section content, as it seems anti-Swifty to me. Either rely on the synthesized initializer, or explicitly declare a separate one as the 'main' initializer or as an additional one in an extension.

However, rather than one day causing a source break by removing the existing fileprivate/private memberwise inits, why not keep them and make this proposal additive?

I’m not sure if I would prefer this, but it should be given additional consideration in my opinion.

4

The motivation section seems a bit lacking in real-world use-cases. It contains simple “minimum working examples” that demonstrate the changes without actually motivating them.

The proposal does a good job of explaining what the proposed changes are, but in its present form it has not provided sufficient evidence to convince me that those changes are worthwhile.

• • •

1. Are there existing structs in the standard library, or the core libraries, or prominent projects such as the source compatibility suite, that would be able to replace a manually-defined init with a synthesized one, if this proposal were adopted?

If so, how common or rare are they?

2. Conversely, are there existing structs that would have to introduce a manually-defined init to replace the existing synthesized one, if this proposal were adopted?

How common are they?

3. Are there other important use-cases that the authors envision, beyond those from (1) and (2)?

If so what are they and how common are they?

• • •

The proposal as written does not answer those question, and therefore does not actually provide any motivation to convince me that the change is worth pursuing. The closest it comes is mentioning that property wrappers already have similar behavior, while macros do not.

In contrast, some of the alternatives and future directions seem much more compelling.

I think that, rather than make piecemeal changes, we should instead open up a discussion in the community to figure out what we want the end goal for memberwise initializers to look like. That is, to hash out something like a “vision” for them.

Then, once we have collectively decided how memberwise initializers ought to be, the proposals to get there can follow accordingly.

3 Likes
5

From the testing so far, they don't seem particularly common (that is, excluding cases where a type has only private properties, since those will continue to be included in the private memberwise initializer). There is 1 case in the source compatibility suite, 1 case in swift-testing, and 4 cases from Swift adopters at Apple (the testing I've done there hasn't looked at fileprivate yet though).

1 Like
6
  • What is your evaluation of the proposal?

Excellent. Please ship this.

In short, as a library developer on my team, I write a lot of explicit initializers simply to resolve the access modifier issue where normally I would rely on the implicit one. The resulting explicit code provides no value and is just boilerplate I have to maintain as I evolve libraries.

  • Is the problem being addressed significant enough to warrant a change to Swift? + Does this proposal fit well with the feel and direction of Swift?

Yes. It seems trivial and unimportant at first glance, but frankly it feels like a rough edge that I expected to be sanded/resolved much earlier on in Swift's evolution. In that regard, it warrants a change, and fits with the expected ergonomics of Swift.

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A quick reading, but it addresses an issue that I have had repeatedly over years of Swift dev.

1 Like
7

This proposal has been accepted with modifications. Thanks to all who participated!

4 Likes