RFC-0031：型型字符

RFC-0031：Typed Epitaphs
狀態	已遭拒
領域	FIDL
說明	表示 Epita 類型的功能與語法。
毛皮變化	486059
作者	pascallouis@google.com
提交日期 (年-月-日)	2019-02-05
審查日期 (年-月-日)	2021-04-07

拒絕原因

這項提案與服務探索互動的方式不佳，因此遭到拒絕。 減少導入作業的複雜度

與服務探索互動

Fuchsia 上的一種常見模式，就是根據名稱來要求特定通訊協定。 呼叫 fuchsia.io/Directory.Open 方法。我們將這項服務稱為探索服務。 在服務探索期間，用戶端會與執行 fuchsia.io/Directory 通訊協定。收到服務探索要求時， 並找到合適的服務 工作階段的伺服器端結尾。也就是說 正與伺服器互動 (支援 fuchsia.io/Directory)，然後 (支援要求的服務)。

遺憾的是，服務探索對口號施加嚴格限制。在 否則用戶端無法判斷 對等點核發了公開註冊編號，是伺服器支援的 fuchsia.io/Directory，或 要求存取的服務？

實際上，服務探索可以包含多個伺服器 相同。因此，八節必須十分籠統，且不得攜帶 網域專屬的詳細資料基本上，當牧者必須滿足 所有可探索通訊協定的最小公分母。

在本提案中，該提案討論並修正了這項限制 並採用所有會參與服務探索的通訊協定來組成 fuchsia/IsDiscoverable 通訊協定。這個通訊協定會定義型別的 Epitaph：

protocol IsDiscoverable {
    epitaph zx.status;
};

fuchsia/IsDiscoverable 的子項都無法定義自訂 Epitaph。 以便正確擷取類型系統中的限制。具體來說 提案中

一個通訊協定只能有一個 Epitaph 類型宣告 (包括任何及所有撰寫的通訊協定，遞迴)。具體來說 避免兩個具有相同語意的 Epitaph 類型宣告 類型。

但是，將所有可探索的通訊協定組合成不可行 這個新的fuchsia/IsDiscoverable。舉例來說 因為設計服務探索是動態的

與要求管道互動

要求管道模式 可視為服務探索模式的通用化 對麻疹也同樣有嚴格限制。

實作複雜度

雖然 FIDL 功能具備複雜性 (語言規則、擴充功能、JSON IR 等)， 例如加入繫結程式碼、產生的程式碼、人體工學等 複雜程度，而且實用性就相當低。取捨 剛好讓我們很開心。

下一步是什麼？

本節代表作者的意見 (pascallouis@google.com)。

加入 Epitaph 時，指定的目標是要「提供」 指出用戶端對伺服器連線關閉的原因。

Epitaph 的確沒有達到這個目標，而且實用性無庸置疑。 那些仰賴 Epitaph 的通訊協定 事件，但不包含上述任何缺點 因為從零層級開始而施加的酬載限制 FIDL 原則

八爪族的好處之一是「徹底終止服務」通訊協定的詞句，其中 伺服器可以保證用戶端對等互連不會與管道解除繫結， 避免發出後續要求。

為加入事件適用的 terminal 修飾符，現已浮點值， 從使用八言詞轉為自訂事件，而且不會失去 「清除終止」資源。設定終端機事件後，圖書館作者 可自由定義事件的酬載為了支援這項功能，我們 會延伸電線格式來分配一個交易型 標頭，指出終止 因此效能相當卓越收到標示為終端機的訊息後，用戶端 除了一般處理作業外，也會終止連線。如果客戶 不知道 事件 (可能在複雜的要求管道情況下)， 用戶端可解讀交易標頭，但酬載 被捨棄。

摘要

我們建議：

1. 新增語法，用於表示通訊協定上的 Epitaph 類型 (我們不會 變更 Epitaph 的預設類型 zx.status)；
2. 一種向繫結公開 Epitaph 類型的方法， 能妥善運用資訊
3. 補充構圖模型，指出口號的類型 是因通訊協定而異，而且由組合負責。

我們預期在「葉子」上輸入 Epitaph 時通訊協定，例如通訊協定 自己定義或組合他人；或一次在「組合樹狀結構」中 放在「頂部」上的 Epitaph 類型或「根」因此效能相當卓越

提振精神

tl;dr (我們喜歡類型)。則代表圖片品質良好我們再選取更多類型

語法和錯誤類型

在 RFC-0053: Epitaphs 中，我們介紹了 Epitaphs 的「a」概念 機制，可讓伺服器在關閉連線前傳送訊息 會說明連線關閉的原因。」八卦 包含錯誤狀態，目前已修正為 int32。時間 審查整組程式碼後，我們選擇將類型修正為 int32，以便疊加 zx.status 必須在使用者偵錯時含有「通訊協定錯誤」在未來的一刻

在 RFC-0060：錯誤處理中，我們導入了專屬語法 類型錯誤，尤其是「錯誤類型必須是 int32、uint32」或 列舉其中一個型別。」我們想讓主角輸入錯誤 挑選與錯誤處理機制相符的表示法

在 RFC-023：通訊協定的組成模型中，我們推出了新的 語法來宣告通訊協定及撰寫通訊協定我們要使用 這裡的縮寫是遵循這樣的

所有先前做出的決定，都符合 主張 (1) 和 (2)。

含 Epitaphs 的組合模型

主張 (3) 有兩個層面 每種通訊協定的縮寫類型不重複性 行為

