Stream: wg-traits

Topic: impl trait


detrumi (Jan 21 2020 at 16:35, on Zulip):

So I'm confused as to what Impl Trait will look like in the chalk ast. I was first assuming that we'd have some item type Foo = impl A + B + C;, but now I see some old tests that have goals like impl Clone: Clone

Jack Huey (Jan 21 2020 at 16:49, on Zulip):

So I'm not 100% sure all those tests still apply (though I assume they would)

Jack Huey (Jan 21 2020 at 16:50, on Zulip):

But, I also am not super sure either

Florian Diebold (Jan 21 2020 at 17:01, on Zulip):

since the new impl Trait does need some def, I would guess the tests need to be rewritten to accomodate that. with the old implementation, one could simply write impl Trait as a type, but presumably now it'll need to be extracted to a definition

Jack Huey (Jan 21 2020 at 17:31, on Zulip):

I mean, if you can't write impl Trait as a type, then how do you lower fn() -> impl Trait? For type Foo = impl Trait, it makes sense that Foo is an alias to the impl Trait type, to me.

Florian Diebold (Jan 21 2020 at 17:36, on Zulip):

types don't have IDs though, right? so I think during lowering, the impl Trait type needs to be assigned an ID (and then lowered to an alias)

Florian Diebold (Jan 21 2020 at 17:37, on Zulip):

and it can't just be the def ID of the type definition, since you can also have things like fn foo(x: Vec<impl Trait>) (IIRC)

detrumi (Jan 21 2020 at 17:37, on Zulip):

Well, you could use placeholders types

detrumi (Jan 21 2020 at 17:38, on Zulip):

and it can't just be the def ID of the type definition, since you can also have things like fn foo(x: Vec<impl Trait>) (IIRC)

Ah, good point. I was thinking of just the result type and parameter indices, but you can also nest them, so it's difficult to have them be a DefId and some offset

Florian Diebold (Jan 21 2020 at 17:39, on Zulip):

but I don't know if you need that whole complexity for the test harness, so it might be enough to only allow explicit type Foo = impl Trait definitions

Florian Diebold (Jan 21 2020 at 17:40, on Zulip):

I mean, you can rewrite everything to that form for tests, I think

detrumi (Jan 21 2020 at 17:40, on Zulip):

Right, that's what I have now in my PR

detrumi (Jan 21 2020 at 17:40, on Zulip):

And you could rewrite the goals to use those types, so you wouldn't need any impl ... in the goals

detrumi (Jan 21 2020 at 17:42, on Zulip):

@Jack Huey Could you explain how the goals in those tests work? I'm not sure what to make of this, for example:

impl Foo<Ref<'static>>: Foo<Ref<'a>>
Jack Huey (Jan 21 2020 at 17:50, on Zulip):

@detrumi I actually have no idea tbh

Jack Huey (Jan 21 2020 at 17:50, on Zulip):

I never really looked at Opaque types

detrumi (Jan 21 2020 at 17:50, on Zulip):

Heh, ok

Jack Huey (Jan 21 2020 at 17:52, on Zulip):

I can look at it a bit more later today and I'll leave some comments here

detrumi (Jan 21 2020 at 17:52, on Zulip):

Appreciated :slight_smile:

Jack Huey (Jan 21 2020 at 17:52, on Zulip):

I mean, I think theoretically you could write the tests so that they're type Foo = impl Trait; Foo: Trait

Jack Huey (Jan 21 2020 at 17:53, on Zulip):

also, might be worth taking a looking at the rust-analyzer impl Trait-related tests

detrumi (Jan 21 2020 at 17:55, on Zulip):

Yeah, and when this PR gets far enough, connecting it with rust-analyzer should be a great way to test it

detrumi (Jan 21 2020 at 20:20, on Zulip):

Alright, got something down for program clauses. Though I'm wondering which rule is better for the auto traits for type Foo = impl A + B:

Implemented(Foo: Send) :- Implemented(A + B: Send) // (1)
Implemented(Foo: Send) :- Implemented(A: Send), Implemented(B: Send) // (2)

Or maybe it doesn't really matter :shrug:

Jack Huey (Jan 22 2020 at 03:51, on Zulip):

