Author: Smin Rana

Swift extensions are one of the most powerful features in the language. They let you add behavior to types you don’t own, cleanly organize code, and unlock advanced patterns with protocols and generics. But they’re also easy to misuse—leading to scattered logic, hidden dependencies, and brittle designs.

This guide is a practical, deep dive into extensions in Swift: what they are, how they work, and—most importantly—how to use them well in real projects. It includes patterns, pitfalls, examples, refactoring strategies, performance notes, and design lore you won’t find in API docs.

Whether you’re building an iOS app, a SwiftUI component library, or server‑side Swift, mastering extensions will make your codebase more modular, testable, and expressive.

What Is an Extension?

An extension lets you add new functionality to an existing type without subclassing or changing the original source. You can extend:

• Standard Library types: Array, String, Dictionary, Optional, Sequence, etc.
• Foundation types: Date, URL, Data, Locale, etc.
• SDK types: UIViewController, UIColor, UIFont, etc.
• Your own types: structs, classes, enums, and protocols.

Extensions can add:

• Instance and static methods
• Computed properties (but not stored properties)
• Initializers
• Nested types
• Protocol conformance and default implementations
• Subscript implementations (if allowed)

You cannot add stored properties or override existing methods with an extension. Extensions are additive, not mutative.

Why Extensions Matter

If you’ve ever found yourself writing utility classes, static helpers, or god objects, extensions are the clean alternative. They:

• Co-locate behavior with the type it belongs to
• Reduce the surface area of objects and APIs
• Improve discoverability via autocomplete
• Enable protocol‑oriented programming
• Support separation of concerns (feature‑based organization)
• Avoid subclassing for simple behavior additions

The payoff: code that reads like prose. Instead of DateUtils.isSameDay(a, b), you can write a.isSameDay(as: b).

The Golden Rules of Extensions

Before diving into patterns, a few rules can keep your extensions healthy:

• Keep them focused: One reason per extension. Don’t lump unrelated utilities.
• Prefer protocol conformance extensions over ad‑hoc helpers.
• Use fileprivate and internal wisely to limit surface area.
• Avoid name collisions with the original type or other modules.
• Don’t surprise users: extensions should be obvious, discoverable, and documented.
• Avoid side effects in initializers added via extensions unless you own the type lifecycle.

A Running Example App

To make this guide concrete, we’ll work with examples you can drop into a project. Imagine a journal app with entries and tags, plus some UI and networking.

Example Types

struct Entry: Identifiable, Hashable {
    let id: UUID
    var title: String
    var body: String
    var createdAt: Date
    var tags: [Tag]
}

struct Tag: Hashable {
    var name: String
}

We’ll add capabilities to Date, String, Array, Sequence, URL, and our own types using extensions.

Core Patterns You’ll Use Daily

1) Computed Properties for Expressiveness

Computed properties convert procedural code into readable nouns.

extension Date {
    var isToday: Bool { Calendar.current.isDateInToday(self) }
    var isWeekend: Bool { Calendar.current.isDateInWeekend(self) }
}

extension String {
    var trimmed: String { trimmingCharacters(in: .whitespacesAndNewlines) }
    var words: [String] {
        components(separatedBy: CharacterSet.whitespacesAndNewlines)
            .filter { !$0.isEmpty }
    }
}

Use them to expose domain concepts as first‑class citizens.

2) Initializers for Safer Construction

Extensions can add convenience initializers to your types.

extension URL {
    init?(safe string: String) {
        guard let url = URL(string: string) else { return nil }
        self = url
    }
}

Tip: Prefer failable initializers when dealing with external input.

3) Protocol Conformance via Extensions

Adding protocol conformance is a top‑tier pattern. It separates core data from behavior and promotes reuse.

// Domain model remains lightweight
struct Money { let cents: Int }

// Conform to Codable without cluttering the primary declaration
extension Money: Codable {}

// Conform to CustomStringConvertible for better logging
extension Money: CustomStringConvertible {
    var description: String {
        let dollars = Double(cents) / 100.0
        return String(format: "$%.2f", dollars)
    }
}

Keep primary declarations minimal. Put conformance in dedicated extensions to make intent explicit and keep diffs small.

4) Namespacing Static Helpers

Stop sprinkling global functions. Attach static helpers where they logically live.

extension Locale {
    static var appPreferred: Locale { Locale(identifier: "en_US_POSIX") }
}

