(選填) 您的 Witty 職稱
| 欄位 | 值 |
|---|---|
| 狀態 | 草稿 |
| 作者 | 你的電子郵件 |
| 已提交 | 提交前請留空 |
| 已批閱 | 審查前請留空 |
摘要
一段文字，說明提案的其他部分。
提振精神
這個提案能解決什麼問題？
設計
這是技術層面的詳細提案。
提案的其中一項重要重點，就是要修改 FIDL 的部分。這至少包括：
- FIDL 來源語言
- FIDL 線格式
- 一流的語言繫結 (C、C++、Dart、Go、Rust)
- FIDL 風格指南和 API 評分量表
- FIDL 調整程序
您的提案必須討論所有相關層面。舉例來說，如果您的提案將新類型新增至 FIDL 語言，也必須討論該功能的樣式指南，以及如何在繫結中實作。
本文件中的下列關鍵字：「必須」、「不得」、「必要」、「應」、「不應」、「應該」、「不應該」、「建議」、「可能」和「選用」等關鍵字，以 RFC 2119 中所述的方式解釋。
執行策略
您要如何進行這項變更？部分 FTP 不會涉及破壞性變更，且可能會發生為單一 CL。有些則可能是清除變更。無論選擇哪一種，請思考如何將實作細分為任務。
如果是可能會變更的複雜實作作業，建議您撰寫「意圖至實作」(I2I) 文件，並在本節中建立文件的連結。之後 I2I 可以作為獨立的設計文件，可能會單獨更新，因此這份文件不會隨著細節變更而不斷重新編輯。這也可讓 FTP 專注於高階重要概念，而非實作和執行。
人體工學
您的變更會讓 FIDL 更容易使用及理解嗎？這可以讓繫結更容易使用嗎？如果不是的話，複雜度為何？
請著重在使用者 API 以及瞭解概念所需的認知參與程度。
說明文件與範例
可能有數種文件需要處理。
您會在各種 FIDL 教學課程的風格中，如何編寫或變更此功能的教學課程？想像一下 向 Fuchsia 新手介紹你的功能
如何撰寫參考說明文件？舉例來說，假設您的提案擴充了 FIDL 線路格式。如何更新傳輸格式的說明文件？請設想一下，向使用者詳細介紹您的功能，讓他們可以實作。
你提議的功能有哪些重要範例或用途？
回溯相容性
回溯相容性有兩種：FIDL 檔案來源相容性，以及 ABI 或傳輸格式相容性。這個部分應會說明兩者內容。長期下來，能夠進行回溯不相容的變更將變得更加困難。
如果您即將推出新的資料類型或語言功能，請先考量會預期使用者需要進行哪些 FIDL 定義變更，而不會破壞產生的程式碼。如果功能對產生的語言繫結套用任何新的來源相容性限制，請在這裡列出。
效能
這項提案會對 IPC 成效造成什麼影響？提升建構效能？
安全性
您的功能對安全性有何影響？是否能在不會安全地使用記憶體的語言中安全地使用功能？您的功能是否容易不小心洩露程序位址空間的詳細資料？
測試
功能的測試方式為何？例如，是否需要針對 fidlc 或 C++ 繫結撰寫新的測試？
如果您的變更會影響編碼或解碼，請規劃更新一致性測試套件。
如何測試新功能的使用情形？如果您新增語言功能，如何針對每種語言的繫結進行測試？
缺點、替代與不明
採行此提案需要多少費用？
還有哪些策略或許能解決相同的問題？
還有哪些問題需要解決，或需反覆解決，才能接受此提案？隨著提案內容不斷推陳出新，您的答案可能會更臻完善。
既有藝術與參考資料
閱讀這份提案時，是否有任何可能有幫助的背景素材？舉例來說，要確保其他序列化作業或處理序間通訊 (IPC) 系統解決這個提案可以解決的問題嗎？