[meta] Wishlist for smallvec 1.0

[mbrubeck]

This is a list of breaking changes that we would like to make before stabilizing the API for smallvec 1.0.

Increases the minimum Rust version from 1.20:

• Use the alloc crate for no_std compatibility (alloc is now stable #159, Requires Rust 1.36).
• Replace mem::uninitialized with MaybeUninit (Possible UB from use of uninitialized [&T; N] #126, Requires Rust 1.36).
• Use NonNull<T> instead of *mut T (Use NonNull instead of a raw pointer #171, Requires Rust 1.25).
• Replace the unreachable crate with std::hint::unreachable_unchecked (Maybe remove the 'unreachable' crate dependency? #128, Requires Rust 1.27).

Breaking API changes:

• Change drain method to take a RangeBounds argument (change drain to be consistent with Vec #142, Requires Rust 1.28).

Deprecations:

• Remove deprecated SmallVecN type aliases.
• Remove deprecated push_all_move method.
• Remove deprecated VecLike trait.

Still depends on unstable Rust features. Postpone until 2.0:

• Use const generics to change SmallVec<[T; N]> to SmallVec<T, N>. Remove the Array trait. (Tracking issue for const generics (RFC 2000) rust-lang/rust#44580).
• Support custom allocators (Support parametric allocators #55, Allocator traits and std::heap rust-lang/rust#32838).
• Use specialization to optimize extend, insert_many, and from for slices of Copy types. Deprecate and remove extend_from_slice, insert_from_slice, and from_slice (Tracking issue for specialization (RFC 1210) rust-lang/rust#31844).
• Use the union representation by default and remove the optional union feature added in Use a union to reduce the size of SmallVec [v2] #94 (Untagged unions (tracking issue for RFC 1444) rust-lang/rust#32836).

[llogiq]

Regarding specialization, I can see how the From implementation can work out, but wouldn't Extend and insert_many violate coherence rules?

[mbrubeck]

Specializing these would require adding an intermediate trait with a default impl and specialized impls, like libstd's impl Extend for Vec.

[cbarrick]

Might I suggest adding an updated drain to the list.

SmallVec::drain was implemented in #26, but does not accept a range argument like Vec::drain. At the time, RangeArgument (now RangeBounds) had not stabilized. RangeBounds is now stable since Rust 1.28.

[mbrubeck]

Many of the unstable Rust features seem unlikely to stabilize any time soon. I think we should consider making a 1.0 release in the near future (sometime this year) which would include everything that is stable now (or in the very near future), and then make a 2.0 release much later (probably 2 or more years from now) with features that stabilize later.

The following would be delayed until 2.0 or later:

• const generics
• custom allocators
• specialization

The following might be ready in time for 1.0:

• MaybeUninit
• liballoc
• union

It might be worth waiting until MaybeUninit is stabilized, since that fixes a potentially critical soundness issue. Alternately we could use build-time rustc version detection to conditionally use MaybeUninit, but this would increase code complexity and we would need to live with it for potentially a long time.

[lambda-fairy]

MaybeUninit and alloc are now stable. Do we want to update this issue?

[newpavlov]

I really hope that v1.0 version will use const generics. Yes, stabilization is unlikely to happen in the near future (6-12 months), but at least it's on horizon, which can not be said about specialization.

[mbrubeck]

I posted a PR for a 1.0.0 release in #175

I'd like to publish this as soon as possible, because lack of MaybeUninit in existing releases is UB waiting to happen, and is already impacting downstream projects that run MIRI tests. We can release a 2.0 version next year or whenever const generics are ready.

[llogiq]

There's a neat trick written up by @dtolnay to emulate specialization on stable. I haven't looked too deeply into how well that performs, but it's probably worth a shot trying to use it.

[matklad]

@mbrubeck thank you for putting work into this!

Seems like the issue can be closed and a new one, wishlist for 2.0, opened instead

[mbrubeck]

Filed #183 to track 2.0 progress.