Swift 6.4: O que há de Novo na Concorrência - SwiftLee

A Apple lançou o Swift 6.4 durante a WWDC 2026, introduzindo uma série de melhorias para ambos os idiomas Swift e as APIs de Concorrência. Embora Swift seja open-source, muitas dessas mudanças ainda podem ter surpreendido você. Ao mesmo tempo, sessões da WWDC não abrangem todas as novas alterações (se você teve a chance de assistir a elas).

Sigo propostas de evolução Swift semanalmente para meu boletim informativo, informando mais de 30.000 desenvolvedores iOS sobre as últimas mudanças em andamento no Swift, então eu estava ansioso para mergulhar mais fundo nas alterações de concorrência. Aqui está um resumo para você!

Um panorama de todas as propostas que foram implementadas no Swift 6.4, parcialmente relacionadas à Concorrência.

Uma breve introdução sobre como eu mantenho o controle de todas as alterações:

• Swift Evolution: Lendo e aprendendo com propostas

Sou um dos poucos a usar essa técnica para economizar seu tempo, mostrando uma visão geral em meu boletim informativo semanal gratuito (30.000 assinantes).

Junte-se ao SwiftLee Weekly.

Eu mantenho o controle das mudanças do Swift lendo propostas de evolução Swift toda semana. É a melhor maneira de entender não apenas o que mudou, mas também por que uma característica foi introduzida e quais trade-offs foram discutidos.

Explicar minha abordagem em Swift Evolution: Lendo e aprendendo com propostas. Eu uso o mesmo hábito para resumir as atualizações mais importantes do Swift no SwiftLee Weekly, meu boletim informativo semanal gratuito lido por mais de 30.000 desenvolvedores Swift.

Agora que você conhece a história por trás dessa visão geral, é hora de mergulhar na primeira alteração de concorrência do Swift 6.4.

Declarações async defer

O Swift 6.4 implementa SE-0493: Suporte a chamadas assíncronas em corpos de defer. Esta é uma das mudanças que parece óbvia assim que você precisa dela.

Antes do Swift 6.4, não era possível chamar uma função assíncrona dentro de um corpo de defer, mesmo se a função envolvente já fosse async. Isso era irritante para o trabalho de limpeza, pois defer é exatamente o lugar onde você quer garantir a limpeza em todas as rotas de saída.

No Swift 6.4, o seguinte código torna-se válido:

func importArticles() async throws {
    let importer = ArticleImporter()
    await importer.open()

    defer {
        await importer.close() // Agora podemos usar await aqui.
    }

    try await importer.importLatestArticles()
}

O corpo de defer ainda executa ao sair do escopo, assim como antes. A diferença é que o Swift agora aguarda implicitamente a limpeza assíncrona antes que a função retorne.

Gosto dessa alteração porque remove a tentação de escrever manualmente a limpeza em cada possível rota de saída. Se uma função pode lançar exceções após a configuração, defer mantém a configuração e o desfazimento juntos.

Um detalhe para manter em mente: async defer não esconde cancelamento. Se a tarefa atual já foi cancelada antes de entrar no escudo, esse cancelamento ainda existe. O escudo apenas faz com que o código dentro da clausura observe Task.isCancelled == false, permitindo que trabalhos de limpeza como database.close() sejam executados. Uma vez que a clausura retorna, Task.isCancelled relata novamente o estado original do cancelamento.

Isto é especialmente útil junto com async defer:

func writeArticles(_ articles: [Article]) async throws {
    let transaction = await database.beginTransaction()

    defer {
        await withTaskCancellationShield {
            // Queremos que isso sempre execute, mesmo se cancelado.
            await transaction.rollbackIfNeeded()
        }
    }

    try await transaction.insert(articles)
    try await transaction.commit()
}

Não usaria escudos de cancelamento em todo lugar. Para ser honesto, ainda não senti falta dessa característica nos meus próprios projetos (embora isso possa ser uma história do ovo e da galinha). No entanto, é valioso para trabalhos curtos de limpeza ou rollback que devem terminar mesmo se a tarefa foi cancelada.

Em outras palavras: use escudos de cancelamento para concluir trabalho que você já começou, não para esconder o cancelamento de operações longas em execução.

Avisos para tarefas lançadoras ignoradas

O Swift 6.4 melhora a manipulação de erros para tarefas sem estrutura através de SE-0520: Uso descartável de resultados em inicializadores de tarefa. A mudança ajuda você a capturar um erro sutil: criar uma tarefa lançadora e, em seguida, ignorar o manipulador de tarefas retornado.

Antes dessa alteração, o seguinte código poderia silenciosamente ignorar erros:

Task {
    try await importArticles()
}

Isto é problemático, pois você pode esconder erros inesperadamente em seu código. Então, a tarefa pode lançar exceções, mas ninguém aguarda task.value, e o corpo da tarefa não lida com o erro. No Swift 6.4, o Xcode avisa:

// Aviso: Tarefa de lançamento sem estrutura não foi usada,
// o que pode ignorar acidentalmente erros lançados dentro da tarefa
Task {
    try await importArticles()
}

Você pode corrigir o aviso lidando com erros dentro da tarefa:

Task {
    do {
        try await importArticles()
    } catch {
        print("A importação de artigos falhou com erro: \(error)")
    }
}

Ou você pode armazenar o manipulador da tarefa e aguardar o valor mais tarde:

let importTask = Task {
    try await importArticles()
}

try await importTask.value // ou
do {
    try await importTask.value
} catch {
    print("A importação de artigos falhou com erro: \(error)")
}

Isto é uma pequena melhoria diagnóstica, mas pode prevenir erros reais. Vi muitas bases de código usar Task { ... } como uma maneira rápida de escapar...