[Filosofia do Swift #4] Swift Evolution e SE-0296

Em artigos e notas de versão do Swift, SE-0296 e SE-0345 aparecem com frequência. async/await usa SE-0296, enquanto a sintaxe abreviada de if let name usa SE-0345. O que esses números significam?

São números de registro de todas as mudanças de linguagem incorporadas ao Swift. Até adicionar uma sintaxe exige passar pelo Swift Evolution, o processo público que atribui números SE às propostas aprovadas. Ao contrário da imagem fechada da Apple, a evolução do Swift acontece em um registro totalmente público.

Esta é a quarta parte da série sobre a filosofia do Swift. As três anteriores abordaram os valores do Swift—segurança, desempenho e expressividade, divulgação progressiva e tipos por valor—; esta trata do sistema que protege esses valores. Filosofia precisa de processo para se sustentar.

O que é Swift Evolution — revisão pública de mudanças na linguagem

Em dezembro de 2015, a Apple tornou o Swift open source e também publicou o processo que decide o futuro da linguagem. O palco é formado pelo repositório swift-evolution no GitHub e pelos fóruns do Swift (forums.swift.org).

A regra central é simples: para mudar a sintaxe ou a biblioteca padrão do Swift, qualquer pessoa precisa escrever uma proposta e passar por revisão pública. Nem engenheiros da Apple nem o próprio Chris Lattner podem ignorar o processo. Propostas iniciais da Apple já foram rejeitadas pela comunidade, enquanto inúmeras propostas externas entraram na linguagem.

O que esse processo protege? A filosofia das três partes anteriores. A comunidade inteira, não apenas o autor, verifica se uma função prejudica a segurança, quebra a divulgação progressiva ou permanece consistente com o código existente. A consistência da linguagem vira resultado do processo, não do gosto de uma pessoa.

A vida de uma proposta — da ideia à sintaxe

Vamos acompanhar passo a passo como uma sintaxe entra na linguagem.

Etapa 1: Pitch. Publique a ideia em Evolution > Pitches no fórum. As restrições são flexíveis; o objetivo é medir a reação. A comunidade sugere alternativas e aponta falhas. A maioria das ideias é filtrada ou muda bastante nessa etapa.

Etapa 2: escrever a Proposal. Se o pitch sobreviver, escreva uma proposta formal. O modelo exige Motivation, Detailed design, Source compatibility, impacto na estabilidade da ABI e Alternatives considered. Não basta explicar por que esse design, mas também por que não outro.

Etapa 3: anexar uma implementação. A prática atual do Evolution exige código funcional junto da proposta. A revisão só começa depois que o código foi testado no compilador. A viabilidade é demonstrada em código, não no papel.

Etapa 4: revisão pública. Um gerente de revisão é designado, e o fórum normalmente recebe a revisão por 1–2 semanas. As perguntas incluem: o problema é importante o bastante, a mudança combina com a direção do Swift e como se compara a recursos semelhantes de outras linguagens?

Etapa 5: decisão. Após a revisão, o Language Steering Group decide. O resultado é Accepted, Returned for revision ou Rejected, sempre com justificativa. Se aprovada, a numeração SE é definida e a implementação é lançada em uma versão específica do Swift.

O peso do processo em casos reais

Vamos ver alguns casos conhecidos para entender como o processo funciona na prática.

SE-0296 async/await. Esta proposta deu início à concorrência do Swift. Sua direção foi apresentada no Concurrency Manifesto de Chris Lattner, de 2017, mas levou anos de proposta, revisão e aprovação até chegar ao Swift 5.5. Nesse período, foi analisada com actor (SE-0306) e concorrência estruturada (SE-0304), formando um único roadmap. Grandes recursos entram como grupos de propostas.

Abreviação de if let do SE-0345. A sintaxe permite escrever if let name = name em vez de if let name. Apesar de pequena, gerou longa discussão no pitch sobre alternativas como if let name?. A decisão final escolheu a sintaxe atual pelo equilíbrio entre concisão e clareza. Até uma sintaxe simples exige tanta argumentação.

Casos rejeitados também são registrados. A proposta inicial de exigir o prefixo self nos argumentos de funções (SE-0009) foi rejeitada após a revisão, e os motivos continuam no repositório. A comunidade concluiu que o ruído adicional no código superava o ganho de explicitude. Registrar os motivos evita repetir a mesma discussão.

O padrão é claro: Evolution registra tanto o que entrou quanto o que não entrou e por quê. Assim se acumula uma jurisprudência do design de linguagens.

Quem decide — estrutura de governança

Quem toma a decisão final?

No topo do projeto Swift está o Core Team, enquanto o Language Steering Group toma as decisões substantivas sobre a linguagem. Há engenheiros da Apple e membros externos; a opinião do fórum é considerada, mas não há decisão por maioria. Segundo a documentação oficial, a revisão coleta argumentos, não votos: vence a evidência mais sólida, não a voz mais alta.

A influência da Apple é real: a maioria dos desenvolvedores do compilador trabalha para a Apple, e necessidades de suas plataformas, como resultBuilder para SwiftUI, já impulsionaram propostas. Ainda assim, a Apple não pode mudar a sintaxe fora do processo, e toda discussão fica publicamente pesquisável. Com o crescimento de server-side Swift e embedded Swift, a governança também se divide em grupos de trabalho.

Benefícios práticos para desenvolvedores

Conhecer o Evolution traz benefícios práticos claros para quem desenvolve em Swift.

Primeiro, material de aprendizado de alta qualidade é gratuito. Quando uma sintaxe nova não fica clara, a proposta original é melhor que um blog. Ela explica o problema, a justificativa do design e as alternativas, mostrando não apenas como usar, mas por que é assim. É possível buscar pelo número SE no painel swift.org/swift-evolution.

Segundo, você antevê o futuro da linguagem. O painel de pitches do fórum é uma prévia do Swift de 1–2 anos à frente. Discussões que estão quentes hoje repetidamente viram novas sintaxes no próximo WWDC.

Terceiro, a porta para participar está realmente aberta. Compartilhar sua experiência em um tópico de revisão pode ser citado na decisão. Feedback prático de usuários coreanos sobre propostas de strings ou formatação é uma contribuição mais valiosa do que parece.

Quarto, isso ajuda nas decisões técnicas do time. Diferenciar uma experimental feature flag, um recurso aprovado e uma upcoming feature fornece base para decidir quando levá-los ao código de produção.

Resumo

• SE-XXXX é o número de uma proposta de mudança de linguagem aprovada pelo Swift Evolution. Toda mudança de sintaxe do Swift passa por esse processo público.
• O caminho é pitch → proposta, incluindo alternativas → implementação → revisão pública → decisão do Language Steering Group.
• A Apple também não pode ignorar o processo, e os motivos de aprovação e rejeição ficam como jurisprudência pública do design da linguagem.
• Para entender uma sintaxe nova, a proposta original é a melhor fonte; o painel de pitches antecipa o futuro do Swift.

Com isso, termina a quarta parte da série sobre a filosofia do Swift. Vimos segurança, desempenho e expressividade, divulgação progressiva, tipos por valor e a instituição Evolution. A seguir, vamos aprofundar a sintaxe básica, começando pelo ponto de interrogação mais comum do Swift: o que são os opcionais.

Continue lendo

• [Swift intermediário #1] ARC do Swift em detalhes: escolha weak ou unowned pelas relações de ciclo de vida
• [Swift intermediário #2] Generics do Swift, da introdução à prática: como elimina duplicação e risco
• [Swift intermediário #3] some vs any no Swift: o que é some View e qual o custo dos existentials