本頁面由 Cloud Translation API 翻譯而成。

RFC-0036：結構宣告更新

RFC-0036：結構宣告的更新
狀態	已遭拒
領域	FIDL
說明	為了更清楚傳達重新排序和重新命名欄位的 ABI 帶來的影響，我們提議變更語法，導入結構體欄位的序數，同時採用類似的語法規則和資料表的語法規則。
作者	pascallouis@google.com
提交日期 (年-月-日)	2019-03-07
審查日期 (年-月-日)	2019-03-14

編輯此 RFC

編輯 RFC 中繼資料

拒絕原因

優點

名稱對 ABI 的重要性或不存在： xunion、struct 和通訊協定全部看起來很類似，不過不同的規則

缺點

然而，所有疑慮都讓消費者重心如果在結構體上引進普通法，會增加尤其是與 protobuf 相比
還有其他行動要解決「這項異動是否會影響 ABI」，即：
- DIFL
- API 差異比較，例如程式庫簽章
名稱對文字格式 (JSON、FIDLText 等) 和訊息傳送時間而言很重要，因此無法變更名稱。

摘要

為更清楚傳達重新排序和重新命名欄位的 ABI 可能的影響，我們提議進行語法變更，引入 struct 欄位的泛型。並使用類似的語法規則

提振精神

著重於會員能否安全重新命名或重新排序因此，您可以運用多種宣告和語法差異，是自然的，並未傳達任何關於 ABI 可能帶來的影響並輸入變更內容

此外，目前的 struct 宣告語法讓編譯器，在發生變化時提供協助和指引。

讓我們來看看幾個範例，這些都是小型和統一的：

struct Name {      table Name {        enum Name {
    T abc;           1: T abc;           ABC = 1;
    U xyz;           2: U xyz;           XYZ = 2;
};                 };                  };

protocol Name {    xunion Name {       bits Name {
    Abc(T t);        T abc;              ABC = 1;
    Xyz(U u);        U xyz;              XYZ = 2;
};                 };                  };

從 ABI 的角度來看：

重新排序：除了結構體外，其餘結構皆可重新調整順序，沒有任何影響。
重新命名：
- 結構體、資料表、列舉和位元可以重新命名，不會產生任何影響
- 通訊協定和 xunion 會在重新命名後影響其 ABI。

(從來源相容性的觀點來看，大多數的繫結將由來源為來源) 相容於重新訂購，且與重新命名作業不相容)。

根據這些觀察，我們提議結構體宣告。現在，上述範例如下：

struct Name {
    1: T abc;
    2: U xyz;
};

具體違規事項如下：

序數必須從 1 開始，序空間則不允許有間隔 (如果最大序數為 7，則 1,2,3,4,5,6,7 全都必須包含。詳情請見原因。
沒有任何兩個欄位可聲明相同序數。
欄位序數會決定包含結構 (而非) 欄位的位置語法位置
v1 中的 JSON IR 沒有任何變更，序數會透過順序傳輸組成成員。請查看第 2 版中的 JSON IR 預定異動。

編譯器指南

實作指引，編譯器可提供建議的語法時，我們會參考幾個範例並比較它們的處理方式。

移除欄位 (中間)

No Ordinals        With Ordinals
----------------   -------------
struct Name {      struct Name {
    T abc;           1: T abc;
-   U def;       -   2: U def;
    V ghi;           3: V ghi;
};                 };
----------------   ---------------
Breaks ABI, no     Breaks ABI,
compiler help      compiler error

移除欄位 (完)

No Ordinals        With Ordinals
----------------   -------------
struct Name {      struct Name {
    T abc;           1: T abc;
    U def;           2: U def;
-   V ghi;       -   3: V ghi;
};                 };
----------------   ---------------
Breaks ABI, no     Breaks ABI, no
compiler help      compiler help

新增欄位

No Ordinals        With Ordinals
----------------   -------------
struct Name {      struct Name {
    T abc;           1: T abc;
+   U def;       +   3: U def;
    V ghi;           2: V ghi;
};                 };
----------------   ---------------
Breaks ABI, no     Breaks ABI, no
compiler help      compiler error

重新排序欄位

No Ordinals        With Ordinals
----------------   -------------
struct Name {      struct Name {
+   U def;       +   2: U def;
    T abc;           1: T abc;
-   U def;       -   2: U def;
    V ghi;           3: V ghi;
};                 };
----------------   ---------------
Breaks ABI, no     Safe
compiler warning

不允許「保留」關鍵字

由於我們要為資料表的結構體對齊序數規則也有機會允許「reserve」字詞。

我們則應進行完全相反的：正確剖析誤用保留關鍵字，並提供明確的編譯器錯誤和解釋。適用對象執行個體「Cannotserv member in structs.新增或移除成員變更結構體版面配置，請考慮手動改為中立成員初始化。」

其他重要原因也禁止「reserve」關鍵字：

與資料表不同的是，結構體中導入邊框間距必須使用明確大小 (即位元組數)；
在結構體中使用邊框間距是為了特定目的而使用開發人員需要特定的記憶體配置由於 FIDL 版面配置始終是固定的，因此這種使用案例很少見，甚至不存在已對齊 8 個位元組。
如要進一步瞭解實作，我們已在 RFC-0066 中說明並說明相關做法： Programmer Advisory Explicit Defaults 某些值進行初始化時，超出了某些要求繫結 (例如 C、LLPP)。因此，應該引述「reserve」結構體中我們必須向後端公開該資訊以便正確初始化這似乎不是必要的。

探索道路 JSON IR

我們同時支援欄位排序 (按照序數) 和說明文件目的 (應遵循宣告順序)，則較佳的做法：

以宣告欄位的顯示順序來表示宣告順序「成員」鍵。
以「普通」表示序數鍵。

設計

未定

執行策略

新語法開始支援，同時支援上一個；
將所有來源檔案遷移至新的語法；
使用先前的語法新增警告，請預留一週的期間確保不會新增任何先前使用的語法；
停止支援先前語法。

人體工學

本提案藉由傳達 ABI 對 AI 造成的影響，改善人體工學都能透過語法協助開發人員請參閱這件事的對立觀點。

說明文件和範例

須符合以下條件：

語言規格
文法
使用結構體的範例

回溯相容性

這與來源層級回溯不相容。請參閱實作策略，進行初步遷移。

成效

沒有影響。

安全性

沒有影響。

測試

在 fidlc 中進行單元測試，用於驗證其他使用者：

剖析；
序數從 1 開始，可能沒有間隔；
JSON IR 沒有任何變更。

缺點、替代方案和未知

替代做法：資料表的序數雜湊

此外，我們也會考慮為資料表使用序式雜湊，也就是語法變化會捨棄明確的基因，讓結構體是唯一的宣告語法和資料表相同

首先，為結構體採用明確序數的好處將維持不變。開發人員還是可以透過語法重新排列欄位順序，序數表示 ABI 中斷。

其次，我們無法對探索採取行動來移除一般資料，因為在執行階段成本之間取捨 (效能較低) 大於人體工學的效益

缺點：結構和表格可能會令人困惑

結合結構體和資料表的語法，以及有些普通人認為結構體與表格混淆，並誤以為而且移除欄位也與 ABI 相容雖然在結構體中間移除欄位會導致錯誤發生，原因是序數序列中出現的間距，移除含有最大序數則保持無聲

既有藝術品和參考資料

未定