Tracking Issue for refined trait implementations

[tmandry]

This is a tracking issue for the RFC "Refined trait implementations" (rust-lang/rfcs#3245). The feature gate for the issue is #![feature(refine)].

About tracking issues

Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• [ ] Implement the RFC (cc @rust-lang/compiler -- can anyone write up mentoring instructions?)
• [ ] Adjust documentation (see instructions on rustc-dev-guide)
• [ ] Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• [ ] Should #[refine] be required in future editions? Options:
  • Required
  • Recommended (by a lint that can be disabled on refined impls without a #[refine])
  • Not recommended (refined APIs are available without the attribute)

See the RFC for more information.

Implementation history

[dhardy]

I didn't see discussion related to applying #[refine] to associated types (which should arguably be a different topic), so I created one here: https://internals.rust-lang.org/t/refine-applied-to-associated-types/19789

One note worth taking away: it may sometimes be desirable to use #[refine] on the trait, not the impl.

[clarfonthey]

Another interesting case for #[refine] that should definitely be excluded from the initial definition, but is worth considering: refining &mut self to &self. This would help, for example, implementing Extend for concurrency-safe collections without requiring unique borrows.