Add ArrayVec::as_inner()

[Fuuzetsu]

Originally I was going to call this as_array()
but as_inner() is more consistent with the
existing into_inner() method. I don't
ultimately care what it ends up being called.

I wonder if we should have a impl From<ArrayVec<T>> for A implementation or is that a bit too foot-gun-y?

Fixes #193.

[Fuuzetsu]

I updated the commit to make it compile on 1.47.

[Lokathor]

I think as_inner makes more sense, because writing an array type to call from would be a pain in the butt and take extra angle brackets, compared to doing a method call on a vec you're working with.

[Lokathor]

Released in tinyvec-1.8.0

[Fuuzetsu]

I think as_inner makes more sense, because writing an array type to call from would be a pain in the butt and take extra angle brackets, compared to doing a method call on a vec you're working with.

I meant having a From impl on top of having as_inner. However with the From impl, it's less obvious that some of the data is past the ArrayVec::len to make a mistake with it.

I think it's fine not to have it for now.

[LunNova]

Is it "safe" to access elements that are past the end of the vec because those elements are always the Default value rather than some undefined behavior, thanks to initializing with the default or mem::take being used when removing something from the Vec?

(I'm not trying to suggest there is a bug, just curious if I'm understanding why this is ok correctly)

[Lokathor]

Yes, the spare slots are not "in the list", but they're always initialized data, so it's safe to access them.

[Fuuzetsu]

I didn't think we could rely on the elements past the "end" being the Default but maybe we can? If yes, can this get documented and made official? This is useful knowledge. I assumed some operations just leave the data as-is without dropping it. I thought truncate just changed the length value but apparently it really does drop things.

[Lokathor]

I'd have to check closely, but I believe that they will not always be the Default value.