Optional / Nullable — conceitos-chave e trabalho com tipos anuláveis

O que são Optional e Nullable?

Optional em Swift e nullable em Kotlin são recursos da linguagem que tornam null uma parte explícita do sistema de tipos. Em Swift, Optional é um enum: Optional.none (nil) e Optional.some(Wrapped). Em Kotlin, nullable é denotado pelo sufixo ? no tipo: String? pode ser uma string ou null.

Ambas as abordagens resolvem o problema fundamental que Tony Hoare chamou de “erro de bilhão de dólares” — null reference. Antes dos tipos opcionais, qualquer referência poderia ser null, e a verificação ficava a cargo do desenvolvedor. Swift e Kotlin transferem essa verificação para o tempo de compilação: código que ignora null não compilará.

Apesar do objetivo comum, Swift e Kotlin implementam null-safety de forma diferente. Swift usa o tipo algébrico Optional com pattern-matching completo. Kotlin incorpora nullable no sistema de tipos no nível do compilador sem criar um tipo wrapper separado.

Historicamente, null reference apareceu em 1965 na linguagem ALGOL W como uma forma de representar a ausência de um valor. Ao longo de seis décadas, null se tornou a fonte de inúmeras falhas — de acordo com a pesquisa de Tony Hoare, 30 a 50 por cento dos erros em código de produção estão relacionados a NullPointerException. Swift com Optional e Kotlin com tipos nullable se tornaram as primeiras linguagens mainstream a resolver esse problema no nível do sistema de tipos, tornando null uma parte explícita do contrato da função.

Optional em Swift: sintaxe e trabalho com tipos opcionais

Em Swift, Optional é um tipo completo declarado como enum Optional<Wrapped>. O açúcar sintático ? substitui a notação completa: Int? é equivalente a Optional<Int>. Trabalhar com Optional inclui várias maneiras de extrair o valor.

If-let e guard-let binding

if let — extração condicional: se Optional contém um valor, ele é vinculado a uma constante dentro do bloco. guard let — saída antecipada da função se Optional for nil. guard let mantém o código plano, evitando if-let aninhados.

Optional chaining

Optional chaining (acesso seguro sequencial) através de ? permite chamar um método ou propriedade em um Optional sem unwrapping explícito. Se qualquer elo da cadeia for nil, toda a cadeia retorna nil. Isso reduz o código ao trabalhar com dados hierárquicos.

Operador nil-coalescing

?? (nil-coalescing) — um operador que retorna o valor Optional se não for nil, caso contrário retorna um valor padrão. É uma alternativa concisa ao if-let para fornecer um valor de fallback.

var name: String? = "Alice"

// If-let binding
if let unwrapped = name {
    print("Olá, \(unwrapped)")
}

// Optional chaining
let count = name?.count

// Nil-coalescing
let display = name ?? "Convidado"

// Map em Optional
let greeting = name.map { "Hello, \($0)" }

Nullable em Kotlin: chamadas seguras e operador Elvis

Em Kotlin, nullable é parte do sistema de tipos, não um tipo wrapper separado. O tipo String? pode conter null, enquanto String (sem o ponto de interrogação) nunca pode. O compilador rastreia nullable através de smart cast e anotações.

Chamada segura ?.

?. — o operador de chamada segura. Se o objeto não for null, o método ou propriedade é chamado; se for null — null é retornado sem chamada. É análogo ao optional chaining em Swift, mas sintaticamente mais curto.

Operador Elvis ?:

?: — o análogo em Kotlin de nil-coalescing. Se a expressão à esquerda não for null, ela é retornada; caso contrário — o valor à direita. O operador Elvis é frequentemente combinado com retorno antecipado via return ou throw.

Smart cast e operador !!

Smart cast — o compilador Kotlin converte automaticamente nullable para non-null após uma verificação de null em if ou when. !! — unwrapping forçado que lança NullPointerException se for null. Use !! apenas quando null for um bug.

val name: String? = "Alice"

// Chamada segura
val length = name?.length

// Operador Elvis
val display = name ?: "Convidado"

// Smart cast após verificação
if (name != null) {
    println("Tamanho: ${name.length}")
}

// Let com lambda
name?.let { println("Olá, $it") }

// Force unwrap — apenas quando tiver certeza
val forced = name!!

Optional vs Nullable: diferenças-chave nas abordagens

Embora Swift e Kotlin resolvam a mesma tarefa, suas abordagens para null-safety são fundamentalmente diferentes. Entender essas diferenças é importante para desenvolvedores que trabalham com ambas as plataformas.

Representação no sistema de tipos

Swift usa enum Optional — um tipo algébrico padrão. Kotlin incorpora nullable no nível do sistema de tipos do compilador sem criar um objeto wrapper. Isso afeta o desempenho: Optional em Swift é um objeto no heap, enquanto nullable em Kotlin é uma verificação de null sem alocação.

Sintaxe e expressividade

A sintaxe de Kotlin é mais curta graças aos operadores embutidos ?., ?:, !!. Swift requer uma sintaxe mais explícita: if let, guard let, map em Optional. No entanto, Swift fornece pattern-matching através de switch, que Kotlin não suporta diretamente para nullable.

Padrões de null-safety no desenvolvimento mobile

No desenvolvimento mobile, padrões estabelecidos para trabalhar com tipos opcionais surgiram, reduzindo código boilerplate e aumentando a segurança.

Map e flatMap em Optional

Swift e Kotlin suportam map e flatMap para Optional e nullable. Se um valor existe, uma transformação é aplicada; se for null — null é retornado. Isso elimina verificações if-let aninhadas.

Valores padrão via Elvis

Em vez de if-let + else, use ?: ou ?? com um valor padrão. Isso torna o código declarativo: “use X se disponível, senão Y” em vez de verificação procedural.

Nullable em Compose e SwiftUI

Em Jetpack Compose e SwiftUI, tipos opcionais controlam a renderização: se o estado for null — esconda o componente, caso contrário mostre. Isso segue o princípio de single source of truth.

data class UserState(
    val name: String?,
    val email: String?
)

// Smart cast em when com variantes diferentes
fun greeting(state: UserState): String = when {
    state.name != null && state.email != null ->
        "${state.name} (${state.email})"
    state.name != null -> state.name
    else -> "Convidado"
}

// Compose: exibição por presença
@Composable
fun UserProfile(name: String?) {
    name?.let {
        Text(text = it)
    } ?: Text(text = "Sem dados")
}

Para migrar código Java existente para Kotlin, é recomendado usar as anotações @Nullable e @NonNull do pacote androidx.annotation. O compilador Kotlin respeita essas anotações durante interop com Java, tornando automaticamente os tipos correspondentes nullable ou non-null. A migração gradual com anotações explícitas é mais segura do que habilitar globalmente null-safety no projeto.

Erros comuns ao trabalhar com Optional e Nullable

Null-safety reduz o número de erros, mas não os elimina completamente. Desenvolvedores frequentemente cometem erros característicos ao trabalhar com tipos opcionais.

• Force unwrap sem garantia — name! ou name!! sem certeza de que o valor não é nil causa crash em produção. Verifique null antes do force unwrap.
• If-let excessivo — if-let aninhados para três ou mais Optional criam uma pirâmide do doom. Use guard let ou flatMap.
• Ignorar nil-coalescing — verificação explícita via if-let com bloco else pode ser substituída por ?? ou ?:, o que reduz código e melhora a legibilidade.
• Nullable em APIs públicas — se uma função aceita nullable, cada chamada requer uma verificação. Prefira non-null com um valor padrão ou sobrecarga.