Protobuf 3がメッセージのすべてのフィールドをオプションにしたのはなぜですか？

protobufの構文3は、すべてのフィールドをオプションにし、キーワードrequiredを削除し、optional以前のproto2構文から削除しました。開発者からのコメントを読むと、前方/後方バイナリ互換性を強化するために行われたようです。

しかし、私にとっては、パッケージ名をバージョン管理するだけで強制できます。たとえばcom.example.messages.v1、クライアントが理解できるデシリアライザーを実装できるようにします。同時に、ソフトウェアエンジニアリングの観点から有用なタイプとして指定されている一部の契約を削除します。たとえば、私が持っている場合

message Location {
   double latitude = 1;
   double longitude = 2;
}

proto3ではLocation、必須フィールドの1つを提供しないことにより、完全に有効な半バックアップを作成できます。

クライアント間でデータを交換するためのスキーマベースのシリアル化形式を作成する場合、これは大きな欠点ではありませんか？すべての必須フィールドに有効な値があることを確認するために、各クライアントに追加の検証コードを移動するのは悪くありませんか？

proto3は クロスプラットフォームシナリオではるかに使いやすくすることを目的として（私が理解しているように）多くの変更を行いました。「割り当てられた」対「割り当てられていないがデフォルト値を報告する」の明示的な追跡は、一部のターゲットプラットフォームで実装するのが非常に難しく、使用するのも混乱させる可能性があります。そのため、proto3ははるかに単純なアプローチを採用しています。

• その 暗黙のデフォルト値は自然のゼロ値（数値/列挙型）、偽（ブール値）または空の文字列（文字列）
• 暗黙のデフォルトのみが許可されます。他のデフォルト値は許可されていません
• フィールドにそのデフォルト値がある場合、シリアル化されません。明示的にゼロ/ false /空の文字列に割り当てられたか、割り当てられなかったかは関係ありません
• このため、「必須」という概念はありません。「明示的にゼロ値が割り当てられている」と「値が割り当てられていない」が同一に見えるためです。

proto3では、必須フィールドの1つを提供しないことにより、半バックアップで完全に有効なロケーションを作成できます。

他の値はゼロです。明示的にゼロに割り当てなかったという事実は、議論の余地があります。これが望ましいかどうかはあなた次第ですが、私には理にかなっており、多くの「新しいオブジェクト/構造体の初期化」が幅広いプラットフォームでどのように機能するかです。

すべての必須フィールドに有効な値があることを確認するために、各クライアントに追加の検証コードを移動するのは悪くありませんか？

検証するものは何もありません！レイアウトは、値ゼロが明示的に割り当てられた場合のとおりです。それが合法である場合、それは合法です。違法である場合（ゼロが意味をなさないため）、違法です。しかし、明示的か暗黙的かは違法です。関連する検証の量は変わりません。

クライアント間でデータを交換するためのスキーマベースのシリアル化形式を作成する場合、これは大きな欠点ではありませんか？

通常、そうではありません...特にスキーマバージョンが明示的であるためです。proto2を使用する場合：proto2を使用します。自動的には何も変わりません。