RFC-0039：類型排在第二位

RFC-0039：類型為第二順位
狀態已遭拒
區域
  • FIDL
說明

我們建議允許 struct、xunions 和 table 的內嵌宣告；改變類型相關欄位名稱 (或引數和傳回名稱) 的顯示順序，特別在名稱後面顯示型別。
作者
提交日期 (年/月)2019-03-07

編輯此 RFC

編輯 RFC 中繼資料

「你馬上就會愛上它」

拒絕原因

當這份提案草擬草案並進行社會上課時，強烈的共識是一次考慮所有語法變更，而不是一次考慮一個項目 (另請參閱 RFC-0038)。我們也希望由一人擔任語法仲裁者，而不是由委員會做出設計風險。

此提案最終是由 RFC-0050 取代，後者同時符合這兩項條件。

摘要

我們建議的做法：

  • 允許結構體、聯集和資料表的內嵌宣告；
  • 翻轉欄位名稱 (或引數/傳回名稱) 與類型對應的順序，尤其是類型在名稱後面。

(我們可能不會推出匿名宣告，因為我們希望改善繫結支援，以確保符合人體工學的品質。)

提振精神

快速：

  • 我們開始看到更多模式，其中各種宣告的組合來說明「單一概念訊息」是例行性的做法。例如：
    • 容器結構體，其最後一個欄位是資料表 (一開始為空白)，以便讓擴充功能開放。
    • Container Union，其中變數是資料表具有彈性的。
    • 容器資料表，其中欄位以結構體分組，而序數則大致符合「版本編號」。
  • 此外，如果支援空白結構、聯集和資料表，也提供低階元件，以便透過版面配置觀測點 (而非繫結) 建構代數資料類型。
  • 上述所有用途皆促使我們允許內嵌宣告。
  • 使用內嵌宣告時，可以更容易先讀取欄位名稱，然後再提供類型說明，這可能會橫跨多行。請參閱下方範例。

設計

以下列舉部分範例：

  • 簡易結構或資料表：

    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 的影響傳達給開發人員，藉此改善人體工學。

說明文件與範例

至少：

回溯相容性

與來源層級回溯不相容。