# It's 2025, can we have a “lazy let”? **URL:** \ **Category:** Using Swift\ **Created:** [April 20, 2025, 2:35pm UTC](https://forums.swift.org/t/its-2025-can-we-have-a-lazy-let/79403 "2025-04-20T14:35:04Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![ksluder](https://avatars.discourse-cdn.com/v4/letter/k/eada6e/32.png) [@ksluder](https://forums.swift.org/u/ksluder)\ **Post date:** [April 20, 2025, 7:03pm UTC](https://forums.swift.org/t/its-2025-can-we-have-a-lazy-let/79403/4 "2025-04-20T19:03:41Z")
This is very closely related to [the recent discussion about `weak let`](https://forums.swift.org/t/pitch-weak-let/79271). Swift has evolved such that `let` and `var` really refer to ownership, not mutability. A `let` variable/property only exposes operations that can be done with shared ownership. A `var` variable/property can also expose operations which require exclusive ownership. Since a `lazy` variable mutates its storage on first access, it must be a `var`. Atomics are the exception that proves this rule: they must be declared `let`, but they support mutating operations. This is because a mutating atomic operation is defined to not require exclusive ownership. Shared mutability is the whole point of atomics, after all. But it does mean if your type contains a public atomic property, you can no longer rely on the law of exclusivity to protect that value’s in-memory representation. `lazy` is not currently thread-safe, but a hypothetical thread-safe version of `lazy` could theoretically be declared `let`. But that would significantly expand the aforementioned hole in the law of exclusivity. The Language Workgroup argued that anyone writing an atomic variable is opting into the paradox of mutability under non-exclusive ownership. I doubt this would be considered true of `lazy let`. --- _[View the full topic](https://forums.swift.org/t/its-2025-can-we-have-a-lazy-let/79403)._