Tracking issue for future-incompatibility lint `invalid_type_param_default`

[petrochenkov]

View all comments

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).