- Start Date: 2015-02-19
- RFC PR: rust-lang/rfcs#735
- Rust Issue: rust-lang/rust#22563
Summary
Allow
Motivation
The main motivation for disallowingimpl
bodies was the implementationType::method
, which only worked correctly for impl Type {...}
if a struct Type
or enum Type
were definedType::method
to <Type>::method
and performs a type-based method lookup instead, with path resolution having no knowledge of inherent impl
s - and all of that was implemented
Aside from invalidating the previousimpl
s: it leads to non-DRY singleAstBuilder
in libsyntax, with almost 300 lines of redundant method definitions.
Detailed design設計(する)
Remove the existing limitation, and only require that the Self
type of the impl
is defined
Drawbacks
Consistency and ease of finding method definitionsimpl
s already have that problem and single
Alternatives代わりのもの、選択肢
-
Leave it as it is. Seems unsatisfactory given
与えられたthat we're no longer limited by implementation実装details. -
We could go further
さらなる、それ以上and allow許可する、可能にするaddingたすinherent methods to any type that could implement実装するa trait outside the crate:The implementation
実装would reuse the same coherence rules as for traitimpl
s, and, for looking up methods, the "type definition定義to impl" map would be replaced with a map from method name to a setセットする、集合ofimpl
s containing含むthat method.Technically, I am not aware of any formulation that limits inherent methods to user-defined types in the same crate, and this extra support could turn out to have a straight-forward implementation
実装with no complications, but I'm trying to presentあるthe whole situation to avoid避ける、回避するissues in the future - even though I'm not aware of backwards compatibility互換性ones or any related to compiler internals.
Unresolved questions
None.