extension DateFormatter {
    static let iso8601: DateFormatter = {
        let f = DateFormatter()
        f.locale = .appPreferred
        f.dateFormat = "yyyy-MM-dd'T'HH:mm:ss.SSSZZZZZ"
        return f
    }()
}

Use static properties and functions for reusable configuration.

5) Conditional Conformance

Swift shines when you can add behavior only when type parameters meet constraints.

extension Array: CustomStringConvertible where Element: CustomStringConvertible {
    public var description: String {
        "[" + map(\.$description).joined(separator: ", ") + "]"
    }
}

This keeps APIs small but powerful. Your generic types behave like pros in the right contexts.

Expert Patterns for Real Apps

Feature‑Scoped Extensions

Organize extensions by feature rather than type, to keep modules cohesive.

// File: Date+Journal.swift
extension Date {
    var journalSectionTitle: String {
        let f = DateFormatter()
        f.dateStyle = .medium
        return f.string(from: self)
    }
}

• Naming: Type+Feature.swift (e.g., String+Validation.swift).
• Scope: Keep file groups per feature to avoid scattering logic across the project.

Protocol‑Oriented Design with Defaults

Protocols provide contracts; extensions provide default behavior. Together they form reusable micro‑frameworks.

protocol Validatable {
    func validate() throws
}

enum ValidationError: Error { case emptyTitle, tooShort }

extension Entry: Validatable {
    func validate() throws {
        if title.trimmed.isEmpty { throw ValidationError.emptyTitle }
        if body.count < 10 { throw ValidationError.tooShort }
    }
}

You can also provide default behavior via protocol extensions:

protocol Slugifiable { var title: String { get } }

extension Slugifiable {
    var slug: String {
        title.lowercased()
            .replacingOccurrences(of: " ", with: "-")
            .components(separatedBy: CharacterSet.alphanumerics.inverted)
            .filter { !$0.isEmpty }
            .joined(separator: "-")
    }
}

extension Entry: Slugifiable {}

This gives every conforming type a ready‑to‑use slug without duplicate code.

Builder‑Style APIs via Extensions

Extensions can make builder patterns feel natural without heavy frameworks.

extension Entry {
    func withTitle(_ newTitle: String) -> Entry {
        var copy = self
        copy.title = newTitle
        return copy
    }

    func addingTag(_ tag: Tag) -> Entry {
        var copy = self
        copy.tags.append(tag)
        return copy
    }
}

Builder‑style methods keep structs immutable by returning modified copies, supporting predictable data flow.

Type‑Safe Validation and Parsing

Guard your boundaries with smart extensions.

extension String {
    var isEmailLike: Bool {
        let pattern = "^[A-Z0-9._%+-]+@[A-Z0-9.-]+\\.[A-Z]{2,}$"
        return range(of: pattern, options: [.regularExpression, .caseInsensitive]) != nil
    }
}

extension URLRequest {
    mutating func setJSONBody<T: Encodable>(_ value: T) throws {
        httpBody = try JSONEncoder().encode(value)
        setValue("application/json", forHTTPHeaderField: "Content-Type")
    }
}

Extensions here keep input and output checks close to the responsibility.

Performance‑Aware Utilities

Extensions can hide expensive work behind cached singletons or lazy properties.

extension DateFormatter {
    static let cachedMedium: DateFormatter = {
        let f = DateFormatter()
        f.dateStyle = .medium
        return f
    }()
}

extension Date {
    var mediumString: String {
        DateFormatter.cachedMedium.string(from: self)
    }
}

Don’t repeatedly construct formatters; use static cached instances for speed.

Domain‑Specific Language (DSL) via Extensions

With thoughtful naming, extensions can become a DSL for your domain.

extension Sequence where Element == Entry {
    func groupedByDay() -> [Date: [Entry]] {
        let cal = Calendar.current
        return Dictionary(grouping: self) { entry in
            cal.startOfDay(for: entry.createdAt)
        }
    }

    func sortedByRecency() -> [Entry] {
        sorted { $0.createdAt > $1.createdAt }
    }
}

Now entries.sortedByRecency().groupedByDay() reads like a formula, not plumbing.

Avoiding Common Pitfalls

Extensions give you power and responsibility. Here’s how to keep things clean:

