Swift中如何实现类String的安全自定义类型？

需求背景 #

我是Swift新手，想沿用其他语言的实践习惯，实现一个EmailAddress自定义类型，要求：

• 实例一旦存在就必然是有效的邮箱地址，无非法内容
• 行为尽可能接近String，方便开发者使用

目前我写出了可在Playground运行的代码，但遇到了一些问题，希望得到优化建议：

import Foundation

struct EmailAddress:
        ExpressibleByStringLiteral,
        LosslessStringConvertible,
        RangeReplaceableCollection,
        Equatable {

    enum ValidationError: Error {
        case invalidAddress
    }

    private let address: String

    /// Satisfies the "LosslessStringConvertible" protocol
    var description: String {
        return address
    }

    init?(_ anAddress: String) {
        guard
            NSPredicate(
                format:"SELF MATCHES %@",
                "[A-Z0-9a-z._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,64}"
            )
            .evaluate(with: anAddress)
        else {
            //I'd rather like to `throw ValidationError.invalidAddress`
            // but then it won't satisfy the protocols
            return nil
        }

        self.address = anAddress
    }

    init(stringLiteral aStringLiteral: StringLiteralType) {
        // I'd like to basically repeat the other init here to not have
        // the validation code twice, this one is just to satisfy
        // the ExpressibleByStringLiteral protocol
        self.address = aStringLiteral
    }

}

// nope it doesn't cast, but I realize now that this
// intended and a good thing.
print("Casts to address: " + EmailAddress("dummy@example.org"))

func demo(aString: String) {
    print("That worked. The string given is " + aString)
}

// compiler says: cannot convert value of type
// 'EmailAddress' to expected argument type 'String'
demo(aString: EmailAddress("dummy2@example.org"))

// this works though. While writing I guess that this is
// actually expected since their is no implicit type casting
// in Swift :D
demo(aString: String(EmailAddress("dummy2@example.org")))

我的疑问 #

1. 这种实现是否属于最佳实践？是否过度设计？比如使用ExpressibleByStringLiteral是否必要、是否有过多开销？
2. 希望初始化器能抛出ValidationError.invalidAddress错误，而非返回nil（类似URL的初始化器）。
3. 当前实现存在诸多问题，陷入僵局，该如何更好地实现需求？

优化方案 #

1. 协议选择：避免过度实现 #

• 移除RangeReplaceableCollection：这个协议针对可修改的集合类型（如String、Array）设计，但邮箱地址是不可变的有效字符串，不需要支持插入、删除等集合操作，强行实现属于过度设计，会增加不必要的代码负担。
• ExpressibleByStringLiteral的取舍：如果希望直接用字符串字面量创建实例（比如let email: EmailAddress = "test@example.com"），这个协议是有用的，但必须在字面量初始化时加入验证——当前你的实现跳过了验证，会导致非法邮箱通过字面量创建出无效实例，违背了类型设计的初衷。如果不需要字面量直接初始化，这个协议可以省略，避免误用。

2. 实现抛出错误的初始化器 #

保留init?(_:)满足LosslessStringConvertible协议，同时新增一个throws初始化器，兼顾协议要求和明确错误提示的需求，还要提取验证逻辑避免代码重复：

import Foundation

struct EmailAddress: LosslessStringConvertible, Equatable {
    enum ValidationError: Error {
        case invalidAddress
    }

    private let address: String

    var description: String { address }

    // 提取验证逻辑为静态方法，复用所有初始化器
    private static func isValid(_ address: String) -> Bool {
        let predicate = NSPredicate(
            format:"SELF MATCHES %@",
            "[A-Z0-9a-z._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,64}"
        )
        return predicate.evaluate(with: address)
    }

    // 满足LosslessStringConvertible的可失败初始化器
    init?(_ anAddress: String) {
        guard Self.isValid(anAddress) else { return nil }
        self.address = anAddress
    }

    // 新增抛出错误的初始化器，类似URL的设计
    init(validating address: String) throws {
        guard Self.isValid(address) else {
            throw ValidationError.invalidAddress
        }
        self.address = address
    }

    // 如果保留ExpressibleByStringLiteral，必须在这里做验证（字面量初始化不能返回nil/抛出）
    init(stringLiteral value: StringLiteralType) {
        guard Self.isValid(value) else {
            fatalError("Invalid email address literal: \(value)")
        }
        self.address = value
    }
}

3. 让类型更贴近String的使用体验 #

• 由于实现了LosslessStringConvertible，String(email)可以直接调用，无需额外代码。
• 可以根据需求添加ExpressibleByStringInterpolation支持，让类型兼容字符串插值语法。
• Equatable协议会自动合成（因为存储属性address是String），无需手动实现==运算符。

4. 最佳实践总结 #

• 核心原则：确保EmailAddress的实例永远有效，所有初始化入口必须经过验证。
• 协议精简：只保留必要的协议：LosslessStringConvertible（支持双向字符串转换）、Equatable（自动合成），ExpressibleByStringLiteral可选（但必须加验证）。
• 代码复用：把验证逻辑提取为静态方法，避免各个初始化器重复代码。
• 错误处理：提供throws初始化器给需要明确错误信息的场景，保留可失败初始化器满足协议和便捷创建需求。

内容的提问来源于stack exchange，提问作者Adrian Föder