Why are inherent associated functions of `ArrayVec` implemented via calls to trait-associated functions of `ArrayVecImpl` and not vice versa?

[JohnScience]

Example:

/// Return a mutable slice containing all elements of the vector.
pub fn as_mut_slice(&mut self) -> &mut [T] {
    ArrayVecImpl::as_mut_slice(self)
}

AFAIK, const trait implementation is not landing soon. If ArrayVecImpl::as_mut_slice is defined via the call to the inherent function instead (i.e. if we reverse the implementation dependency), it will be possible to have easier feature-gated support for the const inherent associated function. Instead of the dependence on both const_trait_impl and const_mut_refs features there will be the dependency only on the latter.

I guess it may be fine if you don't want to offer a feature-gated support for nightly const_mut_refs. However, I wouldn't mind to help you with reversing the dependency and opt-in support for the aforementioned nightly features. There's a popular crate const_fn that can help provide such support cleaner.

[bluss]

The idea for ArrayVecImpl is to pool common code - common to ArrayVec and ArrayVecCopy (when that exists), I don't think you can reverse this