• Don’t add heavy logic to ubiquitous types (e.g., String) without strong domain naming. Keep general helpers separate from business logic.
• Avoid ambiguous or surprising names. If your extension changes semantics (e.g., isEmpty that ignores whitespace), name it clearly (isBlank).
• Watch for collisions. If a library you import adds a conflicting extension, your project can become unstable or confusing.
• Don’t hide side effects. Extensions should be predictable; avoid global state changes.
• Respect access control. Mark extension members private/fileprivate where appropriate.

Extensions vs Subclassing vs Wrappers

• Subclassing: Use when you need polymorphic substitution or to override behavior (UIKit views, custom controllers).
• Wrappers (Composition): Use when you want to encapsulate state and behavior together for a specific domain.
• Extensions: Use to add orthogonal, discoverable functionality without owning the type.

A useful heuristic: If you need to override or store state, don’t use an extension.

Advanced Techniques

Conditional Conformance with Protocols

You can make your types conform to protocols only under constraints.

struct Box<T> { let value: T }

extension Box: Equatable where T: Equatable {}
extension Box: Hashable where T: Hashable {}

This allows flexible composition while keeping generic types small.

Extending Optionals Safely

Optionals are everywhere. Extensions can make handling them safer and more expressive.

extension Optional {
    var isNil: Bool { self == nil }

    func or(_ defaultValue: Wrapped) -> Wrapped {
        self ?? defaultValue
    }

    func mapOr<T>(_ defaultValue: T, _ transform: (Wrapped) -> T) -> T {
        map(transform) ?? defaultValue
    }
}

This turns branching into fluent pipelines.

Result Extensions for Error‑Handling Elegance

extension Result {
    func valueOrNil() -> Success? {
        try? get()
    }

    func mapErrorMessage(_ transform: (Failure) -> String) -> Result<Success, String> {
        mapError(transform)
    }
}

Result extensions can simplify UI binding to errors.

Extending SwiftUI Types

SwiftUI encourages composition. Extensions can keep view helpers tidy.

import SwiftUI

extension View {
    func cardStyle() -> some View {
        self
            .padding()
            .background(RoundedRectangle(cornerRadius: 12).fill(Color(.secondarySystemBackground)))
            .shadow(radius: 2)
    }
}

This style becomes reusable across your app without building a custom modifier type.

Lightweight Combine Helpers

import Combine

extension Publisher {
    func sinkToResult(_ receiveResult: @escaping (Result<Output, Failure>) -> Void) -> AnyCancellable {
        sink(receiveCompletion: { completion in
            if case let .failure(error) = completion {
                receiveResult(.failure(error))
            }
        }, receiveValue: { value in
            receiveResult(.success(value))
        })
    }
}

This bridges reactive streams to a Result‑based callback.

Testing Extensions

Extensions are code like any other. Treat them as units with inputs and outputs.

• Place tests alongside feature groups (Date+JournalTests.swift).
• Favor black‑box tests: given input X, expect Y.
• Test edge cases: empty strings, nil optionals, locale differences, leap days.
• Don’t over‑test trivial wrappers (like or(_:) on Optional). Focus on behavior that could break.

import XCTest
@testable import JournalApp

final class StringValidationTests: XCTestCase {
    func testEmailLike() {
        XCTAssertTrue("[email protected]".isEmailLike)
        XCTAssertFalse("bad@".isEmailLike)
    }
}

Organizing Extensions in a Real Codebase

A scalable structure prevents entropy as the project grows.

• Group by feature: String+Validation.swift, Date+Formatting.swift, Sequence+Entry.swift.
• Keep protocol default implementations near the protocol, or in Protocol+Defaults.swift.
• Avoid all‑purpose dumping grounds like Extensions.swift.
• Use // MARK: sections to clarify intent within a file.

Example layout:

Sources/
  Journal/
    Models/
      Entry.swift
      Tag.swift
    Features/
      Validation/
        String+Validation.swift
        Entry+Validatable.swift
      Formatting/
        Date+Formatting.swift
        DateFormatter+Cache.swift
      Lists/
        Sequence+Entry.swift

This keeps related logic discoverable and makes refactors safer.

Real‑World Extension Recipes

Below are proven snippets you’ll reach for often.

Dates

extension Date {
    func isSameDay(as other: Date, calendar: Calendar = .current) -> Bool {
        calendar.isDate(self, inSameDayAs: other)
    }