口號和特殊事件的語意類似 ，每個通訊協定的回應類型都會不重複。

組合下的行為也同樣採用類似的思考方式，證明 八爪族也就是 Compose下文將說明替代定義及其 缺點。

藉由允許 Epitaph 型別快速組曲，我們將 實際例子假設有一個通訊協定 ChildWithEpitaph 編寫一個 通訊協定 FarawayParent 並將其定義為 Epitaph 型別 SomeSpecificErrorCode 列舉。應該 FarawayParent 決定後製 指定 Epitaph 類型，組合就會遭到禁用，且 ChildWithEpitaph 的編譯作業會失敗。

替代方法：Epitaphs 非 Compose

另一種做法是只將已定義的訊息 (方法和 事件) 可組合成其他通訊協定。在這個替代模型中 會定義一個前置詞類型，這種類型與 可能為子項通訊協定的獨立 Epitaph 類型。舉例來說，我們會 可使用下列定義：

protocol Parent {
    epitaph ParentErrorCode;
};

protocol Child {
    compose Parent;
    epitaph ChildErrorCode;
};

由於我們並未在協議與規範之間提供任何關係 (例如無子假設、 沒有變革性的規則) 而言，這種替代模型有一些優點。這提供了 則有更大的自由度。

不過，我們有一切的意圖和目的，都能定義 因此，不妨根據這個選擇 也就是設計目標舉例來說，當我們引進正式子假設時 關係 (「是」) 是否應由通訊協定組成，其中兩者都會定義 如果變更類型不相容，這些通訊協定會立即無法提交 測試：客戶期望某一種類型的 Epaph 工具不需處理 另一種八分音符類型

因此，我們認為最好立即設下限制。 可以使用的 Epitaph 類型 因此最好還是使用額外資訊 明天。

設計

語法

我們可以延長文法，允許在通訊協定中使用 epitaph 字節 宣告：

protocol SomeProtocol {
    ExampleMethod(...) -> (...);

    epitaph SomeErrorCode;
};

主宰節語法與 compose 段落類似， 遵循為錯誤規格選擇的語法

文法經過正式修改，如下所示：

protocol-declaration = ( attribute-list ) , "protocol" , IDENTIFIER ,
                        "{" , ( protocol-member , ";" )*  , "}" ;

protocol-member = ...
                | "epitaph" type-constructor ; [NOTE]

NOTE: The epitaph stanza allows the more liberal type-constructor in the
grammar, but the compiler limits this to int32, uint32, or enum thereof. There
may be only one epitaph stanza per protocol definition.

ABI 與來源相容性

我們推出 Epitaph 時，已將類型修正為 int32 我們會限制在 32 位元內。修正錯誤代碼為 32 位元後來引入錯誤語法。

我們在這裡維持選擇，因為如先前所述，不會限制在任職期間 設為 int32、uint32 或列舉的列舉

因此，變更 Epitaph 類型 (可能是從預設值變更為 則不會修改 ABI 相容性。

但是，變更 Epitaph 類型很有可能是來源層級的破壞 變更。繫結作者可能會破壞原始碼相容性。我們 是弱勢族群如今沒那麼廣泛使用

JSON IR

我們會將加入類型definition/interface definitions/type。

例如，我們可能會有：

    {
      "name": "example/SomeProtocol",
      "epitaph": {
          "kind": "primitive",
          "subtype": "uint32"
      },
      "methods": [
        {
          "ordinal": 296942602,

epitaph 類型一律顯示在介面宣告中，並設為 預設值為 zx.status。

寫作 Epitaphs

當將通訊協定組合到另一個通訊協定時，八位元的類型會沿用出來。 例如，具有以下通訊協定：

protocol Parent {
    epitaph SomeErrorCode;
};

protocol Child {
    compose Parent;
};

結果 Parent 和 Child 產生的 Epitaph 類型為 SomeErrorCode。

一個通訊協定 (包括 以遞迴方式處理任何及所有撰寫的通訊協定)。我們特別阻止了 語意相同且具有相同類型的 Epitaph 類型宣告。

這個範例無效，應該無法編譯：

protocol Parent1 {
    epitaph SomeErrorCode1;
};

protocol Parent2 {
    epitaph SomeErrorCode2;
};

protocol Child {
    compose Parent1;
    compose Parent2;
};

這個範例也無效，應該無法編譯：

protocol Parent {
    epitaph SomeErrorCode;
};

protocol Child {
    compose Parent;
    epitaph SomeErrorCode;
};

執行策略

(將由 FIDL 團隊所張貼的評論決定。這項變更不具類似 )。

人體工學

無

說明文件和範例

須符合以下條件：

• Wire 格式規格應指出 Epita 為 int32/uint32，必須使用適當的類型解讀。
• 如需詳細說明，請參閱開發人員專用指南。 陳述式，例如："ZX_OK (或相關的成功代碼)"拓展建議 開發人員指定類型。

回溯相容性

FIDL 來源：我們會持續擴充相容於 文法FIDL 檔案中都不會包含「epitaph type-structor」Stanza 。

JSON IR：回溯相容於允許額外鍵的非嚴格剖析器 因為我們加入了「epitaph」。

成效

不會影響效能。

安全性

沒有影響，或有額外類型安全時有輕微正面影響。

測試

fidlc 中的單元測試，以及繫結產生測試。

缺點、替代方案與不明

無

既有作品和參考資料

(如內文所述)。