Concatenate byte arrays without allocating

I would like to append a "marker" byte onto a byte slice to ensure it ends in a newline byte while parsing it. Here's what I think it could look like:

fn parse(inp: &[u8]) {
    let workable_array = inp.basic_append(b'\n');
}

and when a byte is accessed beyond the length of the original input, it'll go onto the added byte. I'll be using the new array in a purely read-only context afterwards.

I'm aware of the concat method on slices, but this internally allocates an entirely new vector, which seems to be unnecessarily costly. Especially when the input string could potentially be very large.

If you are asking for an operation that takes a &[u8] and returns another &[u8] that includes the newline byte, without reallocation, then the answer is that this is impossible. &[u8] is always contiguous memory, so the newline byte has to be physically located at the end of the slice, which can only be achieved through reallocation. Further, it isn't possible to do so with a &[u8] slice, because it is not mutable.

However, you can in fact achieve a similar effect with iterators. It will not allocate and simply provide another newline byte after all the other bytes got produced.

fn append_newline(data: impl Iterator<Item = u8>) -> impl Iterator<Item = u8> {
    data.chain(std::iter::once(b'\n'))
}

fn main() {
    let s = "Hello";
    let s_iter_with_newline = append_newline(s.bytes());
    for b in s_iter_with_newline {
        println!("{:?}", b as char);
    }
}

'H'
'e'
'l'
'l'
'o'
'\n'

Of course this won't be compatible with functions that require a &[u8] as parameter.

Further remarks:

• It sounds like your input sometimes contains a newline and sometimes not. It is much easier to cut away the newline from the ones that have it than to add it to the ones that don't have it. Maybe change your parsing algorithm that so it requires the input without a newline?
• You are using &[u8] here for what sounds like string operations. Be aware that Rust characters are not u8 - Rust strings are are instead a list of variably-sized UTF-8 characters. That's the reason why the &str/String types exist. Use those instead for string processing, as they can handle special characters, unlike &[u8]. Of course the '\n' problem you are having here still exists with str, it still isn't possible without reallocation.