    func daysAgo(_ days: Int, calendar: Calendar = .current) -> Date? {
        calendar.date(byAdding: .day, value: -days, to: self)
    }

    var startOfMonth: Date? {
        let cal = Calendar.current
        let comp = cal.dateComponents([.year, .month], from: self)
        return cal.date(from: comp)
    }
}

Strings

extension String {
    func onlyLetters() -> String {
        filter { $0.isLetter }
    }
    func onlyDigits() -> String {
        filter { $0.isNumber }
    }
    var isBlank: Bool { trimmed.isEmpty }
}

Collections

extension Collection {
    var isNotEmpty: Bool { !isEmpty }
}

extension Sequence {
    func unique<T: Hashable>(by keyPath: KeyPath<Element, T>) -> [Element] {
        var seen = Set<T>()
        var result: [Element] = []
        for e in self {
            let k = e[keyPath: keyPath]
            if seen.insert(k).inserted { result.append(e) }
        }
        return result
    }
}

UIKit

import UIKit

extension UIViewController {
    func showAlert(title: String, message: String) {
        let ac = UIAlertController(title: title, message: message, preferredStyle: .alert)
        ac.addAction(UIAlertAction(title: "OK", style: .default))
        present(ac, animated: true)
    }
}

Foundation

import Foundation

extension URL {
    var queryParameters: [String: String] {
        var result: [String: String] = [:]
        URLComponents(url: self, resolvingAgainstBaseURL: false)?.queryItems?.forEach { item in
            result[item.name] = item.value ?? ""
        }
        return result
    }
}

Architectural Impact: Protocol Extensions vs Type Extensions

It’s crucial to understand where to put behavior.

• Protocol extensions give defaults to all conformers. Use for general behavior with no assumptions.
• Type extensions attach behavior to one type. Use for domain‑specific behavior.

A guiding question: “Should this apply to all conforming types, or just this one?” If the former, prefer protocol extensions to maximize reuse.

Documentation and Discoverability

Extensions are only useful if your team finds and trusts them.

• Document intent at the top of extension files.
• Use // MARK: sections: // MARK: - Email Validation.
• Adopt naming conventions consistently: Type+Feature.swift.
• Avoid clever names. Favor clarity over brevity.

Refactoring with Extensions: A Step‑By‑Step Playbook

Here’s a pragmatic process for improving a codebase using extensions.

1. Identify scattered helpers (global functions, utility classes).
2. Decide the logical home type for each helper.
3. Create Type+Feature.swift and move helpers into extensions.
4. Add tests for edge cases and happy paths.
5. Replace external calls with fluent internal usage.
6. Measure and cache expensive operations where needed.
7. Document new extension with intent and examples.

This top‑down approach reduces churn and concentrates knowledge where it belongs.

Error Boundaries and Safety

Extensions often operate at boundaries: parsing, formatting, validation.

• Use failable and throwing initializers to communicate risk.
• Keep side effects minimal—initialize state, don’t modify global configuration.
• Prefer pure functions and computed properties in extensions.
• Log with os subsystem or print in debug builds only.

Interoperability: Swift, Objective‑C, and Modules

• Mark members with @objc if you need Obj‑C exposure (UIKit targets).
• Place extensions in the right target/module to avoid surprising visibility.
• Beware of name collisions across modules. Prefer prefixing when extending third‑party types in app layer.

Example with prefixes:

extension URL { // App layer
    struct App {}
}

extension URL.App {
    static func isSecure(_ url: URL) -> Bool { url.scheme == "https" }
}

This technique avoids polluting URL with app‑specific semantic names while keeping usage discoverable: URL.App.isSecure(url).

Real Metrics: When Extensions Improve Performance

• Static singletons (e.g., DateFormatter) remove repeated allocation cost.
• Inline small helpers reduce call overhead and improve readability.
• Conditional conformance avoids backtracking on runtime type checks.

Use Instruments to confirm. The goal is clean code first; performance second.

Case Study: Cleaning Up a Messy Utility Module

Imagine a project with a Utils.swift file holding 3,000 lines of unrelated helpers: date formatting, email validation, UI alerts, JSON building, etc. It’s hard to test and harder to discover.

Refactor plan:

• Extract DateFormatter cache into DateFormatter+Cache.swift.
• Move email validation into String+Validation.swift.
• Create URL+Query.swift for query parsing.
• Move UIViewController alert helper into UIViewController+Alert.swift.
• Add unit tests for each file’s behaviors.
• Update call sites: Date().mediumString, string.isEmailLike, url.queryParameters, vc.showAlert(...).

