Stream: wg-traits

Topic: rustc-chalk integration, take 2


nikomatsakis (Nov 18 2019 at 18:39, on Zulip):

So @tmandry and I were talking about how to improve the rustc-chalk integration

nikomatsakis (Nov 18 2019 at 18:40, on Zulip):

And we decided to continue here :)

nikomatsakis (Nov 18 2019 at 18:40, on Zulip):

Currently rustc only uses chalk-engine

nikomatsakis (Nov 18 2019 at 18:40, on Zulip):

and it duplicates all the lowering and other logic

nikomatsakis (Nov 18 2019 at 18:41, on Zulip):

I think what we want instead is that rustc uses chalk-solve

nikomatsakis (Nov 18 2019 at 18:41, on Zulip):

(Like rust-analyzer does)

nikomatsakis (Nov 18 2019 at 18:41, on Zulip):

This will mean that we have to implement the RustIrDatabase trait

nikomatsakis (Nov 18 2019 at 18:42, on Zulip):

We're not going to be be able to do that yet without some work :)

nikomatsakis (Nov 18 2019 at 18:43, on Zulip):

I was hoping to kind of brainstorm out a bit what this work would be

nikomatsakis (Nov 18 2019 at 18:43, on Zulip):

just made a hackmd document to keep notes

nikomatsakis (Nov 18 2019 at 18:44, on Zulip):

anyway the real challenge then is going to be created little bits of chalk-ir and chalk-rust-ir from Rust's HIR/ty values

nikomatsakis (Nov 18 2019 at 18:44, on Zulip):

I expect to use the TypeFamily traits (extended with some more stuff...) to try and make that convenient and efficient

nikomatsakis (Nov 18 2019 at 18:45, on Zulip):

to start, I think we need to add the "ids"

nikomatsakis (Nov 18 2019 at 18:46, on Zulip):

e.g., instead of TypeId being hard-coded to be an integer (wrapped around RawId)

nikomatsakis (Nov 18 2019 at 18:46, on Zulip):

this should probably indirect through TypeFamily

nikomatsakis (Nov 18 2019 at 18:46, on Zulip):

that would allow us to use DefId in the compiler

nikomatsakis (Nov 18 2019 at 18:47, on Zulip):

