Tracking Issue for RFC 213: Default Type Parameter Fallback

[jroesch]

View all comments

2024-07-15: This feature (default_type_parameter_fallback) is slated for removal, but that is currently blocked on too many crater regressions.

---

EDIT: this issue has been stalled on disagreements about how to handle a nasty problem found during implementation. See the internals thread where this was detailed and discussed.

---

This is a tracking issue for RFC 213.

The initial implementation of this feature has landed.

cc @nikomatsakis

[bluss]

What is the status of this?

[pnkfelix]

@bluss it is still feature-gated, AFAICT. See e.g. the discussion on PR #26870 , or just look at this playpen

I am not sure what the planned schedule is for unfeature-gating it.

nominating for discussion.

[mahkoh]

This doesn't seem to be working properly.

#![crate_type = "lib"]
#![feature(default_type_parameter_fallback)]

trait A<T = Self> {
    fn a(t: &T) -> Self;
}

trait B<T = Self> {
    fn b(&self) -> T;
}

impl<U, T = U> B<T> for U
    where T: A<U>
{
    fn b(&self) -> T {
        T::a(self)
    }
}

struct X(u8);

impl A for X {
    fn a(x: &X) -> X {
        X(x.0)
    }
}

fn f(x: &X) {
    x.b(); // ok
}

fn g(x: &X) {
    let x = x.b();
    x.0; // error: the type of this value must be known in this context
}

[jroesch]

@mahkoh there is a necessary patch that hasn't gotten rebased since I stopped my summer internship. I've been unfortunately busy with real life stuff, looks like @nikomatsakis has plans for landing a slightly different version according to a recent post of his on the corresponding documentation issue for this feature.