Compat of adding parameters to stable types

[SimonSapin]

Are there backward-compatibility issues with adding a defaulted type parameter to a stable type? For example changing:

struct Vec<T> {…}

To:

struct Vec<T, A: Alloc = Global> {…}

The API Evolution RFC claims this is not a major breaking change, but I vaguely recall discussion of type inference being negatively affected.

Is rust-lang/rust#27336 relevant here?

[TimDiekmann]

It's compatible as long as methods returning Self are not affected.

changing

impl<T> Vec<T> {
    fn new() -> Self;
}

to

impl<T, A: Default> Vec<T, A> {
    fn new() -> Self;
}

would be a breaking change.

[glandium]

It /might/ be possible to work around this issue with specialization... but specialization of inherent impls is not supported yet. rust-lang/rust#37653

[TimDiekmann]

I think we should be conservative about it and just leave the constructors as they are for now. Similar to RawVec, methods like new_in and with_capacity_in can then be used (just like you did in rust-lang/rust#58457).

[SimonSapin]

https://rust-lang.github.io/rfcs/1398-kinds-of-allocators.html#default-type-parameter-fallback is relevant:

Default type parameters themselves, in the context of type defintions, are a stable part of the Rust language.

However, the exact semantics of how default type parameters interact with inference is still being worked out (in part because allocators are a motivating use case), as one can see by reading the following:

• RFC 213, "Finalize defaulted type parameters": https://github.com/rust-lang/rfcs/blob/master/text/0213-defaulted-type-params.md

• Tracking Issue for RFC 213: Default Type Parameter Fallback: Tracking Issue for RFC 213: Default Type Parameter Fallback rust#27336

• Feature gate defaulted type parameters appearing outside of types: Feature gate defaulted type parameters appearing outside of types rust#30724

[TimDiekmann]

We tested this with rust-lang/rust#71873 and rust-lang/rust#77187.