Implement revised coercion rules

[aturon]

Tracking issue for RFC 401.

[aturon]

Nominating: this contains backwards-incompatible changes.

For triage purposes, we probably want to pull out the DST coercions part of this as P-High.

[nrc]

Summary of changes to make from the RFC:

• Add cast from unsized slices to raw pointers (&[V] to *V);
• allow coercions as casts and add lint for trivial casts - #18601;
• ensure we support all coercion sites;
• * remove [T, .. n] to &[T]/*[T] coercions - #18645;
• add raw pointer coercions - #19766;
• add sub-trait coercions - #5665;
• add unsized tuple coercions - #42877;
• add all transitive coercions - #18602;
• receiver coercions - add referencing to raw pointers;
• * receiver coercions - remove double referencing for slices - #19761;
• * remove function coercions, add function type polymorphism - #18599;
• add DST/custom coercions - #18598.

We should double check that these changes actually get us to the right destination as defined by the RFC.

I filed bugs for the larger pieces of work, the rest are pretty minor and can be tracked here. Those marked with an asterisk are backwards incompatible.

[nrc]

Assigning myself for misc back-compat parts of this, I don't intend to do the rest right now.

[pnkfelix]

Assigning P-backcompat-lang, 1.0.

[aturon]

@nick29581 Are the back-compat parts done? If so, let's re-nominate.

[nrc]

Yep, should no longer block

[pnkfelix]

No more back incompat stuff; just usability issues. P-high.

[arielb1]

@nrc

You can involve type inference quite deeply here:

fn unify<T>(a: T, _: T) -> T { a }
trait Confusing { fn get() -> Self; }
impl Confusing for Box<[u32]> { fn get() -> Box<[u32]> { Box::new([0]) } }
impl Confusing for Box<[u32; 3]> { fn get() -> Box<[u32; 3]> { Box::new([7,8,9]) } }

#[cfg(not(type_error))]
fn f(x: bool) -> u32 {
    let a = Confusing::get();
    let v: Box<[u32]> = Box::new([1,2,3]);
    let s = match x {
        true => unify(a, v),
        false => unify(a, Box::new([1,2,3])),
    };
    s[0]
}

#[cfg(type_error)]
fn f(x: bool) -> u32 {
    let a = Confusing::get();
    let v: Box<[u32]> = Box::new([1,2,3]);
    let s = match x {
        false => unify(a, Box::new([1,2,3])),
        true => unify(a, v), //~ ERROR mismatched types
                             //| expected `Box<[u32; 3]>`
                             //|    found `Box<[u32]>`
    };
    s[0]
}

fn main() { println!("{}", f(false)); }

But I guess we have to do something like this.

[brson]

Triage: ancient RFC tracking bug slipping through the cracks cc @rust-lang/lang what's up?

[nrc]

Discussed at the lang meeting. I will go through the checklist to make sure it is up to date. We think it should remain p-medium since periodic check ins will be worthwhile.

[qnighy]

Looking through rust-lang/rfcs#401, #37685, #32702, #34451, and this, it seems that tuple DSTs and their coercion should be allowed but the coercion is not implemented. Am I right?

[nikomatsakis]

@qnighy I think that is correct. I'm not sure just how much implementation work would be needed, there may be random bits of the compiler that need to be updated scattered around.

[qnighy]

@nikomatsakis Thank you. I'm working on it.

[qnighy]

Another question: PartialEq, Eq, PartialOrd, Ord, Debug, Hash can be generalized to unsized tuples. Are there any RFCs referring to this possibility?

[nikomatsakis]

@qnighy not that I'm aware of; I don't think we necessarily need an RFC for such a thing though

[torkleyy]

Can I use any workaround until this is resolved? I have a custom type that I want to convert from Foo<[u32; 10]> to Foo<[u32]>. I could write a method which replaces the PhantomData, but I want it to work for all Unsize-able types.

[eddyb]

cc @rust-lang/lang Do we want to close this and all the unfinished sub-issues, and require a new RFC for any new features in this area, even if the old RFC covers them?
One thing to note is that we should probably not implement any new coercions until we get a new system built on top of traits and/or chalk, that can handle arbitrary library opt-in.

[Centril]

@eddyb What exactly remains to be done here; could you clarify the unfinished sub-issues?

[eddyb]

@Centril I'm just referring to this comment #18469 (comment) and the unchecked checkboxes in it.