What is this thing from WWDC?

struct Content: View {
  @State var model = ... // property wrappers?

  var body: some View { ... } // reversed generics or opaque types?
}

cc @Joe_Groff @Douglas_Gregor

3 Likes

well maybe that's why the property delegates SE was returned :)

I'll be posting a pitch about this in a bit.

10 Likes

Both property wrappers and opaque result types are used in that example, yeah.

16 Likes

Apple also mentioned that they have a new way for app distribution or deployment (don't remember the exact wording), does this affect how apps can be deployed? If so, will the core team or other members enlighten us soon?

Stdlib / Runtime slices for example :crossed_fingers: imbedded into the app bundles. (Wish thinking.)

Docs are up: Apple Developer Documentation

7 Likes

Also: Apple Developer Documentation

7 Likes

I hope to see the open sourcing of both of those libraries.

1 Like

That would be amazing!!!!

1 Like

All part of the standard evolution process, right?

"Prototyping an implementation and its uses along with the proposal is required because it helps ensure both technical feasibility of the proposal as well as validating that the proposal solves the problems it is meant to solve." :grinning:

1 Like

Looks like a "prototype in prod" thing.

2 Likes

With back-pressure, too. I guess I can stop fiddling with my toy version of that.

1 Like

I'm more interested in the contents of that var body block: looks like multiple initializers get inferred into a single View type somehow?

2 Likes

from Apple Developer Documentation

static func buildBlock() -> EmptyView

Builds an empty view from a block containing no statements.
static func buildBlock<Content>(Content) -> Content

Passes a single view written as a child view through unmodified.
static func buildBlock<C0, C1>(C0, C1) -> TupleView<(C0, C1)>
static func buildBlock<C0, C1, C2>(C0, C1, C2) -> TupleView<(C0, C1, C2)>
static func buildBlock<C0, C1, C2, C3>(C0, C1, C2, C3) -> TupleView<(C0, C1, C2, C3)>
static func buildBlock<C0, C1, C2, C3, C4>(C0, C1, C2, C3, C4) -> TupleView<(C0, C1, C2, C3, C4)>
static func buildBlock<C0, C1, C2, C3, C4, C5>(C0, C1, C2, C3, C4, C5) -> TupleView<(C0, C1, C2, C3, C4, C5)>
static func buildBlock<C0, C1, C2, C3, C4, C5, C6>(C0, C1, C2, C3, C4, C5, C6) -> TupleView<(C0, C1, C2, C3, C4, C5, C6)>
static func buildBlock<C0, C1, C2, C3, C4, C5, C6, C7>(C0, C1, C2, C3, C4, C5, C6, C7) -> TupleView<(C0, C1, C2, C3, C4, C5, C6, C7)>
static func buildBlock<C0, C1, C2, C3, C4, C5, C6, C7, C8>(C0, C1, C2, C3, C4, C5, C6, C7, C8) -> TupleView<(C0, C1, C2, C3, C4, C5, C6, C7, C8)>
static func buildBlock<C0, C1, C2, C3, C4, C5, C6, C7, C8, C9>(C0, C1, C2, C3, C4, C5, C6, C7, C8, C9) -> TupleView<(C0, C1, C2, C3, C4, C5, C6, C7, C8, C9)>

what happened guys

6 Likes

Okay, read this to understand what's going on on the meta level, and read this to understand what's happening technically.

4 Likes

Someone, please tell me a fix is in the works so we don't have to hard-code support for N tuples in a DSL.

Edit: we're still pending variadic generics, so this will get fixed. Sorry, I hadn't read the full thread. Mentioning it here so anyone else like me doesn't find this and panic. cc @taylorswift

1 Like

As I understand it, every similar API will eventually be deprecated when Swift adds support for variadic generics. :slight_smile: And as noted somewhere, SwiftUI adds more pressure to push variadic generics forward.

1 Like