(it's interesting to note that I think Chalk can have a richer notion of ids, all of which map to DefId under the hood)

nikomatsakis (Nov 18 2019 at 18:47, on Zulip):

not sure if that'll cause any difficulty, depends if we currently match on the TypeKindId enum for anything besides debug

nikomatsakis (Nov 18 2019 at 18:49, on Zulip):

(answer: we do, a bit, so we should add some methods around that)

nikomatsakis (Nov 18 2019 at 18:49, on Zulip):

for example, we have code like this

            // If this is a `Foo: Send` (or any auto-trait), then add
            // the automatic impls for `Foo`.
            let trait_datum = db.trait_datum(trait_id);
            if trait_datum.is_auto_trait() {
                match trait_ref.parameters[0].assert_ty_ref().data() {
                    TyData::Apply(apply) => {
                        if let TypeName::TypeKindId(TypeKindId::StructId(struct_id)) = apply.name {
                            push_auto_trait_impls(builder, trait_id, struct_id);
                        }
                    }
                    TyData::InferenceVar(_) => {
                        panic!("auto-traits should flounder if nothing is known")
                    }
                    _ => {}
                }
            }
nikomatsakis (Nov 18 2019 at 18:51, on Zulip):

(@tmandry, still here? :)

tmandry (Nov 18 2019 at 18:51, on Zulip):

yep

nikomatsakis (Nov 18 2019 at 18:51, on Zulip):

apart from the above, I think there are some other mappings we want

nikomatsakis (Nov 18 2019 at 18:51, on Zulip):

e.g.

nikomatsakis (Nov 18 2019 at 18:51, on Zulip):

Parameter<TF> => Kind<'tcx> in rustc

nikomatsakis (Nov 18 2019 at 18:51, on Zulip):

similarly, anything with an embedded Vec or Box seems like trouble

nikomatsakis (Nov 18 2019 at 18:52, on Zulip):

I am debating just a bit now -- I guess I take that (mildly) back, it might be that it's ok to make vectors for now, and then it's just perf optimization to improve it

nikomatsakis (Nov 18 2019 at 18:53, on Zulip):

well I do think we really want to try and map Parameter<'tcx> to Kind<'tcx>,

nikomatsakis (Nov 18 2019 at 18:53, on Zulip):

and see if we can (therefore) map a vector of substitutions to Substs<'tcx>

nikomatsakis (Nov 18 2019 at 18:53, on Zulip):

the reason is

nikomatsakis (Nov 18 2019 at 18:53, on Zulip):

this is what chalk gives back as answers to queries

nikomatsakis (Nov 18 2019 at 18:54, on Zulip):

I'd like it if we (basically) had some (potentially expensive) function that generates "data" from a Ty<'tcx>

nikomatsakis (Nov 18 2019 at 18:54, on Zulip):

for those times that we call ty.data()

nikomatsakis (Nov 18 2019 at 18:54, on Zulip):

this is basically doing the translation from rustc's representation to chalk's, and we can make that gradually cheaper

nikomatsakis (Nov 18 2019 at 18:54, on Zulip):

but ideally we wouldn't need such a translation on the way back

nikomatsakis (Nov 18 2019 at 18:55, on Zulip):

(along those lines, I see one potential problem with the existing type signatures...)

nikomatsakis (Nov 18 2019 at 18:56, on Zulip):
impl Ty<TF> {
    pub fn data(&self) -> &TyData<TF> { ... }
}
nikomatsakis (Nov 18 2019 at 18:56, on Zulip):

if, in rustc, we are generating that TyData on the fly...

nikomatsakis (Nov 18 2019 at 18:56, on Zulip):

it's going to be hard to return borrowed data

nikomatsakis (Nov 18 2019 at 18:56, on Zulip):

well

nikomatsakis (Nov 18 2019 at 18:56, on Zulip):

I guess we can allocate it from the arena

nikomatsakis (Nov 18 2019 at 18:56, on Zulip):

i.e., generate it lazilly (and only once)

nikomatsakis (Nov 18 2019 at 18:57, on Zulip):

I think I remember now that is what I had in mind

nikomatsakis (Nov 18 2019 at 18:58, on Zulip):

ok, looking a bit deeper

nikomatsakis (Nov 18 2019 at 18:58, on Zulip):

obviously the types in rustc have a lot more variants than their chalk counterparts

nikomatsakis (Nov 18 2019 at 18:58, on Zulip):

but most of them are effectively type names of various kinds

tmandry (Nov 18 2019 at 18:59, on Zulip):

but ideally we wouldn't need such a translation on the way back

just making sure I follow.. in the converted type, we can just store a Ty<'tcx>that points back to the rustc type, right?

tmandry (Nov 18 2019 at 19:03, on Zulip):

assuming everything's stored in an arena with the same lifetime, it should work

nikomatsakis (Nov 18 2019 at 19:04, on Zulip):

Sorry, mm,

nikomatsakis (Nov 18 2019 at 19:05, on Zulip):

what do you mean by the "converted type"?

tmandry (Nov 18 2019 at 19:06, on Zulip):

well, not sure =) Ty is what I was thinking of

tmandry (Nov 18 2019 at 19:07, on Zulip):

but we just have to implement things like ty_data()

tmandry (Nov 18 2019 at 19:08, on Zulip):

and we can pass Ty<'tcx> straight through chalk?

nikomatsakis (Nov 18 2019 at 19:08, on Zulip):

yes so

nikomatsakis (Nov 18 2019 at 19:08, on Zulip):

if you implemented ty_data

nikomatsakis (Nov 18 2019 at 19:08, on Zulip):

you convert one type to chalk's representation -- "up to" embedded types

nikomatsakis (Nov 18 2019 at 19:08, on Zulip):

i.e., if you have Vec<u32>, that is two Ty<'tcx> values

