I agree that @Binding is unnecessary in the closure because Binding is a contextual type, so it can be inferred. However, I think there's a better solution than making property wrapper attributes some kind of type attribute. A few reasons why:
- What type does an anonymous closure parameter with a contextual property-wrapped type get? If it's the wrapped value type, do you access the backing wrapper and projected value with
_$0and$$0(not the most readable syntax IMO)? If the anonymous closure parameter gets the backing wrapper type, then the type would change when you name the parameter, which would be really unexpected IMO. - Using property wrapper attributes as type attributes would be really limiting when working with generics. Currently, the
ForEachinitializer has nothing to do withBinding. It would be really unfortunate if API authors had to add a new overload for each kind of property wrapper that API might want to accept. We could alleviate this by adding some kind of language feature or property wrapper protocol that lets you use a generic parameter as a property wrapper attribute.
I think my favorite solution to the inference problem so far is what @Lantua suggested in the pitch thread, which is in Future Directions:
ForEach($shoppingItems) { $item in
TextField(item.name, $item.name)
}
The downside to this approach though is that not every property wrapper has a projected value, so it's sort of conflating the backing wrapper with the projected value.