Tipos Polimórficos em C [pdf]
Uma proposta para adicionar tipos polimórficos à linguagem C, por meio de novos construtos como `_Type` e `_Var`, reacendeu tensões de longa data sobre até onde o C deve evoluir versus delegar a responsabilidade ao C++ ou a linguagens de sistemas mais novas. Os defensores argumentam que generics com segurança de tipos, melhores arrays e informação de tipo em tempo de execução melhorariam materialmente a segurança, a reutilização e a interoperabilidade em domínios como embarcados e aviação, especialmente onde compiladores C++ não estão disponíveis ou não são confiáveis. Os críticos respondem que o design parece ad hoc e esteticamente feio, corre o risco de “inchar” o C com meias-medidas em vez de adotar de forma limpa ideias comprovadas, e pode enfraquecer o apelo do C como uma linguagem central pequena e previsível.
Recepção geral aos tipos polimórficos em C
- Muitos consideram os tipos polimórficos realmente úteis, especialmente para bibliotecas genéricas e substitutos mais seguros para padrões com
void*. - A proposta é vista como “corajosa”, mas também como “remendosa” e estranhamente acoplada ao sistema de tipos existente de C, em vez de um design limpo e de primeira classe.
- Alguns gostam do fato de ela mirar além de templates no estilo C++ em direção a tipos polimórficos/dependentes mais poderosos, evitando monomorfização e inchaço de código.
- Outros criticam regras semânticas condicionais (“válido apenas em alguns contextos”), por ecoarem a complexidade de C++ e dificultarem o raciocínio sobre o código.
C vs C++ e outras linguagens
- Um tema recorrente: “basta usar C++” para generics e polimorfismo vs. “C++ é inchado e confuso.”
- Vários argumentam que C deveria selecionar apenas as “boas partes” de C++ em uma forma mais simples; outros acham que não é isso que está acontecendo — os novos recursos parecem meio comprometidos e mais estranhos do que o necessário.
- Alguns mudaram explicitamente de C++ de volta para C, citando a complexidade e o uso inadequado de recursos avançados de C++ em bases de código reais.
- Alternativas discutidas: Rust (visto como caminhando para o inchaço de recursos), Ada (forte, mas difícil de vender), Zig/Odin/D com
-betterC, e C3 (comany*e uma filosofia de “sem grandes ideias”).
Segurança de tipos, arrays e void*
- Debate sobre se C++ é inerentemente mais seguro em tipos do que C:
- O lado pró-C++ cita generics por template,
std::array, verificação de tipos de ponteiros mais forte estatic_cast. - O lado pró-C contrapõe que C moderno, com estilo cuidadoso (sem arrays decaídos, casts mínimos, macros para segurança), pode atingir segurança semelhante.
- O lado pró-C++ cita generics por template,
- Arrays multidimensionais: alguns elogiam os VLA de C como melhores do que arrays em C++; outros os chamam de risco de segurança, com a réplica de que proteções de stack mitigam isso.
- APIs baseadas em
void*(por exemplo,qsort, PAM, Wayland) são citadas como pontos problemáticos; generics com segurança de tipos são vistos como uma motivação-chave.
Sintaxe, palavras-chave e estética
- Forte rejeição à estética de
_Type/_Var/_Generic; muitos observam que bases de código em C favorecem identificadores totalmente em minúsculas. - Explicação: a forma com sublinhado inicial e letra maiúscula é reservada para não quebrar código existente; depois, aliases em minúsculas ou palavras-chave reais podem aparecer (como
_Bool→boolem C23). - Preocupação de que algumas palavras-chave (como
_Generic) nunca receberam aliases mais agradáveis, limitando a adoção; preocupação semelhante para_Typee_Var.
Casos de uso e tipagem dinâmica / FFI
- Benefícios propostos incluem:
- Interfaces genéricas com segurança de tipos (por exemplo, funções no estilo
qsort). - Construção mais fácil de tipos e chamadas de função em tempo de execução para interoperabilidade entre linguagens, se
_Typeofpuder fornecer descrições de tipos em tempo de execução inspecionáveis.
- Interfaces genéricas com segurança de tipos (por exemplo, funções no estilo
- Alguns questionam se essas necessidades justificam complicar o C em vez de escolher outra linguagem; outros argumentam que nenhuma linguagem existente corresponde à combinação de simplicidade, portabilidade e controle do C.