{"id":9734,"date":"2025-07-23T14:35:00","date_gmt":"2025-07-23T11:35:00","guid":{"rendered":"https:\/\/handoli.com\/index.php\/2025\/07\/23\/deciding-between-let-and-var-for-swift-struct-properties\/"},"modified":"2025-07-23T14:35:00","modified_gmt":"2025-07-23T11:35:00","slug":"deciding-between-let-and-var-for-swift-struct-properties","status":"publish","type":"post","link":"https:\/\/handoli.com\/index.php\/2025\/07\/23\/deciding-between-let-and-var-for-swift-struct-properties\/","title":{"rendered":"Deciding between \u2018let\u2019 and \u2018var\u2019 for Swift struct properties"},"content":{"rendered":"

When declaring a Swift property, we use either the let<\/code> or var<\/code> keyword depending on whether we want our new property to be read-only once assigned through the enclosing type\u2019s initializer, or whether we want to allow the property to be mutated and re-assigned multiple times.<\/p>\n

However, that\u2019s not the only difference between using let<\/code> versus var<\/code> when working with Swift structs \u2014 as both approaches also influence the enclosing struct\u2019s behaviors in various ways. Let\u2019s explore!<\/p>\n

The side-effects of immutability<\/h2>\n

Let\u2019s say that we\u2019ve declared a User<\/code> struct within a project, which currently only contains constant let<\/code> properties:<\/p>\n

struct<\/span> User: Identifiable<\/span>, Codable<\/span> {\n    let<\/span> id: UUID<\/span>\n    let<\/span> name: String<\/span>\n    let<\/span> bio: String<\/span>\n    let<\/span> imageURL: URL<\/span>?\n}<\/code><\/pre>\n
Besides the fact that neither of those properties can be directly modified when working with a mutable User<\/code> value, marking imageURL<\/code> specifically as a let<\/code> actually influences how our struct\u2019s initializer behaves.<\/p>\n
When an optional struct property is declared as a let<\/code>, then we\u2019re always required<\/em> to pass a value for it when using the default compiler-generated, so-called member-wise<\/em> initializer. That means that even in situations when a user\u2019s imageURL<\/code> should be nil<\/code>, we have to explicitly specify that:<\/p>\n
let<\/span> user = User<\/span>(\n    id: UUID<\/span>(),\n    name: \"John Appleseed\"<\/span>,\n    bio: \"Famous person within the Apple Cinematic Universe\"<\/span>,\n    imageURL: nil<\/span>\n)<\/code><\/pre>\n
\n
If imageURL<\/code> was declared as a var<\/code> instead, then we could\u2019ve simply omitted that parameter above.<\/p>\n<\/blockquote>\n
Whether that\u2019s an advantage or disadvantage likely depends on the situation (and personal taste). Sometimes it\u2019s great that we can\u2019t forget to pass an imageURL<\/code>, and sometimes the above just leads to unnecessary boilerplate.<\/p>\n
Another way that let<\/code> properties differ from var<\/code>-declared ones is when it comes to default values<\/em>, since let<\/code> properties treat such values as constant declarations<\/em>. For example, let\u2019s say that we wanted to add a default value for our User<\/code> struct\u2019s id<\/code> property \u2014 to avoid having to manually pass UUID()<\/code> every time we create a new user:<\/p>\n
struct<\/span> User: Identifiable<\/span>, Codable<\/span> {\n    let<\/span> id = UUID<\/span>()\n    let<\/span> name: String<\/span>\n    let<\/span> bio: String<\/span>\n    let<\/span> imageURL: URL<\/span>?\n}<\/code><\/pre>\n
If id<\/code> was a var<\/code>, then the above change would simply mean that our UUID()<\/code> expression would be used unless<\/em> we pass an explicit value for that parameter (either when directly initializing User<\/code>, or when decoding a value from a data format, such as JSON). However, since it\u2019s a let<\/code>, it now means that we can\u2019t<\/em> actually pass a value for that property at all \u2014 the UUID()<\/code> expression will always be used, and there\u2019s no way to override that.<\/p>\n
Since our User<\/code> type also conforms to Decodable<\/code> (through the Codable<\/code> type alias), that actually also means that no id<\/code> value will ever be decoded, and any such value that\u2019s present within the JSON (or other data format) that we\u2019re decoding from will simply be ignored. In fact, the Swift compiler will even give us a warning when using the above pattern, since it\u2019s likely not the decoding behavior we want our type to have.<\/p>\n
Manually declared initializers<\/h2>\n
So what if we wanted to change some of the behaviors that we explored above? One way to do that would be to manually declare our type\u2019s initializer, rather than relying on the member-wise one that the compiler generates for us. For example, let\u2019s say that we wanted to allow call sites to omit the imageURL<\/code> property if it should simply be nil<\/code> (without changing it to a var<\/code>), and\/or use a default UUID<\/code> for the id<\/code> property if no explicit value was passed. That could be done like this:<\/p>\n
struct<\/span> User: Identifiable<\/span>, Codable<\/span> {\n    let<\/span> id: UUID<\/span>\n    let<\/span> name: String<\/span>\n    let<\/span> bio: String<\/span>\n    let<\/span> imageURL: URL<\/span>?\n\n    init<\/span>(id: UUID<\/span> = UUID<\/span>(),\n         name: String<\/span>,\n         bio: String<\/span>,\n         imageURL: URL<\/span>? = nil<\/span>) {\n        self<\/span>.id<\/span> = id\n        self<\/span>.name<\/span> = name\n        self<\/span>.bio<\/span> = bio\n        self<\/span>.imageURL<\/span> = imageURL\n    }\n}<\/code><\/pre>\n
The above strikes a quite nice balance between maintaining immutability (if that\u2019s something we want), while still enabling convenience features like default values \u2014 at the cost of having to manually write and maintain our own explicit initializer.<\/p>\n
A property wrapper alternative<\/h2>\n
An alternative approach to the above, which may be something we want to consider if we want to deploy the constants-with-default-values<\/em> pattern in many places across a larger code base, is to use a property wrapper to make var<\/code> properties read-only<\/em>.<\/p>\n
Since the mutability of a wrapped property depends on the wrapper itself, we could declare a Readonly<\/code> wrapper type which marks its wrappedValue<\/code> as a let<\/code> \u2014 like this:<\/p>\n
@propertyWrapper struct<\/span> Readonly<Value> {\n    let<\/span> wrappedValue: Value<\/span>\n}<\/code><\/pre>\n
Since we\u2019re planning to use our Readonly<\/code> wrapper within types that conform to Encodable<\/code> and Decodable<\/code>, then we also need to adopt those protocols for our wrapper as well \u2014 since all coding tasks are deferred to property wrappers when they\u2019re used:<\/p>\n
extension<\/span> Readonly<\/span>: Encodable<\/span> where<\/span> Value<\/span>: Encodable<\/span> {\n    func<\/span> encode(to encoder: Encoder<\/span>) throws<\/span> {\n        var<\/span> container = encoder.singleValueContainer<\/span>()\n        try<\/span> container.encode<\/span>(wrappedValue)\n    }\n}\n\nextension<\/span> Readonly<\/span>: Decodable<\/span> where<\/span> Value<\/span>: Decodable<\/span> {\n    init<\/span>(from decoder: Decoder<\/span>) throws<\/span> {\n        let<\/span> container = try<\/span> decoder.singleValueContainer<\/span>()\n        wrappedValue = try<\/span> container.decode<\/span>(Value<\/span>.self<\/span>)\n    }\n}<\/code><\/pre>\n
\n
Above we\u2019re using Swift\u2019s conditional conformances feature to not have to require that all Readonly.Value<\/code> types always have to conform to Encodable<\/code> and Decodable<\/code>, which would limit our property wrapper\u2019s versatility.<\/p>\n<\/blockquote>\n
With the above in place, we can now go ahead and update our User<\/code> type to use Readonly<\/code>-marked var<\/code> declarations for the properties that we want to define a default value for:<\/p>\n
struct<\/span> User: Identifiable<\/span>, Codable<\/span> {\n    @Readonly var<\/span> id = UUID<\/span>()\n    let<\/span> name: String<\/span>\n    let<\/span> bio: String<\/span>\n    @Readonly var<\/span> imageURL: URL<\/span>?\n}<\/code><\/pre>\n
\n
Note that, since we\u2019re now using a var<\/code> for our type\u2019s imageURL<\/code> property, it\u2019s default value automatically becomes nil<\/code> \u2014 there\u2019s no need for us to declare that manually.<\/p>\n<\/blockquote>\n
The advantage of the above approach is that we now have a reusable solution that helps us avoid having to manually declare initializers when all we want is to be able to define default values for read-only properties. However, whenever we use a non-standard solution, like the one above, it\u2019s important to consider whether the inherent additional complexity of such a custom solution is worth the benefits that we get from it.<\/p>\n
Is immutability always the answer?<\/h2>\n
Another alternative approach to make our properties support default values is to simply declare them using var<\/code> instead. While that does<\/em> enable those properties to be mutated, perhaps that isn\u2019t actually a problem, given that all structs are by default passed as immutable copies when calling a function or when initializing another type.<\/p>\n
In practice, that means that structs don\u2019t have the same shared mutable state<\/em> problem that classes often do (unless static mutable values are used), so the question is how problematic it would actually be to do something like this:<\/p>\n
struct<\/span> User: Identifiable<\/span>, Codable<\/span> {\n    var<\/span> id = UUID<\/span>()\n    var<\/span> name: String<\/span>\n    var<\/span> bio: String<\/span>\n    var<\/span> imageURL: URL<\/span>?\n}<\/code><\/pre>\n
One benefit<\/em> of making our structs as mutable as possible is that doing so often makes it much easier to write unit tests \u2014 either when our structs are used as stub values, or when the structs themselves are the types being tested. For example, let\u2019s say that we wanted to add a method for normalizing a given user\u2019s name:<\/p>\n
extension<\/span> User<\/span> {\n    mutating func<\/span> normalizeName() {\n        name = name\n            .filter<\/span> { char in<\/span>\n                char.isLetter<\/span> || (char.isWhitespace<\/span> && !char.isNewline<\/span>)\n            }\n            .trimmingCharacters<\/span>(in: .whitespaces<\/span>)\n    }\n}<\/code><\/pre>\n
Since the name<\/code> property is now a var<\/code>, we could easily write a test that verifies various normalization scenarios, all while reusing the same User<\/code> value \u2014 for example like this:<\/p>\n
struct<\/span> UserTests {\n    @Test func<\/span> normalizingName() {\n        var<\/span> user = User<\/span>(name: \"Name\"<\/span>, bio: \"Bio\"<\/span>)\n\n        \/\/ Non-letter characters are removed:<\/span>\n        user.name<\/span> = \"!1_First 2;Last_3?\"<\/span>\n        user.normalizeName<\/span>()\n        #expect<\/span>(user.name<\/span> == \"First Last\"<\/span>)\n\n        \/\/ Leading and trailing whitespaces are removed:<\/span>\n        user.name<\/span> = \" White Spaces \"<\/span>\n        user.normalizeName<\/span>()\n        #expect<\/span>(user.name<\/span> == \"White Spaces\"<\/span>)\n    }\n}<\/code><\/pre>\n
It\u2019s also important to remember that just because we mark a given struct property as a let<\/code> doesn\u2019t mean that its value can never change<\/em>, since the mutability of a given value is always determined by the top-level, enclosing value that the property is contained within.<\/p>\n
For example, let\u2019s say that we wanted to make another attempt at striking a nice balance between mutability and consistency for our User<\/code> type \u2014 this time by making all non-id<\/code> properties variables, while keeping the id<\/code> property a let<\/code> (since that\u2019s the one property we never expect to change throughout the lifetime of a User<\/code> value):<\/p>\n
struct<\/span> User: Identifiable<\/span>, Codable<\/span> {\n    let<\/span> id: UUID<\/span>\n    var<\/span> name: String<\/span>\n    var<\/span> bio: String<\/span>\n    var<\/span> imageURL: URL<\/span>?\n}<\/code><\/pre>\n
Then, let\u2019s say that we wanted to introduce an API for transforming a given User<\/code> value in some way, for example by using the normalizeName<\/code> method we defined earlier. Such an API could take the form of a UserTransformer<\/code> protocol, which uses Swift\u2019s inout<\/code> parameter feature to enable each transformer to directly mutate the User<\/code> value that was passed to it, without first having to make a mutable copy:<\/p>\n
protocol<\/span> UserTransformer {\n    func<\/span> transformUser(_<\/span> user: inout<\/span> User<\/span>)\n}\n\nstruct<\/span> UserNameNormalizer: UserTransformer<\/span> {\n    func<\/span> transformUser(_<\/span> user: inout<\/span> User<\/span>) {\n        user.normalizeName<\/span>()\n    }\n}<\/code><\/pre>\n
So the question is, with the above setup, do we have a guarantee<\/em> that the id<\/code> property of any User<\/code> value that was passed to a UserTransformer<\/code> implementation can never be changed? No, actually, we don\u2019t. Because we have to remember, the User<\/code> value itself<\/em> is mutable, and it can be completely re-assigned with a brand new UUID<\/code> if the implementation so desires \u2014 for example like this:<\/p>\n
struct<\/span> UserIDTransformer: UserTransformer<\/span> {\n    func<\/span> transformUser(_<\/span> user: inout<\/span> User<\/span>) {\n        user = User<\/span>(\n            id: UUID<\/span>(),\n            name: user.name<\/span>,\n            bio: user.bio<\/span>,\n            imageURL: user.imageURL<\/span>\n        )\n    }\n}<\/code><\/pre>\n
Admittedly, code like the above is quite likely to raise some eyebrows during code review (when working with a team), but it just illustrates how we have to think about value types \u2014 such as structs and enums \u2014 when working with them. They don\u2019t have the same concept of identity<\/em> and a lifecycle<\/em>, like classes and actors do, which is important to remember when we design our types and their associated APIs.<\/p>\n
Conclusion<\/h2>\n
So how do<\/em> you decide between using let<\/code> and var<\/code> when declaring struct properties? My personal approach is to keep my struct properties mutable by default<\/em>, since I feel like that really leans into the core concept of value types \u2014 that it\u2019s the enclosing value, not individual properties, that actually determines the real mutability of a given value.<\/p>\n
That being said, marking properties that we never expect to be mutated (such as a type\u2019s ID) as let<\/code> is also usually a good practice \u2014 even though it doesn\u2019t strictly guarantee that such values will never change, it at least signals to everyone on the team what the intended<\/em> mutability of such a property is.<\/p>\n
What do you think? Let me know what your thoughts are on this topic \u2014 along with any questions or feedback you might have \u2014 on either Mastodon<\/a> or Bluesky<\/a>.<\/p>\n
Thanks for reading!<\/p>","protected":false},"excerpt":{"rendered":"
When declaring a Swift property, we use either the let or var keyword depending on whether we want our new property to be read-only once assigned through the enclosing type\u2019s initializer, or whether we want to allow the property to be mutated and re-assigned multiple times. However, that\u2019s not the only difference between using let […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rop_custom_images_group":[],"rop_custom_messages_group":[],"rop_publish_now":"initial","rop_publish_now_accounts":[],"rop_publish_now_history":[],"rop_publish_now_status":"pending","footnotes":""},"categories":[1,15],"tags":[],"class_list":["post-9734","post","type-post","status-publish","format-standard","hentry","category-explore","category-world"],"_links":{"self":[{"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/posts\/9734","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/comments?post=9734"}],"version-history":[{"count":0,"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/posts\/9734\/revisions"}],"wp:attachment":[{"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/media?parent=9734"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/categories?post=9734"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/tags?post=9734"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}