# Pitch #2: Extend Property Wrappers to Function and Closure Parameters **URL:** \ **Category:** Pitches\ **Tags:** propertywrapper\ **Created:** [October 6, 2020, 4:31pm UTC](https://forums.swift.org/t/pitch-2-extend-property-wrappers-to-function-and-closure-parameters/40959 "2020-10-06T16:31:28Z")\ **Posts on this page:** 1\ **Showing post:** 60
**Author:** ![hborla](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/hborla/32/27563_2.png) [@hborla](https://forums.swift.org/u/hborla)\ **Post date:** [October 22, 2020, 5:56pm UTC](https://forums.swift.org/t/pitch-2-extend-property-wrappers-to-function-and-closure-parameters/40959/60 "2020-10-22T17:56:52Z")
> That's where I have problem with this design, the API authors have little control on the type of argument it can support. You can't force `Clamp(to: 0...3)` since the callers will just provide a separate `Clamp` with different parameter. This proposal does not support additional arguments in wrapper attributes on parameters for this exact reason. I mentioned up-thread that there are a few ideas for how to support this in the future in a way that ensures that callers can't change those arguments, for example: > [@Future directions of Property Wrappers](https://forums.swift.org/t/future-directions-of-property-wrappers/27934/11): > > I thought Jordan was going to post it, but instead I'll do it for him in a completely unstructured form (sorry): class Speaker { // Once again, the problem with this in today's property wrappers // implementation is that every instance ends up storing the range, even // though by construction it can't ever be different from instance to // instance. That's a real waste. So what if we have a notion of "shared info // property wrappers" that live on the type and get instantiated? @Clam… --- _[View the full topic](https://forums.swift.org/t/pitch-2-extend-property-wrappers-to-function-and-closure-parameters/40959)._