Ancestors

Written by John Siracusa on 2024-12-18 at 03:31

Welcome to my new series on things I don’t understand about Apple’s premier user interface framework. I’m calling it…

[#]SwiftUWhy

To be clear, these are things I don’t understand, not necessarily things that are “wrong.” They sure look wrong (or at least “suboptimal”) to me! But maybe there are good reasons, and I just don’t know them yet. SwiftUI experts and historians, please tell me!

The first entry is coming up…

=> More informations about this toot | More toots from siracusa@mastodon.social

Written by John Siracusa on 2024-12-18 at 03:35

Why in the world does this interface look like this:

.padding(.top, 1)

.padding(.leading, 2)

.padding(.bottom, 3)

.padding(.trailing, 4)

…or this:

.padding(EdgeInsets(top: 1, leading: 2, bottom: 3, trailing: 4))

…instead of the much more idiomatic:

.padding(top: 1, leading: 2, bottom: 3, trailing: 4)

Like, who in the world thought of this foo(.key, value) API interface in a language with named parameters?!

[#]SwiftUWhy

=> More informations about this toot | More toots from siracusa@mastodon.social

Written by Harshil Shah :psyduck: on 2024-12-18 at 05:09

@siracusa My guess would be because this forces you to declare padding for all edges (if it’s one modifier) or is going to mess up diagnostics and type checking and stuff if they let you pick and choose because that would require multiple modifier variants

=> More informations about this toot | More toots from harshil@mastodon.social

Toot

Written by John Siracusa on 2024-12-18 at 05:15

@harshil Somehow .frame() (almost) manages it, all with a handful of variants with normal named parameters.

=> More informations about this toot | More toots from siracusa@mastodon.social

Descendants

Written by Harshil Shah :psyduck: on 2024-12-18 at 05:18

@siracusa Yeah that’s a good point!

=> More informations about this toot | More toots from harshil@mastodon.social