| RFC-0065：没有可选字符串或向量 | |
|---|---|
| 状态 | 已拒绝 |
| 区域 |
|
| 说明 | 从 FIDL 语言中移除可选字符串和可选向量。 |
| 作者 | |
| 提交日期（年-月-日） | 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>，因此它们的网络格式非常相似，适用于
其中一种格式的内容通常也适用于另一种格式。
在多种目标语言中，可为 null 的向量和字符串难以表示且不符合人体工程学，并且使用不广泛。 虽然有些用例需要区分“不是字符串”和空字符串，但我认为这些用例的数量很少，值得强制这些位置明确表示这种情况。 我怀疑，如果我们实现表，情况会更加如此，因为表可能会涵盖非现有字符串或向量的多个用例。
例如，在 C 和 C++ 中，null vector<T> 表示为零
长度和 null 指针，而空 vector 表示为零
长度和非 null 指针。
根据语言规则，此非 null 指针必须是有效的 T 指针，即使它不能被取消引用也是如此。
我们目前通过以下方式构造此指针：假装下一个辅助对象存储位是 T 数组的末尾，这充其量是可疑的合法，并且在任何情况下都过于微妙。我们修复了实现和客户端中的多个错误，这些错误是由这些规则的微妙性造成的。
C++ 表示法在匹配标准向量和字符串接口的目标方面效率低下，因为它使用指向标准容器的指针。
Rust 同样必须将容器封装在 Option
中。
设计
此提案通过移除可选向量和可选字符串构造来修改 FIDL 语言。
它会影响每个绑定的实现，因为无需为这些构造提供表示法。
实现策略
- 在 FIDL 语言中弃用这些构造。
理想情况下，我们可以从
fidlc发出弃用警告。 - 将
vector?和string?的所有用法迁移到其他表示法。 在某些情况下，相关接口实际上并不使用可选性。 在其他情况下，我们可以手动描述可选性。 - 从 FIDL 以及示例和文档中移除
vector?和string?。 - 对于每种目标语言：采用此提案现在允许的更好的字符串或向量实现。
例如，FIDL 向量在 C++ 中可以只是
std::vector。
文档和示例
这些构造偶尔会在 go/fidl-tut 等内容中被引用，但绝不是以必要的方式引用。
我们应该将它们全部更新为非可选版本。
向后兼容性
这不允许使用该语言中的单个构造。 旧编译器将能够编译未来的代码。
由于我们尚未处于需要广泛的源代码/编译器兼容性窗口的状态，因此成本很小。
性能
我预计性能基本上不会发生变化。
安全
我认为此功能不会对安全性产生任何影响。
测试
我预计，当我们提取这些构造的各个用法时，测试将一次进行 1 个 CQ。
我认为无需为 fidl 管道编写任何新测试。只需要进行修改以移除所有可选字符串或向量。
缺点、替代方案和未知因素
我认为我们不应在生成的代码中放置弃用警告。 最终会有更多对这些代码的引用，并且回溯到警告的真实来源非常麻烦。
有些真实用例需要区分“不是向量”和空向量。不过，uint32 也是如此，我认为我们应该在此提案和表之后重新考虑可选性。
在先技术和参考文档
虽然其他 RPC 或 IPC 系统肯定会面临此类问题，但我没有查看任何此类系统。 我认为，在这种情况下，设计压力在与其他系统的兼容性、性能需求、目标语言支持等方面差异很大，因此我们不太可能仅通过查看另一个系统是否支持可选字符串来得出有用的结论。