nikomatsakis (Nov 18 2019 at 19:09, on Zulip):

that is, the Vec has a list (in rustc) of substitutions Substs<'tcx>

nikomatsakis (Nov 18 2019 at 19:09, on Zulip):

in chalk (today) we have a Vec<Parameter<TF>>, and if you dig in a bit more, you'll see that Parameter<TF> embeds a Ty<TF> which is a newtype of TF::InternedTy

nikomatsakis (Nov 18 2019 at 19:10, on Zulip):

so the thing that rustc would have to create (if we made no further changes from what we have today) when you invoke ty_data on the Vec<u32> type would be these structures, and it would embed the Ty<'tcx> representing u32

nikomatsakis (Nov 18 2019 at 19:10, on Zulip):

not sure if that is making sense

nikomatsakis (Nov 18 2019 at 19:10, on Zulip):

basically a Ty<TF> maps directly to an interned type in rustc (a Ty<'tcx>)

tmandry (Nov 18 2019 at 19:11, on Zulip):

yeah, makes sense now

nikomatsakis (Nov 18 2019 at 19:11, on Zulip):

we don't really have to make any further changes I don't thnk

nikomatsakis (Nov 18 2019 at 19:11, on Zulip):

right now chalk gives back (as its answers) a Vec<Parameter<TF>>, and we could construct a Substs<'tcx> from that, with some work

nikomatsakis (Nov 18 2019 at 19:11, on Zulip):

but it seems like it'd be nicer if pushed that Vec into the type family embedding

nikomatsakis (Nov 18 2019 at 19:12, on Zulip):

that said, looking a bit more, I think something we do have to do is to make TypeName generic

nikomatsakis (Nov 18 2019 at 19:12, on Zulip):

I'm actually a bit torn on this

nikomatsakis (Nov 18 2019 at 19:12, on Zulip):

how this should be handled

nikomatsakis (Nov 18 2019 at 19:13, on Zulip):

the other is that TyKind in rustc has a lot of variants

nikomatsakis (Nov 18 2019 at 19:13, on Zulip):

ah, interesting

nikomatsakis (Nov 18 2019 at 19:14, on Zulip):

yeah it's worth just looking at those and seeing how we would convert them to chalk's notion of TyData

tmandry (Nov 18 2019 at 19:14, on Zulip):

seems like many of them woul dend up as ApplicationTy

nikomatsakis (Nov 18 2019 at 19:16, on Zulip):

yes the vast majority

nikomatsakis (Nov 18 2019 at 19:16, on Zulip):

the interesting one I hadn't thought about is GeneratorWitness

nikomatsakis (Nov 18 2019 at 19:16, on Zulip):

it is a kind of quantified type

nikomatsakis (Nov 18 2019 at 19:16, on Zulip):

seems like many of them would end up as ApplicationTy

anyway this is exactly why I was saying that we probably want TypeName to be generic or something

nikomatsakis (Nov 18 2019 at 19:16, on Zulip):

except that, eventually, I'd like that "list" of types to move from rustc into a (shared) type library

nikomatsakis (Nov 18 2019 at 19:17, on Zulip):

that is used by chalk and a (shared) type-checker and (hence) rustc + rust-analyzer

nikomatsakis (Nov 18 2019 at 19:17, on Zulip):

that type-checker probably cares more about these distinctions

nikomatsakis (Nov 18 2019 at 19:17, on Zulip):

in other words, we might want to sort of hard-code the list

nikomatsakis (Nov 18 2019 at 19:17, on Zulip):

into chalk's type-name

nikomatsakis (Nov 18 2019 at 19:17, on Zulip):

but I'm not sure yet

nikomatsakis (Nov 18 2019 at 19:18, on Zulip):

in terms of other interesting things...

nikomatsakis (Nov 18 2019 at 19:18, on Zulip):

it's worth thinking about refactorings we can do in rusc to make life a touch easier

nikomatsakis (Nov 18 2019 at 19:18, on Zulip):

@csmoe already did some by changing how Closure/Generator work (they take a plain SubstsRef<'tcx>)

nikomatsakis (Nov 18 2019 at 19:19, on Zulip):

the GeneratorWitness is sort of a pain

nikomatsakis (Nov 18 2019 at 19:19, on Zulip):

although it's really just an exists<'a> { .. .} sort of type

nikomatsakis (Nov 18 2019 at 19:20, on Zulip):

we maybe want to add this to chalk

nikomatsakis (Nov 18 2019 at 19:20, on Zulip):

the other thing i'm pondering is -- types like fn() in rustc are one type

nikomatsakis (Nov 18 2019 at 19:20, on Zulip):

but in chalk they are two

nikomatsakis (Nov 18 2019 at 19:20, on Zulip):

a ForAll paired with an application

detrumi (Nov 18 2019 at 19:21, on Zulip):

How does that matter?

nikomatsakis (Nov 18 2019 at 19:21, on Zulip):

well

nikomatsakis (Nov 18 2019 at 19:22, on Zulip):

right now every Ty<TF> (in chalk) and Ty<'tcx> (in rustc) have to have a 1-to-1 correspondence

nikomatsakis (Nov 18 2019 at 19:22, on Zulip):

that said

nikomatsakis (Nov 18 2019 at 19:22, on Zulip):

I think we should just modify chalk a bit here

nikomatsakis (Nov 18 2019 at 19:23, on Zulip):

instead of having QuantifiedTy wrap exactly one type

nikomatsakis (Nov 18 2019 at 19:23, on Zulip):

it should be more like

struct QuantifiedType {
    name: QuantifiedTypeName,
    binders: usize, // number of bound regions
    parameters: Vec<Parameter<TF>>
}
nikomatsakis (Nov 18 2019 at 19:24, on Zulip):

really name and binders kind of overlap and could be merged

nikomatsakis (Nov 18 2019 at 19:24, on Zulip):

the name here would encode the various bits of information from the function signature

nikomatsakis (Nov 18 2019 at 19:24, on Zulip):

e.g., ABI etc

nikomatsakis (Nov 18 2019 at 19:24, on Zulip):

and the parameters listing would be the input/output types

nikomatsakis (Nov 18 2019 at 19:25, on Zulip):

it's a sort of genearlization of chalk's type today but same basic idea -- from POV of chalk, two such types are equal if (a) their names are equal and (b) all the parameters are equal, after instantiating the binders appropriately

tmandry (Nov 18 2019 at 19:27, on Zulip):

I'm a bit lost on the fn() stuff -- what the two types represent in chalk, for example

detrumi (Nov 18 2019 at 19:27, on Zulip):

huh yeah, why is there an application in fn()?

nikomatsakis (Nov 18 2019 at 19:29, on Zulip):

(sorry, multiplexing a few threads)

nikomatsakis (Nov 18 2019 at 19:30, on Zulip):

so today in chalk we effectively have

nikomatsakis (Nov 18 2019 at 19:30, on Zulip):
T = forall<'a, ..> { T }
nikomatsakis (Nov 18 2019 at 19:30, on Zulip):

and I am (first) proposing we genearlize this to

nikomatsakis (Nov 18 2019 at 19:30, on Zulip):
T = forall<'a, ...> { T... }
nikomatsakis (Nov 18 2019 at 19:31, on Zulip):

i.e., you quantify over multiple types

nikomatsakis (Nov 18 2019 at 19:31, on Zulip):

and second, then to add just a bit of a name

nikomatsakis (Nov 18 2019 at 19:31, on Zulip):

why? well, basically because it's not hard to do so, and it lets us map directly to rust's types

nikomatsakis (Nov 18 2019 at 19:31, on Zulip):

rust basically doesn't have a "generic forall" type

nikomatsakis (Nov 18 2019 at 19:32, on Zulip):

it has binders that are "connected" to specifiy sorts of types, such as fn types

nikomatsakis (Nov 18 2019 at 19:32, on Zulip):

plausibly we could just change chalk's QuantifiedTy to FnPointer

nikomatsakis (Nov 18 2019 at 19:32, on Zulip):

since that's really the only thing that uses it

nikomatsakis (Nov 18 2019 at 19:33, on Zulip):

that's effectively what I'm proposing but with more confusing names :)

nikomatsakis (Nov 18 2019 at 19:33, on Zulip):

I guess that's just better

nikomatsakis (Nov 18 2019 at 19:33, on Zulip):

one other thing: chalk uses debruijn indices somewhat differently from rustc

nikomatsakis (Nov 18 2019 at 19:34, on Zulip):

in rustc, a bound variable is identified by a debruijn index (that indentifies the binder) and an internal index (within that binder); in chalk I think we just have the latter. Not sure how much of a pain this will be to reconcile. Probably we should try to adapt one or the other.

nikomatsakis (Nov 18 2019 at 19:35, on Zulip):

one place the difference shows up is exactly fn types --

nikomatsakis (Nov 18 2019 at 19:35, on Zulip):

in rustc they don't have to indicate how many lifetimes they introduce

nikomatsakis (Nov 18 2019 at 19:35, on Zulip):

e.g., for<'a, 'b> fn(&'a &'b u32) in chalk is a QuantifiedTy with num_binders: 2

nikomatsakis (Nov 18 2019 at 19:36, on Zulip):

but in rustc we don't know how many such regions are bound unless we walk the types within

nikomatsakis (Nov 18 2019 at 19:36, on Zulip):

not sure if that's good, just true

nikomatsakis (Nov 18 2019 at 19:36, on Zulip):

plausibly we could just change chalk's QuantifiedTy to FnPointer

does this make sense, @tmandry / @detrumi ?

tmandry (Nov 18 2019 at 19:37, on Zulip):

I think so

detrumi (Nov 18 2019 at 19:37, on Zulip):

hmm

detrumi (Nov 18 2019 at 19:38, on Zulip):

ah, they're both needed to uniquely identify the type, right?

detrumi (Nov 18 2019 at 19:38, on Zulip):

the debruijn index and the internal index

nikomatsakis (Nov 18 2019 at 19:38, on Zulip):

yes, both are needed

tmandry (Nov 18 2019 at 19:39, on Zulip):

..but not in chalk?

nikomatsakis (Nov 18 2019 at 19:39, on Zulip):

well in chalk we have only one set of indices

nikomatsakis (Nov 18 2019 at 19:39, on Zulip):

let me give an example

nikomatsakis (Nov 18 2019 at 19:39, on Zulip):

for<'a, 'b> fn (&'a u32, &'b u32) in chalk is like fn(&^1 u32, &^0 u32)

nikomatsakis (Nov 18 2019 at 19:39, on Zulip):

but in rustc it would be fn(&^0.1 u32, &0.0 u32)

nikomatsakis (Nov 18 2019 at 19:40, on Zulip):

where the ^x in chalk means "bound value with index x"

nikomatsakis (Nov 18 2019 at 19:40, on Zulip):

and in rustc ^x.y means "the yth type bound in binder with index x"

tmandry (Nov 18 2019 at 19:40, on Zulip):

right, and the num_binders in chalk helps you keep track which index belongs to which binder?

nikomatsakis (Nov 18 2019 at 19:40, on Zulip):

in chalk yes

nikomatsakis (Nov 18 2019 at 19:41, on Zulip):

I think there is .. maybe one or two places we take advantage of this? but with the newer clause builder it's hopefully not all that hard to convert

nikomatsakis (Nov 18 2019 at 19:41, on Zulip):

I guess I don't know, I'd have to go look

nikomatsakis (Nov 18 2019 at 19:41, on Zulip):

I do think they should agree, it will make our lives easier

nikomatsakis (Nov 18 2019 at 19:42, on Zulip):

and it seems easier to change chalk than rustc :)

