As coisas óbvias que a linguagem C deveria fazer

• Melhorias óbvias no C

  • Padrão C23: A linguagem C é aprimorada regularmente e agora chegou ao C23. No entanto, ainda existem problemas que continuam sem solução.
  • Esforço da comunidade Dlang: Ao incorporar um compilador C (ImportC) ao compilador da linguagem de programação D, surgiu uma oportunidade de resolver esses problemas.

• Avaliação de expressões constantes

  • Problema: C consegue calcular expressões simples em tempo de compilação, mas não pode executar funções.
  • Solução do ImportC: O ImportC permite executar funções em tempo de compilação, superando essa limitação.

• Testes unitários em tempo de compilação

  • Problema no C: Em código C, testes unitários exigem um alvo de build separado, o que é inconveniente.
  • Vantagem do ImportC: O ImportC facilita a execução de testes unitários por meio da avaliação de funções em tempo de compilação.

• Referência antecipada de declarações

  • Limitação do C: C é sensível à ordem das declarações e não permite referências antecipadas.
  • Vantagem do ImportC: O ImportC não depende da ordem das declarações e permite declarações globais em qualquer ordem.

• Importação de declarações

  • Problema da abordagem existente: Há o incômodo de precisar escrever arquivos .h para cada módulo externo.
  • Solução do ImportC: O ImportC permite importar declarações sem arquivos .h, tornando o processo mais eficiente.

• Materiais de referência

  • Documentação do ImportC: Fornece informações detalhadas sobre o ImportC.
  • Documentação da linguagem D: Fornece informações adicionais sobre a linguagem D.

[GN⁺]

Comentários do Hacker News

• Os arquivos de cabeçalho da linguagem C são bons porque permitem separar claramente o que é público do que é privado, e a interface da implementação. Pelo arquivo .h, é fácil entender como usar uma biblioteca

  • A documentação fica concentrada no arquivo .h, então ele parece diferente do arquivo .c
  • Também é possível colocar a documentação no arquivo .c, mas isso torna a interface mais difícil de ler

• Há quem defenda que a linguagem C deveria permitir executar funções em tempo de compilação, mas funções com tempo de execução longo podem ser problemáticas

  • Um exemplo é a função busybeaver

• Há curiosidade sobre soluções para problemas como avaliação de expressões constantes, testes unitários em tempo de compilação, referência antecipada de declarações e importação de declarações

  • Avaliação de expressões constantes: fica simples se for feita dentro da unidade de tradução, mas exige repetição de código
  • Testes unitários em tempo de compilação: dá para expressar com macros, mas ficaria mais fácil se o primeiro ponto fosse adicionado
  • Referência antecipada de declarações: pode fazer o compilador precisar de duas passagens, afetando o desempenho
  • Importação de declarações: pode quebrar a forma de implementar templates em C

• Escrever testes unitários para código C é possível com um bom sistema de build e um pouco de boilerplate

  • Um exemplo é o código de teste da biblioteca npy

• Quando a avaliação de expressões constantes fica complexa, a velocidade do compilador pode cair, e pode ser necessário usar uma VM

  • Houve a opinião de que teria sido melhor seguir na direção de importar módulos por símbolo do que a definição do C++20

• Testes unitários em tempo de compilação tiram o controle do desenvolvedor e exigem procedimentos desnecessários para concluir o trabalho

  • Testes de falha de build são bons para o build final, mas não são adequados para builds intermediários

• Discussão sobre se definir funções de forma "de cima para baixo" é melhor

  • Mesmo em linguagens como Python, a definição de cima para baixo é comum
  • Há a pergunta se esse estilo é mais adequado para certos tipos de código

• Recursos que alguns gostariam de ver adicionados à linguagem C

  • Suporte a um tipo slice que codifique ponteiro e comprimento
  • APIs reentrantes e thread-safe
  • Padronização de algo como o defer de Go e Zig
  • Suporte portátil a Unicode e UTF-8

• A implementação simples de C é uma vantagem, e expandir muito o escopo não parece uma boa ideia

  • Como em Scheme, poderia haver uma especificação "pequena" e uma "grande"

• Razões pelas quais definir funções de cima para baixo pode ser melhor

  • É parecido com a forma como se escreve código dentro de uma função
  • A posição das funções dentro do módulo fica clara
  • Fica mais fácil identificar dependências circulares
  • Dependências circulares tornam a base de código mais complexa e dificultam entender o módulo
  • OCaml não permite dependências circulares entre funções