willSet et didSet en Swift : définition, syntaxe et fonctionnement des observateurs

Que sont willSet et didSet en Swift ?

willSet et didSet sont des observateurs de propriété (property observers) en Swift, un mécanisme intégré pour suivre les modifications des stored properties.

Contrairement à d'autres langages qui nécessitent une implémentation manuelle des setters ou des systèmes de rappel, Swift fournit une syntaxe déclarative pour réagir aux changements. Les observateurs sont ajoutés directement après la déclaration de la propriété et ne nécessitent pas d'appel séparé.

Selon la documentation développeur Apple (2026), les property observers sont pris en charge pour les stored properties de toute classe, structure ou énumération. Ils ne fonctionnent pas avec les computed properties car celles-ci ne stockent pas de valeur — pour elles, la réaction au changement est implémentée directement dans le setter.

Quand willSet est appelé

willSet est appelé immédiatement avant d'affecter une nouvelle valeur à la propriété. À l'intérieur de willSet, le paramètre implicite newValue est disponible, contenant la valeur qui sera définie. À ce moment, la valeur actuelle de la propriété n'a pas encore changé — vous pouvez lire l'ancienne valeur directement via la propriété.

Selon la proposition Swift Evolution SE-0001 (2024), willSet offre la possibilité d'effectuer une validation ou une journalisation avant le changement réel. Si une exception est levée dans willSet, la nouvelle valeur ne sera pas appliquée, faisant des observateurs un mécanisme de protection des données.

Quand didSet est appelé

didSet est appelé immédiatement après l'affectation d'une nouvelle valeur. À l'intérieur de didSet, le paramètre implicite oldValue est disponible, contenant la valeur avant le changement. À ce stade, la propriété contient déjà la nouvelle valeur et vous pouvez la comparer avec l'ancienne.

Selon Swift by Sundell (2025), didSet est l'observateur le plus populaire car il est le plus souvent nécessaire pour le post-traitement : mise à jour de l'interface utilisateur, recalcul des champs dépendants ou envoi de données au serveur après un changement.

Syntaxe des observateurs de propriété

Les property observers sont déclarés immédiatement après la propriété à l'aide d'accolades. La syntaxe minimale ne nécessite qu'un seul observateur, mais vous pouvez déclarer les deux.

var score: Int = 0 {
    willSet {
        print("Le score va changer en \(newValue)")
    }
    didSet {
        print("Le score a changé de \(oldValue) à \(score)")
    }
}

Les deux observateurs sont facultatifs — vous pouvez spécifier uniquement willSet ou uniquement didSet. Pour willSet, vous pouvez renommer newValue en spécifiant un nom entre parenthèses.

var username: String = "guest" {
    willSet(newName) {
        print("Sur le point de définir \(newName)")
    }
    didSet(oldName) {
        print("Était \(oldName), maintenant \(username)")
    }
}

Selon Swift Language Guide (2026), renommer les paramètres améliore la lisibilité du code, surtout lorsque la propriété et les observateurs sont utilisés dans un grand projet avec des noms longs.

Comment fonctionnent willSet et didSet

L'ordre d'exécution est strictement défini : d'abord willSet (l'ancienne valeur est disponible), puis l'affectation, puis didSet (la nouvelle valeur est disponible).

class Temperature {
    var celsius: Double = 0.0 {
        willSet {
            print("La température va passer de \(celsius) à \(newValue)")
        }
        didSet {
            if celsius > 100.0 {
                print("Point d'ébullition dépassé !")
            }
        }
    }
}

Une limitation importante : les observateurs ne sont pas appelés lors de l'initialisation de la propriété lors de la création d'une instance. À l'intérieur d'init, l'affectation d'une valeur ne déclenche pas willSet et didSet — cela évite les effets secondaires indésirables au moment de la construction.

Selon le blog Apple Swift (2025), ce comportement diffère de nombreux autres langages où les setters sont appelés même dans les constructeurs. Swift choisit la sécurité : les observateurs ne commencent à fonctionner qu'après la fin de l'initialisation de l'objet.

