Type Erasure: escondendo tipos concretos por trás de interfaces uniformes

Type erasure não é só um truque de compilador, é uma estratégia de design que define como o código lida com heterogeneidade sem sacrificar segurança ou performance. Em Java, ela existe por compatibilidade: genéricos são apagados em tempo de compilação, deixando `List` e `List` iguais no bytecode, o que impede `instanceof` dinâmico e exige casts implícitos. Em C++, é um idioma intencional: `std::function`, `std::any` e `std::variant` escondem tipos concretos atrás de interfaces limpas, sem herança obrigatória nem templates expostos ao usuário. Já em Swift, a técnica virou parte da linguagem com SE-0309 (Swift 5.7), permitindo abstração de protocolos com tipos associados, essencial para coleções como `AnyCollection`. A diferença fundamental? Java apaga por restrição; C++ e Swift usam como ferramenta de projeto.

O artigo atual omite um ponto crítico para desenvolvedores: o custo oculto. Type erasure em C++ frequentemente envolve alocação dinâmica (ex: `std::function` com captura grande) ou indireção via vtable, impactando cache e latency. Em Java, a perda de tipo em runtime dificulta serialização eficiente e introspecção real. E em Swift, wrappers manuais ainda exigem cuidado com ownership e lifetime, especialmente quando combinados com async/await. Esses trade-offs não aparecem na definição conceitual, mas definem se a técnica escala em sistemas críticos.

A cobertura anterior do CEVIU não tratava type erasure diretamente, mas os artigos de 26 e 27 de maio de 2026 sobre as divergências entre C e C++ e a complexidade dos arrays em C criam o pano de fundo técnico necessário: modelos de objeto distintos exigem mecanismos como type erasure para preencher lacunas de flexibilidade sem quebrar a ABI. Agora, com a notícia de 3 de junho, o CEVIU fecha o ciclo, não mais apenas descrevendo limitações (como arrays que decaem em ponteiros), mas apresentando a técnica que permite contorná-las com controle explícito. Também há evolução prática: enquanto os artigos anteriores citavam C23 e C++20 como padrões referenciais, a nova matéria assume que o leitor já opera em C++23, onde `std::move_only_function` e melhorias em `std::any` refinam o uso de type erasure sem cópias desnecessárias.

Desenvolvedores que ignoram type erasure acabam recriando-a de forma frágil, com `void*`, `interface{}` ou `any` sem garantias de segurança, gerando bugs difíceis de rastrear em produção. Saber quando usar `std::any` vs `std::variant`, ou quando evitar `Object` em Java em favor de sealed classes + pattern matching, muda a qualidade do código em três frentes: testabilidade (tipos apagados dificultam mocks precisos), performance (indireções não triviais afetam throughput em pipelines de dados) e manutenção (wrappers mal projetados viram caixas pretas que ninguém ousa tocar). Mais que um conceito teórico, é uma decisão de arquitetura com consequências diretas em DX e SLOs.