Typealias : définition, syntaxe et utilisation

Qu’est-ce que Typealias ?

Typealias est une déclaration en Swift qui introduit un nom alternatif pour un type existant. Après avoir déclaré un typealias, le nouveau nom peut être utilisé partout où le type original est attendu — le compilateur les traite comme identiques. Typealias n’ajoute pas d’isolation sémantique : une valeur de type UserID (typealias pour String) peut être passée à une fonction attendant String sans erreur.

Les principaux objectifs de typealias sont de raccourcir les noms longs, documenter le but d’un type et abstraire l’implémentation concrète. Par exemple, typealias JSON = [String: Any] indique explicitement qu’un dictionnaire est utilisé comme structure JSON, et typealias Completion = (Result<Data, Error>) -> Void transforme une signature de closure complexe en un type lisible.

Selon Swift.org (2025), typealias est largement utilisé dans la bibliothèque standard. Par exemple, String est un typealias pour String (un Array<Character> spécialisé), bien que dans les versions modernes de Swift cette implémentation soit cachée. Void est un typealias pour le tuple vide (), ce qui rend les signatures de fonctions plus lisibles.

Utilisez typealias pour documenter la sémantique d’un type, mais rappelez-vous : il ne protège pas contre le mélange de différents concepts du même type de base. Pour une séparation garantissant la sécurité des types, utilisez des wrappers (struct wrapper).

Syntaxe et portées

Typealias est déclaré avec le mot-clé typealias, suivi du nouveau nom, d’un signe égal et du type existant. La forme de base :

typealias Name = ExistingType
typealias UserID = Int
typealias JSONDictionary = [String: Any]

La portée d’un typealias est déterminée par l’endroit où il est déclaré :

Typealias à l’intérieur d’un type (par exemple, User.ID) est un motif courant pour regrouper les alias associés. Cela améliore l’espace de noms : Order.ID et User.ID sont tous deux Int, mais se lisent comme des concepts différents. L’accès à un typealias imbriqué se fait via User.ID ou par notation pointée si le type est connu.

Typealias pour les types closure

L’une des utilisations les plus courantes de typealias est de simplifier les signatures de closure. Les types closure en Swift peuvent être lourds, surtout avec Optional et les paramètres génériques. Typealias transforme (Data?, Error?) -> Void en un lisible FetchResultHandler :

typealias FetchResultHandler = (Data?, Error?) -> Void

func fetchUser(id: Int, completion: FetchResultHandler) {
    // network request
    completion(data, nil)
}

Selon le Guide de Style Ray Wenderlich, typealias pour les closures améliore la lisibilité des signatures de méthodes, en particulier dans les protocoles de délégation et les motifs de callback. Cependant, évitez les alias excessifs — si une closure est utilisée à un seul endroit, elle peut être déclarée inline.

La bibliothèque standard de Swift utilise activement cette approche. Par exemple, DispatchQueue.WorkItem est un typealias pour DispatchWorkItem, bien qu’extérieurement il ressemble à un type séparé. Typealias pour les closures est un outil de lisibilité — n’en abusez pas : 3 à 5 alias de closure par module est une limite raisonnable.

Typealias et paramètres génériques

Typealias peut inclure des paramètres génériques, créant des versions spécialisées de types génériques. C’est particulièrement utile lorsqu’on travaille avec Result, Publisher et d’autres types génériques de la bibliothèque standard et Combine :

typealias FetchResult = Result<Data, Error>
typealias AnyPublisherOfData = AnyPublisher<Data, Error>

func loadData() -> FetchResult {
    // data loading
}

Vous pouvez également créer des typealias avec des paramètres génériques personnalisés qui sont transmis au type original :

typealias NetworkResult<T> = Result<T, NetworkError>

func fetchUser() -> NetworkResult<User> {
    // ...
}

Une règle importante : typealias ne peut pas ajouter de nouvelles contraintes génériques (clauses where) — il transmet simplement les paramètres au type original. Si des contraintes supplémentaires sont nécessaires, créez une structure ou une classe générique. Selon Swift by Sundell (2024), typealias avec des génériques est un moyen idéal de raccourcir les signatures répétitives dans les projets qui utilisent intensivement Combine, Result et async/await.

Associatedtype dans les protocoles

Associatedtype est un typealias déclaré à l’intérieur d’un protocole qui définit un type associé. Contrairement à un typealias normal, associatedtype n’est pas lié à un type spécifique au moment de la déclaration — il est spécifié par chaque type qui adopte le protocole :

protocol Container {
    associatedtype Item
    var count: Int { get }
    mutating func append(_ item: Item)
}

struct IntBox: Container {
    typealias Item = Int
    // implementation
}

struct StringBox: Container {
    typealias Item = String
    // implementation
}

Associatedtype donne aux protocoles la flexibilité des types génériques sans spécifier un type concret au point de déclaration. C’est le fondement de nombreux motifs Swift : Collection (Element), IteratorProtocol (Element), Identifiable (ID). Le compilateur peut déduire associatedtype automatiquement à partir de l’implémentation, donc un typealias Item = Int explicite est souvent omis — Swift déduit Item comme Int à partir du paramètre de la méthode append.

Selon Swift Evolution SE-0195 (2022), les types de résultat opaques (some Container) ont été introduits pour travailler avec des protocoles contenant associatedtype — cela a résolu le problème PAT (protocole avec types associés), qui empêchait d’utiliser ces protocoles comme types de variables.

Typealias vs wrapper de type

La différence clé : typealias est simplement un autre nom pour un type existant, tandis qu’un wrapper est un nouveau type, sémantiquement isolé de l’original. Si vous déclarez typealias UserID = Int, alors UserID et Int sont interchangeables — une fonction attendant Int acceptera UserID sans erreur.

Un wrapper est créé via struct et offre une véritable sécurité de type :

struct UserID: RawRepresentable {
    let rawValue: Int
}

struct OrderID: RawRepresentable {
    let rawValue: Int
}

// Compilation error: cannot pass OrderID where UserID is expected

Selon Point-Free (2025), les wrappers sont préférables lorsque différents concepts sont représentés par le même type de base (UserID vs OrderID). Typealias est justifié lorsque l’objectif est la lisibilité sans isolation : raccourcir les noms longs, documenter la sémantique, abstraire l’implémentation via associatedtype. Choisissez typealias pour la commodité de lecture, wrapper pour la sécurité des types.