The autoclosure describes the behavior of how that one stored property is initialized, but it doesn't describe the behavior of the memberwise initializer synthesized for the entire struct. @DougGregor, should it?

For what it's worth, the output is the same if I move the initialization of the property into the struct, like this:

struct N {
    @Lazy var number: Int = { () -> Int in
      print("-- Initializing Lazy storage")
      return 23
    }()
}

print("++ Initializing N")
var n = N()
print("++ Printing number")
print(n.number)

/* prints:
++ Initializing N
-- Initializing Lazy storage
++ Printing number
23
*/

@belkadan This suggest to me that it's irrelevant whether I use the struct's initializer or the property's initializer. Or I'm still misunderstanding what's supposed to happen.

I do think there's a problem here because:

1. The behaviour of the property-wrapped @Lazy doesn't match the built-in lazy:

struct N {
    lazy var number: Int = { () -> Int in
      print("-- Initializing Lazy storage")
      return 23
    }()
}
// '++ Printing number' comes before '-- Initializing Lazy storage'

2. The behaviour of the property-wrapped @Lazy doesn't match what happens when we explicitly do what the property wrapper ought to have implicitly done, like:

struct N { 
    var _number: Lazy<Int> = Lazy<Int>(wrappedValue: { () -> Int in
      print("-- Initializing Lazy storage")
      return 23
      }())
    var number: Int {
      mutating get { return _number.wrappedValue }
      set(v) { _number.wrappedValue = v } 
    }   
}
// '++ Printing number' comes before '-- Initializing Lazy storage'

Again, it's specifically a problem with the synthesized memberwise initializer, not with the property itself.

@swift-ci create

@belkadan, I'm talking about the case where N is created as just var n = N() (like in @ole's comment), so the synthesized memberwise initializer is not involved. Sorry I didn't make that clear before.

Ah, you're right, I wasn't reading it correctly at all. Sorry!

@belkadan, @DougGregor:

As it turns out, the memberwise initializer is indeed involved.

Under certain conditions, the implicitly generated memberwise initializer arg for a property-wrapped struct member would be of the the wrapped type rather than the wrapper type.

For example:

@propertyWrapper
struct Wrap {
  var wrappedValue: Int
  init(wrappedValue: Int) { self.wrappedValue = wrappedValue }
}

struct N {
  @Wrap var number = computeThing()
}

func computeThing() -> Int { return 0 }

// Implicit memberwise initializer for N in swiftc -emit-silgen is:
// N.init(number: Int = computeThing())
// (Here, the number arg is Int, not Wrap)

This is currently true even if the init(wrappedValue: ) takes an autoclosure of the wrapped type.

@propertyWrapper
struct Wrap {
  var wrappedValue: Int
  init(wrappedValue: @autoclosure () -> Int) { self.wrappedValue = wrappedValue() }
}

struct N {
  @Wrap var number = computeThing()
}

func computeThing() -> Int { return 0 }

// Implicit memberwise initializer for N in swiftc -emit-silgen is:
// N.init(number: Int = computeThing())
// (Here too, the number arg is Int, not Wrap)

So, the autoclosed expression computeThing() is always evaluated during the initialization of N, whether we use the default initializer (var n = N()), or the memberwise initializer (var n = N(number: computeThing())).

To fix this, we need to handle the autoclosure case specially. When we find an autoclosure in the innermost wrapper, we could take one of these approaches:

1. The memberwise initializer arg should be the wrapper type (Wrap) instead of the wrapped type (Int), so N would then be memberwise initialized as N(number: Wrap(wrappedValue: computeThing())), or
2. The memberwise initializer arg should be an autoclosed version of the wrapped type (@autoclosure () -> Int), so N would then be memberwise initialized as N(number: computeThing()).

I think approach #2 is better and will work on a PR with this approach.

In addition, if we find an autoclosure in a non-innermost wrapper, I think we should make the memberwise initializer take an arg of the wrapper type.

@roop Great analysis, thanks for getting to the bottom of this.

Thanks, @ole.

PR opened: #26572

@roop Thanks so much for the PR.

@roop are you still working on this?

@theblixguy Yes. I'll update the status in the PR in a couple of days and tag you.

Confirmed with DEVELOPMENT-SNAPSHOT-2020-03-22-a that @roop and @DougGregor fixed this with #30537 Thank you!