Supporting dyn Trait

[ssyram]

Currently still a draft. Predicates done.

[Nadrieril]

Let's not make this a separate variant, we can handle it as a Trait.

[ssyram]

OK, I will store everything in the ExistentialTraitRef, this is more clean.

[ssyram]

Still not sure how, let us discuss in Zulip.

[ssyram]

So we keep the current structure?

[Nadrieril]

Let's replace all the AutoTraits with Trait, and document what the projection applies to; after that yeah that's good

[ssyram]

So you mean we incorporate the AutoTraits in Trait? An ExistentialPredicate should then be: 1. a "Principal" ExistentialTraitRef (being a TraitRef), 2. a list of projections and 3. a list of auto trait ids? From enum to a struct?

[Nadrieril]

Haven't reviewed everything but from what I've seen: could you change how we represent the existential predicates? The current encoding will cause issues with generics (see inline comments).

[ssyram]

Thanks for all the suggestions from both of you! I'm still not sure about how to refractor the Predicate form. So I will leave it to the discussion in Zulip. Let me fetch & implement the vtable struct & instances first.

[ssyram]

Many fixes applied. Thanks for the advice. Mainly involving the fix for the three kinds of existential predicates. But I'm still not sure about if they work as expected...

[Nadrieril]

Please add an assertion that the trait_ref is the one we expect

[ssyram]

There's no trait_decl_ref now in Projection.

[Nadrieril]

Yes, that's exactly why you should check that the trait_ref you're ignoring is the one you expect. Because someone may write dyn Debug + Pointee<Metadata=()> where the projection applies to some trait other than the main one (I don't know if this is allowed today but this could be).

[ssyram]

Referring to Pointee like that is not possible. But it is still possible that the item refers to the associated type from super trait. Is there a way to refer to that? Using the item name itself seems not sufficient to resolve this. Shall we change the mechanism?

[Nadrieril]

Oh true, could be a supertraits type that's a good example. I propose we error if that happens for now.

[Nadrieril]

Please add a known-failure test for that case please

[ssyram]

Another good point is that, Rust seems to not allow such specification to have shadowing names, hence the specification by name at the point can uniquely point to an assoc type. Or, it may be just that I'm not familiar with the syntax... At least I don't know how to express:

trait Base { type Assoc; }
trait Trait { type Assoc; }
fn main() {
  let x : &dyn Trait<Assoc=(), ???> = ...;
}

where ??? denotes the specification of Base::Assoc. The Rustc error hints that "consider renaming".

[Nadrieril]

Could you add a lot of tests please? We need to cover edge cases even if we don't support them yet (write //@ known-failure at the top for these cases). We should have tests for supertraits, multiple supertraits, casting in a generic context, associated type projections, + 'a bounds, multiple trait bounds (dyn Any + Send), just builtins (dyn Send), traits with methods that are generic and have a Self: Sized bound (which makes them dyn-compatible but means the vtable doesn't have all the methods), etc.

[ssyram]

Yes, of course. Many tests are coming when the infrastructure is about to get done... Maybe we can focus on the implementation for now?

[Nadrieril]

Maybe we can focus on the implementation for now?

The tests will help me understand what the implementation is doing, I can't just be running the code in my head. It's imo crucial to add the tests while doing the implementation because that's when we think of edge cases. When we're done implementing it's too late.