Concatenation of Array

Given nums of length $n$ , return an array of length $2n$ that is nums followed by nums again.

[]int{1, 3, 2, 1}   // → [1 3 2 1 1 3 2 1]

The algorithm is not the point. Everything interesting here is about how Go slices actually behave, and this is the smallest problem where you can see it.

The solution

func getConcatenation(nums []int) []int {
    var size = len(nums)
    var ans = make([]int, 2*size)

    for i, v := range nums {
        ans[i] = v
        ans[size+i] = v
    }

    return ans
}

One pass over nums, two writes per iteration:

Index 1 / 4

nums

▾ i 1 0

3 1

2 2

1 3

ans — allocated once, at length 8

nums[0] is written to ans[0] and ans[4 + 0] in the same iteration. Both destinations already exist — nothing grows, nothing is copied to make room, and the loop runs exactly 4 times rather than 8.

$O(n)$ time, $O(n)$ space — and the space is the output, so there is nothing extra.

Say the length or say the capacity, not neither

Three spellings, and the difference is not stylistic:

ans := make([]int, 2*size)          // length 2n, all zero — index into it
ans := make([]int, 0, 2*size)       // length 0, capacity 2n — append into it
ans := []int{}                      // length 0, capacity 0 — append and realloc

Mixing the first two silently doubles the output

ans := make([]int, 2*size)   // already 2n zeroes
ans = append(ans, v)         // appends AFTER them

make([]int, n) gives you n elements, not n slots waiting to be filled. Appending to it produces [0 0 0 0 1 3 2 1], twice the length you wanted, with the real data at the far end.

Choose one: index into a slice made with a length, or append to one made with a capacity. The compiler is happy either way, which is what makes this worth knowing.

`copy` says it better

The loop is fine. The standard library states the intent in two lines:

func getConcatenation(nums []int) []int {
    size := len(nums)
    ans := make([]int, 2*size)

    copy(ans, nums)
    copy(ans[size:], nums)

    return ans
}

copy moves as many elements as fit in the shorter of the two slices and returns that count. For a slice of a basic type it compiles down to a bulk memory move rather than an element-at-a-time loop, so it is also faster than the version above — the gap widens with n.

ans[size:] is a view onto the second half of the same array, not a new one. No allocation happens on that line.

The one-liner, and why it is a trap

return append(nums, nums...)

This produces the right answer on LeetCode. It can also corrupt data belonging to the caller.

append writes into spare capacity, and the spare capacity may not be yours

A Go slice is a view: pointer, length, capacity. If cap(nums) > len(nums), append writes into that spare room in place rather than allocating — and anything else viewing the same backing array sees the change.

nums = [1 2 1]   len 3, cap 8
neighbour := someOtherViewOfTheSameArray   // [0 0 0]

append(nums, nums...)
neighbour is now [1 2 1]   ← clobbered, without ever being touched

Worse, it is intermittent. With no spare capacity append allocates a fresh array and the caller is untouched, so the same line is safe or destructive depending on how the slice was built — which is a property of code somewhere else entirely.

If you want a guaranteed copy, allocate one. make plus copy is explicit about it; append is not.

A slice is not an array

var a [4]int      // an array: fixed length, part of the type, copied on assignment
var s []int       // a slice:  pointer + length + capacity, shares its backing array

Passing an array to a function copies every element. Passing a slice copies three words and shares the data. That is why a function can mutate its caller’s slice contents but cannot change the caller’s length.

Nearly every Go slice surprise comes from this one distinction, and it is the reason slices.Clone exists.

What it is actually teaching

The concatenation is a pretext. The habits are the point, and they carry to every array problem you will write:

Know the output size before you start, and allocate once.
Prefer copy to a loop when you are moving a run of elements — it is clearer and it is faster.
Never assume a slice parameter is yours to grow, sort or reorder.