The result: a codebase where behavior is co‑located with types, and where autocomplete reveals capabilities without hunting in global helpers.

Guardrails: Access Control in Extensions

Access control guides proper usage and prevents misuse.

• public: Intended external API.
• internal: Default module scope; use for app features.
• fileprivate / private: Keep implementation details sealed.

Example:

extension String {
    // public in a library, internal in an app
    public var kebabCased: String {
        lowercased()
            .replacingOccurrences(of: " ", with: "-")
            .components(separatedBy: CharacterSet.alphanumerics.inverted)
            .filter { !$0.isEmpty }
            .joined(separator: "-")
    }

    // keep helpers private
    private var isAscii: Bool { canBeConverted(to: .ascii) }
}

Building for Teams: Conventions That Scale

Conventions help teams move fast without breaking things.

• Adopt a clear file naming convention (Type+Feature.swift).
• Keep one purpose per extension file.
• Prefer protocol‑oriented defaults for general behavior.
• Document assumptions and edge cases at the top of the file.
• Review extensions for collision risk during code review.

Swift Language Notes That Matter for Extensions

• You can extend generic types, including adding conditional conformances.
• You cannot add stored properties; only computed properties.
• You can add new initializers, but not designated initializers for classes you don’t own.
• Extensions are statically dispatched unless you use protocols with default implementations.

Understanding dispatch helps avoid surprises: protocol default implementations can be shadowed by conformers.

Putting It All Together: A Practical Walkthrough

Let’s wire extensions into a small feature: a list of journal entries grouped by day with human‑friendly headers and simple validation.

// MARK: - Models
struct Entry: Identifiable, Hashable {
    let id: UUID
    var title: String
    var body: String
    var createdAt: Date
    var tags: [Tag]
}
struct Tag: Hashable { var name: String }

// MARK: - String
extension String {
    var trimmed: String { trimmingCharacters(in: .whitespacesAndNewlines) }
    var isBlank: Bool { trimmed.isEmpty }
    var kebabCased: String {
        lowercased()
            .replacingOccurrences(of: " ", with: "-")
            .components(separatedBy: CharacterSet.alphanumerics.inverted)
            .filter { !$0.isEmpty }
            .joined(separator: "-")
    }
}

// MARK: - Validation
protocol Validatable { func validate() throws }

enum ValidationError: Error { case emptyTitle, tooShort }

extension Entry: Validatable {
    func validate() throws {
        if title.isBlank { throw ValidationError.emptyTitle }
        if body.count < 10 { throw ValidationError.tooShort }
    }
}

// MARK: - Date Formatting
extension DateFormatter {
    static let mediumCached: DateFormatter = {
        let f = DateFormatter()
        f.dateStyle = .medium
        return f
    }()
}

extension Date {
    var mediumString: String { DateFormatter.mediumCached.string(from: self) }
    func isSameDay(as other: Date) -> Bool {
        Calendar.current.isDate(self, inSameDayAs: other)
    }
}

// MARK: - Sequences of Entries
extension Sequence where Element == Entry {
    func groupedByDay() -> [Date: [Entry]] {
        let cal = Calendar.current
        return Dictionary(grouping: self) { cal.startOfDay(for: $0.createdAt) }
    }
    func sortedByRecency() -> [Entry] { sorted { $0.createdAt > $1.createdAt } }
}

// MARK: - Usage
let entries: [Entry] = [
    Entry(id: UUID(), title: "First", body: "Hello world...", createdAt: Date(), tags: []),
    Entry(id: UUID(), title: "Second", body: "Another entry", createdAt: Date().addingTimeInterval(-86400), tags: [])
]

let grouped = entries.sortedByRecency().groupedByDay()
for (day, items) in grouped {
    print("\n=== \(day.mediumString) ===")
    for e in items {
        do {
            try e.validate()
            print("- \(e.title) : \(e.slug)")
        } catch {
            print("- Invalid entry: \(error)")
        }
    }
}

This snippet demonstrates how a few well‑chosen extensions can create an expressive mini‑DSL for your app.

Pragmatic Checklist for Extensions

Use this checklist during code review:

