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 或處理序間通訊系統確實面臨了這類問題，但我完全沒有關注。我相信在這個情況下，設計壓力會在與其他系統的相容性、效能需求、目標語言支援等方面產生極大差異。因此，在觀察其他系統是否支援選用字串時，我們不太可能得到實用的結論。