Tracking issue for specialization (RFC 1210)

[nikomatsakis]

View all comments

This is a tracking issue for specialization (rust-lang/rfcs#1210).

Major implementation steps:

• Land Implement RFC 1210: impl specialization #30652 =)
• Restrictions around lifetime dispatch (currently a soundness hole)
• default impl (support default impl for specialization #37653)
• Integration with associated consts
• Bounds not always properly enforced (Trait bounds not checked on specializable associated types #33017)
• Should we permit empty impls if parent has no default members? 🛠️ specialization permits empty impls when parent has no default items #48444
• implement "always applicable" impls 🔬 implement "always applicable impls" #48538
• describe and test the precise cycle conditions around creating the specialization graph (see e.g. this comment, which noted that we have some very careful logic here today)

Unresolved questions from the RFC:

• Should associated type be specializable at all?
• When should projection reveal a default type? Never during typeck? Or when monomorphic?
• Should default trait items be considered default (i.e. specializable)?
• Should we have default impl (where all items are default) or partial impl (where default is opt-in); see support default impl for specialization #37653 (comment) for some relevant examples of where default impl is limiting.
• How should we deal with lifetime dispatchability?

Note that the specialization feature as implemented currently is unsound, which means that it can cause Undefined Behavior without unsafe code. min_specialization avoids most of the pitfalls.

---

Tracking issues have a tendency to become unmanageable. Please open a dedicated new issue and label it with F-specialization for absolutely any topics you want to discuss or have questions about. See rust-lang/compiler-team#739 for details and discussions on this prospective policy.

[aturon]

Some additional open questions:

• Should we revisit the orphan rules in the light of specialization? Are there ways to make things more flexible now?
• Should we extend the "chain rule" in the RFC to something more expressive, like the so-called "lattice rule"?
• Related to both of the above, how does negative reasoning fit into the story? Can we recover the negative reasoning we need by a clever enough use of specialization/orphan rules, or should we make it more first-class?

[arielb1]

I am not sure that specialization changes the orphan rules:

• The "linking" orphan rules must stay the same, because otherwise you would not have safe linking.
• I don't think the "future compatibility" orphan rules should change. Adding a non-specializable impl under you would still be a breaking change.

Worse than that, the "future compatibility" orphan rules keep cross-crate specialization under pretty heavy control. Without them, default-impls leaving their methods open becomes much worse.

I never liked explicit negative reasoning. I think the total negative reasoning specialization provides is a nice compromise.

[sgrif]

Should this impl be allowed with specialization as implemented? Or am I missing something?
http://is.gd/3Ul0pe

[sgrif]

Same with this one, would have expected it to compile: http://is.gd/RyFIEl

[sgrif]

Looks like there's some quirks in determining overlap when associated types are involved. This compiles: http://is.gd/JBPzIX, while this effectively identical code doesn't: http://is.gd/0ksLPX

[SergioBenitez]

Here's a piece of code I expected to compile with specialization:

http://is.gd/3BNbfK

#![feature(specialization)]

use std::str::FromStr;

struct Error;

trait Simple<'a> {
    fn do_something(s: &'a str) -> Result<Self, Error>;
}

impl<'a> Simple<'a> for &'a str {
     fn do_something(s: &'a str) -> Result<Self, Error> {
        Ok(s)
    }
}

impl<'a, T: FromStr> Simple<'a> for T {
    fn do_something(s: &'a str) -> Result<Self, Error> {
        T::from_str(s).map_err(|_| Error)
    }
}

fn main() {
    // Do nothing. Just type check.
}

Compilation fails with the compiler citing implementation conflicts. Note that &str doesn't implement FromStr, so there shouldn't be a conflict.

[aturon]

@sgrif

I had time to look at the first two examples. Here are my notes.

Example 1

First case, you have:

• FromSqlRow<ST, DB> for T where T: FromSql<ST, DB>
• FromSqlRow<(ST, SU), DB> for (T, U) where T: FromSqlRow<ST, DB>, U: FromSqlRow<SU, DB>,

The problem is that these impls overlap but neither is more specific than the other:

• You can potentially have a T: FromSql<ST, DB> where T is not a pair (so it matches the first impl but not the second).
• You can potentially have a (T, U) where:
  • T: FromSqlRow<ST, DB>,
  • U: FromSqlRow<SU, DB>, but not
  • (T, U): FromSql<(ST, SU), DB>
  • (so the second impl matches, but not the first)
• The two impls overlap because you can have a (T, U) such that:
  • T: FromSqlRow<ST, DB>
  • U: FromSqlRow<SU, DB>
  • (T, U): FromSql<(ST, SU), DB>

This is the kind of situation that lattice impls would allow -- you'd have to write a third impl for the overlapping case, and say what it should do. Alternatively, negative trait impls might give you a way to rule out overlap or otherwise tweak which matches are possible.

Example 2

You have:

• Queryable<ST, DB> for T where T: FromSqlRow<ST, DB>
• Queryable<Nullable<ST>, DB> for Option<T> where T: Queryable<ST, DB>

These overlap because you can have Option<T> where:

• T: Queryable<ST, DB>
• Option<T>: FromSqlRow<Nullable<ST>, DB>

But neither impl is more specific:

• You can have a T such that T: FromSqlRow<ST, DB> but T is not an Option<U> (matches first impl but not second)
• You can have an Option<T> such that T: Queryable<ST, DB> but not Option<T>: FromSqlRow<Nullable<ST>, DB>