Slices

Go has two ordered collections. An array's length is part of its type and can never change; a slice is a growable view onto an array, and it is what you use in almost every program.

Arrays are fixed, slices are views

A slice value is a three-field header: a pointer into a backing array, a length (len, the elements you can see) and a capacity (cap, how many fit before Go must allocate a bigger array). make([]T, length) builds a slice of length zero values; make([]T, length, capacity) also reserves room to grow into.

len of a nil slice is 0, not a panic, and append takes a nil slice happily, so code almost never tests for nil.

Values usually arrive as one string, so you split first. strings.Fields("7 3 9") returns []string{"7", "3", "9"}: it cuts on runs of whitespace, so the doubled space yields no empty entry. strings.Split needs one exact separator and with " " would hand back ["7", "", "3", "9"].

Indexing and slicing

Reading past the end panics: letters[9] stops the program with index out of range [9] with length 5.

Slicing copies no data; it builds a new header over the same memory:

copy(dst, src) moves elements into a slice of your own, so that copy can be changed without touching the original.

Growing with append

Always assign the result back. If the element fits inside the current capacity, append writes in place and returns the same header; if not, it allocates a bigger array, copies everything over, and returns a header pointing at that one. A bare append(queue, "eve") therefore appears to work while spare capacity lasts, then quietly stops working.

Carrying an answer across a loop

range over a slice hands you the index and a copy of the element, as in Loops with for. What matters here is the variable that outlives it:

Declared before the loop, updated inside it, printed once after it. Since p is a copy, assigning to p changes nothing; write through prices[i] to edit the slice.

0 is an honest starting value there: before anything is added, the total is zero. That is not true of every running answer. When the answer has to be one of the elements — the shortest word, the earliest date, the biggest number — an invented start can sit untouched for the whole loop. Trace a running answer that starts at 0 over the elements -3, -1, -7, replacing it whenever an element beats it: what is left at the end, and is that value anywhere in the data?

Common mistakes

• A made-up starting value. A total may start at 0; an answer that must be one of the elements may not. When nothing in the data beats the invented seed, the seed is printed.
• Stopping one element short. for i := 0; i < len(xs)-1; i++ never examines the final element, so an answer sitting at the end is missed.
• Printing inside the loop. One line per element; the grader compares one exact line.
• Printing the slice itself. fmt.Println(xs) writes [4 99 6 7], brackets included — not one value.

Your exercise

Print the largest of the integers on the input line. The starter parses them into a slice named nums and prints a placeholder 0; replacing that placeholder is the whole job. The likeliest slip is a running answer whose starting value never came from the data.