`impl<'out, T: 'out, const N: usize> Deref for Out<'out, [T; N]>`

[kupiakos]

So Out<[T; N]> is less of a second-class citizen. The indexing operations have the same concern.

The initial plan is type Target = [T], though Target = [T; N] would be the more purely correct option. This should compare the documentation ergonomics of the two.

[kupiakos]

This should compare the documentation ergonomics of the two.

It appears that if you have two Deref with different type Target, my version of rustdoc will only include the "methods from Deref" for the last declared Deref. It might be a footgun to have [T; N] not mention all of the available methods in its rustdoc, e.g. .as_slice().

[kupiakos]

I've yanked 2a973ec from the tree: turns out it causes some very nasty type ambiguities that I would much rather do without. Further options are discussed in #31.

[kupiakos]

The extra trait bounds seem right in theory, but make surrounding code break without explicitly spelling everything out:

impl<'out, T, U> ::core::ops::Deref for Out<'out, T>
where
    T: ?Sized + AsMaybeUninit,
    T::Uninit: core::ops::Deref<Target = [MaybeUninit<U>]>
{
    type Target = [MaybeUninit<U>];

    #[inline]
    fn deref(&self) -> &[MaybeUninit<U>] {
        self.as_uninit().deref()
    }
}