Weird, looking at the generated SILGen'd output it seems like the backing property's initializer is not being called, before the setter is called.

Okay, after digging a bit, it seems like this isn't a bug. It's because the wrappedValue's setter is non-mutating (and State is a value type), and so we don't rewrite the assignment into an initialization.

It's also not tied to State, for example:

@propertyWrapper
struct Foo<T> {
  private var _value: T

  init(wrappedValue value: T) {
    _value = value
  }

  var wrappedValue: T {
    get { return _value }
    nonmutating set { fatalError("unimplemented") }
  }
}

struct Bar {
  @Foo var value: Int

  init(value: Int) {
    self.value = value
  }
}

although I suppose the diagnostics could be a bit better.

Isn‘t this the other way around then? How is the setter even related to this as we still need to initialize the property wrapper first and therefore substitute the whole line. The initialization isn‘t really going through the computed property.

I mean, this rule says nothing about the setter kind. https://forums.swift.org/t/why-does-this-property-wrapper-code-compile/31931/6

Okay it also seems to happen if `wrappedValue` is get-only, but this rule isn‘t about that but rather about initialization similar to like out of line initialization but from within the init context.

@swift-ci create

This is due to an artificial limitation in the compiler's implementation of property wrappers. The workaround is to initialize the backing storage directly via _value in V.init:

  init(value: Int) {
    self._value = State(wrappedValue: value)
  }

This should be fixed by #35218

This is fixed. Could you please verify using the latest main development snapshot from https://swift.org/download/#snapshots ? Thank you!