search

rust-lang / wg-allocators

Home of the Allocators working group: Paving a path for a standard set of allocator traits to be used in collections!
http://bit.ly/hello-wg-allocators
207 stars 9 forks source link

Compat of adding parameters to stable types #1

Closed SimonSapin closed 3 years ago

SimonSapin commented 5 years ago

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 https://github.com/rust-lang/rust/issues/27336 relevant here?

TimDiekmann commented 5 years ago

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 commented 5 years ago

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

TimDiekmann commented 5 years ago

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 https://github.com/rust-lang/rust/pull/58457).

SimonSapin commented 5 years ago

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:

TimDiekmann commented 3 years ago

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