SE-0293: Extend Property Wrappers to Function and Closure Parameters

[Jumhyn (Frederick Kellison-Linn)]

I had a few more questions come to mind over the past few days.

1. What effect (if any) do parameter wrappers have on the overloading/overload resolution behavior of the function itself? I'd expect there to be no effect (i.e., the addition of a wrapper attribute does not enable the ability to define any new overloads, nor affect how any existing overloads are resolved), but just want to make sure.

2. This proposal has no effect on the requirement that function type signatures be fully-specified, right? I.e., this would be invalid:

@propertyWrapper
struct Wrapper { var wrappedValue: Int }

func foo(@Wrapper arg) {}

?

3. Calling back to an exchange I had with @hborla in the pitch thread:

@hborla

Still curious whether it’s desirable for the wrappedValue overloads to influence the type of the passed argument in potentially non-obvious ways.

Overload resolution can't influence the type of the wrappedValue argument in an unexpected way, because it's an error to have a wrappedValue parameter type that isn't compatible with the type of var wrappedValue in the property wrapper. autoclosure s of compatible types are allowed, though.

It seems like this restriction doesn't actually apply to init(wrappedValue:) overloads in extensions (maybe a bug?). Thus, the following produces a possibly unexpected result:

@propertyWrapper
struct Wrapper {
  var wrappedValue: Double
}

extension Wrapper {
  init(wrappedValue: Int) { // no error!
    self.init(wrappedValue: Double(wrappedValue + 1))
  }
}

struct S {
  @Wrapper
  var x: Double = 0
}

print(S().x) // 1.0

Presumably, this would also cause trouble in a situation like:

func foo(@Wrapper arg: Double)
foo(arg: 0)

which would result in the literal being inferred to have type Int, even though it's passed to a function which ostensibly takes a Double. Am I missing something?