detrumi (Nov 18 2019 at 19:42, on Zulip):

won't it be problematic to not know how many they bind though?

nikomatsakis (Nov 18 2019 at 19:43, on Zulip):

not sure

nikomatsakis (Nov 18 2019 at 19:43, on Zulip):

I mean you can always recover that information

nikomatsakis (Nov 18 2019 at 19:43, on Zulip):

by walking the type

nikomatsakis (Nov 18 2019 at 19:44, on Zulip):

I think what rustc tends to do

nikomatsakis (Nov 18 2019 at 19:44, on Zulip):

well, so I think a side-effect -- where chalk tends to have a signature like

nikomatsakis (Nov 18 2019 at 19:44, on Zulip):
fn substitute(parameters: &[ Parameter ])
nikomatsakis (Nov 18 2019 at 19:45, on Zulip):

in rustc, you instead have to have a closure that (lazilly) computes the value for a given bound thing

nikomatsakis (Nov 18 2019 at 19:45, on Zulip):

since you usually don't know how many there are in advance, and so you kind of generate the substitution as you go

nikomatsakis (Nov 18 2019 at 19:45, on Zulip):

(there is a helper for this)

nikomatsakis (Nov 18 2019 at 19:46, on Zulip):

it may be that we can interconvert, but it seems like it will be a bit tricky, and require a bit of state to do

