A palavra-chave `some` em Swift e SwiftUI: para que serve?

O misterioso «some»: por que milhares de desenvolvedores perguntam sobre ele?

Se você já escreveu em SwiftUI, certamente já viu a construção some View. Ela parece simples, mas os iniciantes frequentemente ficam confusos: «O que é esse «some»? Por que não posso escrever apenas View? E se eu remover o some — vai quebrar?». A pergunta «What is the "some" keyword in Swift(UI)?» acumulou milhares de visualizações no Stack Overflow — e não é por acaso. Por trás de uma palavra curta, esconde-se toda uma filosofia do Swift moderno.

Neste artigo, vamos entender o que é a palavra-chave some, por que ela apareceu na linguagem e por que é impossível imaginar o SwiftUI sem ela. Você descobrirá como ela se relaciona com genéricos, protocolos e «tipos opacos» (opaque types). E, principalmente, entenderá como escrever um código mais limpo e eficiente.

O problema que o «some» resolve

Imagine que você está escrevendo uma função que retorna algum objeto que esteja em conformidade com o protocolo View. No SwiftUI, isso acontece o tempo todo:

func makeGreeting() -> View {\n    return Text("Hello!")\n}

O compilador Swift dirá: «O protocolo 'View' só pode ser usado como uma restrição genérica (generic constraint), porque possui requisitos de Self ou associated type». Parece assustador, mas a ideia é simples: o protocolo View no SwiftUI exige que o tipo seja conhecido em tempo de compilação. Se retornamos View — é uma abstração, e o compilador precisa de algo concreto.

Antigamente, os desenvolvedores contornavam isso com genéricos:

func makeGreeting<T: View>() -> T {\n    return Text("Hello!") as! T\n}

Isso funcionava, mas parecia uma gambiarra: você promete ao compilador que retornará T, mas na verdade está «fingindo». Além disso, o código chamador precisava especificar explicitamente o tipo. Feio e inseguro.

«Some» — o salvador do código repetitivo

A palavra-chave some no Swift apareceu na versão 5.1 justamente para esses casos. Ela diz ao compilador: «Vou retornar um tipo específico que está em conformidade com o protocolo, mas não quero dizer o nome dele. Você mesmo o determina em tempo de compilação». Isso é chamado de tipo opaco (opaque type).

Voltemos ao nosso exemplo:

func makeGreeting() -> some View {\n    return Text("Hello!")\n}

Agora o código compila! O compilador sabe que o retorno é exatamente Text, mas externamente vemos apenas some View. Isso proporciona duas coisas:

\n
• Segurança de tipos — o compilador verifica se o tipo retornado é sempre o mesmo.
\n
• Encapsulamento — ocultamos os detalhes de implementação do código chamador.
\n

Comparação: «some» vs genéricos vs protocolos

Para entender melhor a mágica do some, vamos comparar as três abordagens com um exemplo concreto. Suponha que queremos escrever uma função que retorna uma forma (círculo ou quadrado).

1. Retorno de protocolo (não compila)

protocol Shape {\n    func draw()\n}\n\nstruct Circle: Shape {\n    func draw() { print("Desenhando círculo") }\n}\nstruct Square: Shape {\n    func draw() { print("Desenhando quadrado") }\n}\n\n// Erro: o protocolo 'Shape' não pode ser usado como tipo de retorno\nfunc makeShape() -> Shape {\n    return Circle()\n}

Como já sabemos — não funciona se o protocolo tiver associated types ou Self requirements.

2. Uso de genéricos

func makeShape<T: Shape>() -> T {\n    // Precisamos criar T de alguma forma, mas não sabemos o tipo concreto\n    fatalError("Impossível criar genérico")\n}

Problema: o código chamador precisa saber qual tipo esperar. A função não pode decidir sozinha o que retornar.

3. Uso de «some» (funciona perfeitamente)

func makeShape() -> some Shape {\n