struct Content: View {
@State var model = ... // property wrappers?
var body: some View { ... } // reversed generics or opaque types?
}
well maybe that's why the property delegates SE was returned :)
I'll be posting a pitch about this in a bit.
Both property wrappers and opaque result types are used in that example, yeah.
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 imbedded into the app bundles. (Wish thinking.)
I hope to see the open sourcing of both of those libraries.
That would be amazing!!!!
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."
Looks like a "prototype in prod" thing.
With back-pressure, too. I guess I can stop fiddling with my toy version of that.
I'm more interested in the contents of that var body
block: looks like multiple initializers get inferred into a single View type somehow?
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
Okay, read this to understand what's going on on the meta level, and read this to understand what's happening technically.
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
As I understand it, every similar API will eventually be deprecated when Swift adds support for variadic generics. And as noted somewhere, SwiftUI adds more pressure to push variadic generics forward.