nikomatsakis (Nov 18 2019 at 19:47, on Zulip):

basically to create a chalk type from a rustc type, you'd have to know how many items were in each enclosing binder

nikomatsakis (Nov 18 2019 at 19:47, on Zulip):

and rustc doesn't know

nikomatsakis (Nov 18 2019 at 19:47, on Zulip):

I guess the obvious final thing that chalk needs to handle to truly handle rustc is constants

nikomatsakis (Nov 18 2019 at 19:49, on Zulip):

(for array types)

detrumi (Nov 18 2019 at 19:50, on Zulip):

rustc's Const you mean?

nikomatsakis (Nov 18 2019 at 19:50, on Zulip):

yes, I mean we have this type in rustc:

    Array(Ty<'tcx>, &'tcx Const<'tcx>),
nikomatsakis (Nov 18 2019 at 19:50, on Zulip):

this is an application type in chalk

nikomatsakis (Nov 18 2019 at 19:51, on Zulip):

but one of the arguments is a Const

nikomatsakis (Nov 18 2019 at 19:51, on Zulip):

this is clearly something we just have to add to chalk, a third kind ("constants") -- I dont' think it should be that difficult, but we'll have to experiment a bit to figure out how the interface around that should work (this is also a WIP in rustc)

nikomatsakis (Nov 18 2019 at 19:52, on Zulip):

see also this topic :) -- where I owe a reply or two...

