Protocol Buffersでint16が使えない理由
Protocol Buffers（以下、proto）を使っていると、「int16型があれば便利なのに」と思うことがあるかもしれません。しかし、protoではint16を直接サポートしていません。この記事では、その理由を解説し、関連する公式情報や議論のリンクもご紹介します。
なぜint16は使えないのか？
1. 型設計の簡潔性
Protocol Buffersでは、汎用性を重視して型設計を行っています。そのため、int16やint8といった細かい型をサポートせず、以下のような基本的な型に統一されています：
-
int32（符号あり32ビット整数） -
int64（符号あり64ビット整数）
公式ドキュメントにもスカラー型一覧が記載されています：
Protocol Buffers公式スカラー型リスト
2. 通信サイズに影響しない
Protocol Buffersでは、Varintエンコーディングが採用されています。この方式では、値の大きさに応じて通信サイズが決まるため、int16を使用した場合とint32を使用した場合で通信サイズには大きな違いがありません。
例：
- 値が小さい場合（-64 ～ 63）：1バイト
- 中程度の値（-8192 ～ 8191）：2バイト
- 大きい値（-1,048,576 ～ 1,048,575）：3バイト
つまり、int16が導入されても通信効率におけるメリットは限定的です。
3. 複雑性を排除する設計
int16をサポートすると、他にもint8やuint16といった型の導入を検討する必要が生じます。このような型の増加は、Protocol Buffersの設計を複雑にし、異なる言語間の互換性を損なう可能性があります。
Protocol Buffersの開発者たちは、このシンプルさを維持するために細かい型を導入しない設計を選びました。この方針については、GitHubの議論でも言及されています：
Protocol Buffers Issue #3091: Why no support for smaller integers?
結論
Protocol Buffersでint16が使えない理由は以下の通りです：
-
int32がint16の範囲を完全に包含している。 - Varintエンコーディングにより、通信サイズへの影響がほぼない。
- プロトコル設計をシンプルに保つため。
そのため、int16の代わりにint32を使用することが推奨されます。
参考資料
この記事が、Protocol Buffersにおけるint16の扱いに関する疑問の解消に役立てば幸いです。