可以裁定“只有在当前板条箱中定义的特征可以针对任意类型实施”扩展到工作区?
在同一工作空间中定义的板条
MyWorkSpace-|
|-MyCrateA--> pub MyTrait {}
|
|-MyCrateB--> pub MyStruct;
|
|-MyCrateC--> impl MyTrait for MyStruct {}
特征可以针对任意类型实现”
我测试了规则“在当前板条箱中仅定义的 该规则避免了有关依赖关系的碰撞。
但是,在工作空间的情况下,所有者可以控制其中的板条箱。那么,为什么不可能拥有一个规则“仅在当前工作空间中定义的特征才能针对任意类型实现” ?
I tested rule "only traits defined in the current crate can be implemented for arbitrary types" in the case of crates defined in a same workspace:
MyWorkSpace-|
|-MyCrateA--> pub MyTrait {}
|
|-MyCrateB--> pub MyStruct;
|
|-MyCrateC--> impl MyTrait for MyStruct {}
And as expected, it did not work...
I understood that this rule avoids collisions between impls regarding the dependencies.
However, in the case of a workspace, the owner has control over the crates within it. So why is it not possible to have a rule "only traits defined in the current workspace can be implemented for arbitrary types"?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
工作区是一个货物概念。 Rustc对他们一无所知。
同样,对此功能的需求非常低。如果板条箱仅出于性能原因而分开,则可以随时在需要时统一它们。如果由于API的疑虑而分开,那么孤儿规则可能仍然存在。
我认为是否曾经建议使用此功能(您可以尝试,尽管我怀疑它会被接受),但是它没有接受/实施。
板条箱应该是API边界。如果您需要在工作区内打破孤儿规则,则可能会滥用工作空间。
Workspaces are a Cargo concept. rustc knows nothing about them.
Also, the demand for this feature is very low. If the crates are only separate for performance reasons, you can always unify them if required. If they're separate because of API concerns, then the orphan rules should probably still hold.
I don't think this whether this feature was ever suggested (you can try, although I doubt it'll be accepted), but it wasn't accepted/implemented.
Crates should be an API boundary. If you need to break the orphan rules inside a workspace, you're probably misusing workspaces.