RFC-0039：類型排在第二位

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

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

編輯這份 RFC

編輯 RFC 中繼資料

「你一定會愛上 Go」

拒絕原因

在草擬並發布這項提案時，大家一致認為應一次考慮所有語法變更，而非逐一變更 (另請參閱 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 影響，進而提升人體工學。

說明文件和範例

須符合以下條件：

回溯相容性

這不具備來源層級的回溯相容性。