Stream: t-compiler/major changes

Topic: Infer hidden types without replacing with compiler-team#325


triagebot (Jul 01 2020 at 22:26, on Zulip):

A new proposal has been announced: #325. It will be
announced at the next meeting to try and draw attention to it,
but usually MCPs are not discussed during triage meetings. If
you think this would benefit from discussion amongst the
team, consider proposing a design meeting.

nikomatsakis (Jul 01 2020 at 22:27, on Zulip):

I'd like to get feedback on this idea from @eddyb @oli and @Matthew Jasper, at minimum =)

nikomatsakis (Jul 01 2020 at 22:27, on Zulip):

I'd also like to know if people can come up with other examples that cause problems

eddyb (Jul 01 2020 at 22:27, on Zulip):

oh so this was one of the designs I think

eddyb (Jul 01 2020 at 22:28, on Zulip):

this stuff dropped off my radar but it makes sense

nikomatsakis (Jul 01 2020 at 22:28, on Zulip):

My motivation is that I'd like to push impl trait to stabilization and elegantly handling these situations seems like the major blocker

nikomatsakis (Jul 01 2020 at 22:29, on Zulip):

anyway g2g for now :) dinner time! :food:

eddyb (Jul 01 2020 at 22:29, on Zulip):

I guess this is simpler than other ways that use inference variables

oli (Jul 02 2020 at 07:05, on Zulip):

so... this is basically limiting the effect of opaque type restriction to the sites that actually go from an opaque type to a concrete type or vice versa, otherwise using the same opaque type everywhere (by letting inference carry it). So...

let x = 42;
let y = x;
let z: OpaqueTy = y;

what type will be inferred for y? the concrete type? and then only the z = y assignment will actually do any of the constraining of the opaque type to the concrete type?

oli (Jul 02 2020 at 07:06, on Zulip):

You posted a breaking change example but I don't quite get how it will break

nikomatsakis (Jul 02 2020 at 13:59, on Zulip):

@oli the type inferred for y would be i32, yes, and then assigning to z would create a constraint that OpaqueTy = i32 basically

nikomatsakis (Jul 02 2020 at 14:00, on Zulip):

but the type for z would be OpaqueType

nikomatsakis (Jul 02 2020 at 14:00, on Zulip):

similar to if you did

let z: impl Debug = y;
nikomatsakis (Jul 02 2020 at 14:01, on Zulip):

oli said:

You posted a breaking change example but I don't quite get how it will break

well, it doesn't necessarily break, but if we do it naively it will. You can kind of observe the same effect if you re-order the return statements. In that case, we initially infer the return type to Box<i32> and then get an error because we are returning a Box<dyn Debug>.

In the same way, if we do the naive thing, we'll end up with two constraints:

and we'll get an error because they are incompatible constraints.

For the example to work, we have to figure out that a coercion is possible and apply it to one of the return statements.

triagebot (Jul 06 2020 at 10:45, on Zulip):

@T-compiler: Proposal #325 has been seconded, and will be approved in 10 days if no objections are raised.

Matthew Jasper (Jul 06 2020 at 16:44, on Zulip):

I'm a bit confused as to how this is supposed to work. From what I can tell we have:

Given that I'm not sure how we handle:

nikomatsakis (Jul 06 2020 at 20:00, on Zulip):

@Matthew Jasper Selection is a good question. I did think about that at some point but it looks like I neglected to talk about it in the MCP, and now that I think a bit more about it I'm not sure that the idea I had actually makes sense.

nikomatsakis (Jul 06 2020 at 20:01, on Zulip):

I guess a question would be what amount of trait selection we expect to succeed

nikomatsakis (Jul 06 2020 at 20:01, on Zulip):

i.e., just where can the contraints come from?

nikomatsakis (Jul 06 2020 at 20:01, on Zulip):

I was imagining that trait selection might operate in a "syntactic mode" where traits are dispatched based only on the declared bounds of the opaque type.

nikomatsakis (Jul 06 2020 at 20:02, on Zulip):

i.e., even if you are inside the "inference region", you can't prove that a value of the opaque type implements more trait than its bounds.

nikomatsakis (Jul 06 2020 at 20:16, on Zulip):

I suppose that this is to some extent also a T-lang issue ("what behavior do we expect")

triagebot (Jul 22 2020 at 15:39, on Zulip):

This proposal has been accepted: #325.

triagebot (Jul 22 2020 at 19:02, on Zulip):

A new proposal has been announced: #325. It will be announced at the next meeting to try and draw attention to it, but usually MCPs are not discussed during triage meetings. If you think this would benefit from discussion amongst the team, consider proposing a design meeting.

Matthew Jasper (Jul 22 2020 at 19:03, on Zulip):

This has open concerns

Last update: May 07 2021 at 06:15UTC