RFC-0039：類型排在第二位

RFC-0039：類型第二種
狀態已遭拒
領域
  • FIDL
說明

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

編輯此 RFC

編輯 RFC 中繼資料

「你一定會喜歡」

拒絕原因

這份提案草擬版並完成社會化後，一致地： 想一次處理所有語法變更，而不是逐一處理 (請參閱 RFC-0038)。 我們也希望將一個人做為語法仲裁 由委員會提供

這項提案最終已由以下人員淘汰： 符合的 RFC-0050 同時符合兩項條件

摘要

我們建議：

  • 允許結構體、聯集和資料表的內嵌宣告；
  • 翻轉欄位名稱 (或引數/傳回名稱) 的出現順序 根據類型，明確指出類型顯示在名稱之後。

(我們不能再推出匿名宣告，因為我們可能希望能 加強繫結支援，以確保人體工學的良好。)

提振精神

快速：

  • 我們開始看到更多模式結合各種宣告的模式 描述「一則概念訊息」是常式的。例如：
    • 容器結構，其最後一個欄位為資料表 (一開始為空白) 以退出 即可開啟擴充功能
    • 容器聯集，其中變化版本為資料表，具有彈性。
    • 容器表格，其中欄位依結構分組，而普通 比對「version number」。
  • 此外，支援空白結構、聯集和資料表，還提供了 以便透過版面配置建構代數資料類型支援 而非繫結)。
  • 因此，無論是何種用途，都必須允許我們允許內嵌宣告。
  • 使用內嵌宣告會更容易先讀取欄位名稱，然後 類型說明，且可橫跨多行。請參閱下方範例。

設計

以下列舉部分範例：

  • 簡易結構或資料表：

    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 的影響，從而改善人體工學 經由語法進行檢查

說明文件和範例

須符合以下條件：

回溯相容性

這與來源層級回溯不相容。