Joachim<p><span class="h-card" translate="no"><a href="https://hachyderm.io/@rjmccall" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>rjmccall</span></a></span> hm, interesting. My initial reaction was „because then you have to repeat the whole view spec in the else case. But the whole point of it would be not to display it, so actually you don’t. This *is* is issue for things like `disabled`, where you want to display it but in a specific style, but not as much for hidden. </p><p>But then again: `hidden()` has a different meaning. `hidden` means „don’t display, but *do* take up space“ whereas with `if` it isn’t part of the view hierarchy at all, so it also won’t take up space. </p><p>So `if x { B() }` isn’t a replacement for `B().hidden(x)`. </p><p>But your question made me realize that in my case I actually *want* it, and `hidden` would be the wrong tool for the job. I think I would have realized it faster if I had been able to try out how hidden(false/true) behaves and that it doesn’t do what I want, but still, interesting. </p><p><a href="https://hachyderm.io/tags/SwiftUI" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>SwiftUI</span></a> trains us to want to solve basically everything via modifiers both because it’s „the SwiftUI style“ but also because there are often reminders about how conditionally applying modifiers (not passing conditions *to* modifiers) is bad for performance and likely breaks your animations as the two branches of if-else have different view identities and thus cause a recreation of the subviews. </p><p>I think there are likely still valid use cases for a hidden modifier with a book parameter, but I can imagine that at least half the time when people want to reach for it (like me now) `if` would actually be the correct choice.</p>