Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A deep dive into Swift’s function builders

swiftbysundell.com

Post reply on HN
Print view View original

11–20 of 39 posts

Re: A deep dive into Swift’s function builders

#11

Post by jumhyn »

ridiculous_fish wrote: post #8
jumhyn wrote: post #5

Earlier quoted context omitted.

From what I understand, SwiftUI uses this so that each "snapshot" of the View tree generated by the app can be intelligently diffed against future snapshots. This helps make rendering more efficient, as well as with things like animations. Consider a simple view like: var body: some View { if someStateBool { Text("True") } else { Text("False") } Suppose that initially, `someStateBool ` evaluates to `true`, and then i…

It's more fundamental than that. Consider: var body : some View { if something { return Image("hi") } else { return Text("hi") } } this function won't even compile because Swift infers different types for the returns (Image vs Text). In order to give the return value a type, the if statement has to be encoded in the type system itself.

That problem could have been resolved via type erasure (either via `AnyView`, or, if SwiftUI had been designed differently, by having the `body` property be of type `View` rather than `some View`). In fact, opaque types (a la `some View`) were motivated by SwiftUI so that the type information could be preserved to enable the necessary optimizations/animations, without requiring users/library authors to write out/expose the complex type signatures that can arise from even simple view hierarchies.

Incidentally, if you use `AnyView` liberally you’ll likely see worse automatic animations and degraded performance [ETA: the “degraded performance” claim here appears to have been debunked—see the link below for more info!].

Re: A deep dive into Swift’s function builders

#12

Post by LeoNatan25 »

jumhyn wrote: post #11
ridiculous_fish wrote: post #8

Earlier quoted context omitted.

It's more fundamental than that. Consider: var body : some View { if something { return Image("hi") } else { return Text("hi") } } this function won't even compile because Swift infers different types for the returns (Image vs Text). In order to give the return value a type, the if statement has to be encoded in the type system itself.

That problem could have been resolved via type erasure (either via `AnyView`, or, if SwiftUI had been designed differently, by having the `body` property be of type `View` rather than `some View`). In fact, opaque types (a la `some View`) were motivated by SwiftUI so that the type information could be preserved to enable the necessary optimizations/animations, without requiring users/library authors to write out/expo…

Despite what is claimed about AnyView, this has for the most part been proven wrong. AnyView is just as fast, if not faster.

https://nalexn.github.io/anyview-vs-group/

In fact, Apple themselves use AnyView internally for many of their controller presentations (such as sheets and pushed controllers).

Re: A deep dive into Swift’s function builders

#13

Post by heavyset_go »

LeoNatan25 wrote: post #10

I must have a different idea of what “deep dive” means; this is simply going through the (relatively simple) motions of implementing a builder. “Deep dive”, to me, would look at how the compiler translates statements using these builders, for example, or reverse-engineering Apple’s builders for juicy information. I’ve recently forayed into SwiftUI to see what all the fuss was. I have to say, I really feel for people…

> I’m getting old.

I think you hit the nail on the head with this observation:

> Instead, what we have is a culture of very shallow and information-light “articles”, that seems to me more like SEO bot posts trolling for clicks, rather than written for developers, by developers.

For a while now, content's been created as a means to improve SEO, and it's really obvious when an article was written just so it contains the right mashup of keywords and that it's padded to just the right length.

Re: A deep dive into Swift’s function builders

#14

Post by jumhyn »

LeoNatan25 wrote: post #12
jumhyn wrote: post #11

Earlier quoted context omitted.

That problem could have been resolved via type erasure (either via `AnyView`, or, if SwiftUI had been designed differently, by having the `body` property be of type `View` rather than `some View`). In fact, opaque types (a la `some View`) were motivated by SwiftUI so that the type information could be preserved to enable the necessary optimizations/animations, without requiring users/library authors to write out/expo…

Despite what is claimed about AnyView, this has for the most part been proven wrong. AnyView is just as fast, if not faster. https://nalexn.github.io/anyview-vs-group/ In fact, Apple themselves use AnyView internally for many of their controller presentations (such as sheets and pushed controllers).

Great article! Glad to have that misconception cleared up.

Re: A deep dive into Swift’s function builders

#15

Post by Benjammer »

LeoNatan25 wrote: post #10

I must have a different idea of what “deep dive” means; this is simply going through the (relatively simple) motions of implementing a builder. “Deep dive”, to me, would look at how the compiler translates statements using these builders, for example, or reverse-engineering Apple’s builders for juicy information. I’ve recently forayed into SwiftUI to see what all the fuss was. I have to say, I really feel for people…

Two reasons for these shallow, high-level-walk-through type of articles that I've seen are to pad a resume or to pad a promotion packet.

Re: A deep dive into Swift’s function builders

#16

Post by LeoNatan25 »

Benjammer wrote: post #15
LeoNatan25 wrote: post #10

I must have a different idea of what “deep dive” means; this is simply going through the (relatively simple) motions of implementing a builder. “Deep dive”, to me, would look at how the compiler translates statements using these builders, for example, or reverse-engineering Apple’s builders for juicy information. I’ve recently forayed into SwiftUI to see what all the fuss was. I have to say, I really feel for people…

Two reasons for these shallow, high-level-walk-through type of articles that I've seen are to pad a resume or to pad a promotion packet.

Sure, this is a problem in general when companies require or “heavily encourage” its engineering to post “blogs”. And some developers are just not writers, or lack the skill to do proper articles.

But, here, this is not the case; the author makes their living from this. With the former engineers, that’s excusable. Here, less so.

Re: A deep dive into Swift’s function builders

#17

Post by tsycho »

LeoNatan25 wrote: post #10

I must have a different idea of what “deep dive” means; this is simply going through the (relatively simple) motions of implementing a builder. “Deep dive”, to me, would look at how the compiler translates statements using these builders, for example, or reverse-engineering Apple’s builders for juicy information. I’ve recently forayed into SwiftUI to see what all the fuss was. I have to say, I really feel for people…

The funny part is that Sundell and Hacking With Swift are actually among the more useful sites, offering bite sized information that you would expect Apple documentation to provide.

But Apple's documentation nowadays, is so bad (inconsistently so, some parts are fine) that these sites are filling the gap.

Further, for most other languages, Stack Overflow fits this need mostly fine. But Swift and SwiftUI have been changed so often that the accepted answer on Stack Overflow becomes outdated within a year.

Re: A deep dive into Swift’s function builders

#18

Post by adamnemecek »

LeoNatan25 wrote: post #10

I must have a different idea of what “deep dive” means; this is simply going through the (relatively simple) motions of implementing a builder. “Deep dive”, to me, would look at how the compiler translates statements using these builders, for example, or reverse-engineering Apple’s builders for juicy information. I’ve recently forayed into SwiftUI to see what all the fuss was. I have to say, I really feel for people…

> As if the language somehow defines the identity of the developers, and apps magically become much better as virtue of the language used, rather than the system frameworks.

Language matters just as much as the frameworks.

Re: A deep dive into Swift’s function builders

#19

Post by setr »

rudedogg wrote: post #7
setr wrote: post #2

I don't understand the necessity for BuildIf/BuildEither -- what could you possibly want to inject into a control-flow construct during initialization?

Not sure if I'm missing something, but under the "Conditionals" heading there is an example. I've been writing a lot of SwiftUI code since it came out - and a common use is like that example. Imagine a settings UI where you want to only show an advanced option if a switch/checkbox is toggled.

The example of...

    static func buildIf(_ value: SettingsConvertible?) -> SettingsConvertible {
        value ?? []
    }
and

    static func buildEither(first: SettingsConvertible) -> SettingsConvertible {
        first
    }

    static func buildEither(second: SettingsConvertible) -> SettingsConvertible {
        second
    }
?

These just return their values -- the only one of note is that buildIf returns the empty array by default, but otherwise this is just defining an if statement to be an if statement.

It gives you however to make an if statement do something other than being an if statement, and that seems... bad.

You could for example define it as

    static func buildEither(first: SettingsConvertible) -> SettingsConvertible {
        []
    }
    static func buildEither(second: SettingsConvertible) -> SettingsConvertible {
        []
    }

Re: A deep dive into Swift’s function builders

#20

Post by dwaite »

setr wrote: post #2

I don't understand the necessity for BuildIf/BuildEither -- what could you possibly want to inject into a control-flow construct during initialization?

In other languages, the builder pattern usually consists of just methods on a builder object that manipulate internal state until you 'build' an instance. Function builders on the other hand support building of a strong type.

The builder can convert expressions into components that are then assembled into results. Some applications want to be able to represent the result as a strong generic type.

As an example of this, imagine

  if let releaseName = releaseName {
     Div("Release \(releaseName)")
  else {
     Blink("Prerelease")
  }
might be captured by such a builder as an Either.
Post reply on HN