Stream: wg-traits

Topic: Adding Id's to TypeFamily


detrumi (Nov 19 2019 at 15:44, on Zulip):

@nikomatsakis So I'm making an attempt at making TypeId and such to TypeFamily, with associated types like these:

type TypeId: Debug + Clone + Eq + Ord + Hash + Zip<Self> + Fold<Self>;

First hurdle seems to be this derived Fold impl:

impl<TF: TypeFamily, _TTF: TypeFamily> Fold<TF, _TTF> for ProjectionTy<TF> {
    type Result = ProjectionTy<_TTF>;
    fn fold_with(
        &self,
        folder: &mut dyn Folder<TF, _TTF>,
        binders: usize,
    ) -> ::chalk_engine::fallible::Fallible<Self::Result> {
        Ok(ProjectionTy {
            associated_ty_id: self.associated_ty_id.fold_with(folder, binders)?,
            parameters: self.parameters.fold_with(folder, binders)?,
        })
    }
}

That's failing with this error:

error[E0308]: mismatched types
   --> chalk-ir/src/lib.rs:602:63
    |
602 |             associated_ty_id: self.associated_ty_id.fold_with(folder, binders)?,
    |                                                               ^^^^^^ expected type parameter, found a different type parameter
    |
    = note: expected type `&mut dyn fold::Folder<TF, TF>`
               found type `&mut dyn fold::Folder<TF, _TTF>`
    = note: a type parameter was expected, but a different one was found; you might be missing a type parameter or trait bound
    = note: for more information, visit https://doc.rust-lang.org/book/ch10-02-traits.html#traits-as-parameters

error[E0308]: try expression alternatives have incompatible types
   --> chalk-ir/src/lib.rs:602:31
    |
602 |             associated_ty_id: self.associated_ty_id.fold_with(folder, binders)?,
    |                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected family::TypeFamily::TypeId, found fold::Fold::Result
    |
    = note: expected type `<_TTF as family::TypeFamily>::TypeId`
               found type `<<TF as family::TypeFamily>::TypeId as fold::Fold<TF>>::Result`

I'm getting similar errors in super_fold_ty and other Fold derives if I manually fix this one, so some changes to Fold might be required

detrumi (Nov 19 2019 at 15:52, on Zulip):

(branch here: https://github.com/rust-lang/chalk/compare/master...detrumi:tf-associated-ids)

detrumi (Nov 19 2019 at 15:57, on Zulip):

Oh hmm, maybe the + Fold<Self> bound on TypeId is just wrong, but I don't know what it should be instead, because otherwise self.associated_ty_id.fold_with(...) doesn't work

detrumi (Nov 20 2019 at 08:04, on Zulip):

The problem is that types like ProjectionTy implement Fold<TF, _TTF>, but we can't reference the _TTF when specifying the trait bounds in the associated type

detrumi (Nov 20 2019 at 08:11, on Zulip):

I mean, we could do this in the Fold impls, but that would probably get quite unwieldy:

where TF::TypeId: Fold<TF, _TTF, Result = _TTF::TypeId>,
detrumi (Nov 20 2019 at 08:47, on Zulip):

It's surprising me that it's having trouble with the difference between these two:

expected type `<<TF as family::TypeFamily>::TypeId as fold::Fold<TF>>::Result`
   found type `<TF as family::TypeFamily>::TypeId`
nikomatsakis (Nov 22 2019 at 20:25, on Zulip):

@detrumi the right fix here is to have TypeId<TF>

nikomatsakis (Nov 22 2019 at 20:25, on Zulip):

and have that implement Fold

nikomatsakis (Nov 22 2019 at 20:25, on Zulip):

and then (internally) it wraps a TF::TypeId

nikomatsakis (Nov 22 2019 at 20:25, on Zulip):

much like we have Ty<TF> which wraps a TF::InternedTy

nikomatsakis (Nov 22 2019 at 20:26, on Zulip):

this does however imply that there has to be some kind of "conversion" between type-families for id's

nikomatsakis (Nov 22 2019 at 20:26, on Zulip):

hmm

nikomatsakis (Nov 22 2019 at 20:26, on Zulip):

interesting problem!

nikomatsakis (Nov 22 2019 at 20:27, on Zulip):

it works for types because we have a "canonical" form to convert into / from

nikomatsakis (Nov 22 2019 at 20:28, on Zulip):

I have to wonder if the "conversion between type families" is worth it

nikomatsakis (Nov 22 2019 at 20:28, on Zulip):

I do think it's an interesting idea but it does add some complexity

nikomatsakis (Nov 22 2019 at 20:28, on Zulip):

otherwise I guess we need to add some sort of "canonical id" that is maybe just a fixed number of integers :)

nikomatsakis (Nov 22 2019 at 20:31, on Zulip):

/me shrugs

nikomatsakis (Nov 22 2019 at 20:31, on Zulip):

maybe we should just do that for now

nikomatsakis (Nov 22 2019 at 20:31, on Zulip):

just make "unpack id" convert to a (u64, u64) or something

Last update: Dec 12 2019 at 00:45UTC