Appels imbriqués et récursion

Modifier une propriété à l'intérieur de didSet peut entraîner des appels répétés de l'observateur. Swift ne bloque pas la récursion — le programmeur doit la contrôler manuellement.

var counter: Int = 0 {
    didSet {
        if counter < 5 {
            counter += 1
        }
    }
}

Un tel code créera une récursion totale avec débordement de pile si aucune condition de sortie n'est prévue. Selon la communauté Stack Overflow Swift (2025), c'est l'une des erreurs les plus courantes commises par les débutants lorsqu'ils travaillent avec les property observers.

Observateurs pour les propriétés des structures

Les structures prennent en charge willSet et didSet pour les stored properties sans restriction. Il est important de se rappeler que les structures sont des types de valeur, et la modification d'une propriété à l'intérieur d'une méthode mutante déclenche également les observateurs.

struct Point {
    var x: Double = 0.0 {
        didSet {
            print("X a changé en \(x)")
        }
    }
    var y: Double = 0.0 {
        didSet {
            print("Y a changé en \(y)")
        }
    }
}

var point = Point()
point.x = 5.0

Utilisation des observateurs dans des projets réels

Les observateurs de propriété sont utilisés dans les projets Swift pour un large éventail de tâches : de la synchronisation de l'interface utilisateur à la validation des données et à la journalisation.

Validation des valeurs

didSet permet de revenir en arrière ou de corriger une valeur invalide immédiatement après sa définition. Cela remplace les setters encombrants d'Objective-C et garantit l'intégrité des données au niveau du modèle.

var age: Int = 0 {
    didSet {
        if age < 0 || age > 150 {
            age = oldValue
        }
    }
}

Synchronisation de l'interface utilisateur

Lorsqu'une propriété connexe change, vous pouvez automatiquement mettre à jour les éléments de l'interface sans appel de méthode de mise à jour séparé.

var userName: String = "" {
    didSet {
        nameLabel.text = userName
    }
}

Journalisation des modifications

willSet est pratique pour la journalisation à des fins de débogage ou d'audit. Vous pouvez enregistrer l'heure et la nouvelle valeur avant son application, garantissant ainsi que le journal contient les données originales pour l'analyse.

Selon objc.io (2025), les property observers sont particulièrement utiles dans les architectures à flux de données unidirectionnel, où chaque modification de propriété est enregistrée pour une reproduction ultérieure de l'état.

Comparaison avec les computed properties

Les computed properties calculent une valeur à la volée et n'ont pas de stockage, tandis que willSet et didSet travaillent sur une stored property avec une valeur réelle.

La différence clé : une computed property calcule une valeur à chaque accès, tandis qu'un property observer réagit à un changement d'une valeur existante. Le choix entre eux est dicté par la sémantique — si la propriété est dérivée d'autres données, utilisez computed ; s'il s'agit d'une valeur indépendante dont les changements doivent être observés, utilisez willSet/didSet.

Erreurs courantes lors de l'utilisation

L'erreur la plus courante est l'appel récursif de didSet sans condition de sortie. Chaque modification de propriété à l'intérieur de didSet déclenche à nouveau l'observateur, conduisant à une boucle infinie.

La deuxième erreur courante est la tentative d'utiliser des observateurs sur des propriétés let. Le compilateur Swift générera une erreur car let est une constante.

La troisième erreur est d'ignorer que l'observateur n'est pas appelé lors de l'initialisation. Les développeurs qui s'attendent à ce que willSet se déclenche dans init obtiennent un comportement inattendu.

Le quatrième problème est l'application d'observateurs à des propriétés dans des extensions. Swift interdit l'ajout de willSet/didSet aux stored properties dans les extensions.

Selon Ray Wenderlich (2025), comprendre ces limitations aide à éviter les bugs à un stade précoce et rend le code Swift plus prévisible.