Stabilize concrete type specialization
| Metadata | |
|---|---|
| Point of contact | Tyler Mandry |
| Status | Proposed |
| Needs | Funding |
| Tracking issue | |
| Zulip channel | N/A |
| Help wanted | N/A |
| Other tracking issues | rust-lang/rust#31844 |
| lang champion | Tyler Mandry |
| types champion | Jack Huey |
| Teams | lang, libs, opsem, types |
| Task owners | Jack Huey |
Summary
Follow stabilization of the new trait solver this year by stabilizing a subset of specializing impls: Impls that follow the always applicable rule. This roughly corresponds to specializing trait impls on concrete types.
Motivation
The status quo
Specialization, the ability to branch (potentially through an impl) on type properties known at monomorphization time, is a long-sought feature in Rust. An initial RFC and implementation was made that broadly allows overlapping impls as long as one impl is an unambiguous “winner”. However, there are soundness issues with this design.
A subset of specialization, coined the “always applicable” subset, is restricted to implementations that hold regardless of lifetime substitution, roughly corresponding to specializing on concrete types. A feature gate, min_specialization, was split out that roughly approximates this subset. The feature was designed for use within the standard library, but was not intended as a stable user-facing feature. There are at the very least implementation bugs, but it is not clear if this subset of specialization is truly sound, or whether or not it can cover all the uses cases people need, both inside the standard library and in user crates.
The next-generation trait solver, set to stabilize, resolves some bugs in the current implementation, though the work remaining is primarily one of design. Additionally, there have been alternative features proposed (try_as_dyn and capability-safe specialization) that function differently than “always applicable” specialization and cover different – largely overlapping – use cases.
What we propose to do about it
Given that specialization is largely blocked on design work to address known soundness issues, the bulk of the work within this project goal will be to identify and collect the constraints for a possible stabilizable design (through a survey of existing and expected use cases), document these constraints and propose some design to move towards stabilization (which may only cover some subset of uses), model a stabilizable design, and implement that design within the compiler (possibly adapting existing implementation work).
Work items over the next year
| Task | Owner(s) | Notes |
|---|---|---|
| Survey use cases | Jack Huey | |
| Triage open issues | Jack Huey | |
| Prepare design document | Jack Huey | |
| Model in a-mir-formality | Jack Huey | |
| Implement and iterate design | Jack Huey |
Team asks
| Team | Support level | Notes |
|---|---|---|
| lang | Medium | Review design document |
| types | Large | Review design document |
| libs | Small | |
| opsem | Small |