我们可以像克隆人一样重新将Rust语义移动语义吗？
我们可以在Rust中使用移动语义修补。
也许重新进来移动行为就像克隆一样？
或至少将前移动挂钩附加到执行自定义逻辑？
与官方生锈文档的链接将不胜感激。
从内部语言重新设计提案线程 通过明确指定的重新搬迁语义 看来它不存在。
但是我想确保无法实现它。
Can we tinker with move semantics in rust.
Maybe reimplement Move behavior just like Clone?
Or at least attach pre or post move hook to execute custom logic?
links to official rust docs would be appreciated.
From the internal language redesign proposal thread
Idea: Limited custom move semantics through explicitly specified relocations
it seems it's not present.
but I want make sure there no way of achieving it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不仅没有这种方式，，而不仅仅是一件好事（（ IMO），现在基本上是不可能的，所有试图选择的建议是选择加入而不是选择退出（也就是说，您的通用类型应在非局限移动，否则它基本上不支持它们。这意味着很多事情不会支持它们，至少在生态系统中，如果不在生态系统中。
这是一个非常简单的原因：不安全代码的 依靠移动是位。如果移动可以执行用户代码，那也意味着它可能会恐慌，现在不安全的代码必须对此进行防御。否则，即使不是以前，他们也可以将物体留在无效状态。基本上，他们可以做任何事情，这一切都可能意味着不安全的代码。不安全代码中可能的一切都意味着不确定的行为。因此，没有现有的不安全代码能够使用此动作，这意味着根本没有代码，每种类型都必须声明它是否支持它们。
更不用说优化的好处，或者更容易推理位于位移动。
我认为我没有这样做的RFC，尽管我可能不知道（
move有一个RFC，但它被PIN> PIN取代） 。如果您需要一种自定义移动的方法，则不需要移动。使用
克隆或其他一些特征。Not just there is no such way, and not just this is a good thing (IMO), changing that is basically impossible now, and all proposal that attempted to do that were opt-in rather than opt-out (that is, your generic type should declare support in non-bitwise moves, or it will not support them. Basically some kind of opt-out trait
?Move). That means that a lot of things won't support them, at least in the ecosystem if not in std too.This is for a very simple reason: lots of unsafe code relies on moves to be bitwise. If a move can execute user code, that also means it can panic, and now unsafe code has to defend against that. Or they can leave the object in invalid state even if it wasn't before. Basically, they can do anything, and this anything can mean anything to unsafe code. And anything possible in unsafe code means undefined behavior. So no existing unsafe code will be able to live with this moves, which means that no code at all will be able to and each type will have to declare if it supports them.
Not to mention the optimization benefits or that it's much easier to reason about bitwise move.
I don't think there was ever a RFC to do that, although I may not be aware (there was a RFC for
?Move, but it was replaced byPin).If you need a way to customize moves, you don't want moves. Use
Cloneor some other trait.