RFC-0039：類型排在第二位

RFC-0039：類型為次要
狀態已遭拒
區域
  • FIDL
說明

我們建議允許內嵌結構體、xunion 和資料表的宣告；反轉欄位名稱 (或引數和回傳名稱) 與類型顯示的順序，具體來說，就是讓類型顯示在名稱後方。
作者
提交日期 (年-月-日)2019-03-07

編輯此 RFC

編輯 RFC 中繼資料

「你一定會喜歡」

拒絕理由

在起草及公開討論此提案時，我們一致認為應一次性考慮語法變更，而非逐一考量 (另請參閱 RFC-0038)。我們也希望由一人擔任語法仲裁者，而非由委員會設計。

最後，這項提案已由 RFC-0050 取代，因為後者符合兩項條件。

摘要

我們建議採取以下做法：

  • 允許結構體、聯集和資料表的內嵌宣告。
  • 將欄位名稱 (或引數/傳回名稱) 與類型的顯示順序互換，具體來說，就是讓類型顯示在名稱後方。

(我們不打算引入匿名宣告，因為我們可能會希望改進綁定支援功能，確保良好的人體工學。)

提振精神

快速：

  • 我們開始發現更多模式，其中結合各種宣告來描述「一個概念性訊息」是常態。例如：
    • 容器結構體，其最後一個欄位是表格 (最初為空白)，可讓擴充功能保持開放。
    • 容器聯集，其中變化版本是可靈活運用的資料表。
    • 容器資料表，其中欄位以結構體分組，並且序數大致與「版本號碼」相符。
  • 此外，空結構體、聯集和表格的支援功能可提供低階元件，以便建構代數資料類型支援 (從版面配置角度，而非繫結)。
  • 所有這些用途都促使我們允許內嵌宣告。
  • 使用內嵌宣告後，您可以先讀取欄位名稱，然後再讀取類型說明，而這類說明可以跨越多行。請參閱下方範例。

設計

以下列舉部分範例：

  • 簡單的結構體或表格：

    struct Name {
    field int32;
};

table Name {
    1: field int32;
};

  • 通訊協定：

    protocol Name {
    Method(arg int32) -> (ret int32);
};

  • 含擴充功能的結構體：

    struct Name {
    field1 T1;
    field2 T2;
    ...;
    ext table NameExt {};
};

  • 聯合變數：

    union Name {
    variant1 table NameVariant1 {
        ...
    };
    variant2 table NameVariant2 {
        ...
    };
    ...
};

  • 依版本分組的欄位：

    table Name {
    1: v1 struct NameGroupV1 {
        ...
    };
    2: v2 struct NameGroupV2 {
        ...
    };
    ...
};

注意：

  • 就範圍而言，雖然我們會將所有宣告名稱視為頂層 (因此會針對每個程式庫強制執行不重複)，但我們不會允許內嵌宣告被參照，也就是只能單一使用。

人體工學

本提案透過語法向開發人員傳達 ABI 影響，以改善人因工程。

說明文件和範例

至少：

回溯相容性

這不是源碼層級的回溯相容性。