SE-0539: Enable Macros to Grant `self` Access for Property Initializers

[dohle (Nils Grabenhorst)]

Yes, maybe I should have left the link to that idea out of the proposal. It could only work if the SwiftUI dataflow team decided to support this use case. Any updates to @State and how it interacts with the environment are not part of this proposal.

I would suggest discussing this example in the original pitch thread to keep this proposal review focused.

Side Discussion

Thanks for the neat idea of putting the environment into a DynamicProperty. From reading the docs on DynamicProperty and environment values I would have never guessed this was possible. I always had assumed the environment wrapper needs to be in a struct conforming to View, otherwise there would be a warning like, "Accessing an Environment value outside of being installed on a View". I'll try it out though!

@vanvoorden

So I do think this pitch proposal has some good ideas overall worth discussing. But for this specific SwiftUI example I am not sure that trying to read from Environment before computing a view component body is ever officially supported. If the assumption is this "lazy" variable is only read at the time a view component body is computed then maybe it looks safe… but still feels a little "brittle" to me.

I would offer another solution built on DynamicProperty and update which is explicitly documented to run before our view component body is computed:

@Observable
final class Storage {
  private var modelContext: ModelContext? = nil
  
  init() {
    
  }
  
  func update(modelContext: ModelContext) {
    if self.modelContext !== modelContext {
      self.modelContext = modelContext
      ...
    }
  }
}

struct ViewModel: DynamicProperty {
  @Environment(\.modelContext) private var modelContext
  
  @State private var storage = Storage()
  
  func update() {
    self.storage.update(modelContext: self.modelContext)
  }
}