Inference failure with type_changing_struct_update

[crlf0710]

In the crater run #98456, fajita crate regression exhibited inference failure. Here's a minimal repro:
// when feature gate is enabled below, the compilation fails.

#![feature(type_changing_struct_update)]

#[derive(Default)]
pub struct Foo<P, T> {
    pub t: T,
    pub v: P
}

impl<P: Default, T:Default> Foo<P, T> {
    pub fn o(t: T) -> Self {
        Foo { t, ..Default::default() }
    }
}

[crlf0710]

Just creating an issue for easier tracking.

cc #86555

[nikomatsakis]

We certainly knew this was a possibility when authoring the RFC -- based on the Zulip conversation, I believe that there were a number of inference failures of this kind, right?

The options on the table that I see are:

• Make the change anyway, breaking the crates.
• Make the change over an edition.
• Give up.

My sense was that there was a significant amount of breakage, making the first not an option. In that case, if we want to proceed, we should probably do the work to plan how we can make this an edition change (in particular, can we do migration?). I think we should be able to.

I'm going to nominate this issue to make the @rust-lang/lang team aware, but I'd appreciate it @crlf0710 if you or perhaps @compiler-errors could drop in more details about the scale of breakage found on crater.

[nikomatsakis]

@rustbot label +I-lang-nominated

[WaffleLapkin]

For some context, there is a zulip thread about finishing work on type-changing struct update.

And here is a MRE of this particular problem:

#![feature(type_changing_struct_update)]

#[derive(Default)]
struct Struct<T>(T);

fn _f() { Struct { 0: (), ..Default::default() }; }

If I understood correctly, @compiler-errors has an idea how we can hack inference to allow such examples. It's a hack though, so we may prefer to just do an editional breakage...

[compiler-errors]

For context, here's the experimentation I have done:

• without any additional inferences changes (1687 regressed): [NO MERGE] Enable type_changing_struct_update always (crater run) #98456 (comment)
• With some inference hacks (13 regressed): [NO MERGE] Enable type_changing_struct_update always (crater run) #98456 (comment)

But even with those inference hacks there are still cases where we get failures.

The inference hack is in a6e4db2 but it's very much a hack.

[SparrowLii]

I understood the cause of the problem to some extent and should be able to submit a PR soon to fix it

[SparrowLii]

@rustbot claim

[crlf0710]

Posted my thoughts in Zulip https://rust-lang.zulipchat.com/#narrow/stream/293397-project-type-changing-struct-update/topic/Work.20needed.20to.20finish.20out.20RFC/near/299733175

[scottmcm]

We discussed this in the lang meeting this week.

I don't think we had agreement on what the way forward should be, but we had consensus that

• The inference breakage of just making the basic change is more than we're willing to accept.
• We're interested in seeing a plan to make a migration path reasonable over an edition
  • We don't know what that plan should be.
  • But needing ..<Foo<A, B>>::default() isn't it.

@rustbot label -I-lang-nominated

[SparrowLii]

I came up with my solution, but it looks like the language team wants a different approach. So unassigned myself.

[Crazytieguy]

Are there plans for trying to get this in to the 2024 edition?

[compiler-errors]

I don't think so. The inference fallout is really dramatic without hacks, and (speaking as an individual contributor, and not for the whole types team) I don't believe there is really a good, principled hack to implement here that would make the types team happy.