var validHtml = #html(<p> This could produce an HTML struct containing this paragraph and further tools for adding and building a document </p>)
var invalidHtml = #html(<p> This is an unclosed paragraph and will yell at me at compile time)Well, now they can add ~Copyable to the struct and avoid that. With Rust-like ownership and borrow constructions.
Theoretically, yes, but then you need explicitly use
borrowing/consuming for every function that handles those types. If you do it for all application models, it will become unwieldy. From what I understood, the ownership and noncopyable enhancements to the language came from a need to improve Swift's performance predictability: you don't get unexpected copies of variables. As such, it does make sense to use them in things like tight loops or things that are in a hot path, but they're not designed to be the default setting. Besides, and while this will change in the future, non-copyable types as of now can't be used with Swift Generics nor conform to protocols. You can't even do var someVar: NonCopyableType? because that's syntactic sugar for Optional<NonCopyableType> and, as I said, generics are not yet supported.structs) are more performant than the "optimized", reference-only type, even for medium-sized models. There are good WWDC talks on this (both Understanding Swift Performance and Optimizing Swift Performance). In fact, the issue with big struct types is not (usually) the stack size as they feared, but rather the increased Automatic Reference Counting (ARC) traffic you get (for each reference-counted variable you have in a struct, like Array or String, you have to do a retain cycle, while if your model is class based you retain the entire class instead of the individual properties). The copying of the stack contents themselves is negligible unless you're building an exotic data structure.String or Array, which would have also ensured that the models were always passed by reference, like Swift maintainers suggest here. This would have kept the API of the model unchanged for external users, like a regular struct, while potentially reducing ARC traffic. But this is something that should be done IF the model has poor performance with the off-the-shelf solution (a regular struct), AND profiling/benchmarking shows that it's beneficial to adopt CoW. Implementing it by default in all models is a premature optimization that might not even turn out to be net-positive in performance (small structs are really fast, and you'd be adding another level of indirection (+ more ARC) by using a class instead).
Pretty sure bowstring is default and you only explicitly need to state consuming functions, but otherwise yes, agree with everything you wrote.
Yeah the compiler is really smart about all this and non-mutating, non-shared structs sometimes just automatically get passed by reference when it is guaranteed to maintain value semantics. It's pretty cool
You’re right that, by default, all functions have borrowing parameters (except initializers, which default to consuming). I thought there would still be many situations where you’d need to add explicit keywords, but I now think I overestimated that a bit. You would need to create explicitly borrowing inits for some objects, and I’m not sure if you’d need anything else for returns (as they’re consuming), but most places may not need changes due to the implicit behavior being already what you want.
Funnily enough, I was also writing about SwiftData on here when I reloaded the page and saw your post
A lot of things are still missing documentation in SwiftData. I'm under the impression that it's by far the roughest of the new APIs. Little documentation, several painful bugs... (i.e,
#Preview is still broken in Xcode 15 beta 2 for views using SwiftData objects). For example (related to the documentation) I had stumbled upon changedObjectsArray, and it looks like it could be useful for one of the problems I was having, but it's not documented.Almost every error I got so far related to CoreData was unhelpful. Most of the time I only got
[MyClass] does not conform to PersistentModel regardless of what the problem was.Data objects in SwiftData (as Data is not Codable by default). Worse even, adding a Data property to a @Model does not raise a warning or error, the property is simply not persisted. That's a weird default option, I definitely would have expected some kind of warning. I could trivially convert Data to String and make it Codable that way, but it feels like a hacky and dirty solution for what I thought was a common scenario (wanting to persist images using SwiftData).Yup, I had a similar issue.
@Query is very elegant if it covers the scope of what you want to do, but there isn't a lot of flexibility there. So far I'm happy to see how well the animations work, even with queries. If you use withAnimation { ... } to modify a SwiftData property used in several different views, I think all of them get animations too. That's cool.
#Preview {
MainActor.assumeIsolated {
TestView()
.modelContainer(model)
}
}
Weird. When I went to try this, I discovered what was triggering the issue. It seems like SwiftData only persists non-private variables? Just changing this:
private var imageData: Data?var imageData: Data?image:var image: Image? {
get {
guard let imageData else { return nil }
guard let uiImage = UIImage(data: imageData) else { return nil }
return Image(uiImage: uiImage)
}
}imageData private because in my experience, it's easy to forget that image exists and end up writing the code to convert Data to Image in different places throughout the code (also, conceptually the fact that the image is stored using its Data is an implementation detail).Data seems to be possible, but it's definitely not documented anywhere, documentation only mentions codable types.Hmm, codable enums should work. Maybe it's an Xcode beta problem? I remember reading that someone else was having issues with enums with Xcode beta 2.
Oh, this works!
Weird. When I went to try this, I discovered what was triggering the issue. It seems like SwiftData only persists non-private variables? Just changing this:
To this:Swift:private var imageData: Data?
Solved my issue. But I want the property to be privateSwift:var imageData: Data?
The thing is, I want to enforce that images are always read through the computed varimage:
Swift:var image: Image? { get { guard let imageData else { return nil } guard let uiImage = UIImage(data: imageData) else { return nil } return Image(uiImage: uiImage) } }
I'm insisting on keepingimageDataprivate because in my experience, it's easy to forget thatimageexists and end up writing the code to convertDatatoImagein different places throughout the code (also, conceptually the fact that the image is stored using itsDatais an implementation detail).
I wonder if this is a bug or the intended behaviour. In any case, persisting rawDataseems to be possible, but it's definitely not documented anywhere, documentation only mentions codable types.
Oh, I misunderstood. I thought even the basic setup wasn't working for you. In fact, I went to try it out and I can't even get the basic functionality to work, I found out that:
CoreData: error: Row (pk = 1) for entity 'FooEntity' is missing mandatory text data for property 'fooCaseA'.nil).
@CUScreenBuilder
func makeScreen() -> CUScreenTemplate {
CUList {
CUListSection {
for title in ["First", "Second", "Third"] {
CUListItem(text: title)
.task(perform: { item in
let fetchedImage = await fetchSomeImage()
item.image = fetchedImage
})
.onTap(perform: { item in
item.detailText = "I've Been Tapped"
})
}
}
}
}class MyObservable: ObservableObject {
@Published var fetchedImage: Image?
func fetchImage() {
Task {
let result = await fetchImageFromServer()
await MainActor.run {
fetchedImage = result
}
}
}
}class MyObservable: ObservableObject {
@Published var fetchedImage: Image?
func fetchImage() {
// This could also be written as Future(asyncFunc: fetchImageFromServer) in this case.
Future(asyncFunc: {
return await fetchImageFromServer()
})
.assign(to: &$fetchedImage)
}
}Yeah, it's probably just too low priority to invest the engineering hours required for a rewrite, even though it'd be way easier than things like SwiftData. Some Apple frameworks end up in that place not long after their original release.
@MainActor route for the entire class:@MainActor class MyObservable: ObservableObject {
@Published var fetchedImage: Image?
func fetchImage() async {
let result = await fetchImageFromServer()
fetchedImage = result
}
}fetchImageFromServer() is not @MainActor annotated itself, the code inside that function can run on any thread. But the fetchImage() function is @MainActor annotated (because the entire class is). So there's nothing that actually touches any @MainActor protected state until the fetchedImage = result line, other than the fetchImage() function itself. I honestly had to check what happens in this scenario, because I had no idea if the scheduler/compiler was smart enough to avoid doing this:fetchedImage = result line. Interestingly, it looks like it does not jump to the Main Actor at first! Everything is executed in the cooperative thread pool up until the fetchedImage = result line. So you should be able to call fetchImage() with the Main Actor busy, and the execution wouldn't be blocked until the fetchedImage property had to be set.@MainActor class MyObservable: ObservableObject {
@Published var fetchedImage: Image?
nonisolated func fetchImage() async {
let result = await fetchImageFromServer()
Task { @MainActor in
fetchedImage = result
}
}
}Yep, this circumvents the issue altogether. Though I wonder how Combine fits into the future Apple is planning for its Swift ecosystem. The new Observation framework is no longer built on top of Combine, right? I'm kinda worried about Combine falling out of style.
Yes, that's a huge caveat to keep in mind. In fact, when I went to test this I mistakingly thought at first that the code was doing a jump to the Main Actor at first because the call site was incidentally the Main Actor too. Maybe what's missing is a way to tell Swift Concurrency that some code should *not* be run on the Main Actor. I think the Swift Forums had some talk around the idea of introducing a @BackgroundActor annotation? I think right now you can do something like that with
Task.detached, which won't inherit (I think) the actor isolation context, but the (lack of) inheritance is in any case implicit, so it's a bit confusing to try to know what's running where.My counterpoint (for Swift Concurrency, at least) is that it's not that different to the "magic" compilers do with all kinds of optimizations, which are sometimes really hard to predict. But maybe some of those details are best left to the computer to figure out, rather than the programmer. I do agree however that some things that the programer definitely should know about are difficult to grasp in Swift Concurrency. An example of this would be, precisely, the question: Could this block a global actor (like the Main Actor)?. That's something that should be immediately clear to the programmer, to avoid having long-running code on the Main Actor, but isn't.
Well, over time you develop a intuition around what's happening underneath, but there are definitely some absurd scenarios at times. I couldn't find it again, but I read quite recently a thread on Twitter where a SwiftUI animation was fixed by adding a
.scaleEffect(1.0) to one of the components. Apparently actual Apple engineers were consulted too and that was indeed the way to fix it. That sounds like reciting incantation to me.
I meant that the async context is inherited implicitly from the call site in regular async calls.
Task.detached is probably the only case where you do know for sure what the async context is, as you point out.The context may not be easier to reason about locally, but the flow of code has now much better locality (compared to closure-based async code), so at least there's that. IMHO the tradeoff is worth it, I spent more time trying to make sense of what-is-calling-what when working with closure-based or RxSwift code than I will ever spend on Swift Concurrency trying to figure out in which context my code will be executed. But yes, definitely a tradeoff.
It would help a lot if they had open sourced it. The other day I was playing around with
@main because I needed to run some code before UIApplicationMain and couldn't quite break down how exactly does @main invoke UIApplicationMain in a SwiftUI app, so I had to go a completely different route (used an Objective-C NSObject's load method, which runs before main).String) to see how they had implemented it.
