| 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 数组的一过段，这很可能是合法的，在任何情况下都太微妙。我们修复了由于这些规则的细微差别而导致在实现和客户端中出现的一些 bug。
通过使用指向标准容器的指针，C++ 表示法在与标准矢量和字符串接口匹配方面也效率低下。同样，Rust 必须将容器封装在 Option 中。
设计
此方案通过移除可选矢量和可选字符串结构来修改 FIDL 语言。
它无需为这些构造提供表示法，因此会影响每个绑定的实现。
实施策略
- 在 FIDL 语言中废弃了这些结构。
理想情况下，我们可以从
fidlc发出废弃警告。 - 将
vector?和string?的所有用例迁移到其他表示法。在某些情况下，相关接口实际上并未使用可选性。在其他情况下，我们可以手动描述可选性。 - 从 FIDL 以及示例和文档中移除了
vector?和string?。 - 对于每种目标语言：采用此方案现在允许的更好的字符串或矢量实现。例如，FIDL 向量可以只是 C++ 中的
std::vector。
文档和示例
这些结构偶尔会在 go/fidl-tut 等对象中被引用，但绝不会以重要方式引用。我们应将其全部更新为非可选版本。
向后兼容性
这样就不允许在语言中使用单个构造。旧编译器能够编译未来的代码。
开销很小，因为我们尚不能达到对源代码/编译器的广泛兼容性。
性能
我预计效果基本上不会有变化。
安全性
我相信此功能不会对安全性造成任何影响。
测试
我预计会一次进行 1 个 CQ 的测试，因为我们会分别应用这些结构。
我认为不需要为 fidl 流水线编写任何新测试。只需进行所有修改以移除所有可选字符串或矢量即可。
缺点、替代方案和未知情况
我认为我们不应对生成的代码显示废弃警告。最终会有大量对此类引用的引用，因而很难倒推到警告的真正来源。
有一些真实情况需要区分非向量和空向量。不过，对于 uint32，情况也是如此，我认为我们应该在此提案之后及表后重新考虑总体的可选性。
早期技术和参考资料
虽然其他 RPC 或 IPC 系统肯定会面临这种问题，但我没有关注其中任何一个。我认为在这种情况下，与其他系统的兼容性、性能需求、目标语言支持等方面的设计压力大相径庭，因此我们不太可能仅通过查看其他系统是否支持可选字符串就可以得出有用的结论。