Experimental property wrapper feature in Combine beta 5

I'm no expert on the hidden compiler attributes, but is my assumption correct that @_alwaysEmitIntoClient should be present on experimental features?

Combine beta 5 just introduced this change:

@propertyWrapper public struct Published<Value> {
  public init(initialValue: Value)
  @available(*, unavailable, message: "@Published is only available on properties of classes")
  public var wrappedValue: Value {
    get
    set
  }
  public static subscript<EnclosingSelf>(_enclosingInstance object: EnclosingSelf, wrapped wrappedKeyPath: Swift.ReferenceWritableKeyPath<EnclosingSelf, Value>, storage storageKeyPath: Swift.ReferenceWritableKeyPath<EnclosingSelf, Combine.Published<Value>>) -> Value where EnclosingSelf : AnyObject {
    get
    set
  }
}

Can anyone elaborate what will happen if the experimental feature in question will be designed slightly differently for the end-user. As the name says, this is an experimental feature but it does leak into users code which if I'm not wrong would mean that we would need to stick with it forever?!

cc @Douglas_Gregor @Philippe_Hausler

@_alwaysEmitIntoClient is useful for keeping a particular declaration out of the ABI. I wouldn't say that always means it should be present on experimental features.

It means that SwiftUI will always have to emit the entry points used by this feature (the static subscript(_enclosingInstance:wrapped:storage:)) into their binary. We thought about it; it's not a heavy burden for the framework.

I feel like we've frightened people a bit too much with ABI concerns. Maintaining backward compatibility for an Apple framework like SwiftUI should really be something that Apple engineers are concerned with, not a general concern for the Swift language. Those of us that wear both hats do our best to make sure that the needs of the former don't unduly affect the latter.

Doug

11 Likes