nikomatsakis (Nov 18 2019 at 19:52, on Zulip):

ok, but I think that's it

nikomatsakis (Nov 18 2019 at 19:52, on Zulip):

it's .. not trivial, but nothing seems that hard to me

nikomatsakis (Nov 18 2019 at 19:52, on Zulip):

I can probably turn the notes in the hackmd into concrete issues

nikomatsakis (Nov 18 2019 at 19:53, on Zulip):

though I'm a bit torn on the debruijn indices one (though some part of me wants to rip them out from everywhere in favor of "names that never alias")

nikomatsakis (Nov 18 2019 at 19:53, on Zulip):

we didn't look at the chalk-rust-ir adaptations that are needed but that's ok

nikomatsakis (Nov 18 2019 at 19:54, on Zulip):

I think that will be much easier because

nikomatsakis (Nov 18 2019 at 19:54, on Zulip):

there isn't the whole "nesting" side of things

nikomatsakis (Nov 18 2019 at 19:56, on Zulip):

i.e., you generate (say) a chalk struct datum from the rustc queries

nikomatsakis (Nov 18 2019 at 19:56, on Zulip):

but we never have to go back etc

nikomatsakis (Nov 18 2019 at 19:56, on Zulip):

and they don't embed other things except via def-ids

nikomatsakis (Nov 18 2019 at 19:57, on Zulip):

Well, I have to run to something else, but that was kind of useful, hope it made sense to y'all -- any parting thoughts?

