Tracking Issue for RFC 213: Default Type Parameter Fallback

[jroesch]

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.

[bluss]

@nikomatsakis I know the lang team didn't see any future in this feature, will you put that on record in the issue 😄?

One example where this feature seems to be the only way out is the following concrete example of API evolution in libstd.

Option<T> implements PartialEq today, but we would like to extend it to PartialEq<Option<U>> where T: PartialEq<U>. It appears this feature can solve the type inference regressions that would otherwise occur (and might block us from doing this oft-requested improvement of Option).

[nikomatsakis]

@bluss I HAVE been dubious of this feature, but I'm been slowly reconsidering. @aturon is supposed to be doing some exploration of this whole space and writing up some detailed thoughts. I actually started rebasing @jroesch's dead branch to implement the desired semantics and making some progress there too, but I've been distracted.

One advantage of finishing up the impl is that it would let us experiment with extensions like the one you describe to see how backwards compatible they truly are -- one problem with fallback is that it is not ACTUALLY backwards compatible, because of the possibility of competing incompatible fallbacks.

[nikomatsakis]

That said I still have my doubts :)

[nikomatsakis]

Another example where this could be useful -- basically the same example as petgraph -- is adding allocators to collections in some smooth way.

[durka]

What are the drawbacks to turning this on? It seems to mainly make things compile that otherwise cannot infer enough type information.

[abonander]

I have a pretty good use for this too. It's basically what @bluss mentioned, adding new types to an impl while avoiding breaking inference on existing usage.

[withoutboats]

Is the only issue with this the interaction with numeric fallback? I like default type parameters a lot. I often use them when I parameterize a type which has only one production instantiation, for mocking and to enforce bondaries. Its inconsistent and for me unpleasant that defaults don't work for the type parameters of functions.

[QuineDot]

I did believe that T:: and <T>:: were equivalent, but it's not the case.

What's the difference between T:: and <T>::? Can somebody explain to me why this hack actually works?

Types in part of a (path) expression, like T::, use inference for all elided type parameters -- including defaulted ones -- and do not fallback to the defaulted type when running into ambiguity. That's pretty much what this RFC was about. So these are equivalent and cannot currently fallback to the defaulted type (and thus fail to compile):

    let _ = Foo::Baz;
    let _ = Foo::<_>::Baz;

Where as in type ascription location, you can't elide non-defaulted parameters, but if you elide defaulted parameters they take on the default value. (Then the inferred type parameter in the expression can be resolved from the ascription.) So these are all the same and compile:

    let _: Foo = Foo::Baz;
    let _: Foo<String> = Foo::Baz;
    let _: Foo = Foo::<_>::Baz;
    let _: Foo<String> = Foo::<_>::Baz;

And then we have <T>:: in an expression. The T in <T> is always a type -- on its own inside the <>, T is not part of an expression. Similar to type ascription, you can't elide non-defaulted parameters, but if you elide default parameters they take on the default value. So these are the same:

    let _ = <Foo>::Baz;
    let _ = <Foo<String>>::Baz;

<T> was introduced in RFC 0132, which also says that Foo::<_>::... is now equivalent to <Foo<_>>::.... And sure enough, these don't compile either, as the inference still does not fallback to defaults.

    let _ = <Foo<_>>::Baz;
    let _: Foo<_> = Foo::Baz;

---

Summary

• In an expression position (where you need turbofish)
  • You can elide parameters whether they are defaulted or not
  • Elided parameters, with or without a default, will become fresh inference variables (_)
    • Which do not fallback to parameter defaults
