RFC-0065：不使用選用字串或向量
狀態	已遭拒
區域	FIDL
說明	從 FIDL 語言中移除選用字串和選用向量。
作者	kulakowski@google.com
提交日期 (年-月-日)	2018-09-27
審查日期 (年-月-日)	2018-10-25

拒絕理由

• FTP-016 已遭拒，也就是說，我們目前會保留選用字串和向量：
  • 我們希望能更全面地重新審視選用性，而不是做出點對點的決定。
  • 自從我們開始思考這項功能的實用性後，這項功能的使用率便持續上升，因此我們應該更能掌握現有模式，以及我們想鼓勵 (或不鼓勵) 的模式。
• 在繫結層級：
  • 不要為非選填項目使用選填容器。我們應讓非選用項目比選用項目更容易處理，也就是說，如果某個網域適合使用選用項目，您應明確尋求選用項目。
  • 關於 C++ 人體工學：
    • StringPtr -> std::string 或 fit::optional<std::string>
    • VectorPtr -> std::vector<T> 或 fit::optional<std::vector<T>>

摘要

從 FIDL 語言中移除選用字串和選用向量。

提振精神

注意：在本文件中，我會提到「空字串」或「空向量」。由於網路上的字串基本上是必須為有效 UTF-8 的 vector<uint8>，因此這些字串的網路格式非常相似，且適用於其中一個的內容通常也適用於另一個。

可為空的向量和字串在多種目標語言中難以表示，且不易使用，因此並未廣泛使用。雖然有些用途需要區分非字串和空字串，但我認為這類用途很少，因此不必強制要求這些地方明確呈現該狀態。我認為，如果我們實作表格，這一點就更為明顯，因為表格可能涵蓋不存在字串或向量的多種用途。

舉例來說，在 C 和 C++ 中，空值 vector<T> 會以零長度和空值指標表示，而空白 vector 則會以零長度和非空值指標表示。根據語言規則，這個非空值指標必須是有效的 T 指標，即使它無法解參照也一樣。我們目前會以以下方式建構這個指標，假設次要物件儲存空間的下一個位元是 T 陣列的一個結尾，這種做法充其量合法，但在任何情況下都太過微妙。我們已修正實作和用戶端中因這些規則的微妙之處而產生的幾個錯誤。

在 C++ 表示法中，使用標準容器的指標來比對標準向量和字串介面，這麼做效率不彰。Rust 也必須將容器包裝在 Option 中。

設計

這項提案會移除選用向量和選用字串結構體，藉此修改 FIDL 語言。

這會影響每個繫結的實作方式，因為您不必為這些結構提供表示法。

導入策略

1. 在 FIDL 語言中淘汰這些結構。理想情況下，我們可以從 fidlc 發出淘汰警告。
2. 將 vector? 和 string? 的所有用途遷移至其他表示法。在某些情況下，相關介面實際上並未使用選用性。在其他情況下，我們可以手動說明選用性。
3. 從 FIDL、範例和說明文件中移除 vector? 和 string?。
4. 針對每種目標語言：採用此提案現在允許的更佳字串或向量實作方式。舉例來說，FIDL 向量可以是 C++ 中的 std::vector。

說明文件和範例

這些結構體偶爾會在 go/fidl-tut 等項目中參照，但絕不會以必要的方式參照。我們應該將所有這些項目更新為非選用版本。

回溯相容性

這會禁止語言中單一結構體。舊版編譯器可編譯未來的程式碼。

成本不高，因為我們尚未處於預期來源/編譯器相容性廣泛的狀態。

成效

我預期成效不會有任何變化。

安全性

我認為這項功能不會影響安全性。

測試

我預期測試會一次處理 1 個 CQ，因為我們會提取這些結構體的個別用途。

我認為不需要為 fidl 管道編寫任何新測試。您只需要修改內容，移除所有選用字串或向量。

缺點、替代方案和未知事項

我認為我們不應在產生的程式碼中放置淘汰警告。最終會產生更多參照，因此要反向追蹤警告的真正來源就會變得相當繁重。

有些情況確實需要區分非向量和空向量。不過，這也適用於 uint32，我認為我們應該在這個提案和表格之後，重新考慮選用性。

既有技術與參考資料

雖然其他 RPC 或 IPC 系統肯定會面臨這類問題，但我並未查看任何系統。我認為在這種情況下，設計壓力會因與其他系統的相容性、效能需求、目標語言支援等因素而大幅變化，因此我們不太可能只從其他系統是否支援選用字串，就得出有用的結論。