Tracking issue for future-incompatibility lint invalid_type_param_default

[petrochenkov]

This is the summary issue for the invalid_type_param_default
future-compatibility warning and other related errors. The goal of
this page is describe why this change was made and how you can fix
code that is affected by it. It also provides a place to ask questions
or register a complaint if you feel the change should not be made. For
more information on the policy around future-compatibility warnings,
see our breaking change policy guidelines.

What is the warning for?

Type parameter defaults outside of type declarations were never intended
to be permitted, but some early versions of Rust did accept them. For
example:

struct Foo<T=i32> { 
    // the default of `i32` is legal here, since this
    // is a type declaration
}

impl<T=i32> Debug for Foo<T> { .. }
//   ^^^^^ default not legal here, in an impl

fn bar<T=i32>(x: T) { }
//     ^^^^^ default not legal here, in a fn

When will this warning become a hard error?

At the beginning of each 6-week release cycle, the Rust compiler team
will review the set of outstanding future compatibility warnings and
nominate some of them for Final Comment Period. Toward the end of
the cycle, we will review any comments and make a final determination
whether to convert the warning into a hard error or remove it
entirely.

Current status

• Feature gate defaulted type parameters appearing outside of types #30724 introduces the invalid_type_param_default lint as warn-by-default
• Make sufficiently old or low-impact compatibility lints deny-by-default #36894 makes the invalid_type_param_default lint deny-by-default
• Turn sufficiently old compatibility lints into hard errors #42136 tried to make the invalid_type_param_default lint a hard error, but there was still too much breakage
• turn invalid_type_param_default into a FutureReleaseErrorReportInDeps #127655 tried to make this a hard error, but there was still too much breakage (mostly due to typemap), so it was just made to show up in future breakage reports instead
• PR ? makes the invalid_type_param_default lint a hard error

[petrochenkov]

@nikomatsakis, could you write a description for this?

[nikomatsakis]

@petrochenkov done.

[nrc]

Where can I find discussion of this issue? I don't see any on RFC 213, nor its tracking issue (#27336).

[nikomatsakis]

@nrc perhaps I should have phrased the summary with slightly differently. I think the main thing is that defaults were being accepted in stable code but ignored, unless you opt in to a feature gate, which gives them some semantics (but semantics that I now think I disagree with).

[RReverser]

Is there a reason this is being phased out on functions?

It's sometimes useful to have fn do_smth<A, B=A>(a: A, b: B) { ... }.

[nikomatsakis]

@RReverser Yes. Because, IIRC, they are basically ignored on stable Rust. On nightly Rust, meanwhile, we were considering various possible meanings, but have not yet found one that we are satisfied with.

[RReverser]

Ok, I'm now curious... where can I read about other possible meanings? The expectation seems pretty straightforward, just like in case with struct - that with fn do_smth<T=SomeType>() {}, do_smth() would be equivalent do do_smth::<SomeType>() but maybe I'm missing some issues?

[randomPoison]

I'm also curious as to what the issue is for default type arguments in generic functions. I'm running into a case where it would greatly help ergonomics of using a function with an optional generic parameter: https://is.gd/Gy9bXW

[Starwort]

I'd also like this restriction to be lifted for functions, especially for trait functions. It would be much more ergonomic to have an API which allows default type parameters; For example, Iterator::collect could default to Vec<T>, while still allowing to be overridden by either type inference or an explicit turbofish; additionally Iterator::sum could be optimised for the common case where S = T (e.g. usize -> usize); other use-cases where an obvious default could be picked should be fairly common

[rambip]

It is especially usefull for optional functions:

fn foo<F: Fn() -> String>(bar:Option<F>){}

fn main(){
    foo(Some(|| String::new()));
    foo(None)
}

Here, I have to use turbofish syntax even if it is irrelevant

If I do:

fn foo<F: Fn() -> String=fn() -> String>(bar:Option<F>){}

fn main(){
    foo(Some(|| String::new()));
    foo(None)
}

Now it compiles !

[gsteinLTU]

For example, Iterator::collect could default to Vec<T>

I have to wonder how much time this would have saved people if it was like this from the start.

[rambip]

And in essence, this is just a hint for the compiler saying "instead of raising type annotation needed for Foo, just try to replace with some concrete type to see if that works"
Maybe it is a completely different feature and a new issue should be open (default type parameters can create a bunch of strange situations), but it would be very cool to have this feature.

[QuineDot]

Default type parameters on functions are not completely ignored. Inference doesn't fallback to them just like default type parameters elsewhere, and there are less workarounds because you can't name the types of functions items.

But this works, for example:

#[allow(invalid_type_param_default)]
fn partial_default<T, U: Default = String>() -> U {
    U::default()
}

fn main() {
    let x = partial_default::<()>();
    println!("{}", std::any::type_name_of_val(&x));
}

Because if you have one or more non-defaulted parameters, you can omit defaulted parameters in a turbofish, and (unlike when all parameters are elided / when there is no turbofish), the elided parameters will take on their default values instead of being inference variables.

This is required for things like Vec<Element, Allocator> to work as intended with the default allocator, but happens to work for functions and probably other things, as well.

[RalfJung]

FWIW I did a crater run in #127655 and there's still quite a few crates affected by this lint -- mostly because of typemap.

[tjpalmer]

It is especially usefull for optional functions:

fn foo<F: Fn() -> String>(bar:Option<F>){}

fn main(){
    foo(Some(|| String::new()));
    foo(None)
}

Here, I have to use turbofish syntax even if it is irrelevant

Similar problem for things like Option<impl ToString>. Having to say something like None::<String> is sort of silly.

[EndilWayfare]

euclid is another example of a class of use-case in which this is useful for ergonomic/noise-reduction reasons.

The geometric primitives from this crate have an "optional" type parameter to specify unit of measure, but it's not really optional. You don't have to make active use of it, but you do have to mention it in your client code regardless.

use euclid::UnknownUnit;
// Equivalent to 
// `type Point2D<T> = euclid::Point<T, UnknownUnit>;`
use euclid::default::Point2D;

pub fn my_silly_point<U>() -> euclid::Point2D<i32, U> {
    Point2D::new(42, 21)
}

pub fn also_my_silly_point() -> Point2D<i32> {
    my_silly_point()
}

fn no_units_pls() {
    let leaky_implementation_details = my_silly_point::<UnknownUnit>();
    let strange_and_awkward = my_silly_point::<()>();

    let but_i_can = also_my_silly_point();
}

fn im_already_using_units() {
    struct ScreenSpace;

    let center = euclid::Point2D::<i32, ScreenSpace>::new(2560, 1440) / 2;

    let i_can = center - my_silly_point();

    let but_i_have_to = center - also_my_silly_point().cast_unit();
    let or_maybe_for_some_reason = center - euclid::Point2D::from_untyped(also_my_silly_point());
}

I don't know why euclid chooses to uses a type alias instead of a default type parameter, or even if this is even a deliberate design decision. But, if a crate author decides they don't like default type parameters and you do like default type parameters, functions-with-default-type-parameters would let you have/emulate them without, e.g., a redundant wrapper struct.

[RalfJung]

Yeah default type params in type aliases are common. AFAIK they do not cause any kind of inference fallback so they do not share the issues of what is being tracked here. So for code that currently hits this future compat error, that seems like a good thing to migrate to.