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

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

cc @Joe_Groff @Douglas_Gregor

3 Likes
4

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

5

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

10 Likes
6

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

16 Likes
7

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.)

8

Docs are up: Apple Developer Documentation

7 Likes
9

Also: Apple Developer Documentation

7 Likes
10

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

1 Like
11

That would be amazing!!!!

1 Like
12

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
13

Looks like a "prototype in prod" thing.

2 Likes
14

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

1 Like
16

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
17

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
18

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

4 Likes
19

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
20

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