nikomatsakis (Nov 18 2019 at 19:57, on Zulip):

I guess the question is "when/how will this work happen"

nikomatsakis (Nov 18 2019 at 19:57, on Zulip):

I'm happy to try and create some issues, I think a lot of these refactors will be relatively simple, if grungy

nikomatsakis (Nov 18 2019 at 19:58, on Zulip):

(e.g., changing QuantifiedTy to FnPointer shouldn't be especially difficult..?)

tmandry (Nov 18 2019 at 19:59, on Zulip):

was there anything else that needed to be done for fn pointers?

nikomatsakis (Nov 18 2019 at 19:59, on Zulip):

I think that suffices, though we'll have to include some extra info for stuff like ABI

tmandry (Nov 18 2019 at 19:59, on Zulip):

you said they're one type in rustc and two in chalk, not sure how changing the name of QuantifiedTy is going to change that, or if it matters

nikomatsakis (Nov 18 2019 at 19:59, on Zulip):

it's not just changing the name of the type, in other words

nikomatsakis (Nov 18 2019 at 20:00, on Zulip):

it's also making it have a few extra fields and (in particular) take a Vec<Parameter<TF>> instead of a single Ty<TF>

tmandry (Nov 18 2019 at 20:00, on Zulip):

ah

nikomatsakis (Nov 18 2019 at 20:00, on Zulip):

I'm still a bit torn on whether it should be called ForAllApply or something or FnPointer

nikomatsakis (Nov 18 2019 at 20:00, on Zulip):

the latter seems... a lot more obvious :)

nikomatsakis (Nov 18 2019 at 20:01, on Zulip):

the only argument for the former is that GeneratorWitness is basically ExistsApply

nikomatsakis (Nov 18 2019 at 20:01, on Zulip):

hmm that is kind of a decent-ish argument

nikomatsakis (Nov 18 2019 at 20:01, on Zulip):

but it's not a very strong one

nikomatsakis (Nov 18 2019 at 20:01, on Zulip):

sorry, I'm not being very clear

nikomatsakis (Nov 18 2019 at 20:01, on Zulip):

what I mean is

nikomatsakis (Nov 18 2019 at 20:01, on Zulip):

we have Apply types that do not introduce binders

nikomatsakis (Nov 18 2019 at 20:02, on Zulip):

we could have a QuantifiedApply or something that does

nikomatsakis (Nov 18 2019 at 20:02, on Zulip):

and (depending on the name field) that might be a fn() type or it might be a generator witness

nikomatsakis (Nov 18 2019 at 20:02, on Zulip):

chalk doesn't really care either way

nikomatsakis (Nov 18 2019 at 20:02, on Zulip):

and neither do most part of the code

nikomatsakis (Nov 18 2019 at 20:02, on Zulip):

anyway it's a (relatively) minor detail

tmandry (Nov 18 2019 at 20:02, on Zulip):

that is clearer, thank you :)

detrumi (Nov 18 2019 at 20:02, on Zulip):

Changing all Apply's to QuantifiedApply probably is a bad option, right?

nikomatsakis (Nov 18 2019 at 20:03, on Zulip):

yes, bad option

nikomatsakis (Nov 18 2019 at 20:03, on Zulip):

for one thing unifiying applied types is a lot more complex

nikomatsakis (Nov 18 2019 at 20:03, on Zulip):

basically in general the code does care if there are binders

nikomatsakis (Nov 18 2019 at 20:03, on Zulip):

so I think it should be a different variant

detrumi (Nov 18 2019 at 20:06, on Zulip):

It feels like we're suddenly a lot closer to rustc-chalk integration, this was a very productive discussion :slight_smile:

detrumi (Nov 18 2019 at 20:06, on Zulip):

(though I suppose it was in niko's head all along)

nikomatsakis (Nov 18 2019 at 20:07, on Zulip):

good to get it out

nikomatsakis (Nov 18 2019 at 20:07, on Zulip):

I'll try to take notes on the next few steps that I've been pondering after this too ...:)

Last update: Dec 12 2019 at 01:50UTC