何时在 Rust 中使用 as* vs to* vs into _*？答案

【问题标题】：When to use as_* vs to_* vs into_* in Rust?何时在 Rust 中使用 as* vs to* vs into _*？
【发布时间】：2022-09-27 10:25:44
【问题描述】：

根据标准库示例，我的理解是：

当函数完全吸收所有权并吐出另一种类型时，使用into_ 约定，如into_iter()。理解是否正确？

真正的混淆在 as_ 和 to_ 之间。
似乎 to_ 在 to_owned() 中采用类型的引用并吐出新的相关类型（如类型强制），而 to_string() 采用类型的引用并吐出新类型（如在类型转换中） .

但是as_ 和as_ptr 一样，看起来也像是类型强制。除了as_ptr 或as_mut，我找不到任何示例。

有人可以准确地解释我们需要使用特定命名约定的情况以及超出标准库中使用的真实示例吗？

Rust API Guidelines - Naming
to_owned 和 to_string 不是类型强制。它们通常等于clone，并将深度复制有问题的对象，或者以其他方式分配内存。
@PitaJ 我同意，但 to_ 在 to_owned 的情况下听起来像是类型强制，实际上不是。这就是混乱所在。 API 指南表有很大帮助
谢谢@kmdreko。这个链接应该是文档的一部分。非常有帮助

标签： rust naming-conventions

【解决方案1】：

Rust API 指南中有一个Naming 部分，其中包括“转换”方法的建议并显示了一个方便的表格：

Prefix | Cost      | Ownership
=======+===========+====================================
as_    | free      | borrowed -> borrowed
-------+-----------+------------------------------------
       |           | borrowed -> borrowed
to_    | expensive | borrowed -> owned (non-Copy types)
       |           | owned -> owned (Copy types)
-------+-----------+------------------------------------
into   | variable  | owned -> owned (non-Copy types)

指南继续以str::as_bytes()、str::to_lowercase()、String::into_bytes() 等示例以及抽象和可变性的一些其他考虑。

一种更快的思考方式：

如果它消耗数据，使用into_*
如果它返回数据的另一个“视图”，使用as_*
否则使用to_*

与往常一样，这些更多指导方针比实际规则。约定是有帮助的，但不需要严格遵守。

【讨论】：