`Concat` trait has bad codegen for arrays

[taralx]

Code: https://rust.godbolt.org/z/TjPcbz

use std::convert::TryInto;

pub fn t(a: [u8; 32], b: [u8; 32]) -> [u8; 64] {
    [a, b].concat().try_into().unwrap()
}

This shouldn't allocate. Nor should it be doing anywhere near as many copies. Even if you remove the Vec -> array conversion, it's still doing way more work than it needs to -- the grow calls should not be there for a simple concat.

[taralx]

(Similarly bad code for 2+2=4, but strangely slightly less bad code for 1+1=2.)

[jyn514]

This happens because concat is only implemented on slices, not arrays, so the standard library doesn't know the length of the output at compile time and has to go through a Vec instead. I'm not sure how this would work for slices - maybe with const generics it's possible?

[slightlyoutofphase]

As it stands currently, it definitely is possible to use const generics to write a trait that works exactly like Concat does while generating significantly better assembly for fixed size arrays:

use std::borrow::Borrow;

pub trait ConcatBase<Item: ?Sized, const N: usize> {
    type Output;

    fn my_concat(slice: &Self) -> Self::Output;
}

impl<T: Copy + Clone, V: Borrow<[T]>, const N: usize> ConcatBase<T, N> for [V] {
    type Output = [T; N];

    fn my_concat(slice: &Self) -> [T; N] {
        let slice_ref = slice[0].borrow();
        assert!(slice_ref.len() > 0, "Insufficient input!");
        let mut res = [slice_ref[0]; N];
        let mut i = 0;
        for v in slice {
            for el in v.borrow() {
                if i == N {
                    panic!("Insufficient output capacity!")
                }
                res[i] = *el;
                i += 1;
            }
        }
        res
    }
}

pub trait SliceConcatImpl {
    fn my_concat<Item: ?Sized, const N: usize>(&self) -> Self::Output
    where
        Self: ConcatBase<Item, N>,
    {
        ConcatBase::my_concat(self)
    }
}

impl<T> SliceConcatImpl for [T] {}

pub fn test(a: [u8; 32], b: [u8; 32]) -> [u8; 64] {
    [a, b].my_concat()
}

With that said though, an IMO simpler / more powerful take on what calling concat actually does for arrays specifically that you can't write currently would be a method directly on [T; N] with a fully inferrable signature that looked something like this:

pub fn concat<const N2: usize>(&self, other: &[T; N]) -> [T; N + N2]

[jyn514]

pub fn concat(&self, other: &[T; N]) -> [T; N + N2]

This would need full const_generics I think, which is still a very long way from stabilizing.

[slightlyoutofphase]

It would, yeah. That sort of thing did kind of work (by accident I believe) as long as you wrote the function in just the right way for 6+ months last year though, haha.

[taralx]

Even taking that into account, the code is peephole optimization levels of bad. Manually coding what concat does with a Vec return produces significantly less assembly.