Add non-mutating support to `LazyInjected` for use in value types (`struct`)

[o-nnerb]

Description:

Currently, LazyInjected<T> can't be used inside a struct unless the entire struct is marked as mutating whenever the wrapped value is accessed. This severely limits its usability in value-type contexts, especially in SwiftUI views or other immutable setups where mutation isn't desired or even possible (e.g., inside let constants or non-mutating closures).

The issue stems from the wrappedValue implementation, which is declared as mutating get. While lazy initialization inherently implies mutation of internal state, it’s possible to work around this in Swift by using reference types internally (e.g., a private class holder) to manage the lazy resolution without requiring the outer wrapper to be mutating.

Proposed solution

Refactor LazyInjected to store its state (like dependency and initialize) in a separate reference-type container (e.g., LazyStorage<T>). This would allow wrappedValue to be non-mutating from the consumer’s perspective while still enabling lazy resolution under the hood.

This pattern is already used by other property wrappers in the Swift ecosystem (e.g., @StateObject in SwiftUI) and would preserve the current API while greatly expanding compatibility.

Current limitation example

struct MyView {
    @LazyInjected(\.myService) private var service // ❌ Can't use without mutating context
}

This forces awkward workarounds or prevents adoption in pure value-type architectures.

Benefits

• Enables use of LazyInjected in structs without requiring mutating methods.
• Maintains lazy, on-demand resolution semantics.
• Keeps backward compatibility if implemented carefully.

Would you be open to a PR implementing this approach?

[hmlongco]

The primary use case for LazyInjected is performance and avoiding the creation of an object unnecessary. And that case is weakened if one is always creating an object to hold the object in question.

Further, the only way to persist such state is to do something like we've done in InjectedObservable, and use a State variable to persist the thunk. In effect letting State create an object that holds the object that holds the lazy object.

That's required because, unlike State and StateObject, custom property wrappers don't have access to a view's identity and as such have no way of persisting distinct instances over a view's lifetime. One could rely on Factory to cache and persist such objects... but if you're doing that then there's little to no benefit over simply using Injected and avoiding the indirection.

That said, using Injected in a View is somewhat contra-indicated as well, as a new injection will occur every time the view is recreated during a parent view evaluation. If the instance was cached that's not so bad. If not...

Finally--and not to go off on a rant--I'm not a big believer in "pure value-type architectures". Use a dozen State values in a view and all you're effectively doing is letting SwiftUI create a dozen StateObject equivalents for you and continually performing identity lookups to find each and every one when needed.

Stuff a dozen variables into a structure and cram that into a single State... and again you're letting SwiftUI basically allocate and create a view model for you behind the scenes. Worse, that VM is less efficient than a pure Observable, since every mutation pretty requires the entire structure to be recopied and any change to any element is propagated a a view update.

Apple provided StateObject, EnvironmentObject, and Observable for a reason.

And I added InjectedState and InjectedObservable to support them.

/r