Require that attributed properties be explicitly configured

[gohanlon]

Currently, MemberwiseInit ignores attributed properties by default, as it's unsafe to assume correct initialization behavior for such properties. This default behavior, however, can lead to confusion and compilation errors when properties lack other initializations.

Instead, MemberwiseInit should require explicit configuration for attributed properties, and provide fix-it diagnostics to guide developers in configuring attributed properties appropriately.

Uncommon and unknown attributes

MemberwiseInit doesn't know anything about the behavior of @Logged, which could be a macro or a property wrapper. The developer must apply the correct configuration without much help from MemberwiseInit:

@MemberwiseInit
struct Counter {
  @Logged var count: Int
//┬──────
//╰─ 🛑 @MemberwiseInit requires explicit configuration for attributed properties
//   ✏️ Mark with `@Init` to include 'count'
//   ✏️ Mark with `@Init(.ignore)` and provide a default value
//   ✏️ Mark with`@InitWrapper(type: <#(Any.Type)#>)`
}

Note
The @Init(.ignore) fix-it assumes that a default value is needed. Often that's the correct assumptIon, but, technically, property wrappers can provide default values or connect to more global values. As a fix-it, offering a best-guess is reasonable.

@Binding assumed to be SwiftUI.Binding

@Binding is probably a SwiftUI.Binding, so the fix-it can reasonably assume the intended behavior—this is just a fix-it, after all:

@MemberwiseInit
struct CounterView: View {
  @Binding var count: Int
//┬───────
//╰─ 🛑 @MemberwiseInit requires explicit configuration for attributed properties
//   ✏️ Mark with `@InitWrapper(type: Binding<Int>)`
}

Note
The purpose of SwiftUI's @Binding is for a shared value to be provided from the outside via the initializer, so the intended behavior is unambiguous.

@State assumed to be SwiftUI.State

@MemberwiseInit
struct DetailView: View {
  @State private var isActive: Bool
//┬───────
//╰─ 🛑 @MemberwiseInit requires explicit configuration for attributed properties
//   ✏️ Mark with `@Init(.ignore)` and provide a default value
//   ✏️ Mark with `@Init`; only first init call affects `@State`
}

@ EnvironmentObject assumed to be SwiftUI.EnvironmentObject

@MemberwiseInit
struct SettingsView: View {
    @EnvironmentObject var userSettings: UserSettings
    //┬─────────────────────────────
    //╰─ 🛑 @MemberwiseInit requires explicit configuration for attributed properties
    //   ✏️ Mark with `@Init(.ignore)` as EnvironmentObject is provided implicitly by the parent view
}

@Environment assumed to be SwiftUI.Environment

@MemberwiseInit
struct ContentView: View {
  @Environment(\.managedObjectContext) private var context
  //┬─────────────────────────────
  //╰─ 🛑 @MemberwiseInit requires explicit configuration for attributed properties
  //   ✏️ Mark with `@Init(.ignore)` as Environment objects are not initialized via init
}

Note
It's preferable for the @Init(.ignore) diagnostic to supersede the "private" property diagnostic that could also trigger in this case.

Question: Diagnostic precedence?

Should the following trigger diagnostics for 'count' not being public or requiring an explicit configuration due to being attributed, or both?

@MemberwiseInit(.public)
public struct CounterView: View {
  @Binding private var count: Int
}

Note the above example where @Environment is "private" but should never be initialized via an init.

Question: Breaking change?

While being somewhat of a grey area, I think this is closer to being a breaking change than not. So, if this change moves forward, it should align with version "1.0".

Attributes to consider

• SwiftUI.@Binding
• SwiftUI.@State
• SwiftUI.@StateObject
• SwiftUI.@Environment
• SwiftUI.@EnvironmentObject
• Combine.@Published
• SwiftUI.@ObservedObject
• SwiftUI.@AppStorage
• SwiftUI.@GestureState
• SwiftUI.@FocusedState
• CoreData.@NSManaged
• Observation.@Observable
• SwiftUI.@Bindable