0.3.0

What's Changed

• Changed: Provide an init at the specified access level or fail (#10). @MemberwiseInit has traditionally mirrored Swift’s memberwise initializer, adapting to the access levels of properties. This adapting behavior is necessary for Swift's initializer, which operates without explicit developer intent.

  However, @MemberwiseInit(.public) has the advantage of explicit, specific developer intent: add a public initializer. Now, any restricted properties that would have access leaked via the provided init will trigger diagnostics. This makes MemberwiseInit simpler to use, more obvious and incrementally learnable, and is still safe by default.

• Deprecated: @Init(.escaping) is deprecated in favor of @Init(escaping: true). Existing uses will trigger a warning with a fix-it.

• Fixed: Diagnostic concerning custom 'label' on multiple bindings being misdiagnosed (#20).

• Added: @InitWrapper(type:) to initialize properties that are wrapped by a property wrapper and require direct initialization using the property wrapper’s type, e.g. @InitWrapper(type: Binding<Int>) @Binding var number: Int.

• Added: Add @Init(default:) to support let property default values (#12).

• Added: Support for packages access level (thanks @davdroman, #6).

• Added: Warning diagnostic: ⚠️ @Init can't be applied to already initialized constant (with fix-its). Note: This will escalate to an error in version 1.0.

• Added: Warning diagnostic: ⚠️ @Init can't be applied to 'static' members (with fix-it). Note: This will escalate to an error in version 1.0.

• Added: Warning diagnostic: ⚠️ @Init can't be applied to 'lazy' members (with fix-it). Note: This will escalate to an error in version 1.0.

• Added: @InitRaw macro to provide direct configurability over 'accessLevel', 'assignee', 'default', 'escaping', 'label', and 'type'.

• Added: Error diagnostic: 🛑 Multiple @Init configurations are not supported by @MemberwiseInit when multiple @Init configurations are applied to a single property

Full Changelog: 0.2.0...0.3.0