You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With #13's addition of @Init(assignee:type:), MemberwiseInit's @Init became expressive enough to support property-wrapped members1.
But, MemberwiseInit should provide a cleaner way to initialize properties wrapped by property wrappers. Further, @Init has become burdened by some seldomly needed parameters and is now Xcode autocomplete-unfriendly. We can improve the situation somewhat.
Here’s the new macro definition proposal:
@Init for standard property initialization behavior.
@InitWrapper to initialize the wrapper of a property-wrapped property.
@InitRaw directly exposes the full configurability of the macro.
// An escape hatch that embraces the "template" nature of the macro and directly exposes it's configuration.
// 6 arguments
public macro InitRaw(
_ accessLevel:AccessLevelConfig?=nil,
assignee:String?=nil,
default:Any?=nil,
escaping:Bool?=nil,
label:String?=nil,
type:Any.Type?=nil)=…
// To simplify common usage, forgo 'assignee' and 'type'.
// 4 arguments
public macro Init(
_ accessLevel:AccessLevelConfig?=nil,
default:Any?=nil,
escaping:Bool?=nil,
label:String?=nil)=…
// Use the 'assignee' of 'self._\(#propertyName)'.
// 5 arguments
public macro InitWrapper(
_ accessLevel:AccessLevelConfig?=nil,
default:Any?=nil,
escaping:Bool?=nil,,
label:String?=nil,
type:Any.Type?=nil)=…
Example:
import SwiftUI
@propertyWrapperstructLogged<Value>{varwrappedValue:Value{
didSet {print("Logged: \(wrappedValue)")}}init(wrappedValue:Value){self.wrappedValue = wrappedValue
}}
// NB: Some property wrappers require initialization of the property
// wrapper itself, hence `@InitWrapper`. Here, we want Logged to be
// initialized without triggering its side effects (logging).
@MemberwiseInit(.public)publicstructCounterView:View{
// @Logged: InitRaw
@InitRaw(.public, assignee:"self._name1", default:"Blob")@Loggedvarname1:String
// @Logged: InitWrapper
@InitWrapper(.public, default:"Blob")@Loggedvarname2:String
// @Binding: InitRaw
@InitRaw(.public, assignee:"self._count1", type:Binding<Int>)@Bindingvarcount1:Int
// @Binding: InitWrapper
@InitWrapper(.public, type:Binding<Int>)@Bindingvarcount2:Int
// @State
@Init(.public)@StatevarisOn= false
varbody:someView{…}}
Footnotes
I think@Init(assignee:type:) provides complete (if awkward) support for initializing property wrappers. If I'm wrong, I'd love to hear about it. ↩
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Update: Moved to #17.
With #13's addition of
@Init(assignee:type:)
, MemberwiseInit's@Init
became expressive enough to support property-wrapped members1.But, MemberwiseInit should provide a cleaner way to initialize properties wrapped by property wrappers. Further,
@Init
has become burdened by some seldomly needed parameters and is now Xcode autocomplete-unfriendly. We can improve the situation somewhat.Here’s the new macro definition proposal:
@Init
for standard property initialization behavior.@InitWrapper
to initialize the wrapper of a property-wrapped property.@InitRaw
directly exposes the full configurability of the macro.Example:
Footnotes
I think
@Init(assignee:type:)
provides complete (if awkward) support for initializing property wrappers. If I'm wrong, I'd love to hear about it. ↩Beta Was this translation helpful? Give feedback.
All reactions