• Does the extension belong to this type? Is it the logical home?
• Is the extension single‑purpose and named clearly?
• Could this behavior be a protocol default instead?
• Are we risking collisions with other modules?
• Are computed properties pure and fast, or cached as needed?
• Are access modifiers correct and minimal?

When Not to Use Extensions

• When behavior requires stored state.
• When variability is better expressed via subclassing or strategy objects.
• When you need to override behavior or intercept lifecycle in classes you don’t own.
• When naming becomes forced or misleading.

Reach for composition or dedicated types in those cases.

Migration Tips: From Utility Functions to Extensions

If you have a utility module, migrate gradually:

• Move the easiest helpers first (string trims, date formatting).
• Add tests to lock behavior.
• Replace call sites incrementally.
• Document new patterns and conventions.

The payoffs are immediate: better autocomplete, less cognitive load, and code that reads in the language of your domain.

Security Considerations

Extensions sometimes add parsing or validation. Keep security in mind:

• Validate user input strictly (regex, length, allowed characters).
• Avoid open redirects when extending URL helpers.
• Don’t stash tokens in extensions on ubiquitous types.
• Be mindful of locale and Unicode pitfalls (e.g., normalization).

Localization and Accessibility

Extensions can help you centralize localization and accessibility helpers:

extension String {
    func localized(table: String? = nil, bundle: Bundle = .main) -> String {
        NSLocalizedString(self, tableName: table, bundle: bundle, comment: "")
    }
}

extension UIAccessibility {
    static func announce(_ message: String) {
        UIAccessibility.post(notification: .announcement, argument: message)
    }
}

This keeps localization and accessibility usage consistent and discoverable.

Extension Hygiene in Open Source Libraries

If you publish libraries, be extra cautious:

• Mark APIs explicitly public/open only when intended.
• Provide clear documentation and examples.
• Avoid aggressively extending standard types with opinionated behavior.
• Consider namespacing (e.g., MyLib nested types) to prevent global pollution.

Troubleshooting and Debugging Extensions

When extensions misbehave:

• Check import order and module visibility.
• Look for shadowed names across files.
• Confirm conditional conformance constraints are satisfied.
• Use type(of:) and explicit generic annotations to reduce ambiguity.

Logs and unit tests help reveal where behavior is coming from.

FAQ: Quick Answers for Busy Engineers

• Can extensions add stored properties? No; only computed properties.
• Can I override methods in an extension? No; you can add new ones, not override.
• Should I put protocol conformance in an extension? Yes, generally.
• Do extensions affect ABI? Yes, in libraries—be mindful of public API changes.
• Are extensions testable? Absolutely; treat them like regular functions.

Final Thoughts

Extensions are the Swift way to grow behavior where it belongs—on the types themselves. When used judiciously, they create fluent, maintainable codebases that scale with teams and features. When overused or misapplied, they can turn into hidden traps. Follow the principles in this guide, use the recipes in your projects, and you’ll find your Swift feels more “Swifty” than ever.

The next time you reach for a utility function, ask instead: “What type does this belong to?” Chances are, the right home is an extension away.

Further Reading and References

• Swift Language Guide: Extensions
• Protocol‑Oriented Programming in Swift (WWDC)
• Standard Library Source: Swift GitHub
• API Design Guidelines (Apple)
• Generic in Swift

Subscript in Swift

By implementing Subscript we can set and retrieve structure value by index (associative array or dictionary style) without separate methods for setting and retrieval. Classes and Enumerations can define subscripts too.

For example, I want to build an Address struct that can hold different string values. A contact can have a present address and a permanent address.

public struct Address {
    public var presentAddress: String?
    public var permanentAddress: String?

    public init() {

    }
}

var address = Address()
address.presentAddress = "Present Address"
address.permanentAddress = "Permanent Address"

print(address.presentAddress)
print(address.permanentAddress)

Without the subscript the Address has limited two members, presentAddress and permanentAddress. If we implement subscript we can have more than two addresses.

public struct Address {
    private var members: Dictionary<String, String> = [:]
    
    public init() {
    }
    
    public subscript(member: String) -> String {
        get {
            return members[member, default: "No value set"]
        }
        
        set(newValue) {
            members[member] = newValue
        }
    }
}

var address = Address()

address["presentAddress"] = "Present Address"
address["permanentAddress"] = "Permanent Address"
address["officeAddress"] = "Office Address"

print(address["presentAddress"])
print(address["permanentAddress"])
print(address["officeAddress"])