Imagining an Xcode autocomplete picker that lists SwiftUI modifiers according to their “impact” on the elements in the view hierarchy. Nearly every modifier modifies a View and returns a View but they often are intended for a specific family of controls. So if there’s a ScrollView in the hierarchy, it’ll surface things like contentMargins. If there’s a Button, you’ll get buttonStyle and buttonShape.

@mattcomi This would require language facilities to model the relationships and then support in the completion result system.

But I really like the concept! And I think a language extension like this seems cool!

@mattcomi (Or maybe just less use of “View” and instead just use the existing type system. Unsure if that’s possible but way easier.)
@mattiem at the very least the documentation would need to be annotated to indicate a modifier’s associated views. Traversing the hierarchy is another, much bigger problem.
@mattiem so much SwiftUI problem solving involves discovering a modifier you didn’t know existed. It would be fantastic if the IDE could surface relevant modifiers.
@mattcomi @bens One of my big frustrations with SwiftUI is that the designers use the type system extensively for things like performance but then huge swaths of the API are dumped into extensions on View, making them completely type erased. 🤦‍♂️
@bwebster I think it’s fair to say that *most* of the API exists as modifiers on View but I may just be too frustrated right now :)
@mattcomi yes please. It’s just too hard to find the right incantation for what you’re trying to achieve. Some modifiers make more sense on some views than others, just show me these!

@mattcomi

An Inspector that lists applicable modifers for element at the cursor (or whatever) would be nice.