So, for dyn Trait, order of A and B would matter (according to Niko). But I'm not sure if order matters for impl Trait. but I'm also not sure if switching the clauses in (2) would change anything in Chalk. (Technically, we are "allowed" to select subgoals in any order, though right now they are chosen last first)

detrumi (Jan 22 2020 at 08:55, on Zulip):

Good to know that order might matter in some cases. Let's go with (1) for now, it's easily changed anyways

nikomatsakis (Feb 07 2020 at 21:51, on Zulip):

So I'm confused as to what Impl Trait will look like in the chalk ast. I was first assuming that we'd have some item type Foo = impl A + B + C;, but now I see some old tests that have goals like impl Clone: Clone

btw I don't think these tests really apply

nikomatsakis (Feb 07 2020 at 21:51, on Zulip):

I think they were thinking about things wrong

nikomatsakis (Feb 07 2020 at 21:52, on Zulip):

I'm not 100% sure what we want for the chalk AST, but it might be something like

nikomatsakis (Feb 07 2020 at 21:52, on Zulip):

opaque type Foo: Bounds = Ty;

nikomatsakis (Feb 07 2020 at 21:52, on Zulip):

this is obviously not Rust syntax

detrumi (Feb 07 2020 at 21:52, on Zulip):

Having some consistent starting point would be a great help :slight_smile:

nikomatsakis (Feb 07 2020 at 21:53, on Zulip):

it depends a bit on what we model in chalk -- I think that to start, I would say that the code which has the job of figuring out the "hidden type" is not chalk's job

nikomatsakis (Feb 07 2020 at 21:53, on Zulip):

we could change that later, but it seems like a good starting point to me

nikomatsakis (Feb 07 2020 at 21:53, on Zulip):

I guess that won't necessatrily help rust-analyzer, but in a way it won't matter

nikomatsakis (Feb 07 2020 at 21:53, on Zulip):

maybe we make the "hidden type" optional

nikomatsakis (Feb 07 2020 at 21:53, on Zulip):

I guess that won't necessatrily help rust-analyzer, but in a way it won't matter

to clarify here

nikomatsakis (Feb 07 2020 at 21:54, on Zulip):

the idea is that, if we are "Reveal" mode, then the hidden type becomes "visible" (i.e., we can normalize that alias to the hidden type)

nikomatsakis (Feb 07 2020 at 21:54, on Zulip):

but rust-analyzer would never be in that mode

nikomatsakis (Feb 07 2020 at 21:54, on Zulip):

still, the hidden type is relevant for auto trait "leakage"

nikomatsakis (Feb 07 2020 at 21:54, on Zulip):

which is partly why I say we should just start out by having the AST tell us what it is

detrumi (Feb 07 2020 at 21:55, on Zulip):

opaque type Foo: Bounds = Ty;

Hmm, is Foo the placeholder, and Ty the 'instance' here?

nikomatsakis (Feb 07 2020 at 21:57, on Zulip):

I'm not sure about the term instance

nikomatsakis (Feb 07 2020 at 21:57, on Zulip):

but if the idea is

nikomatsakis (Feb 07 2020 at 21:57, on Zulip):

you can define an alias type A

nikomatsakis (Feb 07 2020 at 21:58, on Zulip):

every alias type has a placeholder form

nikomatsakis (Feb 07 2020 at 21:58, on Zulip):

as well as rules for how to normalize it to some other type

nikomatsakis (Feb 07 2020 at 21:58, on Zulip):

in the placeholder form, you don't know what A represents, but you can still say things about it

nikomatsakis (Feb 07 2020 at 21:58, on Zulip):

so here, Foo would be the alias

nikomatsakis (Feb 07 2020 at 21:58, on Zulip):

and there would indeed be a placeholder form of it

nikomatsakis (Feb 07 2020 at 21:59, on Zulip):

we'd also have rules to normalize Foo to Ty (but they would require Reveal mode)

nikomatsakis (Feb 07 2020 at 21:59, on Zulip):

and we'd have rules for proving that the placeholder version of Foo is Send

nikomatsakis (Feb 07 2020 at 21:59, on Zulip):

i.e.,

nikomatsakis (Feb 07 2020 at 21:59, on Zulip):
Implemented(PlaceholderFoo: Send) :- Implemented(Ty: Send)
Last update: Feb 25 2020 at 03:05UTC