Vec box fix

[alejandro-vaz]

this PR is a draft

it builds upon #739, that should be merged first. this is why the PR looks so bloated now

[bolshoytoster]

Does this support From<alloc::Vec<T, Global>> for SmallVec<T, N, Global> and vice versa on allocator-api2? I thought we established that was something people needed.

[alejandro-vaz]

oh what we finally agreed on is that the only collections that were going to be supported were going to be the ones in that sort of feature

I'm not sure where nor with whom

because if another type was needed then the downstream crate could simply do .into_iter().collect() to their desired type

[alejandro-vaz]

and it is so rare that a crate uses an allocator-api2 allocator on a smallvec but that would want a normal allocator on a vec, it just doesn't make sense

[bolshoytoster]

Should we consider how this appears in docs? cargo doc doesn't seem to generate docs for any of these From implementations, and things like

pub fn from_vec(vec: <Vec<T, Global> as Like>::Type) -> Self

aren't very friendly.

[bolshoytoster]

I'm also not conviced that this is any more readable/maintainable than just using #[cfg]s.

[alejandro-vaz]

Should we consider how this appears in docs?

yeah we should, more or less. but we should be preoccupied with that on rc, not on beta. half of our documentation is unspecified / broken right now anyway

if necessary we can later tell docsrs what we want it to know

I'm also not conviced that this is any more readable/maintainable than just using #[cfg]s.

I haven't yet implemented the Vec / Box allocator support there, I'm waiting for #739, but after that it should be pretty straightforward because it'd be a helper on the Like trait that just moves / discards, literally 20 LOC, instead of ~100

we'd just have one implementation that does it and that's it, without we having to worry about three different implementations with #[cfg]s by abstracting at the "parts of the vec from and to" part