C言語が明らかに実施すべきこと

• Cの明白な改善点

  • C23標準: C言語は定期的に改善されており、現在はC23に至っている。しかし、いまだに解決されていない問題が存在する。
  • Dlangコミュニティの取り組み: Dプログラミング言語コンパイラにCコンパイラ（ImportC）を組み込むことで、これらの問題を解決する機会を提供している。

• 定数式評価

  • 問題点: Cはコンパイル時に単純な式を計算できるが、関数の実行はできない。
  • ImportCの解決策: ImportCはコンパイル時の関数実行を許可し、この制限を克服する。

• コンパイル時ユニットテスト

  • Cでの問題点: Cコードでユニットテストを行うには別個のビルド対象が必要で、煩雑である。
  • ImportCの利点: ImportCはコンパイル時の関数評価によって、ユニットテストを簡単に実行可能にする。

• 宣言の前方参照

  • Cの制約: Cは宣言の順序に敏感であり、前方参照を許可しない。
  • ImportCの利点: ImportCは宣言の順序に縛られず、任意の順序でグローバル宣言を許可する。

• 宣言の取り込み

  • 従来方式の問題点: 外部モジュールごとに .h ファイルを書かなければならない煩わしさがある。
  • ImportCの解決策: ImportCは .h ファイルなしでも宣言を取り込めるため、効率的である。

• 参考資料

  • ImportCドキュメント: ImportCに関する詳細情報を提供。
  • D言語ドキュメント: D言語に関する追加情報を提供。

[GN⁺]

Hacker Newsの意見

• C言語のヘッダーファイルは公開用と非公開用、インターフェースと実装を明確に区別できるのがよい。.h ファイルを通じてライブラリの使い方を簡単に把握できる

  • .h ファイルにドキュメントが集約されるため、.c ファイルとは見え方が異なる
  • ドキュメントを .c ファイルに入れることもできるが、インターフェースが読みにくくなる

• C言語でコンパイル時に関数を実行できるべきだという意見もあるが、実行時間の長い関数は問題になりうる

  • 例として busybeaver 関数がある

• 定数式評価、コンパイル時ユニットテスト、宣言の前方参照、宣言の取り込みといった問題への解決策が気になる

  • 定数式評価: 翻訳単位内で処理すれば単純だが、コードの繰り返しが必要になる
  • コンパイル時ユニットテスト: マクロで表現すれば可能だが、最初のポイントを追加すれば容易になる
  • 宣言の前方参照: コンパイラが2回のパスを必要とし、性能に影響する可能性がある
  • 宣言の取り込み: Cでテンプレートを実装する方法が壊れる可能性がある

• Cコードのユニットテスト作成は、よいビルドシステムと少しのボイラープレートがあれば可能

  • 例として npy ライブラリのテストコードがある

• 定数式評価が複雑な場合、コンパイラ速度が低下する可能性があり、VMが必要になることもある

  • C++20の定義よりも、モジュールをシンボルとして取り込む方向のほうがよかったのではないかという意見

• コンパイル時ユニットテストは開発者の制御を奪い、作業完了のために不要な手順を要求する

  • ビルド失敗テストは最終ビルドにはよいが、中間ビルドには適していない

• 関数定義を「トップダウン」で行うほうがよいかについての議論

  • Pythonのような言語でもトップダウン定義が一般的
  • トップダウン定義が特定の種類のコードにより適しているのかという問い

• C言語に追加されてほしい機能

  • ポインタと長さをエンコードするスライスタイプのサポート
  • 再入可能でスレッドセーフなAPI
  • GoやZigの defer のような機能の標準化
  • UnicodeとUTF-8のポータブルなサポート

• Cのシンプルな実装は長所であり、範囲を大きく拡張するのはよい考えではない

  • Schemeのように「小さい」版と「大きい」版の仕様を持てるかもしれない

• 関数定義を上から下にするほうがよい理由

  • 関数内でコードを書くやり方に似ている
  • モジュール内での関数の位置が明確になる
  • 循環依存関係を明確に把握できる
  • 循環依存関係はコードベースを複雑にし、モジュールの理解を難しくする
  • OCamlは関数間の循環依存関係を許可しない