• In a type position (where you don't need turbofish)
  • You cannot elide non-default parameters
  • Elided default parameters will use the default, not inference
  • "Type position" includes type ascription and <T>

[peter-lyons-kehl]

1. Is this still a tracking issue for https://github.com/rust-lang/rfcs/blob/master/text/0213-defaulted-type-params.md (as referenced from that RFC, and from https://doc.rust-lang.org/nightly/unstable-book/language-features/default-type-parameter-fallback.html)?
   
   If so/As such, shouldn't this issue (or whatever tracking issue) be open (while the feature is, at least somewhat, on nightly) - regardless of unclear future for it?

2. Is this (or any other nightly feature, or another RFC) supposed to apply to either:

• return types of (non-associated) functions, where the return type is not related to any of the arguments (or the function doesn't have any arguments at all)? (I can't see anything else relevant in the Unstable Book, nor at https://rust-lang.github.io/rfcs).
• return types of associated functions, where the return type can be (humanly) inferred from the default type parameter(s) of the struct (or even a trait, if possible)?
  
  And if those are not considered/planned/tracked anywhere, how likely would they be to implement, please?
  
  The following two examples fail with current nightly: cannot infer type of the type parameter A... or type annotations needed, respectively:

#![feature(default_type_parameter_fallback)]

pub fn empty_vec<A=u32>() -> Vec<A> {
    Vec::new()
}

pub fn use_empty_vec() {
    empty_vec();
}

#![feature(default_type_parameter_fallback)]

use core::marker::PhantomData;

pub struct WithTypeDefault<T = ()> {
    field: PhantomData<T>
}

impl <T> WithTypeDefault<T> {
    pub fn to_t(&self) -> T {
        loop {}
    }
}

pub fn use_to_t() {
    let with_type_default = WithTypeDefault {field: PhantomData {} };
    let to_t = with_type_default.to_t();
}

[peter-lyons-kehl]

Someone with access, or @Gankra or @jroesch, could you update the very first comment (issue description) to reflect the following, so as to save readers' time, please.

1. The current "EDIT" part (updated in July 2019) is increasing confusion, because

• in one paragraph it mentions two parts:
  -- "stalled on disagreements... problem found during implementation" and
  -- it links to See the internals thread where this was detailed and discussed.
• (due to GitHub's design) the reader doesn't see right away that the "EDIT" part was added in 2019, two years after that (referred) internals thread was closed.

Unfortunately, that internals thread was auto-closed, and the last comment (from September 2015) says that "the lang subteam" has had a "consensus". So, it doesn't explain the problem mentioned in the "EDIT" in 2019.

As is, the "EDIT" paragraph easily confuses readers to search for the problem in that internals thread. Please split into two paragraphs, or add some wording to make the separation clear.

2. Update the RFC link not to contain the timestamp, in case it gets updated. (According to its commit messages, it has had only typo changes since that timestamp). https://github.com/rust-lang/rfcs/blob/master/text/0213-defaulted-type-params.md

3. Consider linking the description to Default Type Parameter Fallback: Revival #46206.

Curious: Was the problem found during implementation only when there is a conflict between the user-supplied default type and an inferred type? Because I have a huge piece of work (for alloc) that would not have such a conflict (or, in internal or nightly code only). And many people here report this useful, too.

[RalfJung]

There's still a feature gate, default_type_parameter_fallback, pointing to this issue. @rust-lang/types should the issue be reopened, the feature gate removed, or the feature gate be changed to point to a different issue?

[lcnr]

I think we should completely remove the feature gate. It's currently only partially implemented and requires some significant design work before we re-add it afaict.

[nikomatsakis]

+1

…

On Mon, Jul 15, 2024, at 4:17 AM, lcnr wrote: I think we should completely remove the feature gate. It's currently only partially implemented and requires some significant design work before we re-add it afaict. — Reply to this email directly, view it on GitHub <#27336 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABF4ZWVJ62BRCX2DZI6AP3ZMOAP7AVCNFSM6AAAAABKZA5FOKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRXHEZTMMBQG4>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[RalfJung]

Sadly that's not really possible currently, typemap uses this feature...

[RalfJung]

I will reopen the issue then -- as long as the feature gate exists, the tracking issue it points to should remain open.