Change:
Example code I'd expect to work (): (in case the example above seems artificial, the I've reduced this from involves using an associated trait to add around sized types, but not , since wouldn't itself work) <hr/I'd expect to work because should hold, after normalization to (which holds here because ), but nothing performs that normalization before coercion gives up entirely. Unlike (where I've been wary of associated types in the past), there should be no weird interactions here, we should be able to largely treat the as a tuple (and we already ensure the type parameter being changed doesn't show up anywhere else in the , anyway). <hr/The and examples get to normalize before asking the trait system about any or obligations - I wonder if we could just normalize here? But we would have to be careful, because we are in a speculative operation, so we would have to use , like this other piece of coercion logic: cc (author of the crate where this could be useful) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
FWIW, this can be worked around but they're nightly-only and entirely unnecessary if we fix this issue.
Not sure if I should nominate this for compiler team or lang team, but let's try compiler team first.
This removing nomination. please feel free to keep the discussion going on Zulip or even re-nominating it if you consider a re-discussion important.
I'd like to work on this. I haven't worked on the compiler yet, so not sure I'll be able to fix this in a reasonable time. But since it's labelled it's worth giving a try, right? Any advice is appreciated :) claim
I'm not sure if that E-easy label is really accurate! That said, you could try to drop by in #wg-traits on Zulip at some point during one of my morning office hours times, if that works for you (9am-10 US Eastern Time, every day but Tuesday), and we could talk it over.
is this the same as ?
yes, that's the same thing, unsize coercion doesn't properly consider associated types. (maybe it's time for me to return to this )
if there's anything we can do to help, feel free to poke us; we want this for uazu/qcell. =^-^=
It's been some time this issue was touched, so let me take a look at it.

Discussion:
return Err(Unimplemented); } <del> // Extract `TailField<T>` and `TailField<U>` from `Struct<T>` and `Struct<U>`. let source_tail = tail_field_ty.subst(tcx, substs_a); let target_tail = tail_field_ty.subst(tcx, substs_b); </del> <ins> // Extract `TailField<T>` and `TailField<U>` from `Struct<T>` and `Struct<U>`, // normalizing in the process, since `type_of` returns something directly from // astconv (which means it's un-normalized). let source_tail = normalize_with_depth_to( self, obligation.param_env, obligation.cause.clone(), obligation.recursion_depth + 1, tail_field_ty.subst(tcx, substs_a), &mut nested, ); let target_tail = normalize_with_depth_to( self, obligation.param_env, obligation.cause.clone(), obligation.recursion_depth + 1, tail_field_ty.subst(tcx, substs_b), &mut nested, ); </ins> // Check that the source struct with the target's // unsizing parameters is equal to the target.

<ins> // check-pass use std::fmt::Debug; use std::marker::PhantomData; trait Foo { type Gat<'a>: ?Sized where Self: 'a; } struct Bar<'a, T: Foo + 'a>(T::Gat<'a>); struct Baz<T: ?Sized>(PhantomData<T>); impl<T: ?Sized> Foo for Baz<T> { type Gat<'a> = T where Self: 'a; } fn main() { let x = Bar::<'_, Baz<()>>(()); let y: &Bar<'_, Baz<dyn Debug>> = &x; } </ins>

<ins> // check-pass trait Trait {} impl<T> Trait for T {} trait Noop { type Assoc: ?Sized; } impl<T: ?Sized> Noop for T { type Assoc = T; } struct NoopNewtype<T: ?Sized + Noop>(T::Assoc); fn coerce_newtype<T: Trait>(x: &NoopNewtype<T>) -> &NoopNewtype<dyn Trait + '_> { x } fn main() {} </ins>