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 語言中移除選用字串和選用向量。

提振精神

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

在多種目標語言中，可為空值的向量和字串難以表示，且不符合人體工學，因此不廣泛使用。雖然有些用途需要區分非字串和空字串，但我認為這類用途很少，因此值得強制這些位置明確表示這種情況。如果我們實作表格，可能涵蓋多個非現有字串或向量的用途，這點應該更是如此。

舉例來說，在 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 系統肯定也會面臨這類問題，但我並未查看任何相關內容。我相信在這種情況下，設計壓力在與其他系統的相容性、效能需求、目標語言支援等方面的差異極大，因此我們不太可能僅從另一個系統是否支援